Лекция 10. Технологии SCRUM и RAD

1. Лекция 10. Технологии SCRUM и RAD

Вопросы лекции:
Вопрос 1. Технология SCRUM
Вопрос 2. Технология RAD
1

2. Scrum

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

3. Scrum. Терминология

Владелец продукта (Product owner) – это тот человек,
который непосредственно заинтересован в качественном
конечном продукте. Он имеет четкое представление о том,
как должен выглядеть продукт и какие шаги должны быть
предприняты для реализации проекта по разработке
продукта. Он распределяет задачи для команды и работает
с ней, но сам находиться на стороне заказчика.
Scrum-мастер (Scrum master) – руководитель проекта.
Руководит разработкой и следит за соблюдением принципов
Scrum.
Scrum-команда (team)– команда разработчиков ПО,
которые знают и понимают принципы Scrum.
3
3

4. Scrum. Терминология

Спринт – временной отрезок, выбранный для
выполнения определенного количества работ.
Рекомендованное время – 2-4 недели, но все
определяется индивидуально командой и один раз.
Бэклог (backlog) – полный перечень всех работ, которые
необходимо выполнить.
Бэклог делится на два вида.
4
4

5. Scrum. Терминология

Product-бэклог – это список всех требований и
соответствующих работ, которые нужно сделать по
проекту, которые непосредственно приведут команду к
конечной цели.
Когда в Backlog’e нет требований, проект считается
завершенным.
Все требования описаны по единому шаблону, который
называют User Story (пользовательская история).
Требования составлены так, что очевидно и понятно,
какую ценность они представляют для пользователя
Требования отсортированы по приоритетам, которые
пересматриваются каждый спринт.
5
5

6. Scrum. Терминология

Спринт-бэклог (Sprint Backlog) – те требования и
соответствующие работы из product-бэклога, которые
команда определила и согласовала с владельцем
продукта на ближайший спринт, а также установила
конкретные временные рамки.
В течение спринта, новые требования не могут
появится в Sprint backlog.
Все требования должны быть разделены на задачи и
оценены. Задачи, должны быть представлены на
Kanban-доске.
Sprint Backlog – это обязательство команды: что они
должны выполнить за время спринта.
6
6

7. Scrum. Терминология

Канбан-доска должна состоять как минимум из трех колонок:
«сделать» (to-do), «в процессе» (in progress), «сделано»(done).
При разработке по SCRUM канбан-доска может включать следующие
колонки в соответствии со статусом задач: обсуждается (backlog),
согласовано (ready), кодируется (coding), тестируется (testing),
подтверждается (approval) и сделано (done). На доску в
соответствующий столбец прикрепляются канбан-карточки
7
7

8. Scrum. Терминология

Цель спринта (Sprint Goal) - это краткое описание того,
ради чего выполняется данный спринт. Цель спринта
помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда
проекта могла самостоятельно принимать решение в
случае появления альтернативных путей решения задачи.
Чтобы решения команды были осознанными, владелец
продукта определяет цель спринта.
Диаграмма сгорания (Sprint Burndown Chart).
Показывает прогресс насколько команда продвинулась
вперед. В качестве “сгорающих” элементов выступают
человеко-часы или идеальные единицы (Story Points).
Диаграмма обновляется каждый раз, когда завершается
какая-либо задача.
8
8

9. Scrum. Терминология

9
9

10. Scrum. Процессы

Планирование спринта (Sprint Planning Meeting) –
совещание всей Scrum-команды, владельца продукта и
Scrum-мастера.
Владелец продукта определяет цель спринта и конечные
задачи, которые должны быть выполнены по истечению
срока спринта;
Команда выбирает требования из Product Backlog и
формирует Sprint Backlog;
Команда декомпозирует требования на задачи (tasks);
Каждая задача проходит оценку в трудозатратах или
универсальных единицах по методу Planning Poker;
Итоговый список задач утверждается всеми участниками и
не может быть изменен в течение спринта;
Во время встречи Владелец продукта отвечает на вопросы
команды.
10
10

11. Scrum. Процессы

Ежедневная встреча команды (Daily Meeting):
проходит ежедневно и только в одно и то же время;
встреча проходит только стоя;
поэтому длительность встречи не более 15 минут;
чтобы успеть каждый должен ответить всего на 3 вопроса:
что я делал вчера, чем я занимаюсь сегодня, какие есть
проблемы?
На ежедневной встрече команда обменивается опытом. Также
становится понятно, кто и над какими задачами будет сегодня
трудиться. Важно, чтобы команда делала это самостоятельно.
Scrum Master следит за ходом встречи, побуждает участников
высказываться полностью и слушать говорящего.
Встречу команды эффективно проводить напротив Kanban
доски, на которой отражены все задачи спринта.
11
11

12. Scrum. Процессы

Cдача спринта владельцу продукта (Product Owner
Sprint Review)
По завершению каждого спринта команда обязана
провести демонстрацию полученного результата.
Ценность Scrum для обычного заказчика во многом
состоит в том, что результат работ (плохой или хороший)
будет продемонстрирован в любом случае. Это знает и
команда и владелец продукта и другие заинтересованные
лица. Если команда не проводит демонстрацию (иное
название Sprint Review), то это дискредитирует все
преимущества гибких процессов.
12
12

13. Scrum. Процессы

Повестка встречи Sprint Review:
команда зачитывает требования из Sprint Backlog;
по каждому критерию приемки происходит
демонстрация полученных результатов;
каждый вопрос со стороны владельца продукта
записывается, чтобы иметь возможность ответить на
них позже;
каждое новое требование владельца продукта
выписывается, чтобы позже включить его в Product
Backlog.
На встрече могут присутствовать любые сотрудники
организации или просто заинтересованные лица, но
право голоса должны иметь только участники Scrum
процесса (Produt Owner, Team, Scrum Master).
13
13

14. Scrum. Процессы

Ретроспективное совещание (Retrospective)
Необходимо для обмена опытом внутри команды.
Совещание проводится после Sprint Review.
На совещании присутствует вся команда и Scrum Master
(Владелец продукта присутствует, если считает нужным).
Методика проведения встречи варьируется в зависимости
от проекта, его команды и просто традиций в коллективе.
14
14

15. Scrum. Процессы

В любом случае, должны быть озвучены ответы на
следующие вопросы:
1. Какие решения должна принять команда, чтобы
сделать процесс более предсказуемым?
2. Какие проблемы мешают команде выполнять взятые
на себя обязательства?
3. Как улучшить взаимодействие с Владелецом
продукта?
4. Какие ошибки совершает команда и почему.
Решения должны быть записаны на отдельной доске.
После всеобщего голосования решения принимаются к
исполнению со следующего спринта. Scrum Master
контролирует ход встречи и следит за её регламентом.
15
15

16. Scrum. Процессы

Груминг беклога (Grooming)
Беклог продкута отправляется в «парикмахерскую» для
того, чтобы команда и владелец продукта могли:
1. Добавить, убрать или разбить элементы беклога
продукта.
2. Уточнить или дать новые оценки.
3. Изменить порядок следования элементов беклога
продукта.
4. Обсудить и прояснить требования.
16
16

17. Scrum

17
17

18.

Модель быстрой разработки приложений
RAD
RAD (Rapid Application Development)
относится к итерационной стратегии.
модель
В
RAD-модели
компоненты
или
функции
разрабатываются
параллельно
несколькими
высококвалифицированными
командами,
будто
несколько мини-проектов. Временные рамки одного
цикла жестко ограничены. Созданные модули затем
интегрируются в один рабочий прототип.
18
18

19.

Идея RAD (Rapid application development—
быстрая разработка приложений) зародилась
в 1980-х годах как альтернатива устаревшей
методологии Waterfall. Каскадная модель
программирования уже тогда воспринималась
как перегруженная формальностями и
недостаточно гибкая.
19

20.

Заказчик выдавал разработчику техническое задание
и не видел результата до тех пор, пока программа не
«сходила с конвейера» уже готовой, — и ожидания
пользователя зачастую не оправдывались
Продукт мог оказаться слишком сложным,
неудобным, а мог и устареть за время разработки. В
каскадной модели на ранних этапах работы
проводится тщательное планирование, но это не
помогает предусмотреть все риски и сложности.
Поэтому проект дорожает, а время — уходит
впустую.
20

