Собираем и обсуждаем: Советы начинающим в Agile

Опубликовано Тимофей Евграшин 6 Май 2010

Думаю, что нас читает много людей, которые знают об Agile подходах не по наслышке и уже имеют некий практический опыт.

Представьте себе, что ваш знакомый был назначен Скрам Мастером (ScrumMaster) в новый проект. Или наоборот, в уже существующей команде, которая сидит рядом с вами, решили внедрить Scrum подход. В таких ситуациях очень хочется поделиться своим опытом, предостеречь от своих ошибок или хотя бы обратить внимание на самые критические моменты. Ведь скорее всего, в первые итерации команда будет находиться немного в «стрессовом» состоянии из-за множества происходящих изменений.

Поэтому мы хотим объявить что-то вроде конкурса-обсуждения советов для начинающих внедрять Скрам подход и Agile практики в целом.

Итак, представьте себе команду, которая уже прошла предварительную фазу осознания, что им нужны гибкие методы управления проектами. Теперь перед ними стоят простые и жизненные задачи: «выжить» и научиться показывать результат, ну а по дороге стать самой лучшей командой в мире :-)

Оставляйте все ваши советы в виде комментариев. Через месяц, все комментарии будут собраны и сгруппированы по общим темам. Результат в виде брошюры станет доступен на нашем сайте для скачивания и поможет еще не одной команде.

Участники приславшие комментарии выступят соавторами и получат право «первой недели» — т.е. получат брошюру еще до того, как она будет опубликована, и смогут высказать свои идею и замечания по оформлению и подаче материала.

Давайте объединим свои усилия и сделаем доброе дело для тех, кто только делает свои первые шаги в Agile в целом и в Scrum в частности :-)

Статьи по теме

Рубрика: Управление проектами Метки: , ,
«
»
Вы можете оставить комментарий, или отправить trackback с Вашего собственного сайта.
  • http://andrebrov.blogspot.com/ Андрей

    Мне кажется, что обязательно надо ввести следующие активности:
    1) daily meeting — дисциплинирует и помогает всей команде находится в состоянии информационной осведомленности;
    2) в спринт логе писать definition of done — так же дисциплинирует, так как позволяет определить точно ли завершена таска и показывает конечный результат, к которому следует стремиться.

  • almakaieva

    мне кажется, что очень часто существует следующая проблема: команды внедряют SCRUM и роль SCRUM Master'a по умолчанию выполняет менеджер проекта. Так делали сначала и мы. В частности, это приводило к тому, что на daily meetings команда отчитывалась не другу другу, а менеджеру. Совмещение двух ролей — менеджер проекта и скрам мастер, на мой взгляд, крайне не желательно. Хотя такой подход очень распространен. Я понимаю, что во многих командах просто нет другого человека кроме менеджера, который мог бы выполнять роль скрам мастера, но искать варианты всегда можно :-) Мы нашли следующий вариант — роль скрам мастера стал выполнять Sales Support Engineer. Этот человек часть проекта, но не часть скрам команды, команда ему не подчиняется. В результате, митинги (standup, planning, retro) стали более эффективными. SCRUM Master стал facilitator'ом, команда перестала отчитываться менеджеру а, наконец-то начала отчитываться друг-другу! :-)

  • almakaieva

    Так же, думаю, что очень здорово, когда в команде активно используется SCRUM Board. И, мне кажется, что более эффективно использовать не электронный вариант доски, а физический. У нас доска висит в кабинете где сидит команда и standup meetings проводятся возле нее. Ребятам удобно рассказывать возле доски, они могут передвинуть свои задачи, «тыкнуть» в них пальцем, и т.д. И всегда всем виден статус српинта. Sprint Burndown Chart, висящий на той же доске, тоже очень нагляден.

  • almakaieva

    Еще одна проблема, с которой столкнулись мы — это практически отсутствие кросс-функциональности в команде. У нас есть web-developers, server-side developers, QA (все это одна скрам команда). Опыт показывает, что развивать кросс-функциональность можно и нужно. Мы пытаемся делать следующие шаги по развитию кросс-функциональности в команде: привлекать server-side программистов к работе над User Stories, относящихся сугубо к Web-разработке and vice-versa. А как привлечь, всегда можно придумать — написание инструкций, ревью кода и документации, тестирование (да, и программистов иногда можно привлекать к тестированию :-) ) Главное понимать, какая цель приследуется при этом. Цели должны быть следующими — обмен опытом, сосредоточение усилий команды на Stories с более высоким приоритетом, и тд.

  • almakaieva

    и еще :-) мы вот, поняли (наконец-то), что нужна автоматизация тестирования. Советую вам думать о внедрении автоматизации как можно раньше. Автоматизация тестирования при итерационном подходе себя оправдывает на 100%.

  • http://yura-silver.livejournal.com/ Yuriy Silvestrov

    Начинать надо с того, чтобы сфокусировать команду — показать, что только законченные юзер сторис дают вклад в выполнение проекта; что поодиночке ничего не достигнешь — проект/спринт считается выполненным только тогда, когда все выполнили свои задачи. Т.е. перейти от стадии «я работал» к «мы сделали».
    Самыми полезными для нас скрам-активитиз оказались daily meetings и planning poker. Daily meetings помогают сфокусировать команду и отслеживать статус задач. Planning poker — не вполне канонически — больше помог не с оценками (хотя и они улучшились), но обеспечил всю команду общим пониманием каждой задачи и общим представлением о планируемом дизайне.

    Очень хорошо использовать какие-нибудь забавные фишки на митингах, чтобы сделать их более увлекательными. Так, например, у нас на дейли митингах токеном служит футбольный мяч :) Сюда же относится использование «настоящей» planning poker колоды — значительно забавнее играть ею, а не нарезанными бумажками.

    Заказчикам очень нравится burndown chart — иногда даже сама идея о том, что прогресс проекта можно измерять не тем, сколько сделано, а тем, сколько осталось — и тем более извлекать из этого значительно более точные предсказания, чем раньше — оказывается супер новой и интересной :)

  • almakaieva

    а еще — классная практика проводить Standup Meetings на английском языке. Можно каждый митинг, а можно выборочно — как Ваша команда захочет :-) Мы проводим митинги на английском раз в неделю по средам. Почему это эффективно? Потому что когда мы говорим на не родном языке, особенно на английском, отчет получается более четким и мы не расплываемся по древу :-) Плюс — дополнительная возможность попрактиковаться в English Speaking skills. Попробуйте, вдруг вашей команде понравится!

  • almakaieva

    повесьте на стене SCRUM Check List и, например, на ретроспективах пробегайтесь по нему: http://www.slideshare.net/art23/agile-checklist
    Станет хорошо видно, что не так. Нам помогает :-) Надеюсь, Вам тоже поможет!

  • Борис

    Первое: провести собеседование с каждым членом команды, что бы определить их психологический портрет, амбиции, текущие задачи, приоритеты и мотивацию.
    Второе: понять с какими задачами команда и без Тебя эффективно работает, а в каких задачах ей нужна помощь.
    Третье: далее по ситуации …