Практическая программа для тех, кто внедряет Agile в своих проектах. От признанных экспертов индустрии Agile.

1. Современный подход к гибким методологиям: методологии, техники, нюансы, ошибки и грабли
2. Полный набор практик как внедрить гибкий процесс разработки в своей комнаде, в своей ситуации и в своем контексте

Авторы Клуба Agile-практиков — Асхат Уразбаев и Никита Филиппов. Признанные эксперты с многолетним опытом в области внедрения гибких методологий. Главные Agile-евангелисты России. Основатели сообщества Agile Russia. Основатели консалтинговой компании Scrumtrek, внедряющей гибкие процессы разработки в ведущих компаниях России и СНГ. Основатели AgileDays — ведущей российской конференции по гибким методологиям.

Услышать авторов в живую!

Специально для того, чтобы вы могли поближе познакомиться с авторами и ведущими Клубов, мы провели Stratoplan Program-2012 BootCamp, где наши спикеры рассказали по одному небольшому концепту своей программы:

Пробовали внедрять Agile?

Возможно, вы уже пробовали внедрять Agile. Что-то получилось, какие-то вещи провалились. Некоторые вещи, может быть, даже попробовать страшновато?

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

Почему?

• Это просто не ложится на историю ваших предыдущих отношений с командой и заказчиком. Многое уже сказано и сделано. Набрана скорость и развернуться на месте не выйдет.
• Цена ошибки может оказаться слишком высокой и вы боитесь попробовать. Чаще всего вы правы. На самом деле работают только простые практики. Их имеет смысл усложнять, но только после первого успеха.

Стратегия и тактика внедрения

Мало знать ЧТО делать. Нужно понимать, КАК делать. Вы должны научиться разрабатывать ТАКТИКУ и СТРАТЕГИЮ внедрения изменений в конкретных условиях.

Это и есть основной принцип нашего курса. Каждый шаг мы будем рассматривать с точки зрения целей и практики внедрения — в команде, организации или в работе с заказчиком.

Аспекты курса

Именно по этому мы решили запустить 3-месячный клуб Agile-практиков. Программа Клуба выстроена логически и многократно обкатана на живых тренингах и в процессе практических внедрений Agile в компаниях самого разного типа. Итак, программа:

1. Scrum
2. Kanban
3. Тактика внедрения
4. Превращение команды в самоорганизующуюся
5. Роли и ответственность: от теории к практике
6. Ретроспектива и улучшение процессов
7. Backlog и User Story, критерии готовности
8. Оценка сроков и контроль проекта в Scrum и Kanban
9. Взаимодействие с заказчиком.Fixed Price & Fixed Scope
10. Распределенная разработка, большие проекты и команды
11. Тестирование в Agile
12. Создание стратегии внедрения

Каждую практику мы будем рассматривать с точки зрения следующих аспектов:

• Как п(р)одать практику команде/заказчику
• Типичные грабли и что с ними делать
• Тактика и стратегия внедрения

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

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

http://agilitrix.com/2011/06/lego-strategic-play-creative-collaborative-solving-wicked-problems/

StrategicPlay®  (Lego® SERIOUS PLAY®) – мощный эмпирический инструмент для продвижения инноваций и бизнес результатов. В этой статье я суммирую то, чему научился на тренинге  Jacqueline Lloyd Smith.

Поймите сложную проблему

На мой взгляд, основное в StrategicPlay® – это великолепная помощь группе в достижении общего понимания сложных проблем и друг друга. Рассмотрим сложную модель, которая показана ниже. Она итеративно развивалась в течение фаз строительства системы, сторителлинга (storytelling) и интеграции.  Физическая модель не имеет собственной ценности, ее смысл определяют участники игры, решения и модели мышления.

Приложения и как это работает

Рассмотрим диаграмму представленную ниже. Овалы – это типичные приложения StrategicPlay® , под ними – механизмы, используемые для достижения этих результатов.

В своей основе StrategicPlay® - это вспомогательный инструмент. Другие вспомогательные инструменты – заметки, GameStorming и Visual Facilitation.

Почему это работает

Ниже рассмотрены ключевые причины того, почему StrategicPlay® работает так хорошо. На этой картинке (кликните для увеличения) обобщено много хорошего материала (если нужен скринкаст, дайте мне знать через twitter или комментарии).

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

Справа – смешная картинка гомункула, которая поможет вам провести ассоциацию с некоторыми вещами в этом исследовании. Такой видят связь мозга с телом психологи. Обратите внимание, что связь с руками непропорционально больше - когда мы используем наши руки, мы намного лучше используем наш мозга. Мы подключены, когда используем руки, а не просто сидим за столом и разговариваем.

Откуда все это появилось?

Начиная с 1999 года компания Lego® работала с бизнес консультантами и психологами для решения своих собственных проблем развития и создания эффективной стратегии компании. Результатом этого стало изобретение Lego® SERIOUS PLAY® , которая стала общедоступной в июне 2010 года. StrategicPlay® была создана для развития новых приложений и  тренировки помощников. Если вам интересно, посмотрите презентацию История и эволюция StrategicPlay®. Возможно вы также захотите узнать о взглядах Katrin Elster на то,  Как и почему работает StrategicPlay® .

Вау! Это круто! Что дальше?

Хорошая новость заключается в том, что это действительно мощный инструмент. Плохая новость в том, что он сложен и требует значительных вложений.

Он не похож на Agile игры, инструкцию которых можно взять на TastyCupcakes.org и сразу использовать. К сожалению, вы не можете просто вывалить сумку с разнородными деталями Lego® на стол и получить результат.

Вот что нужно, чтобы начать:

