9. Логика семейства методологий Agile. Методологии Scrum и Feature Driven Development.

Agile – семейство подходов к гибкому управлению в игровой, интернет и мобильной сфере, предполагающее ориентацию только на результат.

Гибкий метод является итерационным подходом к проектам, в котором требования и решения изменяются на протяжении сотрудничества клиентов и групп разработчиков. Термин был придуман в 2001 году, когда был составлен «гибкий манифест». Если ваш руководитель беспокоится, что вы наделаете ошибок перед клиентами, данный метод вам не подойдет. Гибкий метод означает, что вы создаете предоставляемые результаты заранее и улучшаете их на протяжении нескольких шагов вместе с клиентом. Однако некоторые заинтересованные лица могут смотреть на это отрицательно.

Плюсы

1. Быстрый запуск, пошаговый выпуск и регулярная критика и отзывы от клиента.

2. Изменение требований со временем.

3. Способность быстро реагировать на изменения.

4. Меньше доработок благодаря непрерывному тестированию и вовлеченности клиента.

5. Связь в реальном времени между группой разработчиков и клиентом.

Минусы

1. Может быть неверно расценен как отсутствие плана или расхлябанность.

2. Требует высококвалифицированной, ориентированной на клиента группы разработчиков.

3. Требует высокого уровня вовлеченности клиента.

4. Отсутствие долгосрочных подробных планов.

5. Производит меньше документации.

Особенности:

1. Управление является всего лишь инструктажем, который помогает избавиться от барьеров на пути к прогрессу

2. Фокус направлен на проект или команду.

3. Гибкие методы обладают большими преимуществами в непонятных и непредсказуемых рынках.

4. Данная модель использует короткие и недлительные обзоры.

5. Гибкие методы процветают в области с низкой ценой ошибок

6. Гибкая методология использует параллельный способ разработки.

Принципы

1. Конечный работающий продукт – главный индикатор эффективности работы команды проекта

2. Минимизация проектной документации

1. ТЗ раньше, теперь Контракт -> Устав проекта (для разработчиков)

2. ТЭО (экономическое обоснование) раньше, теперь БП (бизнес-план)

3. Переход на короткие итерации (максимально частые встречи заказчиков и инвесторов)

4. Использование CSRP как идеологию (вовлечение клиента в процесс производства)

5. Из предыдущего пункта следует максимально оперативная реакция на изменения

6. Изменения приветствуются (команда способна моментально среагировать на любые изменения в создании продукта)

7. Максимально высокая мотивация сотрудников

8. Постоянное повышение квалификации

9. Развитие творческого потенциала

10. Простота и минимизация лишней работы

11. Самоорганизующаяся проектная команда

12. Постоянное техническое совершенствование решений

13. MS Lync -> Skype for Business (замена разговора перепиской)

Проблемы использования Agile

1. Работа в слепую, без планирования

2. Неэффективное управление ресурсами проектной экономики

3. Нет возможности работать в корпоративном сегменте

4. Некачественное управление требованиями

5. Решения Agile редко бывают качественными (соотношение того, что заказчик хотел и того, что заказчик получил)

Согласно Jochen Krebs, автору книги Agile Portfolio Management, существуют три основные метрики, которые предоставляют самые лучше показатели состояния проекта, основанного на гибкой методологии, а именно: прогресс, качество и мотивация группы. Прогресс - это функция, конвертирующая требования в работоспособную версию ПО. Он начинается с плана, который представляет собой прогноз усилий, необходимых для работы над требованиями, и фактическое значение, которое представляет собой реальную работу по разработке. Сравнения планов и усилий позволяют проектной команде модифицировать свои показатели для следующего набора требований и итерации.

Наблюдая за прогрессом проекта, очень полезно будет использовать метод оценки, основываясь на очках, которые являются значениями, присуждаемыми всем документированным требованиям. Данные очки не составляются из рабочего времени или отображают денежные затраты, которые не отражают продуктивность. Вместо этого данная оценка делается согласно результатам команды относительно уровня сложности их работы, а также их собственной оценки личной продуктивности или опыта. После каждой итерации проектные команды изучают свои результаты и баллы и выполняют необходимые модификации по ходу работы к следующей итерации разработки. Прогресс также измеряется в баллах сценариев использования (use-case points), которые измеряют функциональность системы, а также сложность проекта, относящуюся к окружающей среде и технической стороне. Они позволяют спонсорам получить лучшее представление количества ресурсов, которые необходимо предоставить проектной команде, а также договориться и установить контрольные точки проекта. Показатели качества обозначают соответствие с требованиями и больше работают с проблемами благодаря множеству итераций. Ключевым преимуществом гибкой методологии является раскрытие дефектов на ранних стадиях проекта - поэтому, проверка качества предотвращает последующую переработку на протяжении проекта. Управление проектом, основанным на гибкой методологии, в большей степени заключается в управлении людьми. Исследования показали, что в целом мотивация людей напрямую зависит от индивидуальных качеств. Количество личного вклада, который люди привносят в проект, связано с тем, как они могут справляться со стрессом при подходе к следующей итерации и как проблемы сообщаются во время разработки и при переработке. Стрессовая обстановка в команде вызывает трения, что является основной проблемой в случае с аутсорсингом. Чем выше мораль и мотивация, тем эффективнее будут работать члены команды, тем больше трений вы предотвратите и больше производительности будет отражено на качестве товара.

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель (средний спринт 4-6 дней). Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Спринты могут раздаваться по типу аукциона, т.е. команды разработчиков в буквальном смысле уменьшают количество дней на разработку модуля программы

Характеристики Scrum:

1. Минимизация срока исполнения

2. Максимально частые контакты с Product Owner (заказчиком)

3. Максимальная мотивированность Scrum команды на выполнение задачи (на результат)

4. Конкурная раздача спринтов

5. Коллективное принятие решений и помощь

6. Kanban (доска позора)

7. BYod (Bring Your own device) – принеси с собой свое устройство

Основные роли (Core roles) в методологии скрам:

1. Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.

2. Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

3. Команда Разработки (Development Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Дополнительные роли (Ancillary roles) в методологии скрам: