В общем и целом, одна или несколько задач, завершаемых до состояния DoD в каждом спринте, позволяют вам соблюдать принцип инкрементальности Скрама. Но что это означает, и зачем этому принципу следовать? У работы инкрементами множество плюсов, и многие из них перечислены ниже.
Планирование и риски
1) Разделяя крупные истории на истории поменьше, вы автоматически проводите более детальный анализ задач и учитываете большее количество нюансов.2) И тем самым снижаете риски провала задачи.
3) А это означает, что повышается вероятность успешного выполнения такой задачи.
4) И оценка задачи будет точнее.
5) А еще, меньший размер историй означает, что можно запланировать на итерацию их большее количество.
Если при разделении вы стремитесь к максимальной независимости меньших историй (см. критерий Independent в списке критериев хорошей истории INVEST), то:
6) сможете реализовывать в желаемом порядке и разных комбинациях. (И тем самым становитесь более адаптивными к запросам и изменениям.)
В том числе, вы сможете более рискованное делать раньше.
6а) Если самое рискованное – зависимости, то сможете реализовать интеграции в ранних итерациях, и тем самым снизить риски зависимостей от смежных команд.
6б) Если самое рисковое – продуктовые гипотезы, то их и проверять в ранних итерациях.
6в) Если самое рискованное – новая технология, то начать с неё.
7) При возникновении какой-то непредвиденной ситуации, заблокированной окажется только одна история из нескольких запланированных на спринт, а не та единственная большая, которую вы еле-еле впихнули бы в итерацию. Аналогично, при необходимости изменений, они затронут конкретные небольшие задачи, а не одну большую целиком, и другие задачи смогут двигаться дальше.
8) Поскольку независимые истории можно реализовывать в любом порядке, упрощается планирование итерации.
8б) А если в ранних итерациях вы уже реализовали интеграции с компонентами других команд, то станет меньше зависимостей и точек синхронизаций, и планирование следующих итераций будет становиться всё легче и легче.
8в) Станет больше согласованности в действиях с другими людьми и командами.
8г) Уменьшится время ожидания выполнения работы другими командами по каждой истории.
9) Выполнение 6-7-8 ведёт к снижению рисков-неопределенностей в целом.
10) А вместе с пунктом 4 о более точной оценке все это приводит к более точному прогнозу на итерацию, более реализуемому плану.
11) И к высокой предсказуемости работы команды.
12) А это позволит не только запланировать побольше небольших задач (п.5), но и выполнить большинство из них.
13) И таким образом вероятность успеха – создания DoD-инкремента к концу итерации – стремится к 100%.
В качестве дополнительной отложенной выгоды: когда команда научится быстро разделять большие истории на мелкие, она сможет делать это и в ходе спринта. Это полезно, когда команда не успевает сделать историю целиком, и умеет быстро разделить ее, чтобы успеть реализовать важную половину.
Продукт и качество
14) Разработчик хорошо помнит код последних Х часов. Чем меньше задача, тем лучше разработчик помнит написанный код, а значит быстрее произведет поиск и исправление дефектов.
15) В конце спринта (по Скраму) история, как и любой другой элемент бэклога, должна соответствовать Definition of Done – определению готовности. Команда учится завершать каждую задачу до состояния DoD, а не копить набор из десятка задач готовых на 99%.
14 и 15 ведут к более качественному продукту. (И повышает адаптивность/agility команды.)
16) Команда сможет показать готовую задачу еще в ходе спринта, не дожидаясь его окончания, получить комментарии и успеть адаптировать результат до Обзора спринта и демонстрации инкремента.
Это ведет к продукту, более соответствующему запросам клиентов и пользователей.
17) Небольшие задачи позволяют точнее приоритизировать, и тем самым раньше поставлять самое важное и откладывать менее важное. Допустим, у вас были задачи АBCDE, и вы разделили А на А1,А2,А3, проанализировали приоритеты, и оказалось, что правильным порядком будет А1,В,С, А2,D,E, а А3 опустилась далеко вниз бэклога, и тем самым вы и сэкономили время и силы, и раньше реализовали ВСDE.
18) Более частая поставка в промышленную среду позволит чаще получать новые знания: проверять работоспособность в проме, получать раннюю обратную связь от пользователей.
19) Всё это помогает идти в сторону более крутого продукта – и соответствующего ожиданиям клиентов и пользователей, и качественного.
20) И в итоге продукт становится экономически успешнее.
Заинтересованные лица, заказчики
(О том, кто такие "стейкхолдеры" подробнее читайте здесь.)21) Заказчики и пользователи смогут дать свои комментарии к выполненным задачам еще в ходе итерации, а не только в ходе демонстрации в конце спринта. (Конечно, если их пожелания ставят под угрозу Цель спринта и значительно увеличивают объем работы, то запрос может быть помещен в бэклог продукта и отложен до следующих спринтов.)
22) Мелкие задачи выполняются быстрее. И если задача доведена до состояния DoD, и заказчики довольны результатом, то можно раньше вывести поставку в промышленную среду – до окончания спринта, и даже несколько раз в ходе итерации.
23) Более точная приоритизация (п.17) позволяет следовать принципу Lean о снижении потерь перепроизводства и одному из 12 принципов "Манифеста Agile-разработки ПО" максимизации неделаемого (the art of maximizing amount of work not done), и тем самым экономить бюджет, повышая RoI усилий команды.
24) Поскольку с большой вероятностью к концу каждой итерации команда создает доработанную рабочую версию продукта (п.13), то на Обзоре спринта демонстрируется реальный функционал, а не только отчетные слайды. (Согласно Скраму, только DoD-результаты могут демонстрироваться на Обзоре спринта.)
25) Это повышает удовлетворенность заинтересованных лиц.
26) Высокая предсказуемость (п.11) и стабильность работы команды ведет к выполнению данных обещаний, а это укрепляет доверие стейкхолдеров и улучшает взаимоотношения.
Пользователи
Частая и ранняя поставка ценности в виде нового готового качественного функционала в промышленную среду:27) Позволяет пользователям получать ценность небольшими порциями регулярно. А постепенное изучение новых функций делает исчерпывающую обучающую пользовательскую документацию ненужной.
28) Влечет частую обратную связь от пользователей.
29) Повышает удовлетворенность пользователей, даже если вы не поставили всё-всё обещанное вовремя. А это еще больше повышает удовлетворенность заинтересованных лиц (п.25).
30) Позволяет вашему бизнесу раньше получать выгоду: дополнительных пользователей, ранние продажи.
И, опять же, продукт становится экономически успешнее (п.20).
Команда
31) Большой deadline, который обычно влечет неравномерную нагрузку и истощение команды в пожарном режиме в последней четверти срока, теперь разделяется на несколько небольших, обычно 2-недельных последовательных дедлайнов, называемых итерациями или спринтами. Поэтому снижается уровень деструктивного стресса участников команды.
Выполнение нескольких небольших запланированных на спринт задач (п.12)
32) повышает чувство завершенности и удовлетворенности своей работой,
33) повышает ощущение скорости работы, которое вносит свой вклад в укрепление доверия со стейкхолдерами (п.26),
34) а завершенность и скорость, вместе с предсказуемостью и стабильностью (п.11), повышают командный дух.
35) Следуя принципам Lean и Agile (п.23), команда не тратит время и силы на менее важное.
36) Мелкие задачи быстрее проходят процесс создания ПО, особенно при стремлении к фокусировке и One Piece Flow. (См. ценности Scrum.) И поэтому становится равномернее нагрузка сотрудников по компетенциям в ходе спринта. (Команда, конечно же, стремиться к взаимозаменяемости и T-shaping, но не всегда с самого начала такая.) И ниже перегрузка тестировщиков и разработчиков в конце итерации.
37) Не перегруженная команда с низким уровнем разрушительного стресса – более довольная команда.
Доведение задач до завершенного состояния DoD (п.15)
38) делает команду более адаптивной к изменению приоритетов и состава работ.
39) Команда, которая поставляет что-то работающее каждый спринт, пусть не 100% плана, но постоянно, хотя бы часть, но работающую – крутая команда. А крутые команды создают крутые продукты.