Блог компании ScrumTrek - эффективные процессы

Agiledays в Санкт-Петербурге

noreply@blogger.com (Никита Филиппов) — Mon, 19 Jul 2010 13:17:00 +0000

Разговоров про Agile так же много, как и книг, но вопрос, как сделать разработку гибкой и эффективной в конкретной компании, порождает кучу дискуссий. Как показывает практика и предыдущие посты на Хабре об Agiledays и встречах сообщества Agilerussia, интерес к данной теме не угасает. Именно поэтому мы продолжаем делать конференции, связанные c вопросами организации процессов разработки.

Можно поздравить жителей северной столицы - Agiledays добрался и до их города.

Я думаю, рекламировать Agiledays не имеет смысла. Скажу только, что это уже третий раз за последний год, когда мы собираемся вместе (Москва, Екатеринбург), чтобы обсудить современные подходы управления разработкой ПО.

Когда?

Произойдет это все в одной из петербургских гостиниц 17 сентября.
Будет несколько потоков: один или два основных потока с докладами и параллельные сессии мастер-классов и open space’ы.

Поводов собраться у нас более чем достаточно

К нам на конференцию приезжают:

David Hussman, DevJam - консультант по организации процессов и продуктовому менеджменту.
Дэвид разрабатывал программное обеспечение в течении многих лет в самых разных областях: цифровое видео, медицина, биометрия, финансы, торговля и образование. Сейчас Дэвид поддерживает несколько agile-сообществ по всему миру: США, Канада, Европа и даже Азия. Способствовал написанию нескольких книг ("Managing Agile Projects" и "Agile in the Large". Сейчас Дэйв пишет книгу для серии "Pragmatic Programmer".

На конференции Дэйв познакомит нас со своим докладом Products and People Over Process and Dogma, в котором расскажет о том, как в погоне за попыткой сделать "православный Agile" не забыть, зачем вы его применяете, и попытаться сместить фокус с создания классного "процесса из книжек", на простое достижения целей вашей компании, усиливая себя практиками гибкой разработки.

Так же David проведет двухдневный тренинг "Coaching Agility" для тех, кто хочет развиваться в направлении Agile-Coaching, как новой формы менеджмента в компании (создание высокопродуктивных команд).

Dan Rawsthorne - Senior Coach, Certified Scrum Trainer, Danube. Дэн работает в IT индустрии более 25 лет. Прошел путь от простого разработчика до менеджера проектов и продуктов. Он работал как в небольших (3 человека), так и в огромных (500 человек) командах и приобрел колоссальный опыт по организации работ в проектах разной продолжительности и сложности. Дэн занимался улучшением процессов в маленьких "хакерских" компаниях и огромных организациях, сертифицированных по CMMI и ISO.

Дэн прочтет на конференции доклад о типизации User Stories "Storyotypes: The Patterns Within the Stories".

Так же под его руководством пройдут две сертификации Certified Scrum Master и Certified Product Owner

Григорий Мельник – Microsoft, Senior Program Manager в команде patterns & practices в Microsoft. В настоящее время руководит проектами Microsoft Enterprise Library и Software Testing Guidance. Его профессиональный опыт – более 15 лет. Как инженер-разработчик ПО, научный сотрудник и профессор университета с более 40 публикациями внёс существенный вклад в развитие современных методов разработки, тестирования и внедрения комплексных программных систем (включая Acceptance Test-Driven Development).

Григорий еще не объявил нам тему своего доклада, но мы уверены, что этого человека будет интересно слушать независимо от темы.

Сергей Дмитриев, Making Waves, Oslo.

Работая в качестве Scrum Coach, помог внедрению Agile с нуля в 4х компаниях.
Занимался agile development c 2005 года, работал с удаленными и распределенными командами, на маленьких (3 разработчика) и больших (100+ разработчиков) проектах. Тренировал более 25 команд в 6 разных странах. Сертифицированный менеджер проектов PMI, сертифицированный Scrum Master, Scrum Product Owner, Scrum Practitioner, Сергей в данный момент работает над своей сертификацией в качестве сертифицированного скрам тренера.

Сергей поделится своим опытом и расскажет о том, как сделать наши команды и самого себя более ответственными по отношению к продукту, и о том, как в этом может помочь Agile-команда.

Кто будет еще?

Гости из Финляндии и Эстонии
- Дмитрий Викторов, F-Secure. Он и его команда обещали рассказать о практике, названной Business Iteration Planning
- Алек Козлов, Scrum.ee, основатель эстонского сообщества Scrum.ee, один из опытнейших тренеров на постсоветском пространстве.
- Антон Кекс, Codeborne. С успехом перевел весь девелоперский центр банка Swedbank на рельсы XP.

Питерские Аджилисты с многолетним опытом:
- Роман Юферев, Avicode. Один из самых ярких докладчиков Agiledays'09.
- Алексей Корсун, ScrumTrek. Пополнение в рядах ScrumTrek - Леша не раз уже выступал на Agile-конференциях и с успехом вытаскивал команды из паралича в разработке, работая с питерскими компаниями.

И это только начало! Планируется более 20 докладов и мастер-классов.

Участие

Для участия необходимо заполнить форму регистрации на сайте ScrumTrek - организатора конференции: http://scrumtrek.ru/company/registration-spb/

Если вы готовы сами выступить на конференции с интересным докладом, отправьте письмо с абстрактом до 5-го августа на адрес: agiledays@scrumtrek.ru

Сайт конференции: http://spb.agiledays.ru

Видеокаст "Scrum – подход к управлению сложными проектами"

noreply@blogger.com (Асхат Уразбаев) — Thu, 01 Jul 2010 06:15:00 +0000

1 июня 2010 в рамках совместной инициативы Гильдии и Локальной группы по интересам “Управление проектами в ИТ и телекоммуникациях” московского отделения американского Института управления проектами (PMI) состоялся семинар Асхата Уразбаева “Scrum – подход к управлению сложными проектами“.

Scrum – один из подходов к управлению проектами. Он возник как ответ на все возрастающую сложность проектов по разработке программного обеспечения. На семинаре были рассмотрены принципы подхода, практики и роли, а также границы применимости.

Семинар провел Асхат Уразбаев, вице-президент нашей Гильдии, евангелист Agile и Scrum, Agile Coach, совладелец компании ScrumTrek, основатель сообщества AgileRussia.

Семинар транслировался через Интернет в формате вебинара, что помогло принять в нем участие большому количеству желающих.

Как "продать" Agile менеджеру?

noreply@blogger.com (Асхат Уразбаев) — Thu, 24 Jun 2010 12:41:00 +0000

Очень часто задают такой вопрос - ну мы вроде тут все за Agile. А как продать Agile менеджеру или заказчику?

Я стал придумывать, как рассказать об этом, и у меня появилось такое ощущение, что никакой особой специфики нет. Все продается примерно одинаково. Давайте рассмотрим пример.

Представим себе программиста Александра, который считает, что парное программирование это мегакруто. Саша пришел в совершенно новую компанию, там у него эдакий "типичный" менеджер проекта. Саша считает, что парное программирование будет полезно и хочет "продать" ему эту практику.

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

Александр: Какие проблемы?
Менеджер: Багов много. Заказчики просто задрали, жалуются и жалуются. Что-то сделали тут, там отвалилось. Поправили там – тут отвалилось.
Александр: Парное программирование как раз решает эту проблему!
Менеджер: Да ты что, с ума сошел? Какое парное программирование? Это же когда двое за одним компьютером? Это слишком дорого!
Александр: Дело в том, что пока мы исправляем баги, уходит времени больше, чем если бы мы написали сразу все правильно. А писать сразу все правильно реально.
Менеджер: Так что ты предлагаешь?
Александр: Я предлагаю не тратить время на исправление багов, а сразу сделать все правильно. Это даст нам экономию времени, плюс довольные пользователи от того, что у нас работает система.
Менеджер: Да ты просто гик. Начитался книжек умных. У нас тут своя специфика, у нас это не заработает!

Итак, Александр провалился. Менеджер оказался ему не по зубам.

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

Александр: Ну, подумаешь, баги в продакшне, ну и что? Баги всегда есть.
Менеджер: Так заказчики ведь недовольны!
Александр: Ну и что? Мы же не теряем на этом деньги.
Менеджер: Теряем! Полмиллиона долларов. Помнишь, у нас был заказчик-банк? В итоге они купили продукт у другой компании!
Александр: Хм. Вообще-то мы можем это пофиксить. Парное программирование…

Александр превратил маленькую проблему "много багов" в большую "мы теряем деньги". Ну что ж, для некоторого количества менеджеров такой подход сработает. Но наш менеджер так просто не сдастся.

Менеджер: Парное программирование - слишком дорогое удовольствие. Багов может и станет меньше, но производительность упадет вдвое! А что прикажешь делать со следующим релизом? В топку?

Тут Александр может вступить в бой, доказывая, чтоо производительность особенно не снизится. Вряд-ли впрочем, преуспеет. Можно было поступить иначе. Откатим разговор на несколько реплик назад.

Менеджер: Да уж теряли! Полмиллиона долларов. Помнишь, у нас был заказчик-банк? В итоге они купили продукт у другой компании!
Александр: И что ты предлагаешь?
Менеджер: Вообще говоря, это твоя проблема. Ты разработчик, ты и должен заниматься багами.
Александр: Тут подумать надо. Нам надо писать код так, чтобы в нем не было ошибок. Давай подумаем, какие есть подходы, чтобы не делать ошибок? Что-то я такое читал.
Менеджер: Ну там парное программирование, ревью кода.
Александр: Парное программирование? Не знаю… Это может дать снижение производительности. Хотя твоя идея мне нравится.
Менеджер: Дорогое может быть удовольствие! А вдруг мы в два раза медленнее работать будем?
Александр: Да, ты прав. Твою идею сначала надо попробовать безопасно. Я категорически против внедрять парное программирование сразу.

И тут Александр задвигает Менеджеру план по опробованию парного программирования.

Александр: Мы попробуем твою идею в течение одной итерации и я расскажу тебе что у нас получится.
Менеджер: А производительность не пострадает?
Александр: А вот мы и проверим. Через 2 недели я тебе расскажу.

По правде говоря, Александр немного сжульничал. Он изначально намеревался внедрить парное программирование. Но теперь это выглядит как идея менеджера, а Александр просто спешит попробовать ее на практике. Этот прием очень хорошо срабатывает, если вас, конечно, не сильно беспокоят всякие глупости из серии "но это же была моя идея".

Итак, потребности бывают скрытые и явные. Скрытая потребность это когда заказчик не знает, что ему нужно парное программирование, просто испытывает проблемы. А явная это точное знание того, что нужно. Для того, чтобы перевести потребность из скрытой в явную нужно задавать вопросы.

Цикл тут такой:
- Мы выявляем проблему и потребности,
- затем рассматриваем ее последствия,
- предлагаем решение, обсуждаем его выгоду.
- Рассматриваем опасения и устанавливаем безопасное окружение для экспериментов.
- Затем мы соглашаемся вместе на эксперимент, когда все согласны это попробовать.

Метод продажи, который я описал в более общем виде и в применении к продажам товаров и услуг описал Нил Рекхэм в книге «СПИН-продажи»

Написано по мотивам выступления на конференции AgileDays в Екатеринбурге

Типичные "грабли" внедрения Agile/Scrum и реальные кейсы

noreply@blogger.com (Ирина Цыбденова) — Wed, 09 Jun 2010 17:18:00 +0000

Постоянно меняются требования? Невозможно выдерживать сроки? Хотите предсказуемости, прозрачности процесса разработки ПО?

Гибкий подход к разработке поможет вашей команде:

фиксировать требования на короткий период
в конце каждой итерации получать реально работающий продукт
стать прозрачной, в результате растет качество кода
скорость разработки повышается в 2 и более раза!
стать кроссфункциональной – знания остаются в компании на 100%

Обо всем этом вам расскажут и покажут, и вы на пальцах пощупаете Agile/Scrum на нашем тренинге "Agile Software Development with Scrum".

Программа тренинга сформирована с учетом нашего большого опыта внедрения Scrum в самых различных компаниях –Auto.ru, Rambler, Mail.ru и т.д.

Тренеры – Никита Филиппов и Асхат Уразбаев – Agile евангелисты, которые помогли перечисленным выше компаниям и многим другим компаниям стать эффективнее в 2 и более раза.

На тренинге мы рассмотрим практики Scrum, типичные "грабли" внедрения и реальные кейсы. Будет много обсуждений и симуляционных игр, которые помогут понять принципы и практики Scrum.

Стоимость участия - 3000 рублей. Длительность тренинга - 8 часов, с 10-00 до 18-00.

Всем участникам тренинга футболка I am Ag:)le – в подарок!

