Гибкое управление проектами и продуктами

Джефф Сазерленд – технический директор (CTO) компании PatientKeeper, которая занимается созданием ПО для медицинских учреждений. За свою карьеру был техническим директором (или вице-президентом по технологиям) в девяти компаниях. Известность приобрел как изобретатель методологии Scrum.

Дейв Томас – верит, что сердце проекта по разработке – не методология, а люди. По этой причине он является соавтором книги The Pragmatic Programmer.

Crystal Clear

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

Crystal Clear использует семь методов/практик, три из которых являются обязательными.

1. Частая поставка продукта.

2. Улучшения через рефлексию.

3. Личные коммуникации.

4. Чувство безопасности.

5. Фокусировка.

6. Простой доступ к экспертам.

7. Качественное техническое окружение.

Как видите, все практики характерны для семейства Agile-методологий. В графическом виде практики Crystal Clear можно изобразить таким образом.

Методы и практики Crystal Clear

Dynamic Systems Development Method (DSDM)

Методология DSDM (Dynamic Systems Development Method – метод разработки динамических систем) основана на подходе RAD (Rapid Application Development – быстрая разработка приложений) и включает в себя три стадии.

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

2. Жизненный цикл проекта представляет собой реализации проекта и включает в себя пять этапов.

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

Общая схема DSDM

Жизненный цикл проекта включает в себя пять стадий (первые две фактически объединяются).

1. Определение реализуемости.

2. Экономическое обоснование.

3. Создание функциональной модели.

4. Проектирование и разработка.

5. Реализация.

Agile Unified Process

Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданная Скоттом Амблером (Scott Ambler) и состоящая из семи методов.

1. Моделирование используется для понимания бизнес-требования и предметной области.

2. Реализация – преобразование модели в исполняемый код с модульными тестами.

3. Тестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиям.

4. Размещение – доставка готовой системы пользователям.

5. Управление конфигурациями – управление доступом и версиями артефактов проекта.

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

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

Feature-driven development

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

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

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

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

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

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

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

ICONIX

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

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

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

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

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

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

Как внедрить Agile за четырнадцать недель

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

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

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

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

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