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

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

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

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

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

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

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

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

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?

Чем занимается менеджер в 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 билетов бесплатно!

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

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

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

Удачи!

Встреча AgileRussia "Экстремальное программирование"

9 ноября 2009 года состоится очередная встреча AgileRussia, которая будет посвящена обсуждению такой старого и заслуженного метода, как Extreme Programming.

Кто-нибудь вообще использовал "Метафору"? Может быть, весь ваш код разрабатывается в паре? Как внедрить Test Driven Development? Сколько тестов "уже достаточно"? Кто-нибудь может объяснить, что такое Evolutionary Architecture и Emergent Design?

• Рассмотрим назначение практик XP
  
• Подискутируем на тему некоторых важных вопросов
  
• Обсудим результаты внедрения XP
  
• Рассмотрим проблемы на пути внедрения и методы борьбы с ними
  

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

Обзор докладов конференции AgileDays

Ну что же, доклады конференции более или менее понятны и устаканились. Расскажу, что лично мне особенно интересно.

Из серии "это невозможно" у нас такие доклады:

Пока люди холиварят на тему "отсутствия ответа на вопрос, сколько будет стоить в Agile", у нас на конференции выступит Михаил Ганчиков и расскажет, как они у себя в компании Exigen работают по Scrum в проектах с фиксированной ценой (Fixed Price). На всякий случай напоминаю, что у нас на конференции только практический опыт, так что "апологеты аджайла много, если не непрерывно, лгут, и это бесит" за аргумент уже не прокатывает. :-)

Алексей Омельянчук (ИС-Сигма) в докладе "8 битный Scrum" расскажет о своем опыте scrum-проектов по разработке программно-аппаратных комплексов для 8-битных платформ. Если вы интересуетесь этой темой - почитайте для начала старую статью Алексея на сайте AgileRussia на эту тему.

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

Наш западный коллега и признанный гуру Dan Rawsthorne (Danube) расскажет о том, кто такой Product Owner. Не секрет, что PO - самая непростая роль, от которой в большой степени зависит успех проекта.Dan расскажет о том, как представление об этой роли изменилось в современных подходах Agile и что по этому поводу думают "лучшие собаководы" aka "апологеты аджайла".

Про Стаса Фомина я уже рассказывал, уверен, это будет бомба. Если коротко, речь пойдет о способах визуализации процессов разработки в виде музыкальных клипов.

Артем Марченко (менеджер продуктов в компании Nokia и по совместительству один из авторов популярного блогаhttp://AgileSoftwareDevelopment.com) сделает обзор подходов планировании в Agile. Это повторение одного из самых популярных докладов на конфенции AgileEE.com.