Тренинг состоится в Санкт-Петербурге 17 июня и в Москве 28 июня

Расписание тренингов ScrumTrek

Как продать Agile заказчику

noreply@blogger.com (Асхат Уразбаев) — Mon, 07 Jun 2010 15:55:00 +0000

Мой (Асхата) SlideCast с конференции Ag:)eDays-Екатеринбург "Как продать Agile заказчику".

Как продать Agile заказчику

View more webinars from Askhat Urazbaev.

Planning Poker и крупные проекты

noreply@blogger.com (Асхат Уразбаев) — Fri, 21 May 2010 06:23:00 +0000

Вам интересно, как при помощи Planning Poker оценить размер крупного проекта?

Ребята разработали новый инновационный подход! Простота и эффективность метода подкупают.

AgileDays едет в Екатеринбург!

noreply@blogger.com (Ирина Цыбденова) — Tue, 04 May 2010 09:58:00 +0000

4 июня состоится конференция по гибким методологиям - AgileDays в Екатеринбурге!
Цель конференции - обменяться опытом использования Agile, пообщаться с практикующими разработчиками и менеджерами, узнать о современных подходах в разработке ПО.
На конференции выступят признанные в России эксперты по Agile, а также своим опытом поделятся разработчики из различных компаний России: СКБ Контур, CustIS, Exigen, Открытые Системы и других.
Конференцию поддерживает компания Microsoft, со - организатором конференции выступает компания СКБ Контур - федеральный разработчик программного обеспечения.
Организаторы конференции AgileRussia и ScrumTrek постарались подготовить максимально интересную и обширную программу. Конференцию откроет Асхат Уразбаев (ScrumTrek) обзором гибких методологий. Никита Филиппов расскажет об управлении требованиями в Agile, а секреты тестирования вы узнаете от Ильи Гаврилова (Exigen). Илья Гольдберг (СКБ Контур) расскажет об опыте использования Agile в своей компании. Александр Бындю (Открытые Системы) поделится опытом и практиками создания эффективной команды. О построении правильной архитектуры в Agile и о своем более чем трехлетнем опыте применения Agile в заказной разработке ПО расскажет Михаил Заборов (CustIS). С докладом "Как продать Agile" выступит Асхат Уразбаев.
Благодаря формату конференции у вас будет возможность задать вопросы докладчикам во время специальных флип-чарт-сессий.
В рамках конференции пройдут 2 тренинга:
- Управление требованиями в Agile проектах – Эффективная работа с требованиями очень важна для успешного предоставления заказчику ценного с точки зрения бизнеса продукта. Работа с требованиями в Agile имеет свои особенности. Процесс планирования и сбора требований становится итеративным, требования постоянно изменяются. Несмотря на это, мы должны уметь указывать точную дату релиза.
Инструктор – Никита Филиппов Тренер и консультант по гибким методологиям, эксперт в области управления продуктами и требованиями в Agile-компаниях. Никита сертифицированный скрам-мастер (Certified Scrum Master)
- Тестирование в Agile проектах - Тренинг позволяет тестировщикам эффективно строить свою работу в Agile-проектах. Он построен в виде однодневного учебного проекта, где теория перемежается с практикой. Особенно большое внимание уделяется сложным вопросам взаимодействия программистов и тестировщиков, планирования тестирования, автоматизации тестирования и построения эффективной архитектуры тестов, а также поддержания актуального состояния автоматизированных тестов при постоянном изменении требований.
Инструктор: Илья Гаврилов—начальник отдела тестирования компании Exigen, Agile-гуру и специалист по тестированию в Agile.
Посмотреть подробную информацию о конференции и зарегистрироваться можно на официальном сайте конференции ekt.agiledays.ru

ScrumTrek на РИТ++

noreply@blogger.com (Асхат Уразбаев) — Mon, 19 Apr 2010 08:10:00 +0000

Весна - традиционная пора всяких конференций. ScrumTrek обычно активно в них участвует в виде нас с Никитой, читающих доклады или мастер-классы. Это, конечно, дает пиар (куда же без него). Это еще и хороший способ мотивировать себя на создание какого-нибудь интересного контента, который может пригодиться на тренинге.

Однако на прошлой неделе мы выпендрились. На этот раз на РИТ++ у нас была целая будка, мы там сидели как настоящие КРУТЫЕ СПОНСОРЫ. Мало того, мы выдавали промо-материалы! Мы обменивали майки AgileDays на визитки и раздавали брошюры с AgileChecklist.

Никита на фотке малость похудел, не находите?

А в конце мы даже раздавали призы - бесплатные сертификаты на обучение.

Впрочем, без выступления не обошлось. Никита рассказал о StoryMapping и выступил с баяном про метрики. Вот он, златокудрый:

Я ничего не докладывал, берег свой мозг. Он (мозг) был малость высушен кучей работы и креатива не рожал, так что я дал ему побыть под паром .

РИТ++ мне понравился. Жалею, что не попал на некоторые доклады. На некоторых удалось посидеть, выглядело это так:

Автор всех фоток - Сергей Мартынов. Все фотки можно посмотреть здесь.

Мозг успел расслабится, так что уже в среду я выступаю на РИФоКИБе с рассказом о Scrum для веб-разработчиков. А в пятницу иду на SoftwarePeople с докладом Внедрение Agile на разных этапах развития компании . Никита проведет старую добрую игру-симуляцию "Agile Analysis Game: Управление требованиями в Agile".

Situational Leadership for Agile

noreply@blogger.com (Ирина Цыбденова) — Thu, 08 Apr 2010 09:54:00 +0000

28-29 апреля в Санкт- Петербурге и 14-15 мая в Москве ScrumTrek и Happy - PM проведут мегатренинг Situational Leadership for Agile
Product Owner отвечает за продукт и бизнес, Scrum master обеспечивает успех scrum в команде. Как меняется работа менеджера более высокого уровня? Он не может напрямую руководить разработкой, его основная задача – руководить изменениями, подбирать, усиливать и организовать команду. Именно он отвечает за создание правильной, эффективной культуры внутри организации, ориентированной на использование сильных сторон каждого сотрудника.
Как это сделать? На тренинге будут рассмотрены сложные вопросы лидерства разработки ПО. Вы узнаете о том, как создать эффективную команду, как работать со сложными людьми, как увольнять тех, кто саботирует изменения к лучшему, как построить правильную культуру внутри компании, как правильно управлять инновациями и изменениями.
У вас есть уникальная возможность посетить тренинг одного из самых эффективных менеджеров в области разработки ПО в России. Сурен – практик, он является главой департамента управления проектами компании Innova Systems.
Мастер класс предназначен для директоров компаний, заместителей директоров по проектам, руководителей департаментов, руководителей проектов, менеджеров продуктов и программ.
Зарегистрироваться

Встреча AgileRussia "Архитектура в Agile"

noreply@blogger.com (Асхат Уразбаев) — Tue, 16 Mar 2010 12:30:00 +0000

24 марта 2010 года состоится очередная встреча AgileRussia на тему "Архитектура в Agile"

Встреча будет состоять из трех частей:

Роль "Архитектор", её особенности в Agile, взаимодействие с командой и PO;
различные подходы к проектированию (эволюционный дизайн, сверху-вниз, снизу-вверх), их влияние на Agile-процесс, ограничения применимости;
беглый обзор наиболее популярных технических практик: Test-Driven Development, Behavior-Driven Development, Domain-Driven Design.

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

Подробности тут...

Типа waterfall или WaterfallButt

noreply@blogger.com (Асхат Уразбаев) — Tue, 09 Mar 2010 08:14:00 +0000

