-->

Scrum и XP: заметки с передовой

На нашем литературном портале можно бесплатно читать книгу Scrum и XP: заметки с передовой, Книберг Хенрик-- . Жанр: Прочая компьютерная литература / Отраслевые издания. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале bazaknig.info.
Scrum и XP: заметки с передовой
Название: Scrum и XP: заметки с передовой
Дата добавления: 16 январь 2020
Количество просмотров: 297
Читать онлайн

Scrum и XP: заметки с передовой читать книгу онлайн

Scrum и XP: заметки с передовой - читать бесплатно онлайн , автор Книберг Хенрик
Эта книга исключительна полезна. С одной стороны она про такой хорошо (если не излишне) раскрученный термин как Scrum, на который ведутся большинство (если не все) начальников. С другой стороны, она упирает на то, что Scrum без инженерных практик не живёт. Не знаю сознательно ли Хенрик заложил этот месадж в книгу или так получилось случайно, но получилось именно то, что доктор прописал :-)

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала

1 2 3 4 5 6 7 8 9 10 ... 26 ВПЕРЕД
Перейти на страницу:

Как команда принимает решение о том, какие истории включать в спринт?

Мы используем два подхода:

1. на основе интуиции

2. на основе подсчёта производительности

Планирование, основанное на интуиции

ScrumMaster: «Ребята, мы закончим историю „А“ в этом спринте?» (Показывает на самую важную историю в product backlog’а)

Лиза: «Конечно, закончим. У нас есть три недели, а это довольно тривиальная функциональность». ScrumMaster: «Хорошо. А как на счёт истории „Б“?» (Показывает на вторую по важности историю) Том и Лиза одновременно: «Легко!»

ScrumMaster: «Хорошо. Как на счёт историй „А“, „Б“ и „В“?»

Сэм (обращаясь к product owner): «Нужно ли реализовывать расширенную обработку ошибок для истории „В“?»

Product owner: «Нет. Пока хватит базовой». Сэм: «В таком случае историю „В“ мы тоже закончим». ScrumMaster: «Хорошо, как на счёт истории „Г“?» Лиза: «Хмм…»

Том: «Думаю, что сделаем». ScrumMaster: «Вероятность 90 % или 50 %?» Лиза и Том: «скорее 90 %.»

ScrumMaster: «Хорошо, значит, включаем историю „Г“ в этот спринт. Что скажете на счет истории „Д“?» Сэм: «Возможно».

ScrumMaster: «90 %? 50 %?» Сэм: «Ближе к 50 %». Лиза: «Сомневаюсь».

ScrumMaster: «В таком случае, не включаем историю „Д“. Обязуемся реализовать истории „А“, „Б“, „В“ и „Г“. Конечно, если успеем, то реализуем и историю „Д“, однако не стоит на это расчитывать. Поэтому историю „Д“ исключаем из плана спринта. Согласны?» Все: «Согласны».

Интуитивное планирование хорошо работает для маленьких команд и коротких спринтов.

Планирование, основанное на методе оценки производительности

Этот подход включает в себя два этапа:

1. Определить прогнозируемую производительность

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

Производительность является мерой «количества выполненной работы». Она рассчитывается как сумма первоначальных оценок всех историй, которые были реализованы в течение спринта.

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

Scrum и XP: заметки с передовой - Any2FbImgLoader7

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

Я уже слышу ваши возражения: «Какая от этого польза? Высокий или низкий уровень производительности зависит от миллиона факторов! Недалёкие программисты, неправильная начальная оценка, изменение объёма работ, незапланированные потрясения в ходе спринта и т. д.»

Согласен, производительность — это приблизительная величина. Но, тем не менее, очень полезная. Она лучше, чем ничего. Производительность даёт нам следущее: «Независимо от причин, мы имеем разницу между запланированным и выполненным объемом работ».

А что, если история была почти закончена? Почему мы не используем дробные значения для таких историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу «Managing the Design Factory» автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.

Так каким же магическим способом мы оцениваем производительность?

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

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

Более продвинутый вариант оценки производительности заключается в определении доступных ресурсов. Допустим, мы планируем трёхнедельный спринт (15 рабочих дней). Команда состоит из 4-ёх человек. Лиза берёт два отгула. Дэйв сможет уделить проекту только 50 % времени плюс берёт один отгул. Сложим всё вместе …

Scrum и XP: заметки с передовой - Any2FbImgLoader8

Получили ли мы прогнозируемую производительность? Нет! Потому что наша единица измерения — это story point, который, в нашем случае приблизительно равен «идеальному человеко-дню». Идеальный человеко-день — это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни — редкость. Кроме того, нужно принимать во внимание, что в ходе спринта может быть добавлена незапланированная работа, человек может заболеть и т. д.

Без всякого сомнения, наша прогнозируемая производительность будет менее пятидесяти. Вопрос в том, насколько? Для ответа на него введём определения фокус-фактора.

Scrum и XP: заметки с передовой - Any2FbImgLoader9

Фокус-фактор — это коэффициент того, насколько команда сфокусирована на своих основных задачах. Низкий фокус-фактор может означать, что команда ожидает неоднократного вмешательства в свою работу или предполагает, что оценки слишком оптимистичны.

Выбрать разумный фокус-фактор лучше всего, взяв его из последнего спринта (а ещё лучше — среднее значение за несколько последних спринтов).

Scrum и XP: заметки с передовой - Any2FbImgLoader10

За реальную производительность принимается сумма начальных оценок для тех историй, которые были завершены в ходе последнего спринта.

Допустим, в ходе последнего спринта командой из трёх человек в составе Тома, Лизы и Сэма реализовано 18 story point'ов. Продолжительность спринта была 3 недели, что составляет 45 человеко-дней. Необходимо спрогнозировать производительность команды на будущий спринт. Слегка усложним задачу появлением Дэйва — нового участника команды. Принимая во внимание отгулы членов команды и другие вышеупомянутые обстоятельства, получим 50 человеко-дней.

Scrum и XP: заметки с передовой - Any2FbImgLoader11

Таким образом, наша прогнозируемая производительность будущего спринта — это 20 story point'ов. Это означает, что команде следует включать истории в план спринта до тех пор, пока их сумма не будет примерно равна 20.

Scrum и XP: заметки с передовой - Any2FbImgLoader12

В нашем случае команда может выбрать 4 наиболее важные истории (что составляет 19 story point'ов) или 5 наиболее важных историй (24 story point’а). Остановимся на четырёх историях, т. к. их сумма близка к 20. Если возникают сомнения, выбирайте меньше историй.

Ввиду того, что выбранные 4 истории составляют 19 story point’а, окончательная прогнозируемая производительность будущего спринта составляет 19.

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

1 2 3 4 5 6 7 8 9 10 ... 26 ВПЕРЕД
Перейти на страницу:
Комментариев (0)
название