1. Этот шаг для тех, у кого нет никакого опыта с StrategicPlay®. Вам нужно самим почуствовать, насколько это здорово. Попросите меня или другого помощника (facilitator) по StrategicPlay® дать вводную сессию в вашем родном городе или на конференции.
2. Пройдите тренинг в Северной Америке  (как я) или в Европе.
3. Купите специальный Lego® kit. Да, они дорогие и они вам понадобятся.

15 клубов профессионального и карьерного развития проекта Стратоплан.Ру!

С 15 мая начинает работу продолжение самой нашумевшей программы онлайн образования для ИТ-шников — летний набор Программы-2012. В первом наборе программы клубы Стратоплана собрали 315 студентов, которые инвестировали 3 месяца своей жизни в движение по одному или нескольким направлениям профессионального и карьерного роста. Всего в клубах Стратоплана за два года прошло обучение 650 студентов.

С 15 мая стартует второй набор Программы-2012 — к 11-ти клубам весеннего набора, команда Стратоплана прибавила еще 4-ре! Теперь на ваш выбор есть 15 клубов профессионального и карьерного роста!

1.   Клуб профессионального развития: рост в менеджеры

2.   Клуб профессионального развития: предпринимательство

3.   Клуб профессионального развития: лидерство

4.   Клуб профессионального развития: переговоры

5.   Клуб профессионального развития: тренерский бизнес

6.   Клуб по работе с сотрудниками

7.   Клуб по работе с командами

8.   Клуб по работе с заказчиком

9.   Клуб практического тестирования

10.  Клуб практического проектирования

11.  Клуб практического программирования

12.  Клуб системного анализа

13.  Клуб управления проектами в PMI

14.  Клуб управления проектами в Agile

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

Формат работы клубов Стратоплана прост: знания + мотивационный пинок + практика в реальной жизни + обратная связь от эксперта + активная группа единомышленников. И те, кто хотят, получают от этого формата гораздо больше, чем от традиционного оффлайн обучения. Формат клубного обучения работает.

Команда тренеров летнего набора составит 17 человек. И это сильнейшая команда тренеров, которая есть в нашей индустрии. Это энтузиасты, потрясающие специалисты своего дела, которые ко всему прочему имеют уникальный опыт передачи знаний и навыков. Если учиться, то именно у этих людей.

Если вы решите присоединиться к клубам летнего набора Программы-2012, команда Стратоплана будет счастлива вложить свое время, внимание, накопленный опыт в достижение вами максимальных результатов!

Специально для наших читателей действует скидка 10% на оплату клубов:

Оплатить 1 клуб – $540

Оплатить 2 клуба – $990

Оплатить 3 клуба – $1350
Не забывайте, что возможна оплата в рассрочку:

Внести первый платеж за 1 клуб – $200

Внести первый платеж за 2 клуба – $360

Внести первый платеж за 3 клуба – $495
Работа начинается с 15 мая и продлится до 15 августа. Принять решение стать участником можно уже сейчас. Присоединяйтесь к студентам Стратоплана!

………………………..

А еще команда Стратоплана запускает сразу две конференции!

1. Конференция – «Прагматик.РМ»: 18 мая в Питере!

Виктория Мусияченко, руководитель направления Конференции Стратоплана:

“Мы давно хотели посетить конференцию, где будут только самые клевые спикеры, только практики и только те, кого нам самим хотелось бы послушать и у кого мы готовы поучиться. А потом мы как-то вдруг поняли, что такую конференцию надо делать самим. Конференцию, где не будет «темных лошадок» с непонятным заранее качеством докладов, где будут практики своего дела, которые будут говорить не про подходы и философию, а про свой реальный опыт”.
Наши спикеры:
Слава Панкратов и Саша Орлов, Иван Селиховкин, Дмитрий Безуглый, Никита Филиппов, Теймураз Орагвелидзе, Максим Вишнивецкий, Роман Поборчий.

Специально для наших читателей действует скидка 10% на оплату участия в конференции и сопутствующих тренингах (скидка действительна до 11 мая):

Оплатить участие в конференции “Прагматик.РМ” – $180

Оплатить участие в тренинге после конференции – $180

Оплатить участие в конференции+тренинг с дополнительной скидкой – $300
Внимание! До 11 мая действует стоимость “ранняя пташка”, спешите!

Программа конференции «Прагматик.РМ», информация о спикерах, описания тренингов, детальная информация о регистрации – все на нашем сайте.

2. Первая распределенная еженедельная конференция для ИТ-специалистов Стратоконф!

Александр Орлов, со-основатель и ведущий тренер Стратоплан.Ру:

“Мы давно хотели сделать опыт и лучшие практики нашей отрасли доступными широкому кругу слушателей. Тем более, что локальные мероприятия со временем теряют свою первозданную свежесть как для спикеров, которые видят одни и те же знакомые лица, так и для участников, которые часто ходят послушать уже знакомого докладчика на знакомую тему в знакомом формате”.
Слава Панкратов, со-основатель и ведущий тренер Стратоплан.Ру:

“Процесс распространения профессиональных знаний и опыта возглавляют большие отраслевые мероприятия, организаторы которых проводят конференции в крупных городах, куда съезжаются и интересные докладчики и большое количество участников. Но эти поездки далеко не всегда по карману отдельным участникам, ведь не у всех компаний есть бюджеты, чтобы оплатить дорогу, участие и командировку своим сотрудникам, кроме того — нужно найти время, да и проводятся они не так часто, как хотелось бы.

Что касается онлайн-мероприятий — это неплохая альтернатива для всех, однако онлайн лишен, пожалуй, самого главного, что есть в живых мероприятиях — общения, знакомств и ощущения профессиональной тусовки, в которую ты входишь”.
С 19-го апреля 2012 года, каждый четверг, в городах сети Стратоконф, вы можете прийти вечером в уютный зал и в кругу друзей и знакомых послушать интересных спикеров, а, возможно, и выступить с интересной практической темой. Ближайшая послепраздничная сессия – 17-го мая!

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

