Водопадная модель разработки ПО
Начнем с основ и для этого возьмем машину времени и переместимся в 1970 год: доктор Уинстон Ройс пишет свою статью «Управление разработкой больших программных систем» (Managing the development of large software systems), которая и положила начало водопадной модели разработки ПО. Самое интересное, что он в своей статье описывает эту модель как антипаттерн.
Доктор Ройс предлагает решение, в котором есть элементы итеративности и гибкости, но оно больше похоже на тяжеловесную методологию.
1. Подробная проработка архитектуры программы до начала разработки (включая предварительную архитектуру).
2. Максимально подробная документация на каждом этапе.
3. Симуляция всего проекта в уменьшенном виде (фактически прототипирование).
4. Планирование, контроль и мониторинг тестирования.
5. Вовлечение заказчика.
Водопадная модель разработки ПО
В результате у Ройса получается совсем другая схема работы, нежели та, на которую обычно ссылаются.
Авторы Agile-манифеста
В феврале 2001 года в местечке под названием Сноуберд в штате Юта собрались 17 специалистов (консультантов и практиков), чтобы обсудить легковесные методики разработки. В результате родился документ «Манифест гибких методологий разработки» (Agile Manifesto). Позволю себе привести список авторов манифеста и краткую информацию о них.
Кент Бек – создатель разработки через тестирование и экстремального программирования. Автор нескольких книг на эти темы и соавтор JUnit.
Майк Бидл – основатель и генеральный директор e-Architects Inc., консалтинговой компании, которая специализируется на разработке распределенного ПО. Он также является соавтором книги Scrum, Agile Software Development, написанной совместно с Кеном Швабером.
Усовершенствованная водопадная модель разработки ПО
Эйри ван Беннекум – участвовал в разработке методологии DSDM с 1997 года. До этого активно работал над быстрой разработкой (Rapid Application Development).
Алистер Кокберн – известен исследованиями проектных команд и участием в разработке семейства методологий Crystal.
Уорд Каннингем – основатель Cunningham & Cunningham, Inc. Он также широко известен своим огромным вкладом в развитие объектно-ориентированного программирования, экстремального программирования и в концепцию вики.
Джеймс Греннинг – тренер и консультант по гибким методологиям. Является специалистом в области разработки и тестирования встроенного программного обеспечения и автором книги Test Driven Development for Embedded C.
Стивен Меллор – специалист в области разработки программного обеспечения, соавтор метода ООАП Шлаера-Меллора, работал над UML в составе Object Management Group.
Мартин Фаулер – главный исследователь в компании Thoughtworks. Автор многих работ и книг по паттернам анализа, UML, рефакторингу и экстремальному программированию.
Джим Хайсмит – ведущий разработчик методологии Adaptive Software Development и автор соответствующей книги.
Эндрю Хант – соавтор книги Pragmatic Programmer: From Journeyman to Master и других работ, связанных с разработкой ПО.
Рон Джеффрис – владелец сайта XProgramming.com, консультант в компании Object Mentor и соавтор книги Extreme Programming Installed.
Джон Керн – участвовал во многих проектах по исследованиям и разработке в области авиастроения. Он также является евангелистом объектно-ориентированного программирования с начала 90-х годов.
Брайан Мэрик – программист и консультант по тестированию программного обеспечения. Основной вклад Брайана заключается в исследовании процессов тестирования ПО в гибких методологиях разработки.
Роберт Мартин – работает в отрасли разработки ПО с 1970 года. Он является президентом и основателем фирмы Object Mentor Inc., которая специализируется на консалтинге в области экстремального программирования, гибких методологиях разработки, консалтинге по архитектуре ПО и т. д. Он также является соавтором книг по программированию и разработке программного обеспечения.
Кен Швабер – президент компании Advanced Development Methods (ADM), которая занимается улучшением методов разработки ПО. Он является опытным разработчиком, менеджером продуктов и консультантом. В начале 90-х годов он работал с Джеффом Сазерлендом над первыми версиями Scrum. Он также является соавтором книги Scrum, Agile Software Development.
Джефф Сазерленд – технический директор (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. В качестве допущений будем использовать следующие положения:
• длина спринта – две недели;
• длина релиза фиксирована – три итерации;
• внедрение Agile поддерживается руководством.
План рассчитан на то, чтобы серьезно не отрывать команды от производства и сделать внедрение управленческих и технологических инноваций частью корпоративной культуры компании.
Предполагается, что организацией внедрения будет заниматься один человек, работая полный день над этой задачей. Это может быть как внешний тренер/консультант, так и внутренний эксперт-внедренец.
При выборе компании или тренера рекомендуется обратить внимание на следующие факторы.
• Реальный практический опыт работы по теме тренинга. Самым важным параметром при выборе компании и тренера является наличие практического опыта работы по теме тренинга. Дело в том, что тренеры-теоретики просто не способны понять многие вещи в силу отсутствия соответствующего опыта даже при наличии всех необходимых сертификатов.
• Опыт консалтинговой деятельности и проведения тренингов. Одного опыта и наличия практических навыков недостаточно, важно, чтобы у компании или тренера имелся определенный багаж знаний и навыков по консалтингу и внедрению соответствующих практик.
Принципы внедрения
Цикл Деминга (PDCA-цикл)
При организационных изменениях очень помогает использование здравого смысла и научного подхода. Традиционным методом в данном случае является цикл Деминга, который состоит из четырех шагов.
• Plan (планирование). Производится анализ системы, вырабатываются возможные подходы к улучшениям, и определяются желаемые результаты.
• Do (исполнение). Решения, выработанные на предыдущем шаге, реализуются.
• Check (проверка). Производится анализ результатов, полученных на предыдущем шаге.
• Act (корректировка). Выполняются корректирующие действия для уменьшения отклонений от плана.
Цикл Деминга
ShuHaRi
Внедрение методологии и практик можно разбить на три этапа. Важно, чтобы компания и отдельные команды их прошли, не застряв на одном из них. Названия:
• Shu ( 
защита, подчинение) – изучение традиционной мудрости – изучение методологии, работа строго по книжкам, руководствуясь предписаниями тренера/внедренца;
• Ha ( 
отделение, отклонение) – отступление от традиции – понимание методологии на очень глубоком уровне и ее адаптация под требования проектов/бизнеса/внешней среды;
• Ri ( 
покидание, отделение) – превосходство над традицией – осознанное отступление от методологии, например переход со Scrum на Scrumban.
Важно пройти все этапы, не перепрыгивая, – достаточно распространенная ситуация, когда команда не может делать Scrum и сразу перепрыгивает на канбан, что в итоге выливается в классический Code&Fix.
График и содержание внедрения
План состоит из трех частей.
1. Подготовка компании к трансформации – сбор и анализ информации, получение знаний и навыков сотрудниками компании.
2. Первый релиз – знакомство с основными элементами Scrum и Lean.
3. Второй релиз – адаптация Agile к бизнесу компании.
Неделя № 1 (подготовка к трансформации)
Цели: собрать и проанализировать основную информацию о компании, дать основным участникам базовые знания об Agile.
1. Изучение и описание текущих бизнес-процессов компании: составление карты бизнес-процессов, касающихся разработки ПО/сайтов (в графическом или текстовом виде).
2. Изучение проектов и организация их в портфель проектов:
• составление списка проектов;
• разработка методологии приоритизации, принятие решений о запуске/завершении проектов;
• приоритизация и балансировка портфеля проектов.
3. Буткемп по основам Scrum (однодневный тренинг по основам скрама с деловыми играми): каждый участник тренинга должен понимать роли, процессы и артефакты Scrum.
4. Продвинутое обучение скрам-мастеров (четырехчасовой тренинг): скрам-мастера должны получить дополнительные знания и навыки по процессам Scrum, навыки фасилитации и организации работы команд.
5. Продвинутое обучение владельцев продуктов (четырехчасовой тренинг): владельцы продуктов должны получить дополнительные знания и навыки по управлению продуктами (выявление ролей пользователей, построение карт историй, управление журналом пожеланий и релизами).
Неделя № 2 (нулевой спринт)
Цели: выработать понимание продукта и создать высокоуровневую архитектуру.
1. Исследование продукта:
• выявление ролей и персонажей по проектам;
• построение карт историй;
• прототипирование основных интерфейсов;
• сессия для выявления основных рисков и выработки контрмер.
2. Создание высокоуровневой архитектуры продукта:
• выбор платформы реализации;
• диаграмма предметной области/высокоуровневая диаграмма классов.
Неделя № 3 (старт первого «калибровочного» спринта)
Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum.
1. Старт первого спринта с командами:
• проведение планирования спринта и разбиение user story на задачи;
• проведение покер-планирования для оценки user story.
2. Scrum of Scrum:
• определение сроков проведения Scrum of Scrum;
• проведение первого Scrum of Scrum;
• отработка механизма эскалации проблем;
• отработка механизма синхронизации деятельности команд.
Неделя № 4 (завершение первого «калибровочного» спринта)
Цели: отработать завершение спринта и провести ретроспективу на основе качественных показателей.
1. Проведение демонстрации и получение обратной связи.
2. Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений): определение скорости команды эмпирическим путем.
Неделя № 5 (старт второго спринта)
Цели: отработать старт спринта и планирования на основе количественных показателей, начать внедрение базовых практик экстремального программирования.
1. Планирование и старт второго спринта: планируем, исходя из скорости предыдущего спринта.
2. Тренинг и мастер-класс по практикам экстремального программирования:
• внедрение системы непрерывной интеграции – полная сборка продукта происходит автоматически и непрерывно;
• выработка и внедрение стандартов кодирования.
Неделя № 6 (завершение второго спринта)
Цели: отработать завершение спринта и провести ретроспективу на основе количественных показателей, используя инструменты бережливого производства.
1. Изучение практики инструментов бережливого производства (Lean):
• виды потерь при производстве;
• Value Stream Mapping для текущего процесса;
• пять «почему».
2. Демонстрация.
3. Ретроспектива с применением инструментов бережливого производства:
• разбор причин опоздания по невыполненным задачам;
• пять «почему» по каждому дефекту.
Неделя № 7 (старт третьего спринта)
Цели: отработать старт предрелизного спринта и понять, как в будущем избежать таких «стабилизационных» спринтов, начать активно использовать автоматизированное тестирование.
1. Планирование и старт третьего спринта:
• особое внимание уделяем недоделанным историям пользователей, которые не успели выполнить из-за ограничения по скорости команды;
• рассматриваем возможность снизить скорость команды, чтобы успеть все к релизу.
2. Внедрение модульных и приемочных тестов:
• проведение тренинга по приемочным тестам;
• покрытие 5 % основного бизнес-функционала продукта приемочными тестами;
• проведение тренинга по модульным тестам;
• покрытие 50 % кода, реализованного за спринт, модульными тестами.
3. Внедрение рефакторинга.
Неделя № 8 (завершение третьего спринта)
Цели: сделать первый Agile-релиз продукта и выработать серьезные меры по улучшению процессов на основе информации, полученной за три спринта.
1. Кайзен-сессия на ретроспективе: диаграмма Исикавы по глобальным проблемам проекта и выработка мер по устранению проблем.
2. Завершение третьего спринта: первый релиз продукта – обязательно, чтобы конечные пользователи его попробовали и предоставили обратную связь.
3. Post-mortem релиза в рамках ретроспективы.
Неделя № 9 (старт четвертого спринта)
Цели: научиться планировать релиз и управлять им.
1. Планирование релиза:
• начало ведения диаграммы burndown-релиза;
• отбор владельцем продукта пользовательских историй для релиза;
• возможная переоценка журнала пожеланий командой «на пальцах».
2. Внедрение (трех-) четырехзвенной архитектуры.
3. Планирование и старт четвертого спринта: скорость команды считаем эмпирически по трем предыдущим спринтам.
Неделя № 10 (завершение четвертого спринта)
Цель: внедрение статистического управления качеством.
1. Завершение четвертого спринта.
2. Внедрение основ статистического управления качеством:
• статистика по дефектам;
• диаграмма Парето по модулям;
• контрольные карты Шухарта.
Неделя № 11 (старт пятого спринта)
Цель: внедрение канбана для команды поддержки или основной команды.
1. Планирование и старт пятого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.
2. Переход на Scrumban команды поддержки или основной команды:
• тренинг по канбан (четыре часа) для членов команды;
• отказ от жестких итераций.
3. Внедрение разработки через тестирование:
• тренинг и мастер-класс по разработке через тестирование;
• покрытие тестами модулей ядра системы (не менее 50 % строк кода).
Неделя № 12 (завершение пятого спринта)
Цель: улучшение внутреннего качества ядра системы.
1. Частичный рефакторинг модулей ядра системы: определение стратегии рефакторинга и выбор модулей.
2. Завершение пятого спринта.
Неделя № 13 (старт «идеального» шестого спринта)
Цель: запуск «идеального» спринта.
1. Планирование и старт шестого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.
Неделя № 14 (завершение «идеального» шестого спринта)
Цель: завершение «идеального» спринта.
1. Завершение шестого спринта.
2. Релиз продукта.
3. Post-mortem релиза в рамках ретроспективы: анализ релиз-берндауна.