Как вас всех, наверное, достали те разработчики, которые безосновательно считают, что у них Agile. Мы такой процесс называли "типа Agile". Спросишь у них "вы как работаете?" - а они в ответ "ну у нас типа Agile" и скромненько так ручкой махнут.
Я ваше негодование полностью разделяю и поддерживаю. Как так можно? Во-первых, на святое, а во-вторых, они же примазываются. А потом будут кричать везде "ваш Agile фигня".

Ken Schwaber, автор Scrum, называет такой процесс Scrum Butt. Например, "we have scrum, but...(no iterations)". Dan Rawsthorne даже нотацию придумал:

Scrum (but) no Product Owner
Scrum (but) no self-organization
Scrum (but) shitty code

Но я хотел написать совсем не об этом. Видимо, начинаю писать про "типа Agile" и остановится не могу, ну вы меня понимаете.

Так вот, я про waterfall хотел написать. Мне кажется, что настоящие "водопадники" (если бы такие водились) точно также должны были бы обижаться на тех, кто примазывается к их "настоящему водопаду". Такие, я подозреваю, не водятся, поэтому я выступлю в несвойственной для себя роли защитника водопада.

Будем называть такой процесс "типа водопад" или "waterfall butt".

Во-первых, господа "водопадники", вас все критикуют за Big Design Up Front. Вы понимаете, что это должно означать? Как минимум, это:

Design есть. И он создается в начале проекта.

Причем первая часть важнее. Так вот, страшная тайна в том, что дизайн и спецификации - это не требования к системе, то есть не Use Cases! Это описание архитектуры, дизайн компонентов на уровне диаграмм классов, различные sequence diagrams и прочие ужасы дорвавшегося до власти сумасшедшего проектировщика.

Я вам страшную историю расскажу. Прихожу я как-то в одну очень серьезную "водопадную" компанию. Они мне показывают очень многостраничные документы спецификаций. Я прямо за голову хватаюсь, надо же, первый раз настолько серьезную контору вижу. Ну и потом разговорились. Главный программер и говорит: "Ну мы сначала пишем код, а потом пишем к нему спецификации". Нет, вы представляете? Big Design Up Front, my ass!

Водопад по-русски: сначала пять месяцев пишем требования, потом долго придумываем архитектуру, потом создаем план проекта в виде Gantt Charts, потом выбрасываем все это в корзину и пытаемся за оставшееся время доделать систему.

Ну а как? Ведь время от времени прибегает заказчик и что-то еще просовывает, какие там уж планы. Такие запросы получают статус JFDI (Just Fucking Do It) и выполняются в обход всех планов и процедур.

Да и если бы были спецификации. Чтобы их соблюдать, нужно их хотя бы читать! Прораммисты не читают ничего, кроме хабра и башорга. Если бы архитекторы все спецификации складывали в папочку с доступом только на запись, никто бы этого не заметил!

Я сказал чуть выше слово Use Cases? Я погорячился! Какие там Use Cases!
Хотите анекдот? Я его сам придумал:

- Ты знаешь як москали наши Requirements Specifications называют?
- Як?
- Тэзэ. Поубывав бы!

Простите мой украинский, я знаю, что он не идеален.

Так вот, ТЗ (техническое задание) это такой длинный слабо-структурированный текст, где фичи перемешаны с описанием того, как система должна работать. Туда еще понапиханы прототипы экранных форм и все это без указаний приоритетов. Действительно, зачем приоритеты? У нас все важно!

Причем такой документ один. Конечно один, ведь его надо подписать у заказчика. А у заказчика проще подписать один документ, чем пять или десять.

А приемка результатов? У кого есть согласованные с заказчиком приемочные тесты и процедуры приемки? Я таких не видел: у нас другие методы подписания актов приемки. К системе они никакого отношения они не имеют. Зато включают много других интересных телодвижений, которыми вообще-то прокуратура должна интересоваться.

Так что не примазывайтесь. У вас не водопад, а "типа водопад", или, если хотите, "waterfall butt".

Я по простому скажу: никакого watefall в России нет, и слава богу. Без waterfall'а проживем.

Так что покайтесь, и давайте внедрять Agile :-)

Тренинги ScrumTrek на основе TFS

noreply@blogger.com (Ирина Цыбденова) — Thu, 04 Mar 2010 14:51:00 +0000

В середине марта ScrumTrek проводит серию тренингов, посвященную инструментам Microsoft Team Foundation Server - платформа для совместной работы группы, которая объединяет портал группы, управление версиями, отслеживание рабочих элементов, управление построениями, руководство по процессам и бизнес-аналитику на базе единого сервера. Благодаря этому каждый участник группы может более эффективно организовать совместную работу и создавать более качественное программное обеспечение.

17 марта MS Agile Development with Scrum - тренинг для тех, кто планирует внедрять Scrum в своем проекте или организации, или для тех, кто хочет сравнить свои способы работы с лучшими практиками индустрии.
Инструктор – Никита Филиппов.
Стоимость 3 000 рублей.

19 марта MS Тестирование в Agile-проектах – тренинг основан на Microsoft Visual Studio Team System 2010 Test Edition и позволяет тестировщикам эффективно строить свою работу в Agile-проектах. Особенно большое внимание уделяется сложным вопросам взаимодействия программистов и тестировщиков, планирования тестирования, автоматизации тестирования и построения эффективной архитектуры тестов, а также поддержания актуального состояния автоматизированных тестов при постоянном изменении требований. С помощью тестирования инженеры-испытатели могут создавать, выполнять и управлять тестами и связанными с ними рабочими элементами – непосредственно из среды Visual Studio.
Инструктор – Алексей Баранцев, Асхат Уразбаев
Стоимость – 9 000 рублей

22 марта MS Test Driven Development - тренинг основан на Microsoft Visual Studio Team System 2010 Development Edition, с помощью которого можно создавать код более высокого качества, снизить количество проблем, связанных с безопасностью, и избежать появления ошибок на последующих этапах жизненного цикла разработки. Тренинг помогает "сломать" неправильный подход к разработке. Разработчик, прошедший тренинг, уже никогда не будет прежним. Он станет "test-infected".
Инструктор – Андрей Бибичев
Стоимость – 6 000 рублей

Расписание тренингов ScrumTrek вы можете посмотреть здесь

ScrumTrek поздравляет с наступающим 8 марта прекрасную половину человечества и дарит 15% скидку на все тренинги до конца апреля!

Дорогая редакция...Или какие новости в Феврале?

noreply@blogger.com (Никита Филиппов) — Mon, 22 Feb 2010 15:44:00 +0000

Немного об Agile и офисе

Недавно прошел тренинг Agile Development with Scrum и 2-х дневный workshop (тренингом не совсем это назовешь - 50% времени этого тренинга работа с живими документами и генерацией артефактов для получения информации о проекте) по сбору требований в Agile - REQ-Agile Requirements Analysis.

