Постановка задачи и спецификация программы. Vмодель жизненного цикла. Модель быстрого прототипирования. Agileметодологии

• Название: Постановка задачи и спецификация программы. Vмодель жизненного цикла. Модель быстрого прототипирования. Agileметодологии
• Дата: 23.01.2023
• Размер: 45.86 Kb.
• Имя файла: TEXT_Doklada_agile.docx
• Тип: Доклад; #900630

Доклад на тему

«Постановка задачи и спецификация программы. V-модель жизненного цикла. Модель быстрого прототипирования. Agile-методологии»

Москва, 2022 г.

1 Постановка задачи и спецификация программы

(2 слайд).

Если коротко, то основные этапы разработки требований — это:

1. 
   Зачем нам что-то делать?
   
2. 
   Что мы будем делать?
   
3. 
   Как мы это сделаем
   
4. 
   Когда мы это сделаем? 
   

Если вы когда-либо просили что-то сделать — значит вы создавали требования. Они могли быть в форме устного пожелания, письма, технического задания, таски или чего угодно.

(3 слайд).

В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь.
1.1 Цель.

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.

Цель достигается разными путями.

Например, можно воспользоваться методом “Пяти почему” или любым другим. (4 слайд).

Название метода – 5 Почему (Five Whys) происходит от количества задаваемых вопросов. Для того чтобы найти причину несоответствия необходимо последовательно задавать один и тот же вопрос – «Почему это произошло?», и искать ответ на этот вопрос. Число пять выбрано исходя из того, что такого количества обычно достаточно для выявления сути и источника проблемы. Но, несмотря на то что метод называется 5 почему для поиска причин каждого конкретного несоответствия может задаваться как меньшее, так и большее количество вопросов.
1.2 Зачем нам что-то делать?

(5 слайд).

И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели. Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.

У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
1.3 Как мы это сделаем?

(6 слайд)

Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.

Этот этап — дело техники. И если мы успешно прошли предыдущие два — будет гораздо проще.

Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса или аналогичному. Если для вас какой-то тип требований сейчас не актуален, тогда не описываем. Но важно не забыть и проверять себя.

На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.

Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.

Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
1.4 Документирование

(7 слайд)

В ваших требованиях скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно все документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Слабый уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии.

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

Далее можно уже распределять по спринтам/этапам разработки и внедрения. Необходимо повторять данные в рамках каждой итерации.

Конечно, проблемы будут всегда. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
2 V-модель 

(8 слайд)

V-модель — это тип модели, в которой процесс выполняется последовательно в V-образной форме. Модель основана на объединении фазы тестирования с каждой соответствующей стадией разработки. Разработка каждого шага напрямую связана с этапом тестирования. Следующая фаза начинается только после завершения предыдущей. Каждый этап разработки, напрямую связан с тестированием этого этапа.
2.1 Принципы V-модели:

(9 слайд)

• 
  От большого к малому: в V-модели тестирование выполняется в иерархической перспективе, например, требования, определенные командой проекта, создают этапы проекта высокого уровня и детального проектирования. По мере того, как каждый из этих этапов завершается, требования, которые определяются, становятся все более и более уточненными и подробными.
  
• 
  Целостность данных / процессов: этот принцип гласит, что успешное проектирование любого проекта требует интеграции и согласованности как данных, так и процессов. Элементы процесса должны быть идентифицированы для каждого требования.
  
• 
  Масштабируемость: этот принцип гласит, что концепция V-Model обладает гибкостью, позволяющей приспособить любой ИТ-проект независимо от его размера, сложности или продолжительности.
  
• 
  Перекрестные ссылки: прямая корреляция между требованиями и соответствующей деятельностью по тестированию называется перекрестными ссылками.
  
• 
  Материальная документация: этот принцип гласит, что каждый проект должен создавать документ. Эта документация требуется и применяется как группой разработки проекта, так и группой поддержки. Документация используется для поддержки приложения, когда оно становится доступным в производственной среде.
  

