Рис. 56. Сравнительное ранжирование 5-ти рисков 4-мя экспертами
В развитии технологии программирования постоянно появляются новые подходы, некоторые из которых даже претендуют на звание «смена парадигмы» (paradigm shift). Начиная с 1960-х годов можно отметить следующие заметные изменения:
программирование в кодах (machine code);
программирование на языке ассемблера (assembler);
программирование на языках высокого уровня (high-level languages);
структурное программирование (structured programming);
логическое программирование (logic programming);
объектно-ориентированное программирование (object-oriented – OO);
экстремальное программирование (extreme programming – XP);
аспектно-ориентированное программирование (aspect-oriented – AO);
подвижное программирование (agile programming).
Очевидно, этот список будет продолжен с течением времени. Подвижное программирование, появившееся в начале 2000-х годов, к настоящему времени имеет несколько разновидностей, которые по-разному трактуют отдельные процессы в создании ПО, из которых наибольшую известность получили экстремальное программирование и «бойцовское» программирование (scrum от scrimmage – схватка за мяч в регби), которое и будет рассмотрено в дальнейшем. Сторонники подвижного программирования указывает на существенный «сдвиг ценностей» (value shift) при этом подходе, общий всем его разновидностям. При обычном традиционном подходе на первом месте стоят процессы и инструменты разработки, подробная документация по разрабатываемому продукту, процессу разработки и вспомогательным рабочим продуктам, переговоры о подряде (контракте) на создание продукта и следование утвержденному плану разработки.
Признавая безусловную ценность и важность всех перечисленных аспектов разработки, подвижное программирование, тем не менее выше них ставит людей и их взаимодействие в процессе разработки, работающую программу, совместную работу (соработничество) с заказчиком и, что особенно важно, отзывчивость на изменения в исходных требованиях и среде разработки.
Важный документ, Манифест подвижного программирования (Manifesto for Agile Software Development) в 2001 г. сформулировал следующие 12 принципов, положенных в его основу:
Высший приоритет – удовлетворение заказчика путем ранних и непрерывных поставок ценного для него ПП.
Изменения требований приветствуются даже на последних этапах. Процессы подвижного программирования справляются с изменениями для предоставления заказчику конкурентных преимуществ.
Поставлять работающий ПП почаще, один раз в период от 2-х недель до 2-х месяцев, предпочитая более короткие сроки.
Люди, ведущие бизнес, и разработчики должны ежедневно работать вместе.
Выстраивать проекты вокруг мотивированных людей. Обеспечивать им необходимые среду и поддержку и доверять им, чтобы работа была сделана.
Разговор лицом к лицу – самый действенный и экономичный метод передачи информации команде разработчиков и внутри нее.
Работающая программа – главная мера продвижения в проекте.
Процессы подвижного программирования продвигают вперед устойчивое развитие. Спонсоры, разработчики и пользователи должны быть в состоянии поддерживать постоянный темп неопределенно долго.
Непрерывное внимание к техническому превосходству и хорошему дизайну продвигает подвижность.
Очень существенна простота – искусство максимизировать объем работы, которую можно не делать.
Лучшие архитектурные решения, требования и проекты возникают в самоорганизующихся командах разработчиков.
Команда регулярно задумывается над тем, как стать еще более эффективной, и затем соответственным образом подстраивает свой процесс и поведение.
Разработка программного продукта – это всегда создание некоторого уникального изделия, поскольку его дальнейшее тиражирование практически не связано ни с какими затратами. Сравнивая подвижное программирование с традиционным «массовым» производством, можно найти следующие различия, отмеченные в Табл. 22.
Табл. 22. Сравнение массового производства с разработкой нового продукта
Критерий |
Массовое производство |
Разработка нового продукта (ПО) |
Исходная специфи-кация |
Вполне возможно сперва закончить спецификации, а затем осуществить построение продукта |
Редко есть возможность создать в начале неизменяемые и подробные спецификации будущего продукта |
Оценка трудоза-трат |
Уже вблизи стартовой точки можно надежно оценить трудозатраты и стоимость всей разработки |
Только по мере накопления опытных данных становится возможным делать предварительные оценки шаг за шагом и планировать работы |
Планиро-вание |
Вполне возможно выявить, определить, спланировать и упорядочить все подробно описанные действия |
В начале проекта это невозможно; требуются шаги по адаптации, направляемые циклами «создание – получение обратной связи» |
Изменения по ходу работ |
Адаптация к непредсказуемым изменениями не является нормальным явлением, и уровень изменений относительно невысок |
Творческая адаптация к непредсказуемым изменениям является нормой, уровень изменений достаточно высок |
В «бойцовском» программировании процесс производства программного продукта разбивается на отдельные циклы, которые по спортивной аналогии называются дистанциями (sprint). У команды есть определенный набор функциональности, которую предполагается реализовать в продукте, из которой она выбирает то, что будет реализовано в данном рабочем цикле. Результатом завершения цикла является новая версия продукта с добавленной функциональностью, которая проверена и готова к применению на стороне заказчика. Существенно, что в конце цикла команда представляет полученное прибавление функциональности так, что заказчик и пользователи могут его видеть, испытывать и делать поправки к дальнейшему ходу проекта.
Продолжительность каждого рабочего цикла – от 2-х до 4-х недель. При этом каждый рабочий день представляет собой ежедневный цикл, в начале которого оцениваются результаты каждого участника разработки за прошедший день и ставятся задачи на текущий день.
Выделяются следующие роли участников проекта.
Владелец продукта (product owner) управляет продуктом. Он (она) вырабатывает общее видение для всей команды, ведет сбор требований, управляет свойствами продукта, упорядочивает их по важности, осуществляет приемку продукта в конце каждого рабочего цикла, управляет планом выпуска и отслеживает рентабельность (возврат вложений) проекта. Как правило, это один из технических специалистов – руководителей организации.
Наставник (scrum master) управляет процессом. Он (она) обеспечивает условия для команды разработчиков и «пасет» ее, устраняет возникающие препятствия, поддерживает ход процесса в необходимом темпе, продвигает процесс вширь в данной организации, привлекая новых участников разработки.
Команда (scrum team) из 5-9 разработчиков управляет собой сама. Она устанавливает свойства продукта для реализации в каждом рабочем цикле и их объем, обязуясь реализовывать эти расширения функциональности. Осуществляет поставки обещанных расширений, отслеживает свое продвижение и самоорганизуется, отвечая перед владельцем продукта за обещанные поставки. Внутри команды нет никакой специальной иерархии или структуры.
Ключевым механизмом деятельности команды разработчиков являются собрания команды, часто с участием наблюдателей и других лиц.
В рамках рабочего цикла (2-4 недели) проводятся 4 собрания, по 4 часа каждое:
в начале – планирование (совещание по требованиям);
в начале – планирование (совещание по дизайну);
близко к концу – обзор и демонстрация уже готового продукта;
в самом конце цикла – ретроспективный обзор, нацеленный на процесс и выработку оценок для следующих рабочих циклов.
В рамках ежедневного рабочего собрания в начале рабочего дня (15 мин) осуществляется синхронизация ежедневных работ между членами команды через получение от каждого члена команды ответов на вопросы:
Что ты сделал после предыдущего собрания?
Что сделаешь между этим собранием и следующим?
Что тебе препятствует в достижении целей данного рабочего цикла?
Надо ли добавить задачи для данного рабочего цикла?
Есть ли чем поделиться с членами команды?
Разумеется, следование такому процессу требует от каждого участника разработки безусловную дисциплину в исполнении работ и синхронизации с остальными членам команды.
Важным аспектом в подвижном программировании является минимизация документооборота, который, как правило, сводится к следующим документам:
перечень свойств/задач продукта – product backlog;
свойства/задачи для реализации в данном рабочем цикле – sprint backlog;
экран завершенности рабочего цикла – burndown chart;
экран препятствий – impediment backlog.
Эти документы создаются и поддерживаются в самом простом общедоступном формате, например, в виде Excel-таблиц, и регулярно вывешиваются в рабочей комнате для постоянного обозрения всеми членами команды. Примеры приведены на Рис. 57.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||