С уважением,
Команда Стратоплан.ру

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

На трениге будут рассмотрены следующие темы:

• Введение
• Обоснование гибких методик разработки и их преимущества
• Скрам: общее представление и области применения
• Процесс разработки в скрам
• Планирование: итерации, релиза, продукта, портфолио
• Роли в скраме: скрам мастер (ScrumMaster), Product Owner, команда
• Оценки
• Видение продукта (Product Vision)
• Бэклог продукта, спринт-бэклог
• Пользовательсткие истории
• Story mapping
• Расстановки приоритетов
• Как создать product vision
• Как написать бэклог продукта
• Как писать хорошие пользовательские истории
• Как делать story mapping
• Инновативные техники расстановки приоритетов в бэклоге продукта
• Как предсказать дату поставки проекта (или что будет готово к той или иной дате) используя скорость (velocity) команды
• Как работать с заказчиком

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

Представьте гипотетического идеального лидера. Кого вы видите перед собой? Какими качествами он обладает? Чем он занимается? Чем занимается его команда? Если вы представили яркого и храброго оратора, который в одиночку изобретает концепцию, героически справляется со сложностями и объясняет всем этим посредственностям вокруг него как и что нужно делать, то спешим вас разочаровать. В Agile таких людей нет.

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

Предлагаем вашему вниманию уникальный по своей прагматичности авторский тренинг о Cитуационном Лидерстве в Agile Сурена Самарчяна, основанный на опыте десяти лет работы в инновационных компаниях США и России.

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

День первый

Адженда Лидера

1. Лидер использует каждую возможность для усиления своей команды
2. Лидер способствует самостоятельности команды
3. Лидер регулярно заряжает команду позитивной энергией
4. Лидер наполняет жизнь сотрудников смыслом
5. Лидер создает правильную атмосферу
6. Лидер регулярно проверяет идеи и действия сотрудников
7. Лидер регулярно принимает сложные решение в условиях неопределенности
8. Лидер создает и поддерживает правила игры
9. Лидер уничтожает все преграды на пути гипер-продуктивности
10. Лидер думает о будущем

Эффективная коммуникация

1. Искренность и прозрачность
2. Использование интеллекта всех сотрудников
3. Проведение совещаний
4. Формулировки
5. Письменная коммуникация
6. Эффективное слушание
7. Конфликты

Руководство изменениями

1. Коммуникация необходимости изменений
2. Участие топ менеджмента
3. Инкрементальный подход
4. Продумывание деталей
5. Вовлечение сотрудников
6. Поиск и привлечение драйверов
7. Увольнение сопротивляющихся
8. Реинфорсмент
9. Типичные ошибки

Практическое задание

1. Слушатели делятся на несколько групп
2. Каждая группа разрабатывает инициативу по изменениям
3. Моделируем совещания, на которых группы рассказывают о своих предложениях

Работа со сложными людьми

1. Работа со звездами
2. Работа с оппозицией
3. Работа с экс-продуктивными сотрудниками
4. Работа с вирусами
5. Работа с креативными людьми

День второй

Усиление команды

1. Поиск и привлечение талантливых людей в команду
2. Постоянное внимание команды в одном направлении
3. Увольнение непродуктивных
4. Внушение уверенности в себе и самокритичности
5. Постоянное обучение команды на практике
6. Правильное распределение ресурсов
7. Организация тренингов
8. Организация постоянного совершенствования

Создание правильной атмосферы

1. Искренность
2. Доверие
3. Ответственное отношение к делу
4. Высокие стандарты скорости работы
5. Боевой дух
6. Непоколебимые принципы
7. Ритуалы
8. Гордость за команду

Выявление и решение проблем

1. Выявление проблем
2. Решение проблем
3. Изменение стандартов работы
4. Личная ответственность менеджмента
5. Метод А3

Практическое задание

1. Слушатели делятся на несколько групп
2. Каждая группа выбирает одну реальную проблему и решает ее методом А3
3. Группы демонстрируют друг другу полученный результат

Набор сильной команды

1. Поиск
2. Фильтрация
3. Интервью
4. Принятие решения
5. Интеграция

 http://www.b2ttraining.com/?download-id=36

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

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

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

Другое изменение, связанное с agile подходами , это короткие циклы поставки, которые называются итерациями или спринтами. Итерация включает всю работу, от требований и до готовой, протестированной фичи, которую можно поставить в рабочее окружение. Использование итераций позволяет команде анализировать прошлые действия и улучшать процесс разработки. Короткий период итерации (от недели до месяца) означает ,что объем задач по итерации (scope) намного меньше, чем в традиционных проектах, поэтому бизнес аналитику нужно сфокусироваться только на той части всей системы, которая поставляется в текущей итерации. Бизнес аналитики взаимодействуют с остальными членами команды в начале проекта – чтобы определить какой анализ нужен для создания большой картины; а также в каждой итерации – чтобы достичь общего понимания, не создавая обширный набор документов. Третье изменение agile – это роль product owner-а. Product owner принимает решения и представляет в проекте потребности бизнеса. Чтобы быть действительно эффективным, product owner должен разбираться в ключевых методах бизнес анализа, хотя на деле это редко так. Это дает бизнес аналитику прекрасную возможность содействовать product owner-у (см. ниже). Наконец, все члены команды имеют возможность проводить анализ, поэтому бизнес аналитик помогает остальным членам команды по методам анализа и в том, с какими заинтересованными лицами контактировать. За счет участия всех членов команды в сборе требований предотвращается состояние отчуждения, которое бывает в других подходах, и предотвращается ситуация, когда аналитики становятся узким местом общего прогресса команды.

Ниже обсуждаются активности бизнес аналитика по сопровождению product owner-а и команды, а также другие вопросы, связанные с работой аналитика в проекте.

