Просьба подсказать или ткнуть носом - вопрос о планировании/приоритезации зависимых задач в Scrum
Roman
Alexey Krivitsky
1) команда имеет право делать истории в течение спринта в лучшем с точки зрения команды порядке
лучше, если она при этом пообщалась с PO и уговорила его
2) не разбивать истории - CRUD одна история
тогда нет такой проблемы
3) во время планирования спринта обсуждать приоритеты с PO, где рассказывать ему о более логичном порядке из-за тех зависимостей (для этого планирование и проходит вместе с ним)
4) отравить скрам-мастера
5) разобраться в том, почему все так сложно
тут меня насторожило "...сначала команда ждет создание структуры БД, затем реализацию бизнес-логики"
- кто такая команда?
- от кого она ждет?
---
Крв
Вводная - есть достаточно глобальная задача добавления маркетинговых скидочных/бонусных акций. Product Owner благополучно нагенерировал набор пользовательских историй и пораставлял приоритеты. В итоге получилось следующее - согласно приоритетам и оценке трудоемкости на спринт были поставлены истории: добавление, просмотр текущих акций, редактирование, удаление и тд (приведены не все, а только те, что вызвали вопрос), то есть - типичный набор CRUD.Проблема - все делается с нуля, то есть нужно разработать структуру БД, бизнес-логику и пользовательский интерфейс. Примерная последовательность разработки (ИМХО): схема БД -> логика (работа с БД и обертки) -> интерфейс просмотра -> интерфейс создания и редактирования и тд.,то есть набор последовательных задач. PO выставил приоритеты - создание, просмотр, редактирование, удаление. В итоге - сначала команда ждет создание структуры БД, затем реализацию бизнес-логики, а после этого начинается перетягивание страницы просмотра списка записей для добавления ссылок на редактирование и удаление.В запасе есть еще набор историй, которыми можно было бы заняться во время ожидания, но у них низкий приоритет (хотя и малая трудозатратность) - Scrum Master их блокирует.Собственно вопрос - как правильно учитывать зависимость реализации пользовательских историй и задач на спринт? Интересует опыт решения подобных проблем. Можно ли заставлять PO переставлять приоритеты на этапе планирования спринта, исходя из связности/зависимости историй в Product Backlog?
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
Serge Levin
> схема БД -> логика (работа с БД и обертки) -> интерфейс
> просмотра -> интерфейс создания и редактирования и тд.,то есть набор
> последовательных задач.
Попробуйте посмотреть в сторону Onion Architecture. Возможно многие
процессы проектирования и разработки сможете делать параллельно.
Удачи,
Сергей
sergiy movchan
Проблема - все делается с нуля, то есть нужно разработать структуру БД, бизнес-логику и пользовательский интерфейс. Примерная последовательность разработки (ИМХО): схема БД -> логика (работа с БД и обертки) -> интерфейс просмотра -> интерфейс создания и редактирования и тд.,то есть набор последовательных задач.
В итоге - сначала команда ждет создание структуры БД, затем реализацию бизнес-логики, а после этого начинается перетягивание страницы просмотра списка записей для добавления ссылок на редактирование и удаление.
...dali bude...
Borys Lebeda
ДжейБи (который Rainsberger, http://www.jbrains.ca/) тоже бы задал
вопрос: нужна ли вам база данных на данном этапе? Может покажете
продакт оунеру сперва UI ...
Где гарантия, что после того как вы потратите неделю на создание
структуры БД, продакт оунер не скажет, например, вот это?
"Знаете у нас до конца года ожидается целых 4 бонусных акции, я их
вышлю Вам в PowerPoint. Сосредоточтесь на том, что бы они летали на
веб-страничке, а админкой мы займёмся в январе, когда их будет 38."
Обидно, наверное, будет до соплей: вы уже такую класную диаграмку нарисовали!
Может быть вам на данном этапе от бонусной акции нужно только описание
и процент скидки?
Вы будете БД "на вырост" делать?
2011/10/13 Alexey Krivitsky <alexeyk...@gmail.com>:
--
Borys L.
Alexey Krivitsky
Были ли наши советы тебе полезны? Как ты можешь переформулировать свой вопрос, после прочтения наших ответов?
Леша
Artem Marchenko
Согласен с предыдущими ораторами, хочу отметить один нюанс.
Учиться работать так, чтобы не надо было тратить неделю на создание
структуры страниц, бизнес логики и т.д. - это, конечно, полезно, -
однако если прямо сейчас команде требуется куча времени на подготовку
к первому элементу CRUD'а, так и скажите Product Owner'у. Мол, любой
из элементов CRUD'а, поставленный первым потребует примерно N
дополнительных story points.
А дальше - это уже его дело разбираться настолько ли ему нужна эта
функциональность прямо сейчас (может простенького UI-прототипа хватило
бы для начала) и этот ли элемент CRUD'а ему хочется увидеть поскорее.
Может быть увидев, что весь CRUD в спринт не влазит, он захочет
сначала увидеть просмотр записей (как наиболее частый/важный элемент),
а создание, удаление и редактирование подождут до следующего спринта.
С уважением,
Артём.
On Oct 14, 1:49 pm, Alexey Krivitsky <alexeykrivit...@gmail.com>
wrote:
> Рома,
>
> Были ли наши советы тебе полезны? Как ты можешь переформулировать свой
> вопрос, после прочтения наших ответов?
>
> Леша
>
> 2011/10/14 Borys Lebeda <borys.leb...@gmail.com>
>
>
>
>
>
>
>
> > Самый грамотный ответ номер 5:
>
> > ДжейБи (который Rainsberger,http://www.jbrains.ca/) тоже бы задал
> > вопрос: нужна ли вам база данных на данном этапе? Может покажете
> > продакт оунеру сперва UI ...
> > Где гарантия, что после того как вы потратите неделю на создание
> > структуры БД, продакт оунер не скажет, например, вот это?
> > "Знаете у нас до конца года ожидается целых 4 бонусных акции, я их
> > вышлю Вам в PowerPoint. Сосредоточтесь на том, что бы они летали на
> > веб-страничке, а админкой мы займёмся в январе, когда их будет 38."
> > Обидно, наверное, будет до соплей: вы уже такую класную диаграмку
> > нарисовали!
>
> > Может быть вам на данном этапе от бонусной акции нужно только описание
> > и процент скидки?
> > Вы будете БД "на вырост" делать?
>
> > 2011/10/13 Alexey Krivitsky <alexeykrivit...@gmail.com>:
> > > Ответов несколько
>
> > > 1) команда имеет право делать истории в течение спринта в лучшем с точки
> > > зрения команды порядке
> > > лучше, если она при этом пообщалась с PO и уговорила его
>
> > > 2) не разбивать истории - CRUD одна история
> > > тогда нет такой проблемы
>
> > > 3) во время планирования спринта обсуждать приоритеты с PO, где
> > рассказывать
> > > ему о более логичном порядке из-за тех зависимостей (для этого
> > планирование
> > > и проходит вместе с ним)
>
> > > 4) отравить скрам-мастера
>
> > > 5) разобраться в том, почему все так сложно
> > > тут меня насторожило "...сначала команда ждет создание структуры БД,
> > затем
> > > реализацию бизнес-логики"
> > > - кто такая команда?
> > > - от кого она ждет?
>
> > > ---
> > > Крв
>
> > > 2011/10/13 Roman <roman.krutya...@gmail.com>
> > >> Agile Software Development Group, Ukraine,http://www.agileukraine.org/
>
> > >> To visit the group online see:
> > >>http://groups.google.com/group/agile-ukraine/
> > >> To post to this group send email to agile-...@googlegroups.com
> > >> To unsubscribe send email to agile-ukrain...@googlegroups.com
>
> > > --
> > > Agile Software Development Group, Ukraine,http://www.agileukraine.org/
>
> > > To visit the group online see:
> >http://groups.google.com/group/agile-ukraine/
> > > To post to this group send email to agile-...@googlegroups.com
> > > To unsubscribe send email to agile-ukrain...@googlegroups.com
>
> > --
> > Borys L.
>
> > --
> > Agile Software Development Group, Ukraine,http://www.agileukraine.org/
Roman Krutyakov
Рома,
Были ли наши советы тебе полезны? Как ты можешь переформулировать свой вопрос, после прочтения наших ответов?
Леша
Alexey Krivitsky
должна быть настолько детальной, чтоб можно было начинать что-то писать после ~15 минутного брифа с PO перед самым началом или даже без него.
можно, конечно, и бегать за каждой деталью. но это накладные расходы на перемещение ))
--
Alexey Krivitsky
ибо вопрос твой был на уровне SHU
---------
теперь ответ на уровне RI (для просветленных):
в принципе, можно вообще почти ничего не описывать в US, а иметь их больше как напоминание - "билетик на поговорить". а дальше, когда подходит очередь этой US к реализации - садиться вместе и решать что и как делать.
но это не очень вписывается в итеративную разработку (scrum) так как нет плана на спринт, но хорошо впишется в потоковую разработку "flow-based" (kanban) - тут важно понять, как вам удобно работать на данном этапе развития и какой подход приносить больше побочной пользы и несет меньше накладных расходов.
крв
Roman Krutyakov
в принципе, можно вообще почти ничего не описывать в US, а иметь их больше как напоминание - "билетик на поговорить". а дальше, когда подходит очередь этой US к реализации - садиться вместе и решать что и как делать.
но это не очень вписывается в итеративную разработку (scrum) так как нет плана на спринт, но хорошо впишется в потоковую разработку "flow-based" (kanban) - тут важно понять, как вам удобно работать на данном этапе развития и какой подход приносить больше побочной пользы и несет меньше накладных расходов.
Artem Marchenko
> поставили перед фактом - "с понедельника работаете по SCRUM". При этом над
> Хотелось бы услышать стороннее мнение на мой взгляд на организацию процесса
> работы . Я считаю, что в данной ситуации более эффективной будет потоковая
Сочувствую. А нельзя об этом поговорить с тем, кто поставил перед
фактом? Как бы "факт" Скрама требует кроссфункцианальную команду: в
вашем случае и с Java разработчиками, и с дизайнерами, и с флешерами.
А то получается как перевод отдела с велосипедов на машины, но только
дизайнеры продолжают пользоваться велосипедами.
Если поговорить и изменить что-то официально очень сложно, и бы
попробовал пообщаться с коллегами напрямую. В моей практике
встречались случаи успешного сопряжения agile и waterfall-команд
(особенно дизайнерских) через концепцию office hours. Так что вообще-
то дизайнеры работают по своему плану, но раз в день-два-три выделяют
час-два-три на помощь в том, что нужно разработчикам именно сейчас.
> Очень полезны. Вопрос собственно решен.
Кстати, как был решён вопрос? Интересно узнать.
> Однако теперь интересует еще одна вещь - насколько детализированной должна
> быть user story?
Ситуация у вас непростая, я бы подумал над возможностью
поэкспериментировать. Часть историй детализировать сильно, часть -
несильно, часть - оставить "билетиками на поговорить", а после спринта-
двух обсудить какой подход лучше работает для нервов, качества и
выдавания на гора именно того, что нужно PO.
On Oct 20, 10:39 pm, Roman Krutyakov <roman.krutya...@gmail.com>
wrote:
> 19 октября 2011 г. 13:32 пользователь Alexey Krivitsky <
> alexeykrivit...@gmail.com> написал: