Flexible Strints

[Alimenkou Nikolay]

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

- Спринт 2 недели и доступное время в SP (story point)
устанавливается в начале спринта
- На начало спринта обеспечивается бэклог, который покроет как
минимум треть спринта
- Проводится планирование (сокращенное ввиду размера бэклога) и
начинаются работы
- По ходу спринта появляются новые задачи и они планируются и
вносятся в спринт бэклог (допланирование)
- Любое допланирование вносится в демо в конце итерации
- Обновляется спринт бэклог и все что с ним связано
- Если задача не укладывается в оставшееся время, то она дробится или
же не включается
- Если задач нету, и спринт бэклог пуст, то выполняются
запланированные долгосрочные задачи по рефакторингу, чистке кода,
анализу метрик, улучшению процесса разработки

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

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

[Artem Marchenko]

Если команда и клиенты довольны, то почему бы и нет. На до и inspect
and adapt, чтобы пробовать новое и оставлять, если оно работает. Лично
мне с таким подходом сталкиваться не приходилось, но знаю как минимум
пару команд, у которых именно такой подход работает хорошо.

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

В моём личном опыте была не такая, но похожая ситуация. В течение
спринта частенько (но не каждый спринт) приходили значительные по
объёму срочные задачи (например, срочно помочь внезапным клиентам,
которые решили портировать наш софт за неделю до релиза миллиона
экземпляров железа). Мы "выделяли" определённое кол-во SP под подобные
внезапные и срочные задачи. Это помогало не нервничать по поводу
sprint commitment в случае необходимости. Если же необходимость не
возникла, ну тогда потратим эти SP на внутренние усовершенствования
(рефакторинг, написание давно желаемых скриптов и т.д.) либо просто
на следующую по очереди story.

Удачи!
Артём.

On May 31, 3:37 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:

[Borys Lebeda]

Всем привет!

 

Артёму: Команду и клиентов можно держать довольными долго даже если вообще ничего не делать. Гораздо более интересный вопрос даёт ли этот подход больше шансов на появление зрелого продукта больше, чем какой-либо другой.

 

Теперь вернёмся к основному посту. Лично меня озадачили некоторые вопросы:

- Спринт 2 недели и доступное время в SP (story point)
устанавливается в начале спринта
 - На начало спринта обеспечивается бэклог, который покроет как
минимум треть спринта

Итак, имеем 10 дней/3*5человек < 17 человеко-дней . Хотелось бы знать, что вы такое конструируете, что даже на 17 человеко-дней не просматривается workload? Заказчик что-то же все таки от вас хочет?

 - Проводится планирование (сокращенное ввиду размера бэклога) и
начинаются работы

Это ведь не kick-off c участием заказчика - спринт бэклог у вас уже есть. И наверняка известно, что каждый из вас будет делать: пять человек могли участвовать в переговорном процессе. Почему нельзя обойтись просто SCRUM meeting в течении спринта?

Если задач нету, и спринт бэклог пуст, то выполняются
запланированные долгосрочные задачи по рефакторингу, чистке кода,
анализу метрик, улучшению процесса разработки

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

 

 - По ходу спринта появляются новые задачи и они планируются и
вносятся в спринт бэклог

Хотелось бы услышать как осуществляется допланирование у вас.

Лично у меня редко бывает спринты, в котором решительно ни одна задача не поменялась. За одно расскажу как у нас это делалось ...

 

У меня есть что сказать на это:

" Мы "выделяли" определённое кол-во SP под подобные
внезапные и срочные задачи."

но я думаю внезапным задачам лучше посвятить отдельный тред: что бы не затмевать основную тему.

 

Жду ответов, господа присяжные заседатели ...

[Alimenkou Nikolay]

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

On Jun 1, 1:16 am, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Всем привет!
>
> Артёму: Команду и клиентов можно держать довольными долго даже если вообще
> ничего не делать. Гораздо более интересный вопрос даёт ли этот подход больше
> шансов на появление зрелого продукта больше, чем какой-либо другой.
>
> Теперь вернёмся к основному посту. Лично меня озадачили некоторые вопросы:

> *- Спринт 2 недели и доступное время в SP (story point)

