2008/8/19 Antuan Mark <maryuk...@gmail.com>:
Основные обязанности скрам-мастера это:
- помогать команде соблюдать собственные договорённости, в т.ч.
придерживаться методологии Scrum
- помогать команде идентифицировать и преодолевать препятствия
(impediments), причём "impediment" тут понимается максимально широко
- фасилитация на командных митингах (Daily Scrum Meeting, Iteration
Planning Meeting, Retrospective, Demo...)
Естественно, есть ньюансы в зависимости от того, какую роль
скрам-мастер выполнял раньше и как его должность официально называется
в организации.
Скажем, для менеджера:
- Есть соблазн директивно влиять на команду, микроменеджить -
скраммастеру этого не следует делать, надо приучаться сдерживать такие
порывы
- С другой стороны, менеджеру проще делать resolving of impediments,
благодаря большему по сравнению с разработчиком влиянию в компании
- Менеджер часто может объединять в себе роли SM и PO. В идеале их,
конечно, разнести на разных людей. В случае если (пока) всё же эти
роли объединены в одном человеке, ему необходимо чётко осознавать,
когда он в какой роли.
Для разработчика:
- Может быть трудно совмещать роль разработчика (составная часть Team)
и SM (который вне Team). Например, на митингах по планированию, как
разработчик он имеет что сказать о сложности некой истории, и также он
является SM. Может получиться, что он как SM проталкивает своё
решение, а мнения других членов команды будут не так "громко"
высказаны.
- Либо трудно может быть отказаться от любимого дела - программирования.
Совмещение QA и SM я вживую не видел. Думаю, что это может быть лучше
предыдущих двух вариантов. Однако надо убедиться, что есть ещё full
time QA.
Ньюансы - такие же как у разработчика, плюс предполагаю ещё пару
подводных камней:
- свойственный профессии QA перфекционизм, усиленный ролью SM, может
привести к тому, что команда будет "доводить до блеска" на фичах, не
являющимися приоритетными по мнению PO.
В общем, для любого варианта совмещения ролей важно проводить чёткое
разграничение между своим поведением в одной роли и в другой.
Полезно, чтобы SM понимал специфику проекта - конечно, понимания на
уровне готовности что-то самому писать, естественно, не требуется. Но
чем лучше понимает - тем лучше сможет помочь команде.
--
С уважением, Алексей Тигарев
<ti...@nlp.od.ua> ICQ #387-495-165 http://t_gra.livejournal.com/
AgileProductivity: Утройте продуктивность команды программистов,
используя гибкие методологии -- http://nlp.od.ua/
2008/8/19 Antuan Mark <maryuk...@gmail.com>:
--
2008/8/20 Antuan Mark <maryuk...@gmail.com>:
О, спасибо, у меня как раз назревал вопрос по поводу скрам мастера и
нескольких независимых комманд :)