2.2 Этап проектирования V-модели:

(10 слайд)

• 
  Анализ требований — этап включает общение с заказчиком с целью выделить его требования и ожидания от проекта. Другое название этого этапа — сбор требований.
  
• 
  Проектирование системы — этап включает проектирование системы и настройку оборудования и коммуникаций для разработки продукта.
  
• 
  Архитектурный дизайн — системный дизайн, разбивка на модули, выполняющие различные функции. Передача данных и связь между внутренними модулями и с другими системами.
  
• 
  Разработка модулей- система разбивает на небольшие модули. Определяется детальный дизайн модулей, также известный как Low-Level Design (LLD).
  

2.3 Этапы тестирования V-модели:

(11 слайд)

• 
  Модульное тестирование — модульного тестирования разрабатываются на этапе проектирования модуля. Эти планы модульного тестирования выполняются для устранения ошибок на уровне кода или модуля.
  
• 
  Интеграционное тестирование — после завершения модульного тестирования выполняется интеграционное тестирование. При интеграционном тестировании модули интегрируются, и система тестируется. Интеграционное тестирование выполняется на этапе проектирования архитектуры. Этот тест проверяет связь модулей между собой.
  
• 
  Системное тестирование — тестирование тестирует все приложение с его функциональностью, взаимозависимостью и связью. Оно проверяет функциональные и нефункциональные требования разработанного приложения.
  
• 
  Приемочное пользовательское тестирование (UAT – User Acceptance Testing) – тестирование, которое проводится конечными пользователями системы с целью принятия решения о внедрении.
  

2.4 Преимущества V-образной модели

(12 слайд).

• 
  В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки;
  
• 
  В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;
  
• 
  В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО – перед разработкой компонентов;
  
• 
  Модель определяет продукты, которые должны быть получены в результате про­цесса разработки;
  
• 
  Благодаря модели менеджеры проекта может отслеживать ход процесса разработ­ки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой;
  
• 
  Модель проста в использовании.
  

2.5 Недостатки V-образной модели

(13 слайд)

• 
  С ее помощью непросто справиться с параллельными событиями;
  
• 
  В ней не учтены итерации между фазами;
  
• 
  В модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла;
  
• 
  Тестирование требований в жизненном цикле происходит слишком поздно, вслед­ствие чего невозможно внести изменения, не повлияв при этом на график выпол­нения проекта;
  
• 
  В модель не входят действия, направленные на анализ рисков.
  

2.6 Область применения V-образной модели

(14 слайд).

• 
  V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее.
  
• 
  Использование модели эффективно в том случае, когда доступными являются ин­формация о методе реализации решения и технология, а персонал владеет необходи­мыми умениями и опытом в работе с данной технологией.
  
• 
  V-образная модель – это отличный выбор для систем, в которых требуется высокая надежность.
  

3 Модель быстрого прототипирование

Самой тяжелой составляющей процесса построения программной системы является принятие однозначного решения о том, что именно необходимо построить. Ни одна из остальных составляющих работы над концепцией не представляет собой такую трудность, как определение детальных технических требований, включая все аспекты соприкосновения продукта с людьми, машинами и другими программными системами. Ни одна другая составляющая работы в такой степени не наносит ущерб полученной в результате системе, если она выполнена неправильно. Именно эту составляющую процесса разработки тяжелее всего исправить на более поздних этапах.

Следовательно, самая важная функция, которую выполняет разработчик клиентских программ, заключается в итеративном извлечении и уточнении требований к продукту. Ведь на самом деле клиент не имеет представления о том, что именно он хочет получить.

На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы разработки ПО, является разработка методов и средств для ускоренного прототипирования систем как составляющей итеративной спецификации требовании
3.1 Этапы прототипирования

(16 слайд)

