как повысить эффективность скрама
Pavel Aksonov
себе fun для программистов, где они
запросто и вполне законно оценить
задачу в 40 часов работы, которую
реально сделать за 10, зато эти 40 часов
они проведут максимально интересно и
используя (или делая вид что
используют)
code review , pair programming, etc.
Многие скажут - зато за 40 часов код
будет намного качественнее! А
оказывается не всегда - у людей нет
стимула писать качественный код -
главное есть тесты, которые "проходят"
и функционал, который работает.
Относительно code review - некоторые члены
команды, видя плохой код, возмущались
(как они сказали постфактум при
разборе полетов), но команда "убалтала"
ревьювера заапрувить код ( "ведь
завтра демо, а изменить и
протестировать уже не успеем,
отрефакторим в следующем спринте, не
будем же мы заваливать демо!"). В итоге
на демо все красиво (на код ведь никто
не смотрит). На следующем спринте
команда просит добавить техническую
user story "отрефакторить класс такой-то"
для возможности добавления
дальнейшего функционала к этому
классу. Получается что команда даже
где-то заинтересована написать
некачественно (ведь это легче, меньше
внимания к деталям, больше времени
пообщаться на свободные темы :).
Собственно вопрос - как повысить
эффективность скрама? Например члены
команды предпочитают по несколько раз
в час запускать 20 мин remote run со всеми
selenium тестами как средство отладки
своего когда вместо того чтобы
использовать unit тестирование. Эти 20
минут они ждут или ходят по комнате :)
На ретроспективе это обсудили, сказали
что не повторится :) Но ощущение того,
что борешься со следствиями проблемы,
а не причинами - остались.
ИМХО, коллективная ответственность
пока работает хуже чем персональная.
"Сачкануть" при скраме гораздо легче
чем при прямом контроле со стороны team
лида. Всегда можно "подстраховаться"
взяв сложную user story и никто не заметит
что во время скрама "простые" задачи ты
делал достаточно медленно.
Artjom Serdyuk
не каждый день такое слышу от моих ПО )))
Если вы Продакт Оунер, я Вам скажу то же, что и им: оставьте команде
процесс. Требуйте результатов.
Самый легкий способ надавить на команду - дайте им бюджет "человеко-
дней", который нельзя превысить. Если интересно - я расскажу в
подробностях, как это делается.
Туда же: а что для Вас эффективность? Это когда все сидят и кодят? Или
когда из спринта в спринт команда делает все больше и больше? Если
второе - оставьте команду в покое, дайте им самим построить удобный
для себя процесс. Но результат требуйте, и к результату придирайтесь.
Команду отлично мотивирует (в меру) требовательный, но справедливый
Продакт Оунер.
Если же Вы - тимлид или СкрамМастер, тогда Вам вопрос - с какой
радости вдруг ваши программисты хотят писать плохой код? Может, они
привыкли, что ими рулят тим лиды, и им думать не надо? Или они ещё чем-
то недовольны?
А почему команда "убалтывает" того, кто делает ревью? Возможно, у
ревьюера и команды разные цели? Кто его тогда попросил сделать код
ревью - менеджер???
В любом случае, если за народом нужен постоянный контроль, с которого
позволяет "соскочить" Скрам - значит, у команды серьёзные проблемы. Я
бы копал в эту сторону.
Но я ещё раз подчеркнул бы. Сила аджайл девелопмента - в
САМООРГАНИЗУЮЩЕЙСЯ команде. Поэтому, с моей точки зрения, нужно как
можно меньше вмешиваться в процесс, и как можно больше давать народу
рулить самостоятельно.
Sergiy Movchan
--
...dali bude...
Pavel Aksonov
Павел, вы говорите как Продакт оунер (или проджект спонсор). Я чуть ли
не каждый день такое слышу от моих ПО )))
Если вы Продакт Оунер, я Вам скажу то же, что и им: оставьте команде
процесс. Требуйте результатов.
В процесс стараюсь не вмешиваться (правда вот в ретроспективе участвовал, это вмешательство? ), но спринт был завален (т.е. сделали не все что запланировано).
Сейчас команда не вешает проблемы на меня, я чувствую себя лучше, сосредоточен на требованиях к продукту, НО - проблемы никуда не делись :)
Самый легкий способ надавить на команду - дайте им бюджет "человеко-
дней", который нельзя превысить. Если интересно - я расскажу в
подробностях, как это делается.
Расскажите. Ещё расскажите, что всё-таки будет, если не вложатся. А то ведь получается как про британского полицейского без оружия - "Стой, или я ещё раз скажу стой".
Туда же: а что для Вас эффективность? Это когда все сидят и кодят? Или
когда из спринта в спринт команда делает все больше и больше? Если
второе - оставьте команду в покое, дайте им самим построить удобный
для себя процесс. Но результат требуйте, и к результату придирайтесь.
Команду отлично мотивирует (в меру) требовательный, но справедливый
Продакт Оунер.
Я считаю второе, и этого пока не наблюдается. Наблюдается то, что человек видит плохой код, ленится его переделать и добавить свой в уже хороший код, а добавляет свой код в этот плохой наивно считая что так будет быстрее ("а потом уже зарефакторим") Получается не быстрее. И так несколько раз :)
Так же получается что команда бессознательно (или сознательно) находит самого эффективного и пытается повесить проблемы на него :)
Если же Вы - тимлид или СкрамМастер, тогда Вам вопрос - с какой
радости вдруг ваши программисты хотят писать плохой код? Может, они
привыкли, что ими рулят тим лиды, и им думать не надо? Или они ещё чем-
то недовольны?
А почему команда "убалтывает" того, кто делает ревью? Возможно, у
ревьюера и команды разные цели? Кто его тогда попросил сделать код
ревью - менеджер???
Это было заложено мною вначале в сам процесс как правило. То есть любое юзер стори должно быть проревьювено. То есть по идее цель у команды одна. Сдать демо. Но за качеством никто не гонится - например смотреть exceptions в логах веб-сервера и решать скрытые проблемы или избегать кучи if.. else вместо применения соответствующих Design Patterns. Ведь этого всего не видно на демо.
В любом случае, если за народом нужен постоянный контроль, с которого
позволяет "соскочить" Скрам - значит, у команды серьёзные проблемы. Я
бы копал в эту сторону.
Копаю. Вижу как команда заметно активизируется под конец спринта (синдром студента, не так ли?), но я бы не назвал это самоорганизацией :)
Но я ещё раз подчеркнул бы. Сила аджайл девелопмента - в
САМООРГАНИЗУЮЩЕЙСЯ команде. Поэтому, с моей точки зрения, нужно как
можно меньше вмешиваться в процесс, и как можно больше давать народу
рулить самостоятельно.
Позволяю. Завтра планирование, посмотрим на следующий спринт...
Artjom Serdyuk
А) найдите кастомера на проект (или кусок своего продукта). Это может
быть внутренний кастомер или внешний.
Б) определите Scope в виде приоретизированного беклога
В) попросите 1-2-3 лид девелоперов сделать оценки историй беклога в
человеко-днях
Г) добавьте буфер сколько посчитаете нужным (обычно где-то процентов
30-50)
Д) умножте на "стоимость часа" и "продайте" заказчику. А можете и не
продавать. Бюждет у вас уже есть.
Внимание! У продакт оунеров есть острое желание поделить человеко-дни
на кол-во народу в команде и получить дату окончания проекта. Нельзя!
Это очень нелинейно связанные величины! Пожалуйста, оставьте человеко-
дни для бюджета и подсчета денег.
Е) Отдайте бюджет команде. Скажите, что им прийдётся записывать время,
которое они фактически потратили на разработку, и это время не должно
привысить бюджет (иначе покупатель у нас просто ничего не купит).
Внимание! Не забудьте завести систему треканья отработанного времени и
повесить контроль за заполнением на Скрам-мастера.
Ж) Попросите команду оценить истории в стори-поинтах. Попросите
примерно прикинуть, сколько спринтов займет разработка всего беклога
(+- 1-2 спринта).
З) Посчитав количество спринтов и добавив 1-2, получаем Дедлайн. Его
отдаем заказчику и командам, с оговоркой что это Абсолютный Дедлайн,
на котором все заканчивается.
Итого, у команды есть оцененный беклог и есть бюджет времени. Для
того, чтобы следить, не жжем ли мы бюджет слишком быстро, рисуем два
графика: budget burndown и release burndown. Апдейтит их скрам-мастер
по мере продвижения (хоть каждый день).
Сорвать дедлайн команда не может. При переборе беклога происходит тоже
нечто страшное (в худшем случае вы ничего не получаете за проект, т.к.
заказчик отказался платить за недоделку). По-моему, достаточно сурово,
чтобы команда начала чесаться.
On 30 июн, 23:54, Pavel Aksonov <akso...@gmail.com> wrote:
> 2009/6/30 Artjom Serdyuk <artem.serd...@gmail.com>
Artjom Serdyuk
Те проблемы, которые Вас волнуют, участие в демо и требования код
ревью подсказывают мне, что вы берёте на себя обязанности СкрамМастера
и тим лида.
Мне кажется, лучше поговорить с теми, кто выполняет эти роли, о ваших
мыслях, чем с позиции Продакт Оунера пытаться выстраивать процесс.
Я бы попросил Вас дать команде право на ошибку. Все ошибаются.
Особенно если команда новая, процесс не устоялся, или проект только
начался.
Если Вы хотите высокого качества продукта и готовы одобрять
"технические" истории типа рефакторинга, я бы посоветовал Вам
составить документ с acceptable quality criteria. Там можно в явном
виде описать требования к качеству (например, совместимость с W3C-
стандартами или одновременная работа 1000 пользователей, защита от SQL
injection и т.п.). И регулярно не принимать истории, если они не
соответствуют этим критериям.
On 30 июн, 23:54, Pavel Aksonov <akso...@gmail.com> wrote:
> 2009/6/30 Artjom Serdyuk <artem.serd...@gmail.com>
>
Tim Yevgrashyn
Спасибо за интересную тему, которую вы подняли. Чувствую многим найдется что сказать, если они не разбежались по отпускам ;-)
От себя лично скажу следующее:
Если вы работает Владельцем Продукта - сосредоточтесь на этой роли, а уже потом лезте в процессы. {присоединяюсь к Артему}
ВП отвечает за приоритеты, уточнение требований, Value/ROI (тот же бюджет проекта) - займитесь этим и покажите все планы и цифры команде. Пусть это будет некий challenge для них и пусть они не смогут упрекнуть вас, что вы не достаточно хорошо делаете свое дело ;-)
Поддерживаю идею Done Criteria как набора общих практик качества. Т.е. не достаточно "показать", что оно работает - нужно показать чеклист с подтверждениями, что сделано качественно.
Как ВП вы имеете право не принять работу, если она не соответствует и Вашим личным критериям. Дальше все просто не Done - Велосити уменьшилось. Велосити команды должен не падать, а хотя бы оставаться на уровне ;-)
Более того, как ВП вы имеете право не выделять бюджет на новую "рефакторинг" историю (что это такое вообще???).
Если команда считает, что она может "показать", а доделать потом, возможно так было нужно вам, для демо внешним юзерам? Так или иначе, ценность История Пользователя начнет приносить только когда сделана полностью с учетом всех Done критериев и не осталось ничего "еще доделать". Даже если вы, как "добрый ВП", позволили им разбить это на два спринта, то первая часть должна иметь 0 поинтов, а весь приз команда получит когда все доделает.
Уверен, после пары таких "проколов" они поймут, что дешевле сделать с первого раза. Потому, что даже если уговорить ревьювера, то все равно ничего не поменяется. Опять же, при таком подходе выравнивается Скорость (производительность).
По поводу остальных вопросов (типа запускать тесты по 20 минут и прочее) - это сложно решить в лоб. Может может это вообще было единоразово и нечего волноваться.
Лучше сделайте видимым каких результатов они достигли за спринт. Огласите какое общее количество поинтов они смогли выдать с учетом всех Done-Done критериев. Четко покажите достигнута ли цель спринта или нет. Если нет, то почему? (например, не сделаны ключевые фичи, которые были сверху списка, хотя сделано все остальное - это тоже плохо).
У меня есть наглядный пример, как толковый Владелец Продукта (с большим менеджерским опытом в целом) с помощью ясной обратной связи на каждом демо митинге и четкой статистики, смог показать команде, что они работают хуже чем они могут и приняв "вызов" команда значительно улучшилась где-то за 4-5 спринтов.
Tim Yevgrashyn,
Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30
Pavel Aksonov
Павел,
Спасибо за интересную тему, которую вы подняли. Чувствую многим найдется что сказать, если они не разбежались по отпускам ;-)
От себя лично скажу следующее:
Если вы работает Владельцем Продукта - сосредоточтесь на этой роли, а уже потом лезте в процессы. {присоединяюсь к Артему}
ВП отвечает за приоритеты, уточнение требований, Value/ROI (тот же бюджет проекта) - займитесь этим и покажите все планы и цифры команде. Пусть это будет некий challenge для них и пусть они не смогут упрекнуть вас, что вы не достаточно хорошо делаете свое дело ;-)
Поддерживаю идею Done Criteria как набора общих практик качества. Т.е. не достаточно "показать", что оно работает - нужно показать чеклист с подтверждениями, что сделано качественно.
Как ВП вы имеете право не принять работу, если она не соответствует и Вашим личным критериям. Дальше все просто не Done - Велосити уменьшилось. Велосити команды должен не падать, а хотя бы оставаться на уровне ;-)
Более того, как ВП вы имеете право не выделять бюджет на новую "рефакторинг" историю (что это такое вообще???).
Если команда считает, что она может "показать", а доделать потом, возможно так было нужно вам, для демо внешним юзерам? Так или иначе, ценность История Пользователя начнет приносить только когда сделана полностью с учетом всех Done критериев и не осталось ничего "еще доделать". Даже если вы, как "добрый ВП", позволили им разбить это на два спринта, то первая часть должна иметь 0 поинтов, а весь приз команда получит когда все доделает.
Итак, получился прокол - юзер-стори в 2 поинта не была сделана по глупости (признали все и "приняли вызов" :). Итого из 16 сделали 14. Теперь мы уже принимаем 14 за основу для следующего спринта, так? А если те два несделанных поинта включить в новый спринт, то итого 12 стори поинтов вместо ожидаемых 16-17. В итоге получается что чем хуже команда делает, тем легче ей будет на след. спринте? :) Тут вопрос в мотивации как мне кажется.
Расскажите как Вы мотивируете. Деньгами?
Alimenkou Nikolay
> (признали все и "приняли вызов" :). Итого из 16 сделали 14. Теперь мы уже
> принимаем 14 за основу для следующего спринта, так?
Я бы ответил "не так". Если команда осознает что это было по глупости
и что это не повторится в следующей итерации, то можно вполне брать 16
как базис для следующего спринта. А можно поступить еще разумнее. Во
многих командах наблюдается такое, что всегда не доделывают работы на
1-2 стори поинта, какое бы велосити не было. В таком случае вы можете
сделать полный коммитмент от команды на 14 стори поинтов, а на 2 стори
поинта "полвиста" как говорят в преферансе. То есть по идее должны
успеть, но рассчитывать со 100% вероятностью не стоит. Но главное
чтобы это не были резервные стори поинты, поэтому разбирать провал в
них надо так же пристально как и для всех остальных.
> А если те два
> несделанных поинта включить в новый спринт, то итого 12 стори поинтов вместо
> ожидаемых 16-17. В итоге получается что чем хуже команда делает, тем легче
> ей будет на след. спринте? :) Тут вопрос в мотивации как мне кажется.
>
> Расскажите как Вы мотивируете. Деньгами?
Мотивация сложная штука. Тут дело не в деньгах, а в заинтересованности
в работе в этом проекте и с этой командой. И конечно же
ответственность перед членами команды и ПО. Если этого нет, а хватает
людей, которым на все насрать, то ничего путного не получится.
А на прощание совет из книжки (раз уж все дают советы по книжкам :)) -
проводите ретроспективы и выискивайте причины, а не копайтесь в
последствиях. Пока не поймете первопричин все приведенные меры это как
тыкать иголкой в слона в поисках сонной артерии.
И еще вспомнил под конец один прием, о котором много читал, но сам не
пробовал. Команда собирается и придумывает для себя свод правил.
Правила касаются режима работы, качества продукта и кода,
взаимоотношений в команде. И потом расписываются и вешают это на
стенку. Таким образом вроде как сами решили что хорошо, а что плохо.
Против самого себя не попрешь. Могу потом покопошиться и в личку
ссылки кинуть.
Tim Yevgrashyn
При планировании спринта, нужно использовать _среднюю_ скорость. Поэтому если закончили 14 из 16, а по прежнему верят, что в новый сделают 16 и это среднее за последние 6 спринтов, то берите 16 ;-)
К тому же, не факт, что в истории с _начальной_ оценкой в 2 поинта осталось работы на 2 поинта. Может там на 5 минут пофиксить осталось. Тогда это "легкие деньги" и нечего их дарить команде.
Моя идея была показать, что такие истории не приносят "очков" (поинтов), и все же, на них тратится время в спринте. Получается, "мусор" (waste) и команда должна на ретроспективе осознать эту проблему и научиться делать так, чтобы минимизировать потери.
Возможна и другая ситуация, когда просто не успели закончить историю. Тут может быть "мусор" другого рода...
Оставляя не законченную работу, которая переходит из одного спринта в другой, команда тем самым съедает свой бюджет НОВЫХ историй в спринте. Т.е. если среднее велосити 16, а 4 из них пришло в наследство с прошлого спринта, то новых историй возьмем еще на 12 поинтов. Дальше хуже, они опять сделали на 12, а 4 оставили в наследство. В этом случае _среднее велосити_ будет 12 и это будет четко видно. Нужно это показать команде и объяснить почему так происходит. А дальше либо они признают, что их скорость всего 12 и берут только столько, сколько могут сделать. Либо они напрягутся один раз, чтобы избавиться от "тяжелого наследства" и дальше уже вернуться к 16ти, если это была их реальная скорость.
Жизнь она не всегда по книжке, с другой стороны, если придерживаться основных ценностей и правил, то в любой сложной ситуации можно найти решение :-)
По поводу "командного соглашения" - это действительно интересная тема. На сайте СкрамАльянса есть даже пример документа http://www.scrumalliance.org/resources/4 (если нужно, я его выложу в группе).
Идею Коля описал правильно - остальные детали зависят от команды. Вы можете включить в контракт договоренности про Done критерии или оставить только общие соглашения, а Done повесить отдельным списком. Так или иначе, совместный Commitment поможет мотивировать команду.
Pavel Aksonov
On Jul 1, 2009, at 8:03 PM, Alimenkou Nikolay wrote:
>> Итак, получился прокол - юзер-стори в 2 поинта не была сделана по
>> глупости
>> (признали все и "приняли вызов" :). Итого из 16 сделали 14. Теперь
>> мы уже
>> принимаем 14 за основу для следующего спринта, так?
>
> Я бы ответил "не так". Если команда осознает что это было по глупости
> и что это не повторится в следующей итерации, то можно вполне брать 16
> как базис для следующего спринта. А можно поступить еще разумнее. Во
> многих командах наблюдается такое, что всегда не доделывают работы на
> 1-2 стори поинта, какое бы велосити не было. В таком случае вы можете
> сделать полный коммитмент от команды на 14 стори поинтов, а на 2 стори
> поинта "полвиста" как говорят в преферансе. То есть по идее должны
> успеть, но рассчитывать со 100% вероятностью не стоит. Но главное
> чтобы это не были резервные стори поинты, поэтому разбирать провал в
> них надо так же пристально как и для всех остальных.
Лего говорил обратное - если не сделали -
следующий спринт содержит уже меньше стори-поинтов с тем же весом
недоделаной стори, даже если там на 5 минут работы...
Может я неправильно понял?
>
>
>> А если те два
>> несделанных поинта включить в новый спринт, то итого 12 стори
>> поинтов вместо
>> ожидаемых 16-17. В итоге получается что чем хуже команда делает,
>> тем легче
>> ей будет на след. спринте? :) Тут вопрос в мотивации как мне кажется.
>>
>> Расскажите как Вы мотивируете. Деньгами?
>
> Мотивация сложная штука. Тут дело не в деньгах, а в заинтересованности
> в работе в этом проекте и с этой командой. И конечно же
> ответственность перед членами команды и ПО. Если этого нет, а хватает
> людей, которым на все насрать, то ничего путного не получится.
>
> А на прощание совет из книжки (раз уж все дают советы по книжкам :)) -
> проводите ретроспективы и выискивайте причины, а не копайтесь в
> последствиях. Пока не поймете первопричин все приведенные меры это как
> тыкать иголкой в слона в поисках сонной артерии.
>
> И еще вспомнил под конец один прием, о котором много читал, но сам не
> пробовал. Команда собирается и придумывает для себя свод правил.
> Правила касаются режима работы, качества продукта и кода,
> взаимоотношений в команде. И потом расписываются и вешают это на
> стенку. Таким образом вроде как сами решили что хорошо, а что плохо.
> Против самого себя не попрешь. Могу потом покопошиться и в личку
> ссылки кинуть.
the_joric
On 1 июл, 20:03, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> И еще вспомнил под конец один прием, о котором много читал, но сам не
> пробовал. Команда собирается и придумывает для себя свод правил.
> Правила касаются режима работы, качества продукта и кода,
> взаимоотношений в команде. И потом расписываются и вешают это на
> стенку. Таким образом вроде как сами решили что хорошо, а что плохо.
> Против самого себя не попрешь. Могу потом покопошиться и в личку
> ссылки кинуть.
а зачем в личку? сюда давай :) если не сложно
Sergiy Movchan
про это говорят почти все бизнес-тренера, но вот в реале я видел такое очень редко и всего 1 раз в производственном отделе.
зато всякие команды для игр (ролёвки, онлайн, квестообразные и т.д.) имеют кодекс с вероятностью в 90%
--
...dali bude...
Nataliya Trenina
> И еще вспомнил под конец один прием, о котором много читал, но сам неДа, очень интересно! Спасибо за идею
> пробовал. Команда собирается и придумывает для себя свод правил.
> Правила касаются режима работы, качества продукта и кода,
> взаимоотношений в команде. И потом расписываются и вешают это на
> стенку. Таким образом вроде как сами решили что хорошо, а что плохо.
> Против самого себя не попрешь. Могу потом покопошиться и в личку
> ссылки кинуть.
--
Nataliya Trenina,
www.scrumguides.com
GSM: +380 50 412 61 35
Skype: nattrenina
Pavel Aksonov
Yaroslav Gnatyuk
http://martinfowler.com/bliki/ComparativeValues.html
Alimenkou Nikolay
http://www.selfishprogramming.com/2009/04/11/meeting-the-team/
http://www.selfishprogramming.com/2009/04/14/the-team-manifesto-part-1/
http://www.selfishprogramming.com/2009/04/15/the-team-manifesto-part-2/