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

Маргарита Котова mailto: [email_address] 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 Как это происходило?

Водопадная модель 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 может быть успешным при соблюдении следующих условий : Правильная организация и подготовка к процессу Подбор соответствующей команды Адаптация методов и приемов к условиям конкретного проекта

Оцените все «за» и «против» Продумайте, какие препятствия вам могут встретиться, постарайтесь представить как вы их будете преодолевать; мыслите стратегически Оцените способность команды соответствовать требованиям Если нужно, заблаговременно произведите необходимые замены в команде Заранее продумайте процедуру и инструменты, которые вы будете использовать Не придерживайтесь процедуры, если она не работает для вашего проекта, адаптируйте ее или придумывайте новую

The Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

The Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 8. Agile processes promote sustainable development. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 10. Continuous attention to technical excellence and good design enhances agility. 4. Business people and developers must work together daily throughout the project. 11. Simplicity—the art of maximizing the amount of work not done—is essential. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 12. The best architectures, requirements, and designs emerge from self-organizing teams. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 7. Working software is the primary measure of progress.

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

More Related Content

What's hot (18)

Viewers also liked (15)

Similar to Пример внедрения Agile в крупном проекте. Как не следует внедрять Agile (20)

More from Alexey Krivitsky (20)

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