> устанавливается в начале спринта
> - На начало спринта обеспечивается бэклог, который покроет как

> минимум треть спринта*

> Итак, имеем 10 дней/3*5человек < 17 человеко-дней . Хотелось бы знать, что
> вы такое конструируете, что даже на 17 человеко-дней не просматривается
> workload? Заказчик что-то же все таки от вас хочет?

> * - Проводится планирование (сокращенное ввиду размера бэклога) и
> начинаются работы
> *Это ведь не kick-off c участием заказчика - спринт бэклог у вас уже есть.

> И наверняка известно, что каждый из вас будет делать: пять человек могли
> участвовать в переговорном процессе. Почему нельзя обойтись просто SCRUM
> meeting в течении спринта?

> *Если задач нету, и спринт бэклог пуст, то выполняются

> запланированные долгосрочные задачи по рефакторингу, чистке кода,
> анализу метрик, улучшению процесса разработки

> *

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

> * - По ходу спринта появляются новые задачи и они планируются и
> вносятся в спринт бэклог*

> Хотелось бы услышать как осуществляется допланирование у вас.
> Лично у меня редко бывает спринты, в котором решительно ни одна задача не
> поменялась. За одно расскажу как у нас это делалось ...
>
> У меня есть что сказать на это:

> *" Мы "выделяли" определённое кол-во SP под подобные
> внезапные и срочные задачи."*

> но я думаю внезапным задачам лучше посвятить отдельный тред: что бы не
> затмевать основную тему.
>
> Жду ответов, господа присяжные заседатели ...
>

> --
> Borys L.

[Borys Lebeda]

Я готов сам с собой спорить, Николай, но в данном случае я вообще ни с кем спорить не собирался: просто хочу получить ответы на вполне конкретные вопросы:

1) Как команда и заказчик могут не сойтись на постановке задач на 17 человеко-дней, при этом расчитывая на успех проекта?  

2) Почему не включаются в спринт задачи по рефакторингу, чистке кода,
анализу метрик, улучшению процесса разработки, а также исследования?

3) Нужно ли какое-либо планирование сверх того, что предусматривает сам SCRUM: декомпозиция имеющихся SP в начале и daily SCRUM?

4) Как осуществляется то, что Ты назвал "допланированием", а именно измененение задач во время самого спринта.

Очень жаль что автор изначального поста съезжает от ответа на столь очевидные вопросы: я ещё не встречал ничего похожего на "динамические спринты". (набери это в гугле и придёшь на www.agileukraine.org с этим самым постом. Это уже , батенька, не эксперимент, а какое-то ноу хау, которое пока слабо согласуется с тем, что использовалось ранее. Взять, например, "Agile Estimating and Planning" (Mike Cohn). Он ведь там полторы главы посвятил планированию задач спринта (главы 14 и частично 15), и нигде не говорил, что спринт можно стартовать имея какие-то пробелы в плане, которые можно потом залатать "допланированием". Зато зачем-то написал главу 17 Buffering Plans for Uncertainty, для того, что бы объяснить для чего мы МОЖЕМ и ДОЛЖНЫ оставлять в плане пробелы ...

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

Может я что-то пропустил по матчасти? Ну так вперёд: список литературы, ссылки, явки, стрелки ... даёшь, стало быть, "динамические спринты"!

:)))

 

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

Всех благ!

 

Борис Л.
 

--
Borys L.

[Alexey Krivitsky]

Привет

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

Теперь по теме... :)

Individuals and interactions over processes and people. То есть, если команда выбрала процесс, и он работает, то это классно. Другими словами не стоит притягивать ненужные процессы в проект. Если и без итераций все пока ок, то тогда зачем они?

Теперь по существу. :)

Итерации - это механизм получения обратной связи (ОС). Если с получением ОС проблем нет в принципе, то можно в принципе итерации не делать, или делать их нефиксированного размера.

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

Так вот есть подход, называемый Kanban, который в принципе можно использовать вместо итераций.

