User Stories as a thinking tool
5 views
Skip to first unread message
Alexey Krivitsky
Oct 25, 2008, 2:25:59 PM10/25/08
to Agile Ukraine
Опубликовал на сайте статейку на тему историй и их отличия от требований. Как мне кажется среди сообщества (нашего и мирового) есть ряд недопониманий на этот счёт.
Я не претендую на правоту, но мне кажется, что стоит помнить о сути техники при её использовании.
http://www.agileukraine.org/2008/10/user-stories-as-thinking-tool.html
Я не претендую на правоту, но мне кажется, что стоит помнить о сути техники при её использовании.
http://www.agileukraine.org/2008/10/user-stories-as-thinking-tool.html
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
sun
Oct 25, 2008, 2:46:35 PM10/25/08
to agile-...@googlegroups.com
Классно написал.
У меня на одном тренинге тоже появилась мысль, что формат "As as a
[user], I can [do], so that [value]" позволяет сломать мозг и начать
смотреть на проблему со стороны реального пользователя системы.
У меня на одном тренинге тоже появилась мысль, что формат "As as a
[user], I can [do], so that [value]" позволяет сломать мозг и начать
смотреть на проблему со стороны реального пользователя системы.
2008/10/25 Alexey Krivitsky <alexeyk...@gmail.com>:
--
sun
Artjom Serdyuk
Oct 25, 2008, 2:46:57 PM10/25/08
to Agile Software Development Group, Ukraine
Хорошая статья, Лёша! Я лично с таким регулярно сталкиваюсь в роли
Продакт Оунера.
Моих пять копеек:
Как правило, заказчики сопротивляются докапыванию до сути проблемы.
Как говорил Евгений Компаниец в ветке про Продакт оунера, они приходят
с уже заранее готовыми решениями. Как с этим бороться??
И ещё: по-моему, 5 whys (как и Fishbone Diagrams) - достаточно слабый
инструмент анализа проблем. В частности, потому что позволяет найти
необходимые причины, но в большинстве случаев не находит все
достаточные причины.
Я лично предпочитаю и рекомендую Дерево Текущей Реальности и Диаграмму
решения конфликта Голдратта. Если интересно, могу рассказать и
показать подробнее.
On Oct 25, 9:25 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Продакт Оунера.
Моих пять копеек:
Как правило, заказчики сопротивляются докапыванию до сути проблемы.
Как говорил Евгений Компаниец в ветке про Продакт оунера, они приходят
с уже заранее готовыми решениями. Как с этим бороться??
И ещё: по-моему, 5 whys (как и Fishbone Diagrams) - достаточно слабый
инструмент анализа проблем. В частности, потому что позволяет найти
необходимые причины, но в большинстве случаев не находит все
достаточные причины.
Я лично предпочитаю и рекомендую Дерево Текущей Реальности и Диаграмму
решения конфликта Голдратта. Если интересно, могу рассказать и
показать подробнее.
On Oct 25, 9:25 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Artjom Serdyuk
Oct 25, 2008, 2:48:19 PM10/25/08
to Agile Software Development Group, Ukraine
А у нас продакт оунеры сопротилвяются писанию so that <value> изо всех
сил!
It makes me mad! Чем их можно переубедить?
On Oct 25, 9:46 pm, sun <aleksey.solnt...@gmail.com> wrote:
> Классно написал.
> У меня на одном тренинге тоже появилась мысль, что формат "As as a
> [user], I can [do], so that [value]" позволяет сломать мозг и начать
> смотреть на проблему со стороны реального пользователя системы.
>
> 2008/10/25 Alexey Krivitsky <alexeykrivit...@gmail.com>:
сил!
It makes me mad! Чем их можно переубедить?
On Oct 25, 9:46 pm, sun <aleksey.solnt...@gmail.com> wrote:
> Классно написал.
> У меня на одном тренинге тоже появилась мысль, что формат "As as a
> [user], I can [do], so that [value]" позволяет сломать мозг и начать
> смотреть на проблему со стороны реального пользователя системы.
>
Alexey Krivitsky
Oct 25, 2008, 2:49:27 PM10/25/08
to agile-...@googlegroups.com
Спасибо за комменты.
Расскажи плиз про Дерево и Голдратта (хоть я и читал, но техники не помню)
Расскажи плиз про Дерево и Голдратта (хоть я и читал, но техники не помню)
2008/10/25 Artjom Serdyuk <artem....@gmail.com>
Alexey Krivitsky
Oct 25, 2008, 2:52:05 PM10/25/08
to agile-...@googlegroups.com
Спасибо за коммент, Лёша.
Мозг таки-да ломает. Но многим проще сломать технику, чем свой мозг. "Привычка - вторая натура".
Мозг таки-да ломает. Но многим проще сломать технику, чем свой мозг. "Привычка - вторая натура".
2008/10/25 sun <aleksey....@gmail.com>
Alexey Krivitsky
Oct 25, 2008, 2:51:13 PM10/25/08
to agile-...@googlegroups.com
Как вариант - дописывать за них. При чём всякую чушь, пусть исправляют :)
А лучше, конечно объяснить зачем это нужно.
Но как минимум обговорить цель истории во время её разбора для оценки и планирования на спринт.
А лучше, конечно объяснить зачем это нужно.
Но как минимум обговорить цель истории во время её разбора для оценки и планирования на спринт.
2008/10/25 Artjom Serdyuk <artem....@gmail.com>
Artjom Serdyuk
Oct 25, 2008, 4:21:24 PM10/25/08
to Agile Software Development Group, Ukraine
Вкратце так:
Дерево текущей реальности позволяет выявить одну или несколько причин
ВСЕХ проблем в системе (Голдратт уверен, что у всех проблем - одна
причина, "узкое место")
1) выписываем 5-10 проблем
2) находим между ними причинно-следственные взаимосвязи.
Причины рисуют ниже следствий. От причины к следствию рисуем стрелку.
Если причины соединённы между собой связью "И", стрелки от них к
следствию объединяются овалом. Если причины связаны связью "ИЛИ",
стрелки ничем не объединяем
3) дописываем недостающие причины и следствия. Строим дерево вверх до
тех пор, пока не прийдём к главному негативному эффекту наших проблем.
Строим дерево вниз до тех пор, пока не доберёмся до одной причины всех
наших негараздив.
В дереве может быть много уровней, как правило больше пяти. Например,
оно может выглядеть так - http://deming.ru/TeorUpr/TeorOgrGoldKons/3_3.htm
В ДТР важно указать все достаточные причины. Проверяется это так:
проговариваем все причины "Так как (первая причина) и (вторая причина)
или (третья причина) то (следствие), потому что ....". Если удаётся
вставить "потому что", значит мы пропустили ещё одну причину.
Например, у нас есть такое построение: так как на улице зима, то в
доме холодно. Проверим, все ли причины перечислены? "Так как на улице
зима то в доме холодно, потому что...". Явно в доме холодно, потому
что из окон и дверей дует, и батареи не затопили. Т.е. мы нашли
недостающие причины.
Вообще, есть аж с десяток таких проверок логических построений. Они
называются "Критерии проверки логических построений", их описал Уильям
Детмер в своей книжке http://alpina.ru/book/529/.
===================================
Дерево решения конфликта.
Голдратт утверждает, что в основе текущего положения дел лежат
компромисы. Т.е. были конфликты, которые были решены частичным
удовлетворением всех сторон. В итоге ни одна сторона не довольна, но
менять текущее положение дел - всем дороже. ДРК призвано вскрыть
конфликт и предложить его решение, которое устроит всех.
1) Рисуем такую фигуру - http://deming.ru/TeorUpr/TeorOgrGoldKons/4_37.htm
. В англоязычной литературе квадраты обозначают А(вместо З), В и
В' (вместо У1 и У2), С и С' (вместо М1 и М2)
2) В квадратике "З" пишем цель, которой мы хотим достичь. Например,
"увеличить прибыль"
3) В квадратиках У1 и У2 пишем условия, необходимые для выполнения
этой цели. Как правило, это берётся из дерева. Например У1: "увеличить
продажи", и У2 "сократить затраты".
4) В квадратиках М1 и М2 пишем методы обеспечения условий 1 и 2.
Например М1: нанять 10 новых дилеров, и М2: уволить 15 сотрудников.
Если мы выбрали У1 и У2 правильно, то между М1 и М2 есть противоречие:
либо они взаимоисключающие, либо и на то, и на другое не хватит
ресурсов.
5) описываем в явном виде связи между З, У1 и У2: чтобы достичь З,
нужно выполнить У1, потому что 1), 2), и т.п. Например: чтобы
увеличить прибыль нужно увеличить продажи, потому что 1) мы можем
производить больше, 2) мы можем продавать больше, рынок ещё не
выбран... и т.д.
6) то же самое делаем для связей У1-М1 и У2-М2.
7) Находим самые слабые связи в плане объяснения "потому что". Исходя
из них, формулируем прорыв, который внимает противоречие.
ДРК может выглядеть так: http://deming.ru/TeorUpr/TeorOgrGoldKons/4_9.htm
На самом деле, эта штука не совсем "light-weight", и её намного проще
показать, чем объяснить. Если хочешь, в след среду после Люксофтовской
конференции могу показать, как это делается и поделиться книжкой
Детмера. Или на очередном Клубе.
Да, ещё у меня есть подробное объяснение, как строить деревья, и
примеры. Могу их прислать или сюда прикрепить, если кто-то объяснит
как ;))
On Oct 25, 9:49 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Дерево текущей реальности позволяет выявить одну или несколько причин
ВСЕХ проблем в системе (Голдратт уверен, что у всех проблем - одна
причина, "узкое место")
1) выписываем 5-10 проблем
2) находим между ними причинно-следственные взаимосвязи.
Причины рисуют ниже следствий. От причины к следствию рисуем стрелку.
Если причины соединённы между собой связью "И", стрелки от них к
следствию объединяются овалом. Если причины связаны связью "ИЛИ",
стрелки ничем не объединяем
3) дописываем недостающие причины и следствия. Строим дерево вверх до
тех пор, пока не прийдём к главному негативному эффекту наших проблем.
Строим дерево вниз до тех пор, пока не доберёмся до одной причины всех
наших негараздив.
В дереве может быть много уровней, как правило больше пяти. Например,
оно может выглядеть так - http://deming.ru/TeorUpr/TeorOgrGoldKons/3_3.htm
В ДТР важно указать все достаточные причины. Проверяется это так:
проговариваем все причины "Так как (первая причина) и (вторая причина)
или (третья причина) то (следствие), потому что ....". Если удаётся
вставить "потому что", значит мы пропустили ещё одну причину.
Например, у нас есть такое построение: так как на улице зима, то в
доме холодно. Проверим, все ли причины перечислены? "Так как на улице
зима то в доме холодно, потому что...". Явно в доме холодно, потому
что из окон и дверей дует, и батареи не затопили. Т.е. мы нашли
недостающие причины.
Вообще, есть аж с десяток таких проверок логических построений. Они
называются "Критерии проверки логических построений", их описал Уильям
Детмер в своей книжке http://alpina.ru/book/529/.
===================================
Дерево решения конфликта.
Голдратт утверждает, что в основе текущего положения дел лежат
компромисы. Т.е. были конфликты, которые были решены частичным
удовлетворением всех сторон. В итоге ни одна сторона не довольна, но
менять текущее положение дел - всем дороже. ДРК призвано вскрыть
конфликт и предложить его решение, которое устроит всех.
1) Рисуем такую фигуру - http://deming.ru/TeorUpr/TeorOgrGoldKons/4_37.htm
. В англоязычной литературе квадраты обозначают А(вместо З), В и
В' (вместо У1 и У2), С и С' (вместо М1 и М2)
2) В квадратике "З" пишем цель, которой мы хотим достичь. Например,
"увеличить прибыль"
3) В квадратиках У1 и У2 пишем условия, необходимые для выполнения
этой цели. Как правило, это берётся из дерева. Например У1: "увеличить
продажи", и У2 "сократить затраты".
4) В квадратиках М1 и М2 пишем методы обеспечения условий 1 и 2.
Например М1: нанять 10 новых дилеров, и М2: уволить 15 сотрудников.
Если мы выбрали У1 и У2 правильно, то между М1 и М2 есть противоречие:
либо они взаимоисключающие, либо и на то, и на другое не хватит
ресурсов.
5) описываем в явном виде связи между З, У1 и У2: чтобы достичь З,
нужно выполнить У1, потому что 1), 2), и т.п. Например: чтобы
увеличить прибыль нужно увеличить продажи, потому что 1) мы можем
производить больше, 2) мы можем продавать больше, рынок ещё не
выбран... и т.д.
6) то же самое делаем для связей У1-М1 и У2-М2.
7) Находим самые слабые связи в плане объяснения "потому что". Исходя
из них, формулируем прорыв, который внимает противоречие.
ДРК может выглядеть так: http://deming.ru/TeorUpr/TeorOgrGoldKons/4_9.htm
На самом деле, эта штука не совсем "light-weight", и её намного проще
показать, чем объяснить. Если хочешь, в след среду после Люксофтовской
конференции могу показать, как это делается и поделиться книжкой
Детмера. Или на очередном Клубе.
Да, ещё у меня есть подробное объяснение, как строить деревья, и
примеры. Могу их прислать или сюда прикрепить, если кто-то объяснит
как ;))
On Oct 25, 9:49 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> Спасибо за комменты.
> Расскажи плиз про Дерево и Голдратта (хоть я и читал, но техники не помню)
>
> 2008/10/25 Artjom Serdyuk <artem.serd...@gmail.com>
> Расскажи плиз про Дерево и Голдратта (хоть я и читал, но техники не помню)
>
Alexey Krivitsky
Oct 25, 2008, 4:45:15 PM10/25/08
to agile-...@googlegroups.com, Serhiy Yevtushenko
вау, кладезь
что если этому посвятить встречу в клубе?
сергей евтушенко, я думаю, был бы рад поучаствовать
что если этому посвятить встречу в клубе?
сергей евтушенко, я думаю, был бы рад поучаствовать
2008/10/25 Artjom Serdyuk <artem....@gmail.com>
Artjom Serdyuk
Oct 25, 2008, 4:47:47 PM10/25/08
to Agile Software Development Group, Ukraine
Если будут желающие - я всегда готов ;))
On Oct 25, 11:45 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
On Oct 25, 11:45 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> вау, кладезь
>
> что если этому посвятить встречу в клубе?
>
> сергей евтушенко, я думаю, был бы рад поучаствовать
>
> 2008/10/25 Artjom Serdyuk <artem.serd...@gmail.com>
>
> что если этому посвятить встречу в клубе?
>
> сергей евтушенко, я думаю, был бы рад поучаствовать
>
>
>
>
> > Вкратце так:
>
> > Дерево текущей реальности позволяет выявить одну или несколько причин
> > ВСЕХ проблем в системе (Голдратт уверен, что у всех проблем - одна
> > причина, "узкое место")
> > 1) выписываем 5-10 проблем
> > 2) находим между ними причинно-следственные взаимосвязи.
>
> > Причины рисуют ниже следствий. От причины к следствию рисуем стрелку.
> > Если причины соединённы между собой связью "И", стрелки от них к
> > следствию объединяются овалом. Если причины связаны связью "ИЛИ",
> > стрелки ничем не объединяем
>
> > 3) дописываем недостающие причины и следствия. Строим дерево вверх до
> > тех пор, пока не прийдём к главному негативному эффекту наших проблем.
> > Строим дерево вниз до тех пор, пока не доберёмся до одной причины всех
> > наших негараздив.
>
> > В дереве может быть много уровней, как правило больше пяти. Например,
> > оно может выглядеть так -http://deming.ru/TeorUpr/TeorOgrGoldKons/3_3.htm
>
>
> > Вкратце так:
>
> > Дерево текущей реальности позволяет выявить одну или несколько причин
> > ВСЕХ проблем в системе (Голдратт уверен, что у всех проблем - одна
> > причина, "узкое место")
> > 1) выписываем 5-10 проблем
> > 2) находим между ними причинно-следственные взаимосвязи.
>
> > Причины рисуют ниже следствий. От причины к следствию рисуем стрелку.
> > Если причины соединённы между собой связью "И", стрелки от них к
> > следствию объединяются овалом. Если причины связаны связью "ИЛИ",
> > стрелки ничем не объединяем
>
> > 3) дописываем недостающие причины и следствия. Строим дерево вверх до
> > тех пор, пока не прийдём к главному негативному эффекту наших проблем.
> > Строим дерево вниз до тех пор, пока не доберёмся до одной причины всех
> > наших негараздив.
>
> > В дереве может быть много уровней, как правило больше пяти. Например,
>
> > В ДТР важно указать все достаточные причины. Проверяется это так:
> > проговариваем все причины "Так как (первая причина) и (вторая причина)
> > или (третья причина) то (следствие), потому что ....". Если удаётся
> > вставить "потому что", значит мы пропустили ещё одну причину.
>
> > Например, у нас есть такое построение: так как на улице зима, то в
> > доме холодно. Проверим, все ли причины перечислены? "Так как на улице
> > зима то в доме холодно, потому что...". Явно в доме холодно, потому
> > что из окон и дверей дует, и батареи не затопили. Т.е. мы нашли
> > недостающие причины.
>
> > Вообще, есть аж с десяток таких проверок логических построений. Они
> > называются "Критерии проверки логических построений", их описал Уильям
> > Детмер в своей книжкеhttp://alpina.ru/book/529/.
> > В ДТР важно указать все достаточные причины. Проверяется это так:
> > проговариваем все причины "Так как (первая причина) и (вторая причина)
> > или (третья причина) то (следствие), потому что ....". Если удаётся
> > вставить "потому что", значит мы пропустили ещё одну причину.
>
> > Например, у нас есть такое построение: так как на улице зима, то в
> > доме холодно. Проверим, все ли причины перечислены? "Так как на улице
> > зима то в доме холодно, потому что...". Явно в доме холодно, потому
> > что из окон и дверей дует, и батареи не затопили. Т.е. мы нашли
> > недостающие причины.
>
> > Вообще, есть аж с десяток таких проверок логических построений. Они
> > называются "Критерии проверки логических построений", их описал Уильям
>
> > ===================================
> > Дерево решения конфликта.
> > Голдратт утверждает, что в основе текущего положения дел лежат
> > компромисы. Т.е. были конфликты, которые были решены частичным
> > удовлетворением всех сторон. В итоге ни одна сторона не довольна, но
> > менять текущее положение дел - всем дороже. ДРК призвано вскрыть
> > конфликт и предложить его решение, которое устроит всех.
> > 1) Рисуем такую фигуру -http://deming.ru/TeorUpr/TeorOgrGoldKons/4_37.htm
> > ===================================
> > Дерево решения конфликта.
> > Голдратт утверждает, что в основе текущего положения дел лежат
> > компромисы. Т.е. были конфликты, которые были решены частичным
> > удовлетворением всех сторон. В итоге ни одна сторона не довольна, но
> > менять текущее положение дел - всем дороже. ДРК призвано вскрыть
> > конфликт и предложить его решение, которое устроит всех.
Alexander Rivkind
Oct 25, 2008, 6:18:59 PM10/25/08
to agile-...@googlegroups.com
Я тоже буду рад поучаствовать. И Серегу повидать тоже рад буду.
--
Best Regards, Alik.
--
Best Regards, Alik.
Mykola Gurov
Oct 26, 2008, 2:08:35 AM10/26/08
to Agile Software Development Group, Ukraine
Статья, несомненно, полезная.
Но меня мучают сомения по поводу того, насколько можно назвать
последнюю редакцию требования историей ("...не пропускать...иметь
возможность..."). Попробую объяснить почему.
ИМХО это не читается как история или даже эпика (epic). Это цель.
Может даже миссия, как в данном конкретном примере календаря. Это чаще
всего не положишь в Product Backog - слишком абстрактно и потенциально
бесконечно, чтобы можно было даже грубо оценить размер и
приоритезировать. В Product Backlog, ИМХО пойдут скорее стратегии
достижения таких целей (собственно типа двух историй, приведенных в
статье).
Или я что-то упускаю?
P.S. не оспариваю важность явного определения целей.
On Oct 25, 8:25 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Но меня мучают сомения по поводу того, насколько можно назвать
последнюю редакцию требования историей ("...не пропускать...иметь
возможность..."). Попробую объяснить почему.
ИМХО это не читается как история или даже эпика (epic). Это цель.
Может даже миссия, как в данном конкретном примере календаря. Это чаще
всего не положишь в Product Backog - слишком абстрактно и потенциально
бесконечно, чтобы можно было даже грубо оценить размер и
приоритезировать. В Product Backlog, ИМХО пойдут скорее стратегии
достижения таких целей (собственно типа двух историй, приведенных в
статье).
Или я что-то упускаю?
P.S. не оспариваю важность явного определения целей.
On Oct 25, 8:25 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Evgeny Kompaniyets
Oct 26, 2008, 4:47:10 AM10/26/08
to Agile Software Development Group, Ukraine
Мне тоже нравится как тема для клуба.
Serhiy Yevtushenko
Oct 27, 2008, 8:07:16 AM10/27/08
to agile-...@googlegroups.com
Касательно недопонимания историй
У Джеймса Шора (James Shore) есть мнение, что многое, что говориться об историях, имеет свои корни в раннем ХП, когда не понимали до конца ролей историй.
И, с его точки зрения, требования и история - это вещи ортогональные.
То есть, история - это просто название, которое позволяет отслеживать кусок работы, доставляющий ценность заказчику.
А требования - это вещь ортогональная. То есть, если работаете в сложной области, или распределенно - это ОК иметь документ с требованиями.
Также я бы добавил для затравки еще 2 момента, которые есть в истории.
Маленький размер - иначе никакого менеджмента объемом работ
И однозначность - чтобы нельзя было раздувать объем какой-то истории (Здесь вспоминается формат ФДД (как <выполняющий такую то роль>, выполнить <действие> на <объекте>)
Кто что думает по этому поводу ?
Сергей Евтушенко
26 октября 2008 г. 10:47 пользователь Evgeny Kompaniyets <evg...@gmail.com> написал:
Alexey Krivitsky
Oct 27, 2008, 5:53:11 PM10/27/08
to agile-...@googlegroups.com
Я не уверен, что ты меня убедил на счёт ортогональности. Хотя что-то определённо в этом есть..
2008/10/27 Serhiy Yevtushenko <syevtu...@gmail.com>
Reply all
Reply to author
Forward
0 new messages