Что же в действительности представляет собой agile?

Определений agile столько, сколько людей, которые дают эти определения. В этой статье, agile определяется как сотрудничество заинтересованных лиц (stakeholders) для поставки ценности заказчику с частыми инкрементами, при постоянном размышлении (reflection) и адаптации. Это определение фокусируется на характеристиках, присущих любому agile окружению, а именно:

• Сотрудничество – как люди работают вместе, включая команду, занимающуюся разработкой, и заинтересованных лиц (stakeholders)
• Поставка ценности – цель прилагаемых усилий – это поставка ценности заказчикам, что бы это ни было: программное обеспечение, более эффективные процессы или новые продукты.
• Частые инкременты – команда поставляет ценность каждые несколько дней, недель или месяцев, а не единожды, в конце проекта.
• Постоянное размышление и адаптация – проектная команда размышляет над подходами и проектом на регулярной основе, и настраивает свою работу в соответствии со сделанными выводами.

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

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

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

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

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

• Это что-то, что требует заинтересованное лицо (stakeholder) ?
• Это что-то нужное команде для эффективного выполнения работы?

Поскольку аналитикам не надо фокусироваться на написании множества документов требований для команды разработчиков, они могут больше обратить внимание на реальный анализ – рассмотрели ли мы все сценарии, которые могут произойти? Поддерживаем ли мы наше решение в целостном состоянии? Знаем ли мы о тех непредвиденных обстоятельствах, которые вызовут наши изменения?

И последний аспект agile, представляющий отход от традиционных подходов – это акцент на командной работе, а не на жесткой специализации. Наиболее заметно для бизнес аналитиков это выражается в том, что всех членов команды поощряют напрямую общаться с заинтересованными лицами, чтобы понять их потребности. Поначалу бизнес аналитики могут рассматривать это как угрозу, но потом они понимают, что у них появляется возможность проводить коучинг среди членов своей команды, помогать им быть более эффективными в этом. Они тоже могут расширить свои навыки, помогая другим членам команды с их задачами. Agile команды не всегда стартуют полностью сплоченными. По началу команды часто попадают в ловушку, когда разработчики только разрабатывают, тестировщики только тестируют и , конечно, аналитики только проводят анализ. Бизнес аналитики помогают команде двигаться в сторону сплочения и взаимодействия, исполняя сразу две роли, что делает их по-настоящему ценными членами команды:

• Бизнес советник (Business Advisor) (для поддержки Product Owner-а)
• Бизнес коуч (Business Coach) (бизнес аналитик действует как эксперт по анализу в команде)

Характер изменений в работе бизнес аналитиков касается исключительно взаимодействия с другими членами команды, product owner-ом и заинтересованными лицами. Теперь они уже не отвечают в одиночку за требования. Они гораздо больше взаимодействуют – помогают членам своей команды улучшать навыки анализа и фокусируются на более важных стратегических активностях, общаясь с product owner-ом.

Роли в Agile

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

Product Owner основной специалист, принимающий решения по проекту. Эта роль отвечает за видение продукта ( product vision), приоритезацию фич, в соответствии с бизнес ценностью, и за ответы на вопросы команды.

Scrum Master отвечает за процесс. Эта роль отвечает за окружение, подходящее для достижения успеха, за устранение препятствий и за получение тесного сотрудничества между всеми ролями.

Team - это группа из 5-9 человек, выделенных для проекта на полное время, они отвечают за самоорганизацию и поставку ценности заказчику в каждой итерации. Команда определяет, как разрабатывать продукт и как распределить работы в условиях выделенного на проект времени.

Stakeholder (заинтересованное лицо) - это любой, кто может повлиять на проект и внести вклад в определение бизнес целей продукта. Заинтересованные лица, активно вовлеченные в проект, это часть команды. Заинтересованные лица, которые не вовлечены активно в проект, могут взаимодействовать с product owner-ом, участвуя таким образом в пополнении баклога (backlog) продукта.

Бизнес аналитик как бизнес советник

В большинстве agile подходов выделяется специфическая роль, представляющая лицо, принимающее окончательные бизнес решения, такая как product owner. Product owner определяет видение продукта, отвечает за понимание и представление нужд бизнеса и пользователей. Product owner определяет, какие требования более важны перед началом каждой итерации, и как инкрементально поставлять ценность, чтобы удовлетворить нужды заинтересованных лиц. У бизнес аналитика не всегда есть власть для принятия решений, необходимая эффективному product owner-у. Но бизнес аналитики могут стать незаменимыми, дополняя product owner-а при нехватке времени или навыков бизнес анализа. Бизнес аналитик поддерживает product owner-а, помогая ему анализировать бизнес область (business domain), пополняя и приводя в порядок баклог.

Анализ бизнес области

Бизнес аналитик помогает команде и product owner-у понять и описать бизнес область и проблемы, которые нужно решить путем дискуссий по таким вопросам:

• Какие бизнес процессы нужно пересмотреть, создать или исключить?
• Какую информацию мы хотим знать и отслеживать по разным сущностям?
• Какие заинтересованные лица (такие как заказчики, поставщики. вендоры) и системы вовлечены?
• Какие правила и политики определяют бизнес поведение и решения?

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

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

Наполнение баклога продукта

Наполнение баклога продукта – это определение списка пользовательских историй, которые представляют весь объем проекта. Пользовательская история (user story) кратко описывает функциональность или фичу, ценную для пользователя или заказчика системы или программного решения. До конца этой статьи пользовательские истории и их более крупные вариант, эпики (epic) [прим. перев. - см. на devprom.ru, Требования в Agile: что такое Epic и в чем отличие от User Story?] называются историями, если не указано другое. Бизнес аналитик помогает product owner-у выделять истории из моделей, созданных во время анализа бизнес области. Это аналогично определению бизнес требований и границ проекта (scope).

Дополнительные истории возникают с развитием проекта и выделяются из моделей, созданных или обновленных во время общения с заинтересованными лицами в течение проекта. Бизнес аналитики помогают product owner-у и заинтересованным лицам, и команда создает истории как напоминание о том, что нужно поставить функциональность из моделей или обсуждений. Истории могут возникать из таких моделей требований, как модели данных, диаграммы потоков, use case-ы, бизнес правила и диаграммы пользовательских интерфейсов.

Истории возникают также из разговоров с заинтересованными лицами. Эти обсуждения варьируются от неформальных бесед до запланированных и подготовленных совещаний, специально с целью определения списка историй. Неформальные обсуждения приводят к появлению в проекте новых историй, это большое преимущество проектов в agile окружении. Использование баклога продукта – список того, что нужно поставить за проект – позволяет команде отмечать возникающие по ходу новые требования, не отвлекаясь от текущей работы в ходе итерации.

Требования помещаются в баклог для будущего анализа и изучения product owner-ом. С новыми историями также сталкиваются во время работы над итерацией и в конце демонстраций по итерации. Новая функциональность вдохновляет заинтересованных лиц на рассмотрение дополнительных фич или на размышление над другими сценариями, где система должна вести себя по-другому.

Чистка баклога продукта

Чистка баклога продукта – это поддержка баклога, так чтобы он оставался живым инструментом для команды и product owner-а, и не был бы тяжким бременем. Бизнес аналитики помогают product owner-у чистить баклог продукта, принимая во внимание цели, приоритезируя и организуя истории, разбивая эпики на пользовательские истории и заботясь о полноте описания решения.

Зная, как история поддерживает цель проекта, и зная организационную стратегию, бизнес аналитик может помочь product owner-у решить, включать ли историю в баклог, и какой подход использовать при поставке каждой конкретной истории. Модель Purpose Based Alignment помогает команде понять организационную стратегию, понять, какие активности выделяются, и в соответствии с этим принимать решения проектного уровня. Размещение историй в подходящем блоке помогает команде определить, как:

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

Бизнес аналитики могут помочь product owner-у упорядочить баклог , обеспечивая информацию по оценке разных пунктов баклога со стороны заинтересованных лиц. В моделях не указываются приоритеты, но есть много других методов для сбора информации о приоритетах у заинтересованных лиц. Две из них – это value point-ы и покупка фич (buying features). В подходе с value point-ами заинтересованных лиц просят собраться вместе и определить относительные оценки историй, по сравнению с другими историями, подобно тому как это делается в planning poker-е. В методе покупки фич заинтересованные лица определяют, как много фичи из баклога значат для них, когда тратят некоторое количество “фича-долларов” (“feature dollars”) на некоторые или на все пункты из баклога. Количество фича-долларов, назначенных каждому пункту, определяет важность этого требования. Приоритезация вносит некоторый порядок в баклог, но часто командам нужен другой порядок упорядочивания требований. Бизнес аналитики помогают product owner-у и команде поддерживать баклог так, чтобы с ним было легко работать, они используют множество методов, таких как группировка историй по темам и организация историй в релизы и итерации.

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

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

Во время  планирования проекта (roadmap planning) бизнес аналитики помогают product owner-ам и заинтересованным лицам упорядочивать истории в баклоге по релизам, учитывая приоритетность поставки наиболее ценных для стейкхолдеров историй. Заинтересованные лица получают первоначальное представление о том, когда ожидать поставку той или иной функциональности.

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

При планировании итерации команда берет на себя обязательства поставить набор историй в данной итерации, и product owner вносит необходимые изменения в план релиза.

Бизнес аналитики часто работают с командой, чтобы определить правильный размер историй для поставки в итерации. Размер историй отличается, в зависимости от того, насколько они близки к поставке. Эпики слишком велики для поставки в одной итерации, они существуют как напоминание о функциональности, которую еще нужно будет в дальнейшем определить, когда приблизится время реализации. Из этого дальнейшего определения создаются пользовательские истории, они достаточно небольшие, и их можно сделать за одну итерацию. Пользовательские истории определяют для поставки в ближайшем будущем. Есть много разные способов разбить историю на части. Два наиболее часто встречающихся подхода – это разбивка по границам операций (создание, чтение, модификация и удаление) или по границам данных (различные части информации, ассоциированные с сущностью). И наконец, бизнес аналитики помогают product owner-ам удостовериться, что часть решения, поставляемого в текущей итерации и релизе полностью выяснена. Вот некоторые вопросы, которые помогут удостовериться в полноте описания решения:

• Знаем ли мы, у каких пользователей одна цель?
• Есть ли пользователи, которые не должны использовать разработанную функциональность?
• Есть ли сценарии, которые мы должны взять во внимание, чтобы обеспечить ожидаемый результат?
• Достаточно ли у нас информации, чтобы достичь цель, поставленную в пользовательских историях?
• Достаточно ли у нас информации для обеспечения определенных правил?
• Какие непредвиденные последствия могут произойти, если мы поставим эти пользовательские истории?
• Есть ли у нас полное понимание процесса, который будет использовать эту функциональность?

Жизненный цикл проекта в Agile

Итеративный характер проектов в agile окружении меняет форму жизненного цикла, а не выполняемые активности.

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

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

Навыки бизнес аналитика жизненно важны для определения полноты баклога продукта. В результате бизнес аналитики либо сами проводят этот анализ или помогают другим членам команды проводить его. Вовлечение всей команды увеличивает шансы на достижение полного понимания проблемы и описание решения.

Бизнес аналитик как бизнес коуч

Во время работы над итерацией бизнес аналитик взаимодействует с командой , выступая как специалист по анализу. Вот некоторые из активностей, которые бизнес аналитик делает сам или в которых он помогает команде во время итерации: обеспечение взаимодействия, создание примеров, передача знаний.