Недавно слушал доклад на эту тему. Идея в том, что команда работает с непрерывным потоком задач. Но очередь задач, которые в работе ограничивается в размере, для увеличения пропускной способности и избежания излишек производства (читайте про lean). Так вот, этот подход, говорят, хорошо работает если у вас одна команда и множество потоков задач (множество мелких проектов) - IT shop.

В принципе этот же подход никто не мешает использовать для среды "одна команда - один проект". Велосити подсчитывается в принципе так же как и при итерациях - сумма сделанных элементов работы за единицу времени.

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

Я это не пробовал. Так что пересказываю теорию со слов других.

Полезные ссылки:

1. http://en.wikipedia.org/wiki/Kanban
2. http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html

Лёша

2008/6/1 Borys Lebeda <borys....@gmail.com>:

[Alimenkou Nikolay]

С удовольствием отвечу на вопросы, но прошу читать тему изначального
поста. Кратко она звучит так: "Кто работал по такой схеме поделитесь
опытом о имевшихся проблемах". Если не работал, то зачем писать? Я же
не спрашивал "Посоветуйте мне как поступить" или "Какой из вариантов
выбрать". Не могу понять для чего отвечать вопросом на вопрос. :(

On Jun 1, 7:59 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Я готов сам с собой спорить, Николай, но в данном случае я вообще ни с кем
> спорить не собирался: просто хочу получить ответы на вполне конкретные
> вопросы:
> 1) Как команда и заказчик могут не сойтись на постановке задач на 17
> человеко-дней, при этом расчитывая на успех проекта?

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

> 2) Почему не включаются в спринт задачи по рефакторингу, чистке кода,
> анализу метрик, улучшению процесса разработки, а также исследования?

Не включаются, потому что есть очень большая доля вероятности, что
спринт бэклог будет заполнен
уже через 3 дня после начала итерации. А выбрасывать задачи из бэклога
- корень зла при перепланировании.

> 3) Нужно ли какое-либо планирование сверх того, что предусматривает сам
> SCRUM: декомпозиция имеющихся SP в начале и daily SCRUM?

Когда в начале у тебя почти нету задач, то конечно нужно.

> 4) Как осуществляется то, что Ты назвал "допланированием", а именно
> измененение задач во время самого спринта.

Допланирование осуществляется очень просто - это копия планирования в
начале спринта. Такой эффект достигается за
счет того, что мы НИКОГДА не выбрасываем задачи из спринта, а только
добавляем новые, пока не достигнем предела SP
на спринт. Зачастую это бывает даже полезно, потому что люди уже
начали делать функционал и могут дать более адекватные
оценки, чем в начале итерации.

> Очень жаль что автор изначального поста съезжает от ответа на столь
> очевидные вопросы: я ещё не встречал ничего похожего на "динамические
> спринты". (набери это в гугле и придёшь на

> www.*agile**ukraine*.org<http://www.agileukraine.org> с этим
> самым постом.

Название придумал самолично, поэтому ничего удивительного. Мог назвать
мега-спринты, попугай-based-cпринты и так далее. ;)

>Это уже , батенька, не эксперимент, а какое-то ноу хау,
> которое пока слабо согласуется с тем, что использовалось ранее. Взять,
> например, "Agile Estimating and Planning" (Mike Cohn). Он ведь там полторы
> главы посвятил планированию задач спринта (главы 14 и частично 15), и нигде
> не говорил, что спринт можно стартовать имея какие-то пробелы в плане,
> которые можно потом залатать "допланированием". Зато зачем-то написал главу
> 17 Buffering Plans for Uncertainty, для того, что бы объяснить для чего мы
> МОЖЕМ и ДОЛЖНЫ оставлять в плане пробелы ...
> Кроме того, все защитники традиционных моделей вообще костьми ляжут, что бы
> не допустить отсутствия плана на следующую неделю ...

Можно ложиться костьми по поводу, например если есть проблемы. Если же
команда работает успешно, то в чем смысл
этой укладки? Чтобы просто показать что ты за идею, которую прочитал в
книге? :)

> Может я что-то пропустил по матчасти? Ну так вперёд: список литературы,
> ссылки, явки, стрелки ... даёшь, стало быть, "динамические спринты"!
> :)))
>
> Я не обижаюсь на Тебя, Николай, но этот демарш я не могу оставить без ответа
> ... Уж слишком он какой-то неотёсанный для человека, который целых два
> доклада собирается прочитать перед большой аудиторией ...
>

