Книга Софт за 30 дней. Как Scrum делает невозможное возможным, страница 39. Автор книги Кен Швабер, Джефф Сазерленд

Разделитель для чтения книг в онлайн библиотеке

Онлайн книга «Софт за 30 дней. Как Scrum делает невозможное возможным»

Cтраница 39

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

Раздел 7.02. Бэклог спринта

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

Бэклог спринта определяет объем работы, которую команда разработки должна выполнить, чтобы превратить бэклог продукта в «законченный» инкремент. Бэклог спринта делает видимой ту работу, которую команда разработки считает необходимой для достижения цели спринта.

Бэклог спринта достаточно детализирован, чтобы прогресс работы над ним можно было увидеть на каждом ежедневном Scrum-митинге. Команда разработки вносит изменения в бэклог на протяжении всего спринта, и он постоянно изменяется. Такие изменения происходят потому, что в процессе деятельности команды разработки возникают все новые и новые задачи, которые нужно выполнить для достижения цели спринта.

Если возникает необходимость в дополнительном объеме работы, команда разработки добавляет ее в бэклог спринта. Когда же работы выполнены, оценки оставшегося объема работ обновляются. Если некоторые пункты плана считаются уже неактуальными, то их попросту удаляют. Только команда разработки может изменять свой бэклог во время спринта. Бэклог спринта – наиболее наглядный документ, показывающий реальную картину работы, которую команда разработки планирует завершить до окончания спринта, и он принадлежит исключительно ей.

А. Отслеживание прогресса спринта. В любое время можно суммировать оставшуюся в спринте работу. Команда разработки отслеживает ее по меньшей мере на ежедневном Scrum-митинге, чтобы понять вероятность достижения цели спринта. Отслеживая оставшуюся работу на протяжении спринта, команда разработки может видеть прогресс и управлять им.

Scrum не рассматривает время, проведенное над пунктами бэклога спринта. Оставшиеся время и дата – единственные переменные, представляющие интерес.

Раздел 7.03. Инкремент

Инкремент – это сумма всех выполненных требований бэклога продукта, реализованных во время текущего спринта, и ценности всех предыдущих спринтов. По окончании спринта новый инкремент должен быть «законченным», то есть пригодным к использованию и отвечать определенным Scrum командой критериям «законченности». Несмотря на решение владельца продукта относительно выпуска той или иной версии инкремента, он должен быть готовым к использованию.

Статья VIII. Определение «законченности»

Когда элемент бэклога продукта или же инкремент называется «законченным», все должны понимать, что означает «законченность». Хотя это определение Scrum-команды интерпретируют по-разному, для гарантирования прозрачности их участники должны иметь общее понимание того, что означает завершенная работа. Именно единое определение понятия «законченности» используется Scrum-командой для оценки окончания работы над инкрементом продукта.

Это же определение помогает команде разработки оценить количество выбранных элементов бэклога продукта во время планирования спринта. Цель каждого спринта – разработка инкремента потенциально готового к выпуску функционала, отвечающего текущему определению «законченности» Scrum-команды.

Каждый спринт команда разработки предоставляет инкремент функционала продукта. Такой инкремент пригоден к использованию, поэтому владелец продукта может принять решение о немедленном релизе продукта.

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

По мере увеличения профессионализма Scrum-команды критерии «законченности» могут дополняться более строгими критериями для достижения лучшего качества продукта.

Статья IX. Заключение

Scrum – бесплатный метод, и его описание предоставлено в этом гайде. Роли, артефакты, правила и мероприятия Scrum не подлежат изменению, и, хотя возможно использование только отдельных его частей, конечный результат уже не будет Scrum. Scrum существует только в своей целостности и может быть контейнером для дополнительных техник, методологий и практик.

Статья X. Благодарности
Раздел 10.01. Люди

Среди тысяч людей, способствовавших развитию Scrum, мы хотим выделить тех, кто на протяжении первого десятилетия существования метода внес в его разработку наиболее весомый вклад. В первую очередь это, конечно же, Джефф Сазерленд и Джефф Маккенна, а также Кен Швабер, Майк Смит и Крис Мартин. В последующие годы много людей способствовали развитию Scrum, и без их содействия он не был бы настолько усовершенствован. Дэвид Старр использовал все свои редакторские навыки при создании этой версии Scrum-гайда.

Раздел 10.02. История

Кен Швабер и Джефф Сазерленд впервые представили Scrum на конференции OOPSLA (Object-Oriented Programming Systems, Languages and Applications) в 1995 году. Данное руководство основывается на опыте, приобретенном Кеном и Джеффом на протяжении многих лет применения Scrum.

История развития Scrum уже может считаться длительной. Отмечая те компании, в которых Scrum был впервые использован и усовершенствован, мы не можем не вспомнить о корпорациях Individual, Inc., Fidelity Investments и IDX (сегодня GE Medical).

Scrum-гайд описывает метод в том виде, в котором он был разработан и поддерживался в течение более 20 лет Джеффом Сазерлендом и Кеном Швабером. В других источниках вы можете найти образцы, процессы, справку и полезные инструменты, которые дополняют фреймворк Scrum. Это позволяет достичь продуктивности, ценности, проявить креативность и в итоге испытать гордость.

Приложение 3. Сценарий достижения гибкости организации

Используется с 2005 года

1.1. Введение

Давление со стороны глобальной экономики требует от современного бизнеса в большей степени полагаться на способность создавать программное обеспечение в качестве ключевого конкурентного преимущества. Программное обеспечение – для управления процессами производства и доставки до потребителя или для повышения эффективности ежедневных рутинных действий – затрагивает практически все аспекты современного бизнеса.

Вход
Поиск по сайту
Ищем:
Календарь
Навигация