sprint demos in distributed env
Alexey Krivitsky
есть вопрос к специалистам рапределенного скрама:
как стоит организовывать спринт-демонстрации, если заказчики (PO) и
команда удалены друг от друга.
поделитесь опытом.
опции
1 демонстрация командой
a) мы пытались проводить демонстрации по skype+desktop sharing, но
демонстрировать что-то не видя аудиторию было очень тяжело.
широкоугольные камеры могли бы помочь.
б) так же есть негативный опыт от демонстраций, где каждый
программист (пара) показывал фичи, которые сделал - не было
целостности демонстрации. страдали заказчики.
2 демонстрация посредником на стороне заказчика
a) демонстрация фич кем-то на стороне заказчика (не командой)
проходили лучше для заказчиков, но это не совсем по scrum, так как
команда чувствует себя как бы вне процесса демонстраций, что
демотивирует
оптимально, конечно, посылать разных посредников на сторону заказчика
для демонстраций, или встречаться всем в одном месте. но при частых
циклах (коротких спринтах), это редко является опцией.
буду рад за любые советы.
леша
Artem Marchenko
времени у него было не очень много. Пытались решать вопрос
подготавливая легко-скачиваемые демки, чтобы он могу их установить и
попробовать в один клик. Кроме того, product owner (proxy product
owner, если хотите), периодически летал к Заказчику.
В общем-то работало, но надо учесть, что мы с самого начала достаточно
неплохо представляли себе, что Заказчику на самом деле нужно.
Удачи!
-Артём.
On 16 май, 16:32, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Artem Marchenko
об очень похожем :)
http://agilesoftwaredevelopment.com/scrum-customer-management-not-partic
krivitsky
Спасибо за линк. Очень полезные выводы.
Вот мои комментарии
>1. Get a proxy product owner
Из моего опыта - это абсолютная правда. Проекту, в котором много
ответственных лиц на стороне заказчика, обычно нехватает
синхронизации, целей ну и как следствие контроля. Такие проекты обычно
быстро разочаровывают команду.
Я благодарен Scrum за недвусмысленность в отношении к Product Owner.
Ken Schwaber называет (http://www.scrumalliance.org/articles/12-scrum-
release-) человека, который выполняет обязанности PO, так же "single
wringable neck" (что-то типа "единственная скручиваемая шея", перевод
можно оспорить) и это объяснимо - только этот человек принимает
конечные решения по использованию проектных инвестиций для увеличения
прибыли.
Майк Виздос написал интересный пост на своем блоге на этот счет:
http://www.implementingscrum.com/cartoons/cartoons_files/implementingscrum-20070416.html
> 2. Push demos to the customers
Согласен. "Если заказчик не идет на демо митинг для осмотра
инкремента, инкремент сам идет к заказчику"...
Но тут есть одно "но" как по мне. Демо митинги предназачены не только
для демонстрации потенциально поставляемого инкремента продукта, но
также эо возможность общения команды и заказчика. На этом митинге
хорошие команды поделятся с заказчиком на этом митинге своими
страхами, проблемами, гипотезами, идеями и прочее. Хорошие заказчики
же создадут безопасную атмосферу для подобного диалога и учтут
пожелания команды.
Так что я считаю этот момент ключевым, так как этот митинг - часть
ретроспективы, а ретроспективы - это отличительное свойство agile
проектов.
> 3. Reserve some slack for urgent requests
Да, иногда просто нет другого выхода. Когда проект параллельно в
продакшине и разработке, кто-то должен иметь возможность делать
срочные починки, и выделение времени может сработать довольно неплохо.
Статистика появления проблем (частота, время на починку..) могут быть
весьма полезными статистическими характеристиками помогающими команда
выделять необходимое кол-во людей на поддержку.
Другой стратегией может быть веделение людей, которые работают на
поддержке живой системы во время спринта. Этот подход имеет свои
недостатки и плюсы. Недостатком может является то, что авторы
проблематичных фич могут быть невовлечены в решение проблем, возникших
с "их" кодом на живой системе, таким образом они не получат
возможность поучиться на своих ошибках. Но это может решаться за счет
проведения более детальных митингов по проблемам живой системы, что
позволит всей проектной команде делать выводы и учиться. Люди, которые
"сидят на поддержке" должны присутствовать на scrum митинге и
рассказывать всем "новости с фронта". Это я понял на своем опыте.
Плюсом же является более простое планирование спринта остальными
членами команды на основании оценок и своих возможностей.
> 4. Explain the costs
На мой взгляд является одной из важнейших ролей скрам мастера является
научить команду объяснять заказчику суть проблем таким образом, чтоб
заказчик мог принимать адекватные решения (которые базируются на
финансовых характеристиках). Команда, которая умеет это делать, думаю
уже не нуждается в скрам мастере...
On May 16, 10:55 pm, Artem Marchenko <artem.marche...@gmail.com>
wrote:
> Кстати, вспомнил: я буквально вчера писал на AgileSoftwareDevelopment
> об очень похожем :)http://agilesoftwaredevelopment.com/scrum-customer-management-not-partic
Max Pendyschtschuk
Kennt man wirklich jeden ьber 3 Ecken? Die Antworten gibt's bei Yahoo! Clever.
Alexey Krivitsky
всё что касается agile - "по теме" :)
пиши.