Я тоже не обижаюсь, но хотелось бы повторить. Я когда-то уже писал об
этом полгода назад. Если человек ищет людей, которые
имеют опыт в каком-то подходе, зачем писать им что по вашему этот
подход неверен, хотя вы его ни разу не пробовали? По поводу
такого же подхода недавно прочитал пост:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/copypaste-reasoning

> Всех благ!
>
> Борис Л.

[Alimenkou Nikolay]

On Jun 2, 5:25 am, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> Привет
>
> Хочу напомнить об этике общения. *Плииииз, не переходите на личности.

> Обсуждайте топик, а не друг друга. Как вариант, сначала читайте пост, а уже

> потом имя автора.*

>
> Теперь по теме... :)
>
> Individuals and interactions over processes and people. То есть, если
> команда выбрала процесс, и он работает, то это классно. Другими словами не
> стоит притягивать ненужные процессы в проект. Если и без итераций все пока
> ок, то тогда зачем они?

Итерации нужны, чтобы иметь законченный функционал с демо к какому-то
сроку, а также для
снятия и анализа метрик с процесса.

> Теперь по существу. :)
>
> Итерации - это механизм получения обратной связи (ОС). Если с получением ОС
> проблем нет в принципе, то можно в принципе итерации не делать, или делать
> их нефиксированного размера.
>
> Другими плюсами итерациий является наличие ритма в проекте, который
> большинству приходится по вкусу. Но "на вкус и цвет все фломастеры
> разные"...
>
> Так вот есть подход, называемый Kanban, который в принципе можно
> использовать вместо итераций.
>
> Недавно слушал доклад на эту тему. Идея в том, что команда работает с
> непрерывным потоком задач. Но очередь задач, которые в работе ограничивается
> в размере, для увеличения пропускной способности и избежания излишек
> производства (читайте про lean). Так вот, этот подход, говорят, хорошо
> работает если у вас одна команда и множество потоков задач (множество мелких
> проектов) - IT shop.
>
> В принципе этот же подход никто не мешает использовать для среды "одна
> команда - один проект". Велосити подсчитывается в принципе так же как и при
> итерациях - сумма сделанных элементов работы за единицу времени.
>
> Используя подход хранения стабильного кода в отдельном бренче, можно
> обеспечить наличие стабильной сборки в любой момент времени, независимо от
> состояния очереди задач, .
>
> Я это не пробовал. Так что пересказываю теорию со слов других.
>
> Полезные ссылки:
>

> 1.http://en.wikipedia.org/wiki/Kanban
> 2.http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html
>
> Лёша

Спасибо за ответ, я тоже немного читал про это. Посмотрю внимательнее.

[Borys Lebeda]

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

 

С ответами на эти вопросы, многое прояснилось:

1. У вас не одна, а несколько команд. На пять человек ...

2. Заказчик у вас скорее всего боец, который взял на себя роль аналитика.

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

 

Между прочим, ситуация, указанная в пунктах 1 и 2, имет место и у меня. Третий пункт для меня остаётся загадкой. Вероятно, причина в том, что мне не кажется выбросить задачу из спринта таким уж недопустимым. Как сказал один видный политик "Коней на переправе не меняют, а ослов можно и нужно менять ..."

 

Вывод: я не работал по схеме, которую Ты описал, хотя до этой мысли я дошёл не сразу , а только после ответов на мои вопросы ...

 

P.S. Про канбан ничего не слышал, но источников достаточно много: есть что поизучать ...

 

2008/6/2 Alimenkou Nikolay <lumii.su...@gmail.com>:

--
Borys L.

[Igor Khotin]

В целом можно выделить два подхода к процессу организации обработки
задач:
plan-based и incident-based.
К первой категории можно отнести практически все Agile подходы, равно
как и другие методики разработки програмного обеспечения. Так как сама
природа software development предусматривает какой-то определенный
объем работ известный заранее. Таким образом практически всегда можно
выделить и очертить объем работ на следующий спринт.