21.

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

22. Что предлагает RAD

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

23.

Модель быстрой разработки приложений RAD
Условия, позволяющие создать систему за 60 - 90 дней,
причем без ущерба качеству, включают в себя:
1. Полностью определенные требования;
2. Обязательность вовлечения пользователей в процесс разраб
отки;
3. Ограниченность
проектной
области,
возможность
декомпозиции будущего ПО на отдельные модули;
4. Высокий уровень фактора повторного использования
компонент использование мощных инструментальных
средств разработки;
5. Тестирование и развитие проекта, осуществляется одноврем
енно с разработкой;
6. Команде, работающей над проектом, знакома предметная
область, и она обладает достаточными навыками в
использовании средств разработки и имеет высокую степень
мотивации при выполнении данного проекта.
23
23

24.

Модель быстрой разработки приложений RAD
7. Модель применима для относительно небольших
проектов, разрабатываемых под конкретного
заказчика;
8. Неприменима для построения сложных расчетных
программ, требующих написания большого объема
уникального кода;
9. Неприменима для разработки приложений, от которых
зависит безопасность людей, так как итеративный
подход предполагает, что первые несколько версий,
скорее всего не будут полностью работоспособны, что
в данном случае исключается.
24
24

25.

Изначально программист создает приложение в черновом варианте.
Это могут быть наброски интерфейса и несколько пунктов меню. Если
заказчика устраивает первый прототип, программа дорабатывается:
добавляются новые элементы интерфейса, функциональность. С
каждой итерацией приложение обрастает возможностями, и
пользователь постоянно уточняет требования и задает вектор
развития.
25

26.

Методологию быстрой разработки RAD
можно сравнить с работой художника.
Сначала живописец делает эскиз. Потом
создает черновой вариант картины. Затем он
начинает прорабатывать элементы,
добавляет детали, исправляет недочеты.
Разумеется, не каждый заказчик способен по
первому наброску представить себе
конечный продукт. Куда проще внести
исправления в эскиз, чем в завершенное
полотно.
26

27.

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

28.

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

29. Этапы разработки приложения по методологии RAD

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

30.

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

31.

Затем в дело вступают программисты. С
помощью инструментов CASE они
воплощают требования в виде модели,
создавая очередной прототип. Его
показывают пользователю и получают
обратную связь. Уточняя пожелания и
требования к программе, заказчик
фактически руководит разработкой.
Как только заказчик дал обратную связь, цикл
начинается заново. Вырабатывается план на
следующую итерацию. Если пользователя
что-то не устроило в прототипе, на новом
витке цикла изменения откатывают назад и
реализуют альтернативный вариант
31

32.

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

33.

Когда моделирование завершено,
начинается конструирование:
автоматически сгенерированный код
дорабатывается и совершенствуется.
Финальный этап разработки —
переключение. Готовый программный
продукт тестируют, развертывают на
пользовательских машинах,
конвертируют информацию в новый
формат или «заливают» в новые базы
данных, подготавливают документацию и
обучают операторов работе в системе.
33

34. Эффективные варианты применения RAD

1. Если проект легко делится на независимые или слабосвязанные
модули.
2. Если требования к программному обеспечению быстро меняются
3. В условиях ограниченного бюджета
4. Когда у пользователя нет ясного представления, как должен
выглядеть и работать продукт.
5. Когда у вас есть коллектив хороших разработчиков и дизайнеров
6. Если пользователь готов активно участвовать в проекте на
протяжении всей работы
34

35. Преимущества RAD

1. Разработка выполняется быстро и дешево.
2. RAD обеспечивает приемлемый для пользователя уровень качества.
3. Пользователь получает в итоге именно ту функциональность,
которую хочет.
4. Пользователь может оперативно внести изменения в проект.
5. Функциональность, которая нужна заказчику «еще вчера», можно
разработать в первую очередь, и использовать, даже если остальные
части программы еще не готовы
35

36. Недостатки RAD

RAD применима для больших команд.
RAD зависит от вовлеченности заказчика в работу. Если он не
может принять участие в очередном обсуждении проекта,
работа может приостановиться
36