Блог SkillsCup.com

Почему история должна быть меньше 1 спринта?

Зачем нужно, чтобы умещалось в один спринт? И даже больше – зачем разделять истории на ещё меньшие куски?
Разделение историй улучшает приоритизацию
Выгода №16

  1. Следование принципу Скрама об инкрементальности. Следование, конечно же, не слепое – у работы инкрементами множество плюсов, как раз они и перечислены ниже.
  2. Банальная работа с риском не успеть вовремя. Меньше задача – выше вероятность успеха. Мелкие истории подразумеваютболее детальный анализ задач и учёт большего количества нюансов.
  3. Снижать технические риски.
  4. Снижать риски зависимостей от смежных команд – реализовывать интеграции в ранних итерациях. Больше согласованности в действиях с другими людьми и командами, меньше ожиданий по каждой истории. (Если точнее, то более рискованное делать раньше. Если самое рискованное – зависимости, то делать их. Если самое рисковое – продуктовые гипотезы, то проверять их.)
  5. При возникновении блокеров или при необходимости изменений, они затронут конкертные небольшие задачи, а не одну большую целиком, и другие задачи смогут двигаться дальше.
  6. Получать новые знания: работоспособность в проме, обратная связь (ОС) от пользователей, ранняя ОС в ходе спринта ещё до Обзора спринта и демонстрации инкремента и возможность тут же адаптироваться. И постепенно идти в сторону более крутого продукта.
  7. Разработчик хорошо помнит код последних Х часов. А значит и устранение дефектов будет быстрее.
  8. Команды научатся завершать работу, а не копить набор из десятка задач готовых на 99%. В конце спринта (по Скраму) история, как и любой другой элемент бэклога, должна соответствовать Definition of Done – определению готовности
  9. Повышать качество продукта.
  10. Поставлять ценность раньше и чаще. Пользователи более удовлетворены, даже если вы не поставили всё обещанное вовремя. Пользователи будут получать новые функции порциями, а вам не потребуется создавать детальные обучающие материалы.
  11. Получать выгоду раньше.
  12. При необходимости, возможность поставить по запросу до окончания спринта. И в целом поставлять чаще, чем 1 раз в спринт.
  13. Лучше распределение работы в ходе спринта. Меньше перегрузка в конце спринта.
  14. Разделять большой deadline, на несколько небольших.
  15. Снижать уровень деструктивного стресса.
  16. Каждые две недели иметь доработанную рабочую версию продукта.
  17. Демонстрации в конце итерации перестанут основываться на отчётных слайдах.
  18. Независимые истории можно реализовывать в любом порядке, и поэтому намного проще планировать итерации. (См. критерии хорошей истории INVEST.)
  19. Больше комбинаций и меньше зависимостей и точек синхронизаций облегчают планирование, прогноз получается более точным, и больше задач реализуется за спринт.
  20. Cледовать принципу Lean и Agile-принципу максимизации неделаемого (the art of maximizing amount of work not done), и тем самым не тратить время и силы на менее важное.
  21. Лучше приоритизировать. Допустим, у вас были задачи АBCDE, и вы разделили А на А1,А2,А3, проанализировали приоритеты, и оказалось, что правильным порядком будет А1,В,С,А2,D,E, а А3 опустилась далеко вниз бэклога, и тем самым вы и сэкономили время и силы, и раньше реализовали ВСDE. (См. рис. выше.)
  22. Мелкие задачи быстрее проходят процесс (One Piece Flow).
  23. Если не успеваете сделать историю целиком, то можно декомпозировать и в ходе спринта.
  24. Мелкие задачи оцениваются точнее, а это повышет предсказуемость.
  25. Предсказуемость приводит к выполнению обещаний, и вместе с чувством скорости они повышают доверие между командой и stakeholders.
  26. Стабильность ичувство завершённости поднимают командный дух.
  27. Команда будет поставлять всегда. Пусть не 100% плана спринта, но всегда хоть что-то, хотя бы часть, но работающую.
  28. И вы будете молодцами! Потому что держите данные обещания.
Выгода №19
Выгода №21
Agile
Made on
Tilda