Думаю, что нас читает много людей, которые знают об Agile подходах не по наслышке и уже имеют некий практический опыт.
Представьте себе, что ваш знакомый был назначен Скрам Мастером (ScrumMaster) в новый проект. Или наоборот, в уже существующей команде, которая сидит рядом с вами, решили внедрить Scrum подход. В таких ситуациях очень хочется поделиться своим опытом, предостеречь от своих ошибок или хотя бы обратить внимание на самые критические моменты. Ведь скорее всего, в первые итерации команда будет находиться немного в «стрессовом» состоянии из-за множества происходящих изменений.
Поэтому мы хотим объявить что-то вроде конкурса-обсуждения советов для начинающих внедрять Скрам подход и Agile практики в целом.
Итак, представьте себе команду, которая уже прошла предварительную фазу осознания, что им нужны гибкие методы управления проектами. Теперь перед ними стоят простые и жизненные задачи: «выжить» и научиться показывать результат, ну а по дороге стать самой лучшей командой в мире 🙂
Оставляйте все ваши советы в виде комментариев. Через месяц, все комментарии будут собраны и сгруппированы по общим темам. Результат в виде брошюры станет доступен на нашем сайте для скачивания и поможет еще не одной команде.
Участники приславшие комментарии выступят соавторами и получат право «первой недели» – т.е. получат брошюру еще до того, как она будет опубликована, и смогут высказать свои идею и замечания по оформлению и подаче материала.
Давайте объединим свои усилия и сделаем доброе дело для тех, кто только делает свои первые шаги в Agile в целом и в Scrum в частности 🙂
повесьте на стене SCRUM Check List и, например, на ретроспективах пробегайтесь по нему: http://www.slideshare.net/art23/agile-checklist
Станет хорошо видно, что не так. Нам помогает 🙂 Надеюсь, Вам тоже поможет!
Мне кажется, что обязательно надо ввести следующие активности:
1) daily meeting – дисциплинирует и помогает всей команде находится в состоянии информационной осведомленности;
2) в спринт логе писать definition of done – так же дисциплинирует, так как позволяет определить точно ли завершена таска и показывает конечный результат, к которому следует стремиться.
мне кажется, что очень часто существует следующая проблема: команды внедряют SCRUM и роль SCRUM Master'a по умолчанию выполняет менеджер проекта. Так делали сначала и мы. В частности, это приводило к тому, что на daily meetings команда отчитывалась не другу другу, а менеджеру. Совмещение двух ролей – менеджер проекта и скрам мастер, на мой взгляд, крайне не желательно. Хотя такой подход очень распространен. Я понимаю, что во многих командах просто нет другого человека кроме менеджера, который мог бы выполнять роль скрам мастера, но искать варианты всегда можно 🙂 Мы нашли следующий вариант – роль скрам мастера стал выполнять Sales Support Engineer. Этот человек часть проекта, но не часть скрам команды, команда ему не подчиняется. В результате, митинги (standup, planning, retro) стали более эффективными. SCRUM Master стал facilitator'ом, команда перестала отчитываться менеджеру а, наконец-то начала отчитываться друг-другу! 🙂
Так же, думаю, что очень здорово, когда в команде активно используется SCRUM Board. И, мне кажется, что более эффективно использовать не электронный вариант доски, а физический. У нас доска висит в кабинете где сидит команда и standup meetings проводятся возле нее. Ребятам удобно рассказывать возле доски, они могут передвинуть свои задачи, “тыкнуть” в них пальцем, и т.д. И всегда всем виден статус српинта. Sprint Burndown Chart, висящий на той же доске, тоже очень нагляден.
Еще одна проблема, с которой столкнулись мы – это практически отсутствие кросс-функциональности в команде. У нас есть web-developers, server-side developers, QA (все это одна скрам команда). Опыт показывает, что развивать кросс-функциональность можно и нужно. Мы пытаемся делать следующие шаги по развитию кросс-функциональности в команде: привлекать server-side программистов к работе над User Stories, относящихся сугубо к Web-разработке and vice-versa. А как привлечь, всегда можно придумать – написание инструкций, ревью кода и документации, тестирование (да, и программистов иногда можно привлекать к тестированию :-)) Главное понимать, какая цель приследуется при этом. Цели должны быть следующими – обмен опытом, сосредоточение усилий команды на Stories с более высоким приоритетом, и тд.
и еще 🙂 мы вот, поняли (наконец-то), что нужна автоматизация тестирования. Советую вам думать о внедрении автоматизации как можно раньше. Автоматизация тестирования при итерационном подходе себя оправдывает на 100%.
Начинать надо с того, чтобы сфокусировать команду – показать, что только законченные юзер сторис дают вклад в выполнение проекта; что поодиночке ничего не достигнешь – проект/спринт считается выполненным только тогда, когда все выполнили свои задачи. Т.е. перейти от стадии “я работал” к “мы сделали”.
Самыми полезными для нас скрам-активитиз оказались daily meetings и planning poker. Daily meetings помогают сфокусировать команду и отслеживать статус задач. Planning poker – не вполне канонически – больше помог не с оценками (хотя и они улучшились), но обеспечил всю команду общим пониманием каждой задачи и общим представлением о планируемом дизайне.
Очень хорошо использовать какие-нибудь забавные фишки на митингах, чтобы сделать их более увлекательными. Так, например, у нас на дейли митингах токеном служит футбольный мяч 🙂 Сюда же относится использование “настоящей” planning poker колоды – значительно забавнее играть ею, а не нарезанными бумажками.
Заказчикам очень нравится burndown chart – иногда даже сама идея о том, что прогресс проекта можно измерять не тем, сколько сделано, а тем, сколько осталось – и тем более извлекать из этого значительно более точные предсказания, чем раньше – оказывается супер новой и интересной 🙂
а еще – классная практика проводить Standup Meetings на английском языке. Можно каждый митинг, а можно выборочно – как Ваша команда захочет 🙂 Мы проводим митинги на английском раз в неделю по средам. Почему это эффективно? Потому что когда мы говорим на не родном языке, особенно на английском, отчет получается более четким и мы не расплываемся по древу 🙂 Плюс – дополнительная возможность попрактиковаться в English Speaking skills. Попробуйте, вдруг вашей команде понравится!
Первое: провести собеседование с каждым членом команды, что бы определить их психологический портрет, амбиции, текущие задачи, приоритеты и мотивацию.
Второе: понять с какими задачами команда и без Тебя эффективно работает, а в каких задачах ей нужна помощь.
Третье: далее по ситуации …