grischenko-proj-management / lectures / lecture-11-conspect

1

Менеджмент проектов программного обеспечения Лекция №11: «Гибкие методологии разработки»

1.Гибкие методологии разработки

Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.

В феврале 2001 в штате Юта США был выпущен Манифест гибкой методологии разработки ПО. Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время. Данный манифест был одобрен и подписан представителями методологий Extreme programming (XP), Crystal Clear, DSDM, Feature-Driven Development, Scrum, Adaptive Software Development, Pragmatic Programming. Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако именно после этого события произошло вхождение Agile-разработки в массы.

Манифест не дает рекомендаций, он только определяет основные принципы гибкого подхода.

1.Самоорганизующаяся команда

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

2.Короткие итерации

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта,

2

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

3.Тесное общение с заказчиком

4.Минимизация документооборота

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.

2.Основные идеи

1.Личности и их взаимодействия важнее, чем процессы и инструменты;

2.Работающее программное обеспечение важнее, чем полная документация;

3.Сотрудничество с заказчиком важнее, чем контрактные обязательства;

4.Реакция на изменения важнее, чем следование плану.

3.Принципы Agile Manifesto

1.удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;

2.приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

3.частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);

4.тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

5.проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

6.рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

7.работающее ПО — лучший измеритель прогресса;

8.спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;

9.постоянное внимание на улучшение технического мастерства и удобный дизайн;

10.простота — искусство НЕ делать лишней работы;

11.лучшие технические требования, дизайн и архитектура получаются у

самоорганизованной команды;

12.постоянная адаптация к изменяющимся обстоятельствам.

4.Основные недостатки

3

5.Основные недостатки

1.Нет плана

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

2.«Потом отрефакторим»

Рефакторинг является стандартным этапом разработки программного

4

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

3.Подталкивает к быстрым решениям

Cчитается, что работа в Agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжелые к воспроизводству дефекты после реального развертывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

4.Много разговоров

6.Гибкие методики

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

2.Kanban

3.Extreme Programming

7.Scrum

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

1.Спринт — итерация в разработке (спринты от 2 до 4 недель).

2.Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или

5

элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.

3.Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

4.Встречи (митинги)

8.Роли в Scrum: Свиньи

Курица говорит свинье: «Давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как мы его назовем?» Курица подумала и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

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

1.Руководитель (ScrumMaster) — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster)

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

3.Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

9.Роли в Scrum: Куры

1.Пользователи (Users)

2.Клиенты, Продавцы (Stakeholders)

3.Эксперты-консультанты (Consulting Experts)

10.Scrum-процесс

6

На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта[7]. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

11.Product backlog: Обязательные поля

1.ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.

2.Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и product owner могли понять, о чем идёт речь и отличить одну историю от другой.

3.Важность (Importance) — степень важности данной истории, по мнению product owner’a. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем

7

выше приоритет.

4.Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».

5.Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.

12.Product backlog: дополнительные поля

1.Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля product owner может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.

2.Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.

3.Инициатор запроса (requestor). Product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.

4.ID в системе учёта дефектов (bug tracking ID) — если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

13.Планирование спринта (Planning Meeting)

1.Происходит в начале итерации.

2.Выбирается объём работ, обязательства по выполнению которой за спринт принимает на себя команда

3.Обсуждается и определяется, каким образом будет реализован этот объём работ

4.Каждая запись в Product Backlog, принятая к реализации, разбивается на подзадачи, которые оцениваются в человеко-часах

5.Ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.

8

14.Митинг (Daily Scrum)

1.Происходит каждый день в течение спринта. Является «пульсом» хода спринта. Митингу присущи следующие ограничения:

2.Начинается точно вовремя;

3.Все могут наблюдать, но только «свиньи» говорят;

4.Длится не более 15 минут;

5.Проводится в одном и том же месте в течение спринта.

15.Вопросы митинга

1.Что сделано с момента предыдущего митинга до текущего?

2.Что будет сделано с момента текущего митинга до следующего?

3.Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает ScrumMaster. Обычно это решение проходит за рамками митинга и в составе лиц, непосредственно затронутых данным препятствием.)

16.Демонстрация (Demo Meeting)

1.Происходит в конце итерации (спринта).

2.Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.

3.Привлекается максимальное количество зрителей.

4.Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).

5.Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

17.Ретроспектива (Retrospective Meeting)

1.Все члены команды рассказывают своё отношение к ходу прошедшего спринта.

2.Отвечают на два основных вопроса (Что было сделано хорошо в прошедшем спринте? Что надо улучшить или не допускать в следующем?).

3.Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

4.Ограничена 1—3-мя часами

Ретроспектива, должна завершаться чётким планом, в который верят все участники.

18.Выводы

1.Гибкие методики решают некоторые проблемы «водопада»

2.Но и привносят свои

3.Существует множество гибких методик. Все они поддерживают Agile Manifesto, но имеют различия в процессах

9

4. Серебряной пули нет!

Список литературы

1.Х. Книберг, М. Скарин. Scrum и Kanban: выжимаем максимум.

2.Гибкая методология разработки. http://ru.wikipedia.org/wiki/Гибкая_методология_разработки

3.Scrum. http://ru.wikipedia.org/wiki/Scrum