Введение в методы agile

1

1. Введение в методы Agile

Технологии разработки программного обеспечения

() Владислав Лавров, vlavrov.com

2

Библиография

Книга:Agile! Прекрасный, ужасный, шумный / Бертран Мейер; пер. с англ. и ред. В. Биллига. - Москва Тверь : НАУ "ИНТУИТ" - ЗАО НИИ ЦПС, 2015. - 248 с.

Один из ведущих ученых в области инженерии программного обеспечения Computer Science и Software Engineering

Бертран Мейер

Электронный курс:Анализ и оценка методов разработки программного обеспечения (Agile)http://www.intuit.ru/studies/courses/3505/747/info


http://www.intuit.ru/studies/courses/3505/747/info

http://www.intuit.ru/studies/courses/3505/747/info

3

Agile software development, agile-методы

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

– серия подходов к разработке программного обеспечения,

ориентированных на использование интерактивной

разработки, динамическое формирование требований и

обеспечение их реализации в результате постоянного

взаимодействия внутри самоорганизующихся рабочих групп,

состоящих из специалистов различного профиля

Что такое Agile?


4

Манифест создателей Agile (2001)

• люди и взаимодействие важнее процессов и

инструментов;

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

документации;

• сотрудничество с заказчиком важнее согласования

условий контракта;

• готовность к изменениям важнее следования

первоначальному плану;


5

1. Переопределение ролей разработчиков, менеджеров и потребителей.

2. Отказ от «Предваряющего анализа» (Big Upfront) – начальных этапов разработки.

3. Итеративная разработка.

4. Ограниченная функциональность, основанная на договоренностях.

5. Фокусирование на качестве, достижимом в процессе тестирования.

1.1. Предпосылки (доктрины) Agile


6

1.2. Принципы Agile

Организационные принципы:

1. Поставить клиента в центр.

2. Разрешать самоорганизацию команды.

3. Сохранять устойчивый темп разработки.

4. Разрабатывать минимально необходимое ПО:

• создавать минимальную функциональность.

• создавать только запрашиваемый продукт.

• разрабатывать только код и тесты.

5. Допускать изменения.


7

Технические принципы:

6. Вести разработку итеративно:

• выполнять частые рабочие итерации.

• замораживать требования на время итерации.

7. Рассматривать тесты как ключевой ресурс:

• никакую новую разработку не начинать, пока не

пройдут все тесты.

• вначале тесты.

8. Выражать требования через сценарии.

Принципы Agile (продолжение)


8

Принцип 1. «Поставить клиента в центр»

• Разработка является ориентированной на

потребителя.

• Цель разработки – поставка потребителю

продукта с наилучшим ROI (Return On

Investment, «Возврат Инвестиций»).

• Представители потребителей должны

включаться в проект, их роль одна из важных

ролей в команде разработчиков


9

Принцип 2. «Разрешать самоорганизацию команды»

• Команда является самоорганизующейся.

• Решение зависит от специфики решаемых задач.

• Ограничение прав менеджера проекта.


10

Принцип 3. «Сохранять устойчивый темп разработки»

• Развитие проекта идет устойчивым темпом.

• Благодаря жесткому графику отсутствуют

так называемые "смертельные марши",

когда для выдержки контрольного срока

начинается авральная работа днем и ночью.

• "Устойчивость" требует, чтобы работе

отводилось разумное время, сохраняя

вечера и уикэнды для отдыха.


11

Принцип 4. «Разрабатывать минимально необходимое ПО»

• создаются только основные функции

(минимальная функциональность);

• строится только то, что запрашивается, исключая работы для

будущего повторного использования и расширений (минимальный

продукт);

• создаются только два вида продуктов – программы и тесты,

исключая все, что не поставляется потребителю, и избавляясь тем

самым от излишних трат (минимальные артефакты)


12

Принцип 5. «Допускать изменения»

• Разработка должна допускать изменения.

• Все требования не могут быть определены в начале

разработки. Потребности выявляются в процессе

разработки.

• В ходе испытаний промежуточных версий как у

потребителей, так и у самих разработчиков возникает

понимание необходимости новых свойств или изменения

существующих свойств системы. Такие изменения

рассматриваются как нормальная часть процесса

разработки.() Владислав Лавров, vlavrov.com

13

Принцип 6. «Вести разработку итеративно»

• разработка представляет итеративный процесс, состоящий из