Было достаточно интересно. Первый тренинг проходил почти в виде круглого стола. В течении 4 часов мы обсуждали Agile - что это такое, почему подход рекомендует те или иные практики. Прихошли к тому, что магии особой в этом нет и это здравый смысл в организации работы проектов.

Один из участников приятно отозвался об этом тренинге:

"Был на тренинге у Никиты Филипова - Agile инъектция в мозг. Категорически рекомендуется все кто типа "мы используем agile в своем проекте". Чтобы понимать что все эти крайне разнообразные извращения которые вполне благополучно существуют в реальной жизни не имеют никакого отношения ни к agile, ни к scrum. А также того что agile не решает проблемы того что например команда недостаточно мотивирована или внутри команды есть противоречия. Scrum - хороший способ построить за вполне обозримое время эффективную команду из хороших ( = средних ) программистов.Если хочется ( но колется ), или уже "используем", но что то хреново получается - сходите на тренинг чтобы не тратить время на пробивание стен своей головой. Во первых далеко не всем и не всегда это рецепт помогает, а во вторых может быть вы просто "не умеете их правильно готовить"" - спасибо за столь эмоциональный отзыв :)

Еще одним немаловажным событием, лично для меня, было то, что мы делали этот тренинг уже в своем новом офисе на Газетном переулке. Теперь у нас есть свой небольшой тренинговый зал и кабинет, где мои колеги - Ирина и Асхат, творят дела на благо компании ScrumTrek и компаний, которым мы помогаем стать лучшими на российском рынке :). Поэтому всех друзей и знакомых ждем к себе в гости.

Управление требованиями

Второй и третий день прошел в атмосфере "рабочей группы" - в течении двух дней в кругу восьми Product Owner'ов и Project Manager'ов мы обсуждали жизненный цикл сбора требований в Agile-процессе. Было много обсуждений, безусловно, некоторые из них не касались требований напрямую, а имели процессный характер, но мы их не стали обходить стороной. Весь тренинг состоял из нескольких активностей:

Теория

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

Практические инструменты и упражнения наработанные индустрией, а так же личный опыт работы с компаниями по этому направлению.

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

Приятно было, что на тренинге столкнулись менеджеры из расных сегментов: Продуктовая разработка на Российском рынке и Аутсорс разработка с западными заказчиками. Завязывались интересные дискуссии, а опыт Ромы Юферева (Avicode) был неменее полезен для многих, чем кейсы из моей практики.

После тренинга Роман написал мне письмо со своим напутствующим отзывом:

Среди проблем, с которыми наиболее часто приходится сталкиваться специалистам, работающим в области разработки ПО можно выделить две наиболее значимых области: Проблемы Процесса и Проблемы Продукта. И зачастую (по крайней мере, на моей практике) основной фокус усилий направляется на создание/улучшение процесса. Особенно в outsource-проектах, где иногда можно наблюдать «феномен Золушки»: процесс является любимой дочкой, а продукт и его проблемы волнуют разве что «добрую фею» - Product Owner-а. Находясь в роли этой «доброй феи» в данный момент на 2-х аутсорсинговых и одном внутреннем проектах я четко осознал, что одной из ключевых проблем в моем случае является вопрос сбора, анализа и упорядоченной работы с требованиями. Тренинг “Agile Requirement Analysis” Никиты Филиппова уже помог мне (хотя прошла всего неделя) упорядочить и перестроить процесс работы с требованиями на двух проектах. Еще не все «бреши» заделаны, но уже четко видны проблемы, ясно их влияние на процесс разработки и определены меры по решению этих проблем. Такой тренинг, на мой взгляд, является крайне полезным, так как покрывает область проблем, в которой сам Scrum нам ничего не предоставляет. На тренинге нам удалось изучить(вспомнить) набор практик и инструментов, которые можно применять фактически в любом итеративном процессе разработки: Составление Vision, определение целей и ограничений проекта, определение пользовательских ролей и т.д. Так что какой бы процесс у вас ни был (может, даже WTF,…простите waterfall) – этот тренинг будет скорее всего полезен.

Вот такие новости за прошедший февраль :)

Увидимся в марте

Конференции об Agile и AgileDays в рамках РИТ

Планы компании на следущее полугодие

Новые интересные тренинги и статьи по управлению разработкой ПО и ИТ-компаниями спомощью Lean и Agile

Чем еще можно улучшить разработку?

Software Quality Assurance Days

noreply@blogger.com (Ирина Цыбденова) — Mon, 15 Feb 2010 09:16:00 +0000

14 - 15 мая 2010 г в Харькове состоится 7-ая Международная конференция специалистов в области обеспечения качества ПО.
SQA Days это прекрасная платформа общения и обмена опытом для людей, вовлеченных в сферу тестирования ПО. Это возможность рассказать про свои достижения, показать, как эффективно использовать инструменты, методики и методологии. Ну и, конечно же, это новые полезные знакомства. Узнать подробнее

Людям о менеджерах

noreply@blogger.com (Асхат Уразбаев) — Wed, 10 Feb 2010 08:21:00 +0000

Среда, 10 февраля, 17.30 по Москве. Денис Войханский проведет вебинар "Людям о менеджерах". Будет много всего интересного, подробности тут

Полезные метрики в Agile: Метрики производительности

noreply@blogger.com (Никита Филиппов) — Mon, 25 Jan 2010 12:43:00 +0000

Быть или не быть...

Сегодня я хочу поговорить о метриках.

Нужны они или нет?
Наш опыт показывает, что мало кто измеряет те или иные показатели в разработке. И на то есть причины:

Некоторые меряют, но не знают зачем и перестают это делать
Другие хотят что нибудь померить и в этом случае сталкиваются с огромным количеством метрик. Что и чем мерить не всегда понятно.
Третьи используют все метрики, о которых написано в книгах, что приносит больше вреда, чем пользы.
Остальные просто не видят в этом смысла

Все очень просто. У вас есть процесс, вам хочется, чтобы этот процесс позволял(помогал) делать хороший продукт. Для этого нам нужны показатели, отклонение которых будут давать нам информацию для корректировки нашего процесса.

Метрики - это инструмент позволяющий принимать решения по улучшению взвешено и объективно.
Нужно заметить, что при всей объективности метрик легко можно попасть в ловушку, где "Термометр измеряет температуру термометра". Данная метрика будет интересной и возможно очень точной, но пользы нести не будет.

В этом и последующих постах я буду рассказывать о "Полезных метриках" и рассказывать об опасных способах их использования

Ниже я буду описывать метрики которые мы считаем крайне полезными для отслеживания качества процесса разработки. Мы делим их на 4 основных направления:

Производительность
Прогнозирование
Качество
Ценности

Производительность.
Для оценки производительности, мы используем: Velocity, WIP, Story Cycle Time(Avg),

