Пример внедрения Agile в крупном проекте. Как не следует...

Маргарита Котоваmailto:mk@nixsolutions.com

NIX SolutionsХарьков

Характеристика проекта Проблемы проекта Почему и как планировалcя переход на Agile Как это происходит на самом деле Попытка анализа причин неудач Попытка прогноза результатов проекта

Специализированный программный продукт, клиентами являются крупные корпорации

Аутсорсинговый проект До начала 2008 года выполнялся по водопадной

модели, релизы примерно раз в полгода С начала 2008 по решению руководства начал

выполняться по процессу Agile

Заказчик NIX Solutions

Web-приложение Java:Сервер приложенийСервер базы данныхLDAPИнтеграция с несколькими видами DMS

Вспомогательные сервера

Use Cases: 402

UI Pages: 473 Hierarchical Trees: 3 Wizards: 15

Database Tables: 602

Tests: 2814

Проблемы проекта при водопадной модели

PM: Нереалистичное планирование релизов

Development: Низкое качество разработки

QC: Неэффективная автоматизация тестирования

Стремление усилить конкурентоспособность продукта за счет наращивания функциональности

Стремление уменьшить стоимость выполнения проекта за счет сокращения ресурсов и времени на разработку

Неправильная оценка уровня квалификации разработчиков, необходимого для успешной реализации планов

Недостаточная квалификация разработчиков, не соответствующая потребностям проекта

Несовершенная внутренняя архитектура приложения, ограничивающая возможности наращивания функциональности и исправления дефектов

Необходимость работать в сжатые сроки из-за нереалистичного планирования

Неправильная идентификация тестов, подлежащих автоматизации

Неправильный процесс составления сценариев автоматических тестов

Отсутствие координации ручного и автоматизированного тестирования

Использование инструмента, непригодного для автоматического тестирования приложения

Несмотря на большие затраты на тестирование, клиенты несвоевременно получают низкокачественный продукт

Маркетинговая обстановка: появление потенциально конкурентоспособных продуктов

Появление новых клиентов, и, как следствие – увеличение вариабельности требований к продукту

Необходимость добавления новой функциональности и коренной переработки старой

Необходимость улучшения качества продукта для удержания существующих клиентов

Работа по процессу Agile

Как это предполагалось осуществить?

Минимализация объема разработки за счет реализации только необходимой клиентам функциональности (Lean)

Постоянная обратная связь PM с клиентами для выяснения и уточнения требований

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

Улучшение качества поставляемого продукта

Улучшение качества кода (рефакторинг)

Качественное улучшение архитектуры Тестирование продукта одновременно с

разработкой Раннее обнаружение дефектов Исправление дефектов одновременно с

разработкой новой функциональности

Двухнедельные итерации Планирование каждой итерации

(Iteration Planning Meetings) Разработка требований для каждой

итерации и их уточнение/изменение по мере разработки каждой функциональности

Unit-тестирование исправленного кода перед сборкой билда

Ежедневная автоматическая сборка билда

Тестирование на daily билдах Завершение работы над

функциональностью по результатам приемочного тестирования

Неформальное тестирование◦Ad-hoc тестирование на daily билдах для

ознакомления с функциональностью, написания формальных

◦Предоставление отчетов о дефектах непосредственно разработчикам, работающим над данной функциональностью, минуя баг-трекинговую систему

◦Приемочное тестирование функциональности в конце итерации на QC билдах

Формальное тестирование с регистрацией результатов тестирования и дефектов в баг-трекинговой системе (Quality Center)

Работа по процессу Agile

Как это происходило?

Заказчик NIX Solutions

Водопадная модель Agile

Manual Team

Automation Team

Manual Team

Automation Team

Хорошее взаимодействие и взаимопонимание между PM и QС

Руководство QC оказывает всяческую поддержку, прислушивается к мнению и спрашивает советов

Полное отсутствие взаимодействия с разработчиками, запрет на непосредственное общение с ними

Болезненная реакция разработчиков на обнаруженные дефекты

На первых четырех итерациях отсутствовало вообще, начиная с пятой итерации начало формироваться и к настоящему моменту в вошло в норму

Нереалистичное планирование итераций: объем запланированных работ существенно превышает возможности их реализации

Требования для каждой итерации разрабатываются в нужные сроки, в нужном объеме

Документация быстро обновляется при изменении требований

Из-за невозможности правильно реализовать некоторые функции в должной мере и в должном объеме, требования адаптируются под возможности реализации, либо откладываются на следующий релиз

Испробовано: WIKI Version One Списки дефектов, отправляемые по

электронной почте Quality Center Excel spreadsheetВ настоящее время используется: Version One + Quality Center + Excel

+ Documentum

Хроническое отсутствие билда Неполное покрытие unit тестами (20%) Зачастую билды, поставляемые для

приемочного тестирования содержат критические дефекты

Добавление каждой новой функциональности, либо изменение существующей, нарушает прочие функциональные области, включая уже прошедшие приемочное тестирование

Новая функциональность добавляется как попало, без учета требований

Рефакторинг каждой функциональной области приводит к ее поломке

При малейшей возможности протестировать какую-либо функциональность, анонсированную как завершенную, обнаруживается большое количество дефектов

Дефекты не устраняются в процессе работы

Тестирование проводится хаотично, в спешке, при каждом появлении билда

Из-за отсутствия билда невозможно разрабатывать тесты параллельно с разработкой функциональности, поэтому тесты разрабатываются вслепую, по требованиям

Обнаруженные дефекты не исправляются либо отклоняются

Из-за нерегулярности работы, невозможно сосредоточиться ни на тестировании ни на разработке тестов

Ни одна из итераций не была завершена успешно

К настоящему моменту условно готовой к формальному тестированию можно считать только одну функциональную область, завершение которой намечалось на второй итерации (в настоящее время выполняется десятая)

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

Существует огромный риск провала проекта

Водопад Agile

PM: Нереалистичное планирование релизов

Development: Низкое качество разработки

QC: Неэффективная автоматизация тестирования

PM: Нереалистичное планирование релизов

Development: Низкое качество разработки

Неправильная идентификация основной проблемы проекта и отсутствие мер по ее устранению

Неготовность либо неспособность команды к работе по данному процессу

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

Отсутствие подготовки и адаптации стиля работы команды к новому процессу

Использование старых методов, непригодных для нового процесса

Фактически проект выполняется не по Agile, а лишь под вывеской

Agile

Agile может быть успешным при соблюдении следующих условий:Правильная организация и подготовка к процессуПодбор соответствующей командыАдаптация методов и приемов к условиям конкретного проекта

Оцените все «за» и «против» Продумайте, какие препятствия вам

могут встретиться, постарайтесь представить как вы их будете преодолевать; мыслите стратегически

Оцените способность команды соответствовать требованиям

Если нужно, заблаговременно произведите необходимые замены в команде

Заранее продумайте процедуру и инструменты, которые вы будете использовать

Не придерживайтесь процедуры, если она не работает для вашего проекта, адаптируйте ее или придумывайте новую