Обеспечение взаимодействия

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

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

Создание примеров

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

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

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

Примеры могут иметь разную форму. При описании применения бизнес правил подходящая форма примеров – таблица. Обсуждение примеров в табличной форме помогает понять содержание, найти пробелы и несоответствия. При описании процесса более подходящей является форма “Учитывая – Когда – Тогда” (Given, When, Then).

Учитывая <Предусловие>

Когда <Действие>

Тогда <Ожидается>

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

• Как нам проверить, что эта пользовательская история реализована полностью и правильно?
• Представим, что мы уже поставили это – как нам оттестировать это?
• Есть ли еще сценарии, связанные с этой пользовательской историей,  для которых мы не определили поведение системы?

Передача знаний

Бизнес аналитик и product owner лучше всего представляют себе большую картинку проекта, и место, которое он занимает в организационной стратегии. Во время работы по итерации бизнес аналитики проводят значительное количество времени , передавая другим членам команды информацию, полученную когда они действовали как бизнес советники. Лучший способ передачи знаний – это вовлечение членов команды в анализ бизнес области и в наполнение и чистку баклога. Вся команда не может быть вовлечена в каждую из этих активностей, поэтому требуется некоторая ретрансляция этой информации. Эту информацию можно передавать, вывешивая ее на информационных источниках или в общей области, доступной всей команде.

Хороший член команды

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

Заключение

Agile подходы не дают описание многих ролей, потому что акцент на взаимодействие делает многие роли ненужными. Недостаток описанных ролей дает бизнес аналитику прекрасную возможность расширить свои горизонты, с бизнес и с технической стороны. Бизнес аналитики тесно сотрудничают с product owner-ом , чтобы доставить наибольшую ценность заинтересованным лицам. В этом процессе они расширяют свои знания по бизнес области и получают новый опыт решения проблем бизнеса. Кроме того, бизнес аналитики тесно сотрудничают с членами своей команды, улучшая их аналитические навыки и получая новые навыки, например тестирования или даже кодирования. Эти возможности заставляют аналитиков смотреть вне рамок роли, вместе с членами своей команды поставлять ценность заказчикам, и улучшать их ценность в организации.

Ключевые бизнес аналитические навыки в Agile проектах

Высокопродуктивный бизнес аналитический персонал команды повышает вероятность того, что результирующий продукт действительно будет отвечать потребностям бизнеса и хорошо подойдет текущему бизнес окружению.Если нет опытного бизнес аналитика, хотя бы один член команды должен пройти обучение по бизнес анализу и иметь опыт анализа.Ключевые бизнес аналитические навыки, которые нужны в agile проектах:

• Понимание бизнес области проекта
• Экспертиза в концептуальном моделировании; способность увидеть большую картинку и представить возможные решения
• Выдающиеся вербальные и невербальные коммуникативные навыки
• Многозадачность
• Способность приводить команду к консенсусу по рамкам проекта, решениям связанным с дизайном и реализацией
• Способность задавать вопросы, которые помогают команде находить проблемные области
• Способность документировать требования формально или неформально, в зависимости от нужд проекта
• Понимание agile процесса разработки
• Знание методик , таких как пользовательские истории, use case-ы и неформальное моделирование. Это основные методики работы с требованиями в agile командах.

Библиография

Cohn, Mike, (2004), User Stories Applied: For Agile Software Development, Addison Wesley.

Cohn, Mike. (2005), Agile Estimating and Planning, Addison-Wesley Professional.

Cohn, Mike (2009), Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional.

Cohen, Greg (2010), Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams, Super Star Press.

Pichler, Roman (2010), Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional.

Pixton, Pollyanna, Niel Nickolaisen, Todd Little and Kent McDonald (2009), Stand Back and Deliver: Accelerating Business Agility, Addison Wesley.

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

Содержание

1. Цель тестирования в Agile

2. Agile-тестировщик: супергерой или командный игрок

3. Планирование задач по тестированию на итерацию (спринт)

• Работа с документацией часть 1 – стори тесты
• Работа с документацией часть 2 – акцептанс тест кейсы и spec by example
• Анализ требований
• Планирование релиза и спринта
• Практика по оценке задач

4.Написание тест кейсов в Agile

• Подход к разработке тест кейсов
• Практика по написанию тест кейсов

5.Передача истории из разработки в тестирование

• Передачи истории в тестирование
• Практики тетисрования
• Взаиможействие с разработчиками

6.Автоматизация тестирования в Agile

• Подход к автоматизации в Agile
• Примеры применения автоматизации с использованием Watir и Selenium
• Практика

7.Работа с частыми изменениями в Agile

• Оценка изменений
• Обновление тест кейсов
• Обновление автоматизации
• Ревью и ретроспектива

8. Шаги по внедрению agile

• Работа с командой
• Путь скрам мастера

9. Советы, рекомендации, реальные кейсы

Автор: Евгений Неделько

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

Первое, что я сделал, когда подключился к этому проекту, – я постараться сформулировать суть проблемы, то есть задачу, которую я хочу решить. Почти во всех проектах, в которые я был вовлечен, план строился на точных оценках отдельных задач, на конкретных числах указанных в качестве продолжительности, трудоемкости или стоимости задачи. Лишь некоторые проекты использовали методику PERT, определяя кроме наиболее ожидаемых затрат также оптимистичные и пессимистичные оценки, но даже в этом случае общая оценка проекта представляла собой одно конкретное число. Я же понимал, что в реальности фактические затраты всегда будут больше или меньше первоначальной оценки, а вероятность точного совпадения стремится к нулю. Я был уверен, что любой выделенный бюджет будет или перерасходован, или недотрачен.  Нашему потенциальному клиенту и мне лично хотелось получить возможность определять вероятность вписаться в тот или иной бюджет, т.е. с одной стороны избежать ситуации, когда деньги кончаются посреди проекта, а с другой стороны избежать ситуации, когда остаются лишние деньги, которые просто «осваиваются», не принося уже дополнительных прибылей бизнесу.

