Зачем нужно, чтобы история умещалась в один спринт? Чем полезны истории размером меньше 1 итерации? И даже больше – зачем разделять истории на ещё меньшие куски?
В общем и целом, одна или несколько задач, завершаемых до состояния 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% плана, но постоянно, хотя бы часть, но работающую – крутая команда. А крутые команды создают крутые продукты.
В заключение
Более довольные, адаптивные и крутые команды, каждые 2 недели или чаще поставляющие новый качественный DoD-функционал, получают в ответ довольных пользователей и стейкхолдеров, и вместе получают крутой и успешный продукт.