sprint demos in distributed env

1 view
Skip to first unread message

Alexey Krivitsky

unread,
May 16, 2007, 9:32:45 AM5/16/07
to Agile Ukraine
всем привет.

есть вопрос к специалистам рапределенного скрама:
как стоит организовывать спринт-демонстрации, если заказчики (PO) и
команда удалены друг от друга.

поделитесь опытом.

опции
1 демонстрация командой
a) мы пытались проводить демонстрации по skype+desktop sharing, но
демонстрировать что-то не видя аудиторию было очень тяжело.
широкоугольные камеры могли бы помочь.
б) так же есть негативный опыт от демонстраций, где каждый
программист (пара) показывал фичи, которые сделал - не было
целостности демонстрации. страдали заказчики.

2 демонстрация посредником на стороне заказчика
a) демонстрация фич кем-то на стороне заказчика (не командой)
проходили лучше для заказчиков, но это не совсем по scrum, так как
команда чувствует себя как бы вне процесса демонстраций, что
демотивирует

оптимально, конечно, посылать разных посредников на сторону заказчика
для демонстраций, или встречаться всем в одном месте. но при частых
циклах (коротких спринтах), это редко является опцией.

буду рад за любые советы.

леша

Artem Marchenko

unread,
May 16, 2007, 1:20:28 PM5/16/07
to Agile Software Development Group, Ukraine
Некогда наш заказчик находился в пятиста километрах от команды и
времени у него было не очень много. Пытались решать вопрос
подготавливая легко-скачиваемые демки, чтобы он могу их установить и
попробовать в один клик. Кроме того, product owner (proxy product
owner, если хотите), периодически летал к Заказчику.

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

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

On 16 май, 16:32, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

Artem Marchenko

unread,
May 16, 2007, 4:55:41 PM5/16/07
to Agile Software Development Group, Ukraine
Кстати, вспомнил: я буквально вчера писал на AgileSoftwareDevelopment
об очень похожем :)
http://agilesoftwaredevelopment.com/scrum-customer-management-not-partic

krivitsky

unread,
May 20, 2007, 4:31:07 AM5/20/07
to Agile Software Development Group, Ukraine
Привет Артем.
Спасибо за линк. Очень полезные выводы.

Вот мои комментарии
>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

unread,
May 21, 2007, 1:55:51 AM5/21/07
to agile-...@googlegroups.com
Привіт,
 
мабуть не по темі, але можливо чимось допоможе (хоча б інформативно):
 
Agile Offshoring : It's hard work but it works!
 
успіхів,
Максим


Kennt man wirklich jeden ьber 3 Ecken? Die Antworten gibt's bei Yahoo! Clever.

Alexey Krivitsky

unread,
May 21, 2007, 3:13:22 AM5/21/07
to agile-...@googlegroups.com
спасибо Макс,

всё что касается agile - "по теме" :)
пиши.

Reply all
Reply to author
Forward
0 new messages