1 CMM и Agile – возможен ли симбиоз? Проект с использованием комбинированного процесса Иван Гуменюк, Санкт-Петербургский Центр Разработок ЕМС 25 октября, 2008

2 Почему выбрана такая тема? –Антагонизм приверженцев разных подходов –Время может потребовать новых подходов к разработке, в том ичсле комбинацию существующих –Комбинированные процессы уже реально используются CMM(I) –Немножко истории –ЗА и ПРОТИВ; Применимость Agile –ЗА и ПРОТИВ; Применимость Как это происходило у нас в проекте… Примеры взаимодополняемости подходов Пояснение…

3 CMMI и «водопадная модель» не одно и то же –CMM – появился в 1987 как инструмент для оценивания компаний-разработчиков ПО –5 «уровней зрелости»: Начальный, Повторяемый, Определенный, Управляемый, Оптимизируемый –Ключевые Процессные Области, для каждой из которых определены Цели, Свойства и Практики –Документирование не самоцель, а способ предоставления доказательств для оценивания Качество является результатом строгих правил разработки ПО CMM(I): немного истории

4 CMM(I) За и Против –Хорошо проработанная методология и процессы / Может быть не всегда гибкой –Хорошее документирование продуктов, систем и процессов / Требует больших трудозатрат, не годится для небольших организаций/продуктов –Уровень 3 достаточен в большинстве случаев (для управления проектами) Уровни 4 и 5 для управления и улучшения процессов работы –CMMI более гибкий чем CMM, определяет больше процессных областей Главная цель – высокое качество и предсказуемость результатов –CMM(I) подходит для больших проектов/организаций, с высокими требованиями к качеству, для сложных систем –CMM(I) хорошо использовать для распределенных проектов –CMM(I) НЕ подходит для маленьких проектов, быстро меняющихся условий, простых систем с невысокими требованиями к качеству CMMI: За и Против

5 CMM(I): Applicability

6 Появился в конце 1990-х, Agile Manifest опубликован в 2001 Совокупность методологий разработки ПО, использующих: –итеративный подход к разработке –интенсивное сотрудничество и коммуникацию в группах –адаптивное управление проектом –частые промежуточные релизы, концепция всегда работоспособный продукт –принцип test first («сначала тесты») Agile

7 Вначале в нашем проекте использовался Agile… –команда в одном месте –SCRUM + Scrum Of Scrums –Итерации длиной 1 месяц, «собранные»в квартальные релизы –Использование backlog для сбора и распределения задач Что изменилось? –Значительное усложнение архитектуры после создания первого прототипа Много компонент и интерфейсов между ними; сложность интеграции –4 группы (3 в Америке, одна в России) – разные часовые пояса, «не- родной» язык, отсутствие опыта в данной технической области –Команда выросла от нескольких десятков до более 100+ человек –Недостаток документации – задержка адаптации новых сотрудников –Больше народа + больше сложности = нестабильность trunk От Agile к CMMI…

8 Что было сделано (элементы CMMI) –Создана высокоуровневая Системная Спецификация (500+ страниц) описывающая компоненты, их интерфейсы, отображение функций продукта на компоненты –Были созданы функциональные группы (feature teams) –Введены строгие процедуры поставки (check-in) кода в trunk –Планирование фазы интеграции –Тестовые планы – на продукт и features –Больше внимания на автоматизацию тестирования –Вместо квартальных релизов, базирующихся на задачах из backlog – помесячное планирование основанное на feature plans –Процесс работы с дефектами Это помогло! –Более быстрая и легкая адаптация новых сотрудников – существует документация –Улучшение планирования и отслеживания проекта –Улучшение коммуникации –Более стабильный trunk, уменьшение потерь времени и усилий От Agile к CMMI…

9 В CMMI есть элементы Agile… –Спиральная модель разработки проекта была создана ещё в 1989… в CMMI есть и другие модели итеративной разработки –Планирование релизных дат с большими интервалами между ними хорошо сочетается с использованием Scrum внутри интервалов Объединение подходов …а в Agile есть CMMI –Управление Конфигурацией, Управление Интеграцией продукта, Управление Требованиями– эти и другие процессные области CMMI де-факто существуют в любом хорошем Agile проекте

10 Численность группы возросла, стало больше check-ins и trunk стал нестабильным? –Необходимо сделать процедуру поставки кода в trunk более формальной и строгой… Невозможно быстро исправить дефект, найденный в прошлогодней версии продукта? –Может быть, документирование дизайна системы и внутренних интерфейсов смогло бы помочь? Группа выросла, и теперь размещена в 2-х удаленных местах? –Пора задуматься о создании системной спецификации и библиотеки для всех документов с общим доступом… После окончания тестирования выяснилось, что одна функциональная область была не проверена вообще? –Полный список требований выданный группе тестирования как можно раньше, помог бы предотвратить это… Несколько итераций было потрачено на улучшение продукта, а тем временем конкуренты выпустили на рынок свой продукт? –Должно делаться долгосрочное планирование даты выхода на рынок… Примеры «добавления» CMMI к Agile…

11 Затянувшаяся фаза дизайна привела к опозданию начала кодирования? –Раннее прототипирование, итеративная фаза дизайна могли бы помочь… Тестировщики не могут начать тестовый цикл, потому что разработчики не дали final build? –Создавайте тесты как только появляется ранняя версия требований, запускайте и отлаживайте тесты на ранних версиях… Жалобы на то, что формальное ревью кода занимает слишком много времени, и всё равно не находит всех дефектов? –Можно сделать процесс ревью не столь формальным и трудоемким, и при этом обеспечить ведущих разработчиков временем на участие в ревью… В проекте уже более 30 человек и им невозможно управлять? –Могут быть полезны Scrums в малых группах и Scrum Of Scrums чтобы координировать группы меж собой… Примеры «добавления» Agile к CMMI …

12 Комбинирование CMMI и Agile возможно; примеры этого существуют –CMMI всего лишь формально описывает многие практики, реально используемые во многих Agile проектах Современная тенденция - не писать код с нуля, а переиспользовать и интегрировать имеющиеся доступные компоненты –«Водопадная» модель не работает –Традиционные методы оценки трудоемкости не работают –Главными фазами работы становятся интеграция, тестирование и исправление ошибок Заключение … Требов ания и Архите ктура Поиск подходя щих готовых решений Модификация компонентов Тестирование компонентов Интеграция компонентов Тестирование продукта

13 Спасибо !