И тут мне повезло: наша компания, являясь одним из крупнейших в мире поставщиков услуг в области аутсорсинга, обладает огромными массивами данных по выполненным проектам, и я смог довольно быстро получить большую выборку данных от одного из Российских проектов. Я получил значения оценок и фактических затрат по нескольким тысяч заявок с  типичными трудозатратами от 1 до 50 ч-часов. После несложных манипуляций в Excel я получил искомое распределение (рис. 1). На гистограмме по вертикали отложено число заявок, а по горизонтали – размер фактических затрат относительно прогнозируемых. Например, если фактические затраты совпадают с оценкой, то на гистограмме такая заявка увеличит на единицу столбик в точке 1. Если фактические затраты составили полдня при оценке в два дня, то заявка попадет в точку 0,25.

Рис.1. Распределение фактических затрат в одном проекте

Вот что то я увидел анализируя получившийся график:

Во-первых, оказалось что наши сотрудники делают очень правдоподобные оценки, т.е. указывают те затраты, вероятность которых максимальна (на графике эта точка отмечена зеленым цветом). Если наш специалист говорит, что какая то задача займет 12 часов, то вероятность того, что задача займет именно 12 часов немного выше вероятности того, что реальные затраты составят 11 или 13 часов, и намного выше того, что затраты будут равны 6 или 24 часам.

Во-вторых, когда я подсчитал средние затраты по всем заявкам, то обнаружил, что среднее арифметическое оказались заметно больше, чем первоначальные оценки. В первый год работы проекта средние затраты превышали исходную оценку на 50%, потом разница сократилась до 30%, но никуда не исчезла. Этому странному на первый взгляд факту нашлось простое объяснение. Ошибиться в сторону уменьшения затрат мы можем не больше, чем на первоначальную оценку (размер затрат ведь не может быть отрицательным), а в сторону превышения оценки у нас нет почти никаких ограничений и фактические затраты могут превысить оценку в два, в три,  в четыре или даже в десять раз. Примеры, к сожалению, имеются. В результате ошибки в сторону увеличения затрат перевешивают ошибки в сторону уменьшения, и в среднем реальные затраты оказываются больше самых правдоподобных и вероятных оценок. Говоря языком статистики, получается, что распределение фактических затрат несимметрично, а математическое ожидание больше моды распределения.

Следующим важным наблюдением является поведение людей, которые гарантируют, что они впишутся в обещанные затраты. Для того чтобы быть уверенными в этом они подписываются под той оценкой затрат, риск превысить которую не больше 5-10%. А это означает, что вероятность того, что реальные затраты составят меньше обещанного – 90-95%, причем судя по полученному распределению – превысят раза в 2-3. Получается, что гарантированное соблюдение бюджета и сроков выливается в 2-3 кратное увеличение бюджета и сроков, т.е. строгий контроль сроков и бюджетов без оглядки на их адекватность и реалистичностьгарантирует падение общей эффективности.

Чтобы побороться с этим эффектом некоторые заказчики и руководители требуют указания в качестве целевых наиболее вероятных оценок затрат и соглашаются прощать возможное превышение оценок в рамках резервов на непредвиденные обстоятельства. К сожалению, размер таких резервов редко когда превышает 20%, а как я написал выше, затраты по отдельным задачам в среднем превышают правдоподобные оценки на 30-50%. В рамках большого проекта ошибки по отдельным задачам могут компенсировать друг друга, но, тем не менее, со временем ошибки накапливаются и приводят к гарантированному превышению целевого бюджета.

Чтобы побороть этот пагубный эффект можно воспользоваться одним из двух методов: можно попытаться рассчитать поправочный коэффициент к сумме правдоподобных оценок, или воспользоваться методикой PERT, разработанной еще в 50-е годы прошлого века на основе идей Генри Форда и Фредерика Тейлора. Первый способ — проще, однако второй позволяет не только получить реалистичную оценку, но и понять каково распределение возможных значений фактических затрат.

***

Для того чтобы рассчитать реалистичную оценку на базе наиболее правдоподобной, используя поправочный коэффициент, этот коэффициент для начала нужно рассчитать. Для этого нужно взять не менее 20-40 выполненных задач и рассчитать среднее отношение фактических затрат к исходной оценке. Если размеры оценок различаются более чем в два-три раза, то имеет смысл определить два или даже больше коэффициентов для задач разных размеров. В использованных мной данных, поправочный коэффициент для задач с оценкой менее 2 ч-часов оказался в три раза больше коэффициента для задач с оценкой от 12 до 24 ч-часов.

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

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

***

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

Для того, чтобы рассчитать реалистичную оценку проекта по методике PERT необходимо указать для каждой задачи три оценки: полученную обычным способом наиболее правдоподобную оценку, оптимистичную – оценив минимальные затраты в случае, если мы переоцениваем сложность задачи, и пессимистичную – оценив максимальные затраты, которые могут потребоваться для завершения задачи. После чего реалистичная оценка по отдельной задаче определяется по представленной ниже формуле. Затраты по всему проекту в целом оцениваются простым суммированием реалистичных оценок по каждой задаче.

где

μ –        реалистичная оценка затрат по проекту или релизу в целом,

n –        число задач в проекте или релизе,

μi –        реалистичная оценка затрат по задаче i,

Oi –        оптимистичная оценка затрат по задаче i,

Ei –        наиболее правдоподобная оценка затрат по задаче i,

Pi –        пессимистичная оценка затрат по задаче i