С другой стороны есть incident-based подходы. В них объем работ
неизвестен наперед - задачи возникают по ходу возникновения
"инцидентов". Такие используют для организации работы техподдержки или
bugfixing-а. Например, известный мне ITIL используют IT отделы для
обработки возникающих инцидентов. Такой процес собирает статистику,
позволяя прикидывать наперёд объемы работ. Я уверен, что есть ряд
других методик. Упомянутый Лёшей Kanban также основан на событиях -
Kanban is a signaling system to trigger action. То есть есть инцидент
- и есть ответная реакция.

Приспособление итераций для обработки инцидентов несет в себе
сомнительные преимущества. Так как при этом теряется сама суть
итераций (когда мы фиксирует время и планируем объем работ).

Более разумным я вижу создать два независимых процесса - основанный на
agile plan-based для обычных задач из бэк-лога + основанный на
инцидентах процесс, который будет заниматься инцидентами. Можно
разделить между ними ресурсы, но это может привести к необоснованным
растратам (если, к примеру, инциденты не будут возникать вовсе).

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

Но в любом случае будут происходить накладки между этими процессами,
так как они имеют разную природу.

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

Удачи!
Игорь.


On 31 май, 15:37, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:

[Alimenkou Nikolay]

Спасибо за ответ. Я проясню процесс заполнения проджект бэклога. На
начало итерации в бэклоге есть
задач на 20 SP. Остальные задачи не сформулированы и параллельно
исследуются другой командой. Обычно они
выливаются в бэклог через 3-4 дня после начал итерации. Именно в этот
момент происходит допланирование. Больше 2
допланирований на спринт еще не было. При этом отказ от итерации
неинтересен по причине наличия фиксированного
интервала времени, после которого можно проанализировать результаты и
получить законченный функционал.
Дополнительно можно получить метрики процесса и воздействовать на них.
Демо вызывает фидбек, который не всегда
просто вызвать во время повседневной работы.

[Tim Yevgrashyn]

Алексей,

Меня смутило

> Остальные задачи не сформулированы и параллельно исследуются другой командой. Обычно они выливаются в бэклог через 3-4 дня после начал итерации. Именно в этот момент происходит допланирование.

Если вы так уж хотите держаться ближе к Scrum, то пробовали ли вы делать следующее:

а) начать спринт на 4 дня позже, чтобы вторая команда уже добавила недостающие истории?
Да, для этого придется подождать немного, и все-таки я думаю это не проблема чем занять людей между спринтами

б) Пробовали ли вы сделать спринты короткими (вплоть до 1й недели), чтобы обеспечить плавную передачу работы между двумя командами?
Т.е. то, что заресерчила одна команда - инпут для следующей итерации второй команды. А то, что вторая показала - инпут для новых ресерчей первой. И так они идут синхронным тайм-лайном, хотя со сдвинутыми целями спринтов.

2008/6/2 Alimenkou Nikolay <lumii.su...@gmail.com>:

--
Tim Yevgrashyn,
Member of decision board of AgileUkraine.org
Scrum coach at SCRUMguides.com

Phone: +380 67 408 53 30
Skype: spidertim
LinkedIn: http://www.linkedin.com/in/yevgrashyn

[Borys Lebeda]

У нас было в одной из команд нечто подобное: были сформированы Sprint tasks и за резервировано время под urgent tasks. Удельный вес вторых был от 40% до 75%. Пожалуй в терминологии Игоря это и будет plan-based и incident-based

Оно работало, но в результате оказалось проще разбить команду на две: одна занимается разработкой, другая - support. При этом первая команда практиковала SCRUM, а вторая ... 

Приспособление итераций для обработки инцидентов несет в себе сомнительные преимущества.

Я бы даже так сказал: итерации вообще не имеют смысла: поток urgent tasks может быть достаточно неоднороден и мало предсказуем, если там находились какие-то вещи, которые можно было предугадать, доработать, автоматизировать, они сразу становились элементом спринта разработки и соответсвенно получали оценку ... в другой команде

2008/6/2 Igor Khotin <chaos...@gmail.com>:

--
Borys L.