• 
  Планирование проекта— результат: документ, описывающий в общих чертах примерные графики и результативные данные.
  
• 
  Быстрый анализ: предварительные опросы пользователей используются для разработки умышленно неполной высокоуровневой модели системы на уровне документации. Результат: документ, содержащий частичную спецификацию требований, который используется для построения исходного прототипа, создаваемого на последующих трех этапах.
  
• 
  Дизайнер конструирует модель (используя для этого инструментальные средства), то есть частичное представление системы, которое включает в себя только те базовые свойства, которые необходимы для удовлетворения требований заказчика.
  
• 
  Затем начинается итерационный цикл быстрого прототипирования.
  
  • 
    Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование.
    
  • 
    После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер.
    
  • 
    Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования.
    
  • 
    Создание базы данных представляет собой первую из этих двух фаз.
    
  • 
    После создания исходной базы данных можно начать разработку меню, после чего следует разработка функций, то есть создается рабочая модель.
    
• 
  Затем модель демонстрируют пользователю с целью получения предложений по ее усовершенствованию, которые объединяются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной.
  
• 
  Затем получают официальное одобрение пользователем функциональных возможностей прототипа. После этого создается документ предварительного проекта системы.
  
• 
  Основным компонентом является фаза итерации прототипа, на протяжении которого при использовании сценариев, предоставленных рабочей моделью, пользователь может разыграть роли и потребовать, чтобы последовательное уточнение моделипродолжалось до тех пор, пока не будут удовлетворены все функциональных требования.
  
• 
  Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование.Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования.
  
• 
  При разработке производственной версии программы, может понадобиться:
  
  • 
    более высокий уровень функциональных возможностей,
    
  • 
    различные системные ресурсы,
    
  • 
    необходимых для обеспечения полной рабочей нагрузки,
    
  • 
    ограничения во времени.
    
  • 
    После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.
    
  • 
    Заключительная фаза представляет собой функционирование и сопровождение, которые отображают действия, направленные на перемещение системы в стадию производственного процесса.
    

3.2 Преимущество Модели быстрого прототипирования

(17 слайд).

• 
  Взаимодействие заказчика с системой начинается на раннем этапе разработки;
  
• 
  Демонстрации разрабатываемого продукта сводит к минимуму количество неточностей в требованиях;
  
• 
  В процесс разработки можно внести новые или неожиданные требования пользователя;
  
• 
  Модель представляет собой формальную спецификацию, воплощенную в рабочую модель.
  
• 
  Модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла;
  
• 
  При использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно; (18 слайд)
  
• 
  Ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки;
  
• 
  Возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей;
  
• 
  Благодаря меньшему объему доработок уменьшаются затраты на разработку;
  
• 
  Обеспечивается управление рисками;
  
• 
  Документация сконцентрирована на конечном продукте, а не на его разработке;
  

3.3 Недостатки модели быстрого прототипирования

(19 слайд)

• 
  Модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе;
  
• 
  С учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания.
  
• 
  Иногда в результате использования модели получают систему с низкой рабочей характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
  
• 
   При использовании модели решение трудных проблем может отодвигаться на будущее.
  
• 
  На итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система;
  
• 
  Несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса;
  
• 
  Заказчик может предпочесть получить прототип, вместо того, чтобы ждать появления полной, хорошо продуманной версии; (20 слайд)
  
• 
  Если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;
  
• 
  Прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл "кодирование — устранение ошибок" (code-and-fix cycle)
  
• 
  Разработчики и пользователи не всегда понимают, что когда прототип превращается в конечный продукт, все еще существует необходимость в традиционной документации, когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу.;
  
• 
  На заказчиков может оказать негативное влияние тот факт, что они не располагают информацией о точном количестве итераций, которые будут необходимы;
  
• 
   На разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом;
  
• 
  Структурные методы не используются, чтобы не помещать выполнению анализа.
  

3.4 Область применения

