Читать онлайн «Гибкое управление проектами и продуктами». Страница 16

6. Управление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, финансами и т. д.

7. Среда – совокупность процессов, инструментов, стандартов и правил.

Feature-driven development (функционально-ориентированная разработка) – методология, созданная Джеффом Де Люка (Jeff De Luca). Разработка ведется в пять этапов.

1. Построение модели.

2. Создание списка функций.

3. Планирование реализации функций.

4. Создание архитектуры для функций.

5. Реализация функций.

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

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

• диаграмма вариантов использования;

• диаграмма классов;

• диаграмма робастности;

• диаграмма последовательности.

Об использовании методологии ICONIX см. разд. «Процесс ICONIX» гл. 8.

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

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

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

Будем считать, что в компании по исторически сложившимся обстоятельствам применяется «методология» Code&Fix. В качестве допущений будем использовать следующие положения:

• длина спринта – две недели;

• длина релиза фиксирована – три итерации;

• внедрение Agile поддерживается руководством.

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

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

При выборе компании или тренера рекомендуется обратить внимание на следующие факторы.

• Реальный практический опыт работы по теме тренинга. Самым важным параметром при выборе компании и тренера является наличие практического опыта работы по теме тренинга. Дело в том, что тренеры-теоретики просто не способны понять многие вещи в силу отсутствия соответствующего опыта даже при наличии всех необходимых сертификатов.

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

При организационных изменениях очень помогает использование здравого смысла и научного подхода. Традиционным методом в данном случае является цикл Деминга, который состоит из четырех шагов.

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

• Do (исполнение). Решения, выработанные на предыдущем шаге, реализуются.

• Check (проверка). Производится анализ результатов, полученных на предыдущем шаге.

• Act (корректировка). Выполняются корректирующие действия для уменьшения отклонений от плана.

Цикл Деминга

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

• Shu (защита, подчинение) – изучение традиционной мудрости – изучение методологии, работа строго по книжкам, руководствуясь предписаниями тренера/внедренца;

• Ha (отделение, отклонение) – отступление от традиции – понимание методологии на очень глубоком уровне и ее адаптация под требования проектов/бизнеса/внешней среды;

• Ri (покидание, отделение) – превосходство над традицией – осознанное отступление от методологии, например переход со Scrum на Scrumban.

Важно пройти все этапы, не перепрыгивая, – достаточно распространенная ситуация, когда команда не может делать Scrum и сразу перепрыгивает на канбан, что в итоге выливается в классический Code&Fix.

План состоит из трех частей.

1. Подготовка компании к трансформации – сбор и анализ информации, получение знаний и навыков сотрудниками компании.

2. Первый релиз – знакомство с основными элементами Scrum и Lean.

3. Второй релиз – адаптация Agile к бизнесу компании.

Цели: собрать и проанализировать основную информацию о компании, дать основным участникам базовые знания об Agile.

1. Изучение и описание текущих бизнес-процессов компании: составление карты бизнес-процессов, касающихся разработки ПО/сайтов (в графическом или текстовом виде).

2. Изучение проектов и организация их в портфель проектов:

• составление списка проектов;

• разработка методологии приоритизации, принятие решений о запуске/завершении проектов;

• приоритизация и балансировка портфеля проектов.

3. Буткемп по основам Scrum (однодневный тренинг по основам скрама с деловыми играми): каждый участник тренинга должен понимать роли, процессы и артефакты Scrum.

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

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

Цели: выработать понимание продукта и создать высокоуровневую архитектуру.

1. Исследование продукта:

• выявление ролей и персонажей по проектам;

• построение карт историй;

• прототипирование основных интерфейсов;

• сессия для выявления основных рисков и выработки контрмер.

2. Создание высокоуровневой архитектуры продукта:

• выбор платформы реализации;

• диаграмма предметной области/высокоуровневая диаграмма классов.

Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum.

1. Старт первого спринта с командами:

• проведение планирования спринта и разбиение user story на задачи;

• проведение покер-планирования для оценки user story.

2. Scrum of Scrum:

• определение сроков проведения Scrum of Scrum;

• проведение первого Scrum of Scrum;

• отработка механизма эскалации проблем;

• отработка механизма синхронизации деятельности команд.

Цели: отработать завершение спринта и провести ретроспективу на основе качественных показателей.

1. Проведение демонстрации и получение обратной связи.

2. Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений): определение скорости команды эмпирическим путем.

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

1. Планирование и старт второго спринта: планируем, исходя из скорости предыдущего спринта.

2. Тренинг и мастер-класс по практикам экстремального программирования:

• внедрение системы непрерывной интеграции – полная сборка продукта происходит автоматически и непрерывно;

• выработка и внедрение стандартов кодирования.

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