последовательного выполнения итераций.

• Каждая итерация (спринт) совершенно короткая – несколько

недель, ее результатом является рабочий релиз системы,

возможно, носящий довольно частный характер.

• Представители пользователей могут провести испытания,

результат которых может стать источником новых идей для

следующей итерации() Владислав Лавров, vlavrov.com

14

Принцип 7. «Рассматривать тесты как ключевой ресурс»

• Никакая новая разработка не может начаться, пока не

пройдут все тесты.

• Вначале тесты. Никакой код не может быть написан до

того, как для него не созданы тесты.

• Тесты представляют замену спецификаций и требований.


15

Принцип 8. «Выражать требования через сценарии»

• Сценарий представляет описание варианта взаимодействия

пользователя с системой


16

• Менеджер проекта (разработки) (Manager);

• Команда (Team);

• Владелец продукта (Product owner);

• Scrum-мастер (Scrum Master);

• Потребитель (Customer – заказчик, пользователь).

1.3. Роли в Agile

Ключевые agile роли:


17

• назначать задачи;

• принимать решение, какие функции следует реализовать;

• распределять работы между членами команды;

• запрашивать отчеты о выполненных работах.

Роли в Agile. Менеджер проекта (разработки)

В классическом Agile-методе

менеджеры НЕ должны:


18

• обеспечение окружения, позволяющего

команде работать успешно;

• организация «гладкого» взаимодействия с

остальной частью организации: в этой роли

менеджер представляет команду для высшего

руководства и других подразделений;

• управление ресурсами, включая поставщиков

и партнеров по аутсорсингу.

Роли в Agile. Менеджер проекта (разработки) (продолжение)

Задачи:


19

• Команда – это не группа людей, управляемых менеджером, а

самоорганизуемая группа, наделенная правами. Главное для

самоорганизуемой команды – решить, что делать следующим.

• Ключевое достоинство состоит в способности быстрой

адаптации к новым обстоятельствам.

• Рекомендуется иметь кросcфункциональную команду, в

которой любой разработчик должен быть способен подойти к

списку задач, взять и реализовать следующую задачу.

Роли в Agile. Команда (Team)


20

• Представляет организацию заказчика.

• Важнейшая обязанность – определение функциональности.

• Владелец является лицом продукта, продвигает решения, за ним

остается последнее слово в этих решениях.

• На владельце продукта лежит ответственность за определение и

сопровождение журнала заказов (бэклога) продукта – списка

заказанных функций

Роли в Agile. Владелец продукта (Product owner)


21

• Одна из первостепенных задач мастера –

устранять препятствия, указанные членами

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

любого типа, технические и организационные, все,

что мешает команде работать в полную силу

(реализовать столь много пользовательских

историй, насколько это возможно).

• Защита команды от внешних раздражителей, от

администрации и других подразделений компании

Роли в Agile. Scrum-мастер (Scrum Master)


22

Роли в Agile. Потребитель (Customer)

• Методы agile ставят потребителя в центр, в некоторых

случаях включают его в члены команды.

• Потребитель обеспечивает требования, устанавливает

приоритеты и направляет проект.

• Уровень пользовательского включения может быть разным.


23

1.4. Практики в Agile


Организационные практики:

1) Спринт (Sprint).

2) Ежедневные встречи (Daily meeting).

3) Игра в планирование, планирующий покер (Planning game, planning poker).

4) Непрерывная интеграция (Continuous integration).

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

6) Разделяемое владение кодом (Shared code ownership).

24

Практики в Agile (продолжение)


Технические практики:

7) Тест-управляемая разработка (Test driven development).

8) Рефакторинг (Refactoring).

9) Парное программирование (Pair programming).

10) Простейшее решение, которое только может работать (Simplest solution that can possibly work).

11) Стандарты кодирования (Coding standards).

25

1.5. Артефакты в Agile


Виртуальные

1) Варианты использования (Use case, user story).

2) График ликвидации (Burndown chart).

Материальные

3) Карты историй (Story card).

4) Панель историй (Story board).

5) Открытая комната (Open room).

26

График ликвидации нереализованных задач в Agile. Убывающая диаграмма выполнения


Отставание от графика

Опережение графика

«Идеальный» ритм выполнения задач

27

Карта историй в Agile


28

Панель задач, отражающая динамику развития проекта


Введение в методы agile

Education