(21 слайд)

1. 
   Требования к программному продукту заранее неизвестны;
   
2. 
   Требования не постоянны или неудачно сформулированы;
   
3. 
   Требования необходимо уточнить;
   
4. 
   Нужна проверка концепции;
   
5. 
   Существует потребность в пользовательском интерфейсе;
   
6. 
   Выполняется новая, не имеющая аналогов разработка;
   
7. 
   Разработчики не уверены в том, какое решение следует выбрать.
   

4. Agile методологии

(22 слайд)

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с гибкими методологиями, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях.

Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

Например, в гибкую методологию XP (экстремальное программирование) входят такие приемы как парное программирование и игра в планирование, которые указывают вполне конкретные алгоритмы действий.

И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.

Следование этим ценностям повышает скорость разработки и бизнес-эффект от разрабатываемых продуктов. При этом стоимость разработки может увеличиваться, поэтому Agile нужен не всегда.

4.1 Ценности Agile

(23 слайд)

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. 
   люди,
   
2. 
   работающий продукт,
   
3. 
   сотрудничество с заказчиком,
   
4. 
   готовность к изменениям.
   

4.2 Люди и их взаимодействие важнее процессов и инструментов

(24 слайд)

Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более программный инструмент не диктует, что людям делать. Более того, они сами решают, как менять процессы/инструменты своей работы.

Чтобы ускорить процесс разработки, люди также должны взаимодействовать напрямую (без посредников в виде документов или других людей), активно общаться между собой лично, а не письменно. Правда, в современном бизнесе общение часто вынуждено переходить в онлайн. Но тогда это должна быть видеосвязь с интерактивными онлайн-досками, а не только письма и чаты.

4.3 Работающий продукт важнее исчерпывающей документации

(25 слайд)

Чтобы клиенты были довольны,им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.

Чтобы укладываться в сжатые сроки с минимумом затрат, зачастую не стоит связывать себя документацией. Поддержка документации в адекватном продукту состоянии нередко замедляет разработку и требует неоправданно больших затрат.

4.4 Сотрудничество с заказчиком важнее согласований условий контракта

(26 слайд)

Чтобы на выходе получить продукт, действительно ценный для заказчика, стоит отказаться от излишних деталей в контракте между подрядчиком и заказчиком (равно как и в требованиях внутреннего заказчика к внутреннему разработчику продукта). Будучи жестко заданы на старте, детали контракта мешают учитывать новые данные и приоритеты, появляющиеся лишь во время разработки.

Чтобы бизнес-ценность продукта быстро росла, заказчик с разработчиком должны плотно общаться по ходу работы. В этом случае все возникающие изменения и проблемы оперативно обрабатываются обеими сторонами. А чтобы такое сотрудничество исполнителя и заказчика стало возможным, нужно выстраивать их доверие друг к другу.

4.5 Готовность к изменениям важнее, чем следование плану

(27 слайд)

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

Чтобы в первую очередь делалось самое ценное, текущее видение бизнес-ценности и позиционирования продукта должно быть прозрачно для разработчиков, а процесс их работы должен позволять вносить существенные изменения в прежние планы. В том числе, разработчики должны быть готовы добавлять в продукт незапланированные новые возможности, если они стали ценными в изменившейся ситуации.

Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.
4.6 Agile сложнее, чем 4 ценности

(28 слайд)

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов которые уточняют и дополняют ценности.

1. 
   Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения
   Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.
   
2. 
   Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения конкурентного преимущества заказчика
   В этом их преимущество перед традиционными командами, которым обычно не так легко управлять изменениями.
   
3. 
   Работающий продукт следует выпускать как можно чаще, с периодичностью от двух недель до двух месяцев
   Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.
   
4. 
   На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе
   Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.
   
5. 
   Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте им условия, обеспечьте поддержку — и полностью им доверьтесь
   Agile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.
   
6. 
   Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды
   Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.
   