Тут важно обратить внимание на ещё одну особенность полученных данных — вероятность ошибиться в два раза в сторону уменьшения оказалось равной вероятности ошибиться в два раза в сторону увеличения. Т.е. распределение относительной ошибки (в отличие от абсолютной ошибки) оказалось симметричным. Соответственно соотношение наиболее правдоподобной оценки к оптимистичной должно быть минимально отличаться или равно отношению пессимистичной оценки затрат к наиболее правдоподобной оценке.

Если это не так, то имеет смысл проверить правильность оптимистичной и пессимистичной оценок.

***

Для определения необходимых резервов на непредвиденные нужды требуется рассчитать интервал возможных затрат при заданной оценке (см. рис.2). Если первоначальная оценка по задаче составила 16 ч-часов, то с 50% вероятностью можно говорить о том, что фактические затраты будут находиться в диапазоне от 15 до 24 ч-часов, а с вероятностью 95% можно было утверждать лишь то, что затраты будут в диапазоне от 3 до 56 ч-часов.

Рис 2. Доверительный интервал

Наиболее типичным является использования диапазона с вероятностью 90%. В этом случае предполагается вероятности того, что значение затрат превысит пессимистичную оценку, и того, что затраты окажутся меньше оптимистичной оценки, равны по 5%. Вероятность того, что фактические затраты попадут в диапазон между оптимистичной и пессимистичной оценкой равна 90%.

Получение распределения вероятностей фактических затрат по релизу и проекту возможно используя оптимистичные и пессимистичные оценки полученные в методике PERT. Сама методика для получения диапазона возможных значений предлагает просто сложить оптимистичные и пессимистичные оценки, однако простейшее моделирование показывает, что это некорректно. Пессимистичная оценка проекта оказывается меньше суммы оценок, а оптимистичная – больше. Диапазон с вероятностью 90% оказывается меньше простой суммы диапазонов для отдельных задач.

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

Соответственно, чем детальнее мы разбиваем большой  проект и больше задумываемся о каждой отдельной задаче, тем более точную оценку мы можем дать. Например, если взять большой интеграционный проект внедрения, трудозатраты по которому могут составить 50 000 ч-дней, то разбив план на 1 000 задач мытеоретически можем получить погрешность менее 800 ч-дней или менее 2%. График теоретической зависимости разброса затрат в зависимости от детальности плана представлен на рис.3.

Рис.3. Теоретическая зависимость точности оценки затрат в зависимости от количества подзадач в плане:

К сожалению, в реальной жизни есть ряд ограничений  не позволяющих достигнуть такой точности и самым существенным является то, что требования и состав выполняемых задач может меняться по ходу проекта. Для большинства компаний типичным является потеря актуальности 10-30% задач, поэтому как бы мы не детализировали наш план, ошибка в первоначальных оценках всё равно неизбежна.

Суммируя полученные выводы, мне удалось понять следующее. Используя для оценки большого проекта сумму наиболее правдоподобных оценок затрат, мы гарантировано занижаем оценку, суммируя пессимистичные оценки – гарантировано её завышаем. Для того, чтобы получить реалистичную оценку необходимо использовать предварительно рассчитанный поправочный коэффициент или методику оценки ПЕРТ. Воспользовавшись оценками в методике ПЕРТ мы также можем получить диапазон затрат, про который можно говорить, что фактические затраты попадут в него с вероятностью 90% и в котором нет излишних резервов. А детализируя план проекта и аккуратно оценивая каждую задачу, можно существенно сократить этот диапазон, в итоге достигая требуемого размера резервов.

Евгений Неделько

Менеджер практики совершенствования ИТ процессов компании Accenture

Друзья!

6-7 июля 2012 года в Нижнем Новгороде, пройдет третья практическая не-конференция AgileCamp, посвященная гибким методикам разработки программного обеспечения.

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

Это значит, что на конференции не будет ни одного абстрактного теоретического доклада – вместо этого мы предлагаем вам принять участие в непрерывных мастер-классах, на которых за два основных дня конференции вы сможете пройти весь цикл разработки нового программного продукта: от формирования команды и понимания основ процесса разработки, до глубокой проработки идеи продукта и формирования плана релиза, готового к разработке.

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

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

Регистрируйтесь, количество билетов ограничено!

Отчеты о прошедших AgileCamp в Самаре, Новосибирске 2011 http://nsk11.camp.agiledays.ru/

Stay tuned!

http://agiledays.ru

http://www.facebook.com/AgileDays

С уважением,

Организационный комитет AgileDays

+ 7 (495) 991-69-20

e-mail: agiledays@scrumtrek.ru

www.agiledays.ru

Agile и адаптивные подходы, объединяющие людей, проекты и полезную ценность

Мы представляем сообщество проектных лидеров, чья работа по достижению хороших результатов стала очень успешной. Для достижения этих результатов:

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

©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith и Robert Wysocki.

Название “Декларация взаимозависимости” имеет множество значений. Это означает,что члены проектной команды представляют собой взаимозависимое множество, а не группу несвязанных между собой индивидуумов. Это означает,что проектные команды, их заказчики и все заинтересованные лица тоже взаимозависимы. Проектные команды, не осознающие эту взаимозависимость, редко бывают успешными.

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

Все утверждения представлены в следующей форме: сначала сказано, чем важен данный пункт, а потом дано описание ценности. Т.е. “рост возврата инвестиций ” – это то, почему важно фокусироваться на постоянном потоке ценности. Эти утверждения подчеркивают важность поставки надежных (не то же самое, что повторяемых) результатов, управления неопределенностью, творчества и инноваций, увеличения производительности и повышения эффективности.

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

Если вас заинтересовала данная информация, посетите наш вебсайт или подключайтесь к дискуссионной группе www.groups.yahoo.com/group/agileprojectmanagement.

Jim Highsmith, 17 февраля 2005.