Velocity
Цель: Определить производительность команды за итерацию
Что измеряем: количество фитч в итерацию.

К сожалению наши фитчи не равны между собой, поэтому мы используем "Относительную оценку сложности" названную StoryPoints.

Рост Velocity положительная характеристика.

Расчет Velocity

Оценка

Чтобы измерять Velocity вам нужно оценить ваш список задач в StoryPoints.

Два наиболее популярных способа оценки:

Размеры в стиле "Ваш размер одежды": XS(1), S(2), M(4), L(8), XL(16), XXL(128), Unknown
Planning Poker

Подсчет Velocity

Считаем сколько реально сделанных задач в StoryPoints сделано за несколько итераций
Вычисляем среднеарифметическое

Velocity = (SP1 + SP2+SP3+SPn)/n

Факты
Velocity изменяется, на это может влиять несколько факторов:

Состав команды изменился. Каждый раз, когда у вас новый член команды или наоборот кто-то уходит, происходит спад производительности. При уходе члена команды он естественно больше, чем когда вы принимаете новичка. С приходом новичка, появляется потребность в притирке и обучении, что снижает вашу производительность на некоторое время.
Улучшения в процессе повлияли на производительность, вы делаете ретроспективы, улучшаете свою работу, безусловно это может повлиять на вашу скорость выпуска функциональности
Обмен знаниями. Чем дольше люди работают в проекте, тем больше они знают о проекте, тем быстрее принимают правильные решения: где и что нужно внедрить, написать, чтобы получить новую функциональность.

Важно:
Velocity возрастает - хорошо или плохо?

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

Work in Progress
Метрика Work in progress пришла к нам из Lean Software Development.
С точки зрения эффективного процесса разработки (и производства), чем меньше задач в процессе работы, тем выше пропускная способность "Рабочей ячейки" (Команды)

Цель WIP: Повысить пропускную способность, повысить Velocity. Безусловно, само по себе значение WIP нам ничего не даст. Наша цель - Limit Work in Progress.

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

Хорошей практикой является сокращение WIP от первых стадий до конечных, от большего к меньшему.

На фазе Development WIP = 5
Testing WIP = 3
Deploy WIP = 1.

Этот подход отлично решает проблемы сбалансированности работ в итерации: "Много кода, но мало протестированно". Теперь, чтобы взять еще одну задачу, нужно чтобы задачи "протолкнулись" на уровне тестирования.

Высокий WIP является негативным показателем
Низкий WIP - положительная характеристика, как для производительности, так и для команды в целом - показатель уровня кроссфункциональности.

(In Sprint) Story Cycle Time
Это еще одна метрика, которую стоит отслеживать при анализе производительности вашей команды.

Цель SCT: Оценить производительность на уровне каждой фичи. Индикатор для оценки объективности Velocity.
Что измерять: Время старта задачи, время окончания (либо выпуска ее на продакшн - зависит от целей вашего ).

Как правило мы используем Story Cycle Time, как среднее значение (Avg. Story Cycle time), так как не все задачи имеют одинаковой размер.

Возможно вы спросите, зачем измерять и Cycle Time и WIP и Velocity (Velocity достаточно)? Дело в том, что Velocity, как метрика может искажаться и вы будете получать ложную информацию и принимать не правильные решения.

Очень важно валидировать результаты на всех уровнях, несколькими способами (количество StoryPoints за итерацию "сверху", контроль производительности спомощью WIP и SCT "снизу")

Например:
Вы измеряете Velocity, WIP, SCT. Фиксированные данные нам ничего не дают, все метрики интересны, если мы измеряем отклонения и делаем выводы.

Velocity вырос.
Cycle Time увеличился.

или

Cycle Time уменьшается
Velocity стабилно

и т.д.

В первом случае скорее всего это нехороший симптом. Повод обсудить на ретроспективе.

Причины могут быть разные (например: команда начала оценивает задачи в более крупных оценках, что приводит к инфляция Storypoints), но самое главное - вы получаете сигнал для того, чтобы собраться и проанализировать сложившуюся ситуацию, получаете возможность выявить проблему как можно раньше:

Может быть, имеет смысл переоценить весь бэклог. Возможно, менеджер использовал Velocity для давления на команду, и она невольно начала завышать оценки. Это породило рост Velocity "на бумаге", но не на деле.
Возможно есть проблемы, с качеством.(в погоне за количеством)
и т.д.

Вывод:

Комплексный анализ анализ Velocity и Story Cycle Time и WIP дают объективную информацию о скорости разработки:

В фичах за итерацию
Среднее время выполнения фичи в итерации.
WIP используется как инструмент выстраивания сбалансированной работы в итерации. Стремясь сокращать WIP, вы будете находить решения, позволяющие вам повышать производительность.

Вы получаете объективную информацию (mistake proof), так как контроль Velocity (как основной бизнес метрики) подкреплен анализом WIP и StoryCycle Time.

Полезные метрики

noreply@blogger.com (Никита Филиппов) — Sat, 23 Jan 2010 21:51:00 +0000

Agile Base Camp 2010

Agilemetrics

View more documents from Nfilippov.

Я заболел, но мой колега дал шанс докладу быть услышанным...
Асхат зачитал мой доклад про метрики=)

Слайды "Внедрение Agile на разных этапах развития компании"

noreply@blogger.com (Асхат Уразбаев) — Sat, 23 Jan 2010 16:09:00 +0000

Презентация с AgileBaseCamp

Внедрение Agile на разных этапах развития компании

View more presentations from Askhat Urazbaev.

Тренинги в Екатеринбурге

noreply@blogger.com (Асхат Уразбаев) — Thu, 21 Jan 2010 14:33:00 +0000

25-го января мы, Дима Лобасев и Асхат Уразбаев, съездили в Екатеринбург. Я читал однодневный тренинг по Scrum, а Дима – тренинг по Test Driven Development.

Екатеринбург встретил нас совершенно дикими (уральскими) морозами в тридцать с лишним градусов. Несмотря на то, что от гостиницы до места тренинга было всего 10 минут ходу, мы с Димой успевали очень основательно промерзнуть.

Зато встречали очень тепло, так что все было проведено на высшем уровне!

Тренинг нам помогали организовывать коллеги из компании “СКБ Контур” и Microsoft. Интерес к Scrum был огромный, участников было так много, что часть людей не попали на тренинг. Так что в феврале в скором времени будет проведен еще один тренинг в Екатеринбурге :-).

Сразу после тренингов Дима уехал, а я остался поработать с одной из команд компании "СКБ Контур". Команда оказалось очень сильной, с правильным отношением к качеству и коду! Мы попробовали всякие современные практики Agile по работе с требованиями и внутри итерации.
Из интересного - ребята уже использовали практику Story Owner. Это когда кто-нибудь из команды ответчает за разработку требований к истории. Разумеется, сама история потом внутри итерации потом разрабатывается командно.