7. 
   Работающий продукт — основной показатель прогресса
   Смысл принципа, который называет работающий продукт основным показателем прогресса, в том, что главная цель команды всегда остается одна — предоставить клиенту как можно более высококачественный результат. Когда клиент доволен, это и есть главный показатель успеха проекта.
   
8. 
   Agile помогает наладить устойчивый процесс разработки. Инвесторы, разработчики и пользователи должны иметь возможность бесконечно поддерживать постоянный ритм Многие команды поначалу показывают бурный прогресс, который не получается сохранить до конца проекта.
   
9. 
   Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта
   Agile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.
   
10. 
    Простота как искусство сократить до минимума лишнюю работу крайне необходима
    Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.
    
11. 
    Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд
    Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микроменеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микроменеджмента.
    
12. 
    Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
    Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться бо́льшего.
    

4.7 Кратко о том, что входит в Agile сегодня

(29 слайд)

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

Scrum — это набор правил для организации гибкого рабочего процесса, который заключается в командном подходе, работе итерациями, фокусировке на цели каждой итерации и нестандартном распределении обязанностей внутри коллектива. Метод пришёл из мира IT-разработки, а сейчас применяется в разных сферах бизнеса.

При работе по Scrum создают универсальные продуктовые команды, которые состоят из дизайнеров, маркетологов, разработчиков. Исчезает потребность взаимодействия между отделами — все, кто необходим в работе, находятся в составе команды.

Помимо того, обязательно присутствуют владелец продукта (фокусируется на ценности продукта, решает, что делать в первую очередь) и scrum-мастер (фокусируется на эффективности работы команды, помогает команде улучшать рабочие процессы и решать внешние проблемы). Никто из них не диктует разработчикам, как именно работать. Scrum образуют самоорганизующуюся команду.

Работа по Scrum строится на «спринтах» — это периоды продолжительностью от 7 до 30 дней, всё зависит от состава команды и проекта. На каждый спринт формируют свою цель, по которой и подводят результаты. Следующий спринт начинается после завершения предыдущего независимо от его результатов — если, конечно, спонсор не принимает решение о завершении работы над продуктом.

В Scrum-командах есть следующие роли:

(30 слайд)

1. 
   Владелец продукта. Несёт ответственность за максимизацию ценности продукта. Этот человек точно знает, что необходимо реализовать в первую очередь.
   
2. 
   Scrum-мастер. Его задача — организовать в команде работу в соответствии с руководством по Scrum и чтобы никто не мешал команде самостоятельно и комфортно решать поставленные задачи.
   
3. 
   Developers. Группа людей, обладающих всеми знаниями и навыками, необходимыми для достижения цели. Они определяют, как именно достигать цели, отвечают за качество продукта и ежедневную адаптацию плана внутри спринта.
   

Владелец продукта, Scrum-мастер и Developers составляют одну общую команду. В руководстве по Scrum 2020 года не выделяется отдельно команда разработки. Команда состоит из 5–9 человек — если людей будет больше, это усложнит взаимодействие между звеньями, а это негативно скажется на эффективности работы.

Рассмотрим некоторые примеры отличия Канбана от Скрама.

(31 слайд)

1. 
   имеет более широкую область применения (не только новые продукты, но и поддержка);
   
2. 
   в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
   
3. 
   нацелен не только на ускорение, но и на равномерность процессов;
   
4. 
   имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
   
5. 
   отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).
   

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу».

Впервые концепцию kanban-доски разработала и внедрила на своих заводах компания Toyota. Визуальная система управления задачами помогла менеджерам быстро повысить эффективность организации производственного процесса и снабжения. Позже методология нашла широкое применение в других секторах: финансах, маркетинге, IT-индустрии.

Сейчас системы канбан используются в разных областях, от развития продуктов до запуска космических аппаратов. Масштаб проекта не имеет значения: канбан-доску применяют как для управления личными делами, так и для реализации крупных корпоративных задач.