Scrum is

noreply@blogger.com (Асхат Уразбаев) — Fri, 15 Jan 2010 10:12:00 +0000

В блоге у Алексея Кривицкого (кстати, очень рекомендую) есть любопытная заметка о том, является ли Scrum инструментом или чем-то большим.

Леша считает, что Scrum - это не инструмент. Scrum для Алексея – это совокупность ценностей, принципов, хороших практик разработки, современных подходов лидерства и собственно, самого каркаса скрам.

Так что такое Scrum – инструмент или нечто большее?

Изначально Scrum был очень простым и понятным фреймворком. Он был сформулирован Schwaber в книге Agile Software Development with Scrum и потом чуть исправлен и дополнен в книге Agile Software Management with Scrum.

Простота Scrum имеет и хорошие и плохие стороны. С одной стороны, чем меньше правил, тем легче их придерживаться. Лишние правила способствуют догматичности методологии. Ну типа, надо делать именно так, а не иначе, ведь так написано в книжке. А ведь догматичность - это то, с чем мы вроде как боремся :-)

Ken Schwaber считает, что в Scrum не нужно привносить новые правила. Он активно против, см его статью на сайте Scrum Alliance:

Он говорит так: "The context, players, and dynamics of each organization's situation is unique, and the solutions must be unique, too".

Самый главный минус – описанного количества правил Scrum явно недостаточно для реальной проектной работы. Индустрия придумывает новые подходы, практики и правила, мутируют роли и так далее. В том числе появляются новые методологии (например, канбан), которые тоже что-то привносят в Scrum.

Тренинги проводят те, кто работает с реальными командами. Они учат не Scrum как таковому (потому что он очень маленький, тренинг бы занял менее часа), а скорее некоторому набору устоявшихся и эффективных практик разработки. Так вот, то, чему они учат - тоже меняется во времени. Эволюцию такого "Scrum" суммировал Dan Rawsthorne в своем блоге. Правда, это его "личная" эволюция, всего лишь один из вариантов, хотя вроде как (по ощущениям) в где-то в общем тренде. :-)
Получается, что методология, которую большинство людей называют Scrum, скрамом, собственно говоря, не является.

Поскольку мы тут говорим об инструментах, я приведу такую аналогию. Купили вы бензопилу и в восторге. Однако другие пользователи считают, что бензопила - отстой и не работает. Вы выслушиваете жалобы людей с отрезанными пальцами. Объясняете, что такое бензин и где его брать. Боретесь с распространенным мнением, что бензопилы работают только для маленьких деревьев. Решаете проблемы с лесорубами при переходе с топора на бензопилу. Вы создали тренинг, успешно обучили сто пятьсот команд работе с бензопилами и написали книжку "Философия бензопилы". .

И вот вы встречаете в чьем-то блоге запись о том, что бензопила – это инструмент и ваша душа не выдерживает... :-)

AgileDays'09

noreply@blogger.com (Ирина Цыбденова) — Thu, 24 Dec 2009 08:54:00 +0000

Всем привет!

Конференция AgileDays'09 прошла и мы спешим поделиться впечатлениями :)

Отличительной особенностью конференции стал упор на практический опыт и реальное применение гибких методологий. Программа была разделена на 3 трека – experience report, technical excellence, main stage. Особенный интерес у участников вызвали доклады представителей крупных компаний. Евгений Сорокин и Антон Бевзюк из компании Intel рассказали о том, как эволюционировали их подходы за более чем семь лет применения Agile в проектах компании. Дмитрий Никонов рассказал об опыте использования Scrum в компании Microsoft и Amazon, Артем Марченко – о подходах к планированию в компании Nokia.
Серия докладов была посвящена одной из самых актуальных проблем – масштабированию Agile на большие команды. По забавному совпадению доклады на эту тему делали три Дмитрия – Лапыгин (IBM), Лобасев (RapidSoft) и Викторов (F-Secure).
Отдельный трек был посвящен техническим докладам, в рамках которого Тимур Маркунин (IBM) и Евгений Злобин (Microsoft) провели «соревнование» платформ IBM Rational Jazz и MS Team System. Соревнование проходило в непринужденной обстановке, которое вызвало бурное обсуждение.
В рамках конференции прошел тренинг-сертификация "Scrum Master Certification". Участники тренинга стали сертифицированными скрам-мастерами. Тренинг провел Senior Coach компании Danube, сертифицированный Scrum-тренер Dan Rawsthorne.
Несколько отзывов от участников и докладчиков AgileDays'09:
«Весьма интересными и полезными оказались доклады представителей различных компаний о том, как в их компаниях внедрялся Scrum, и на какие грабли они наступали в процессе внедрения, - рассказал Евгений Ларчик, Ланит-Терком. - Понравилась свободная атмосфера на конференции, возможность в любой момент подойти к докладчику, чьё выступление меня заинтересовало, и обсудить вопросы, которые остались после его доклада. С удовольствием буду участвовать в таких мероприятиях и впредь».
«Уникальное по формату и содержанию мероприятие, аналогов которому в России до этого не было, а лет 5 назад подобного рода конференция была невозможна (ИТ-сообщество было не готово к "промышленному" использованию гибких методологий). Уже некоторые подсмотренные практики и рекомендации используем в своей работе» Олег Клименко, КазСофт.
«Это лучшее мероприятие, на котором я был в этом году. Всё замечательно - и содержание, и организация» Леонид Ларшин, Макхост
"Мы успешно внедрили Agile, а точнее одну из его практик - Scrum в стандартной по размеру команде разработчиков из 5-7 человек, и нам было интересно посмотреть на опыт более крупных коллег по ИТ-рынку, таких как Intel и IBM, чтобы узнать заранее о болезнях роста. В целом обмен опытом состоялся, конференция прошла на достойном уровне, подтвердив право называться Всероссийской / Международной (нужное оставить). Несомненно, будем приезжать еще" Денис Ермаков, Веблайм
«Очень радует, что у нас проводятся такие мероприятия, но еще более - что они собирают такое количество людей. Интерес к гибой разработке растет с каждым годом, здесь в этом можно убедиться наглядно. И, в этом же ключе, трудно переоценить значение практических докладов о внедрении и использовании Agile, которым на конференции выделена целая секция» Максим Гапонов, Авто ру

С фотографиями, презентациями и видео можно ознакомиться на сайте конференции www.agiledays.ru

Управление требованиями в Agile

noreply@blogger.com (Асхат Уразбаев) — Mon, 23 Nov 2009 13:09:00 +0000

Управление проектом/продуктом в Agile в первую очередь связано с эффективным управлением требованиями. Хорошие требования = ценный для заказчика продукт. Для любого менеджера продуктов существует две основных преграды к реализации продукта:

Что делать в первую очередь? Как управлять приоритетами?
Как интегрировать сбор требований в итеративный процесс разработки.

На ближайшей встрече AgileRussia, которая пройдет 2 декабря, мы обсудим:

Чем отличается сбор требований в Agile от классических подходов
Какие существуют практики работы с требованиями
Обсудим за что должен отвечать Product Owner.
Затронем тему Usability, как неотъемлемую часть процесса разработки требований.
Поговорим о том, что такое инкрементальный дизайн при разработке интерфейса десктоп и веб приложений

Место и время проведения: 02.12.09, 19:00, центр Москвы, офис компании Заказные ИнформСистемы

Условия участия: Бесплатно. Регистрация обязательная. Просто заполните регистрационную форму или напишите письмо на askhat@agilerussia.ru.

Чехов, встаньте!

noreply@blogger.com (Асхат Уразбаев) — Fri, 13 Nov 2009 22:21:00 +0000

Standup Chekov

I worked in an XP team where we posted a checklist on our team board to remind us what to cover at our daily standup. We called this list the “Standup Chekov,” and we posted a sign on our team board with a picture of Pavel Chekhov, a character from the original Star Trek TV series to remind us to check off our Chekov questions.

You’ll notice we moved on from the three-question format. We had some other items we wanted to cover, mostly related to customer support. For instance, every day we took turns to make sure that some developers were designated “Exposed,” which meant interruptible for sales and customer support issues. At the time, we were experimenting with tracking time spent per story so we could improve our estimates. But the most crucial question that we used this meeting for was who would be pair programming together.

Our team later added some other Chekovs to remind them about other things, such as getting a story done.

Из книги "Agile Coaching" by Rachel Davies and Liz Sedley

Куда подевался менеджер в Agile?

noreply@blogger.com (Асхат Уразбаев) — Mon, 09 Nov 2009 13:10:00 +0000

Чем занимается менеджер в Agile? Быть того не может, что весь этот замес правильного отношения к делу в стиле "get the job done", бесценных навыков по проведению совещаний, искусства построения правильных отношений с заказчиком и прочих весьма полезных вещей стали вдруг никому не нужны в Agile.

Вопрос не праздный, поскольку в Scrum никакого менеджера проекта нет. Вместо этого есть три роли: Product Owner, Scrum Master и команда.

Давайте посмотрим, что стало с менеджером проекта.

Я честно выписал все активности менеджера проекта из PMBOK. Получилось довольно много:

Управление интеграцией проекта
Разработка Устава проекта
Разработка предварительного описания содержания проекта
Разработка плана управления проектом
Руководство и управление исполнением проекта
Мониторинг и управление работами проекта
Общее управление изменениями
Закрытие проекта
Управление содержанием проекта
Планирование содержания
Определение содержания
Создание иерархической структуры работ (ИСР)
Подтверждение содержания
Управление содержанием
Управление сроками проекта
Определение состава операций
Определение взаимосвязей операций
Оценка ресурсов операций
Оценка длительности операций
Разработка расписания
Управление расписанием
Управление стоимостью проекта
Стоимостная оценка
Разработка бюджета расходов
Управление стоимостью
Управление качеством проекта
Планирование качества
Процесс обеспечения качества
Процесс контроля качества
Управление человеческими ресурсами проекта
Планирование человеческих ресурсов
Набор команды проекта
Развитие команды проекта
Управление командой проекта
Управление коммуникациями проекта
Планирование коммуникаций
Распространение информации
Отчетность по исполнению
Управление участниками проекта
Управление рисками проекта
Планирование управления рисками
Идентификация рисков
Качественный анализ рисков
Количественный анализ рисков
Планирование реагирования на риски
Мониторинг и управление рисками
Управление поставками проекта
Планирование покупок и приобретений
Планирование контрактов
Запрос информации у продавцов
Выбор продавцов
Администрирование контрактов
Закрытие контракта

Понятно, что в Scrum некоторые вещи называются по другому. Что поделаешь, каждая методология вносит свои термины (лично я это ненавижу - зачем понадобилось итерацию называть спринтом? Зачем standup называется daily scrum?).

Кое-что остается за бортом методологии. Например, управление поставками никак не описывается в Scrum. Делать, понятно, это все равно иногда приходится.

Давайте раскидаем все эти активности по ролям Scrum. Для понятности я буду все именовать так, как это делается в Agile, а описание из PMBoK буду использоваться в качестве справочника, просто чтобы ничего не забыть. У меня получается следующая картина:

Получается, что обязанности классического менеджера более или менее равномерно распределились по всем ролям в Scrum. Менеджер проекта при переходе в Scrum чаще всего достаточно органично трансформируется в Product Owner'a.

За кадром на самом деле осталось ровно две вещи, которые надо таки делать, хотя Scrum ни сном ни духом об этом не говорит.

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

Спонсор. Управление бюджетом

Старт и закрытие проекта
Управление поставками проекта (на уровне принятия решений по бюджету)
Ввод и вывод людей из команды
Бюджетирование проекта

Вторая группа - это HR практически в чистом виде:

HR. Управление людьми

Найм и увольнение сотрудников

Управление ресурсами: зарплаты, бонусы, повышения

Вопрос в том, кто это должен делать в Scrum-команде? Достаточно часто это какие-то отдельные люди. Спонсором проекта является вышестоящий менеджер (генеральный директор либо начальник отдела). HR-активности логичным образом падают на HR-менеджера. Впрочем, в Luxoft, например, есть специальная роль - people manager, который чаще всего является менеджером подразделения.

Относительно неплохо все эти вещи может делать Product Owner, если вы конечно не боитесь его перегрузить :-)

Только не надо совмещать роли HR и Scrum Master в одном человеке! Скрам-мастер все таки член команды, эдакий добрый малый, свой в доску. Представьте себе, утром он помогает команде, а ночью увольняет несправившихся. Это какой-то оборотень получается!

AgileDays лотерея: 10 билетов бесплатно!

noreply@blogger.com (Никита Филиппов) — Mon, 09 Nov 2009 10:48:00 +0000

Хочешь попасть на AgileDays'09? Тогда участвуй в нашей лотерее! С 9 по 23 ноября будет разыграно 10 билетов. Чтобы участвовать в розыгрыше билетов тебе нужно:

Зарегистрироваться на сайте http://AgileDays.ru, заполнив свой профиль.
Отметить наиболее интересные доклады
Написать в twitter или в свой блог о докладе на AgileDays, наиболее полюбившийся тебе (Или просто заметку про AgileDays).
Для твиттерян: Зафоловить @agiledays в твиттере, сделать ретвит поста о розыгрыше.
Для блогеров: Добавить свой блог в раздел Соцссылки!

Розыгрыш билетов будет проходить каждые 3 дня. Следите за нами в Twitter'е @Agiledays и будьте в курсе событий!

Удачи!