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

3,467 views

Published on

Published in: Technology, Sports
  • Be the first to comment

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

  1. 1. Маргарита Котова mailto: [email_address] NIX Solutions Харьков
  2. 2. <ul><li>Характеристика проекта </li></ul><ul><li>Проблемы проекта </li></ul><ul><li>Почему и как планировал c я переход на Agile </li></ul><ul><li>Как это происходит на самом деле </li></ul><ul><li>Попытка анализа причин неудач </li></ul><ul><li>Попытка прогноза результатов проекта </li></ul>
  3. 3. <ul><li>Специализированный программный продукт, клиентами являются крупные корпорации </li></ul><ul><li>Аутсорсинговый проект </li></ul><ul><li>До начала 2008 года выполнялся по водопадной модели, релизы примерно раз в полгода </li></ul><ul><li>С начала 2008 по решению руководства начал выполняться по процессу Agile </li></ul>
  4. 4. <ul><li>Заказчик </li></ul><ul><li>NIX Solutions </li></ul>
  5. 5. <ul><li>Web -приложение Java : </li></ul><ul><li>Сервер приложений </li></ul><ul><li>Сервер базы данных </li></ul><ul><li>LDAP </li></ul><ul><li>Интеграция с несколькими видами DMS </li></ul><ul><li>Вспомогательные сервера </li></ul>
  6. 6. <ul><li>Use Cases: 402 </li></ul><ul><li>UI Pages: 473 </li></ul><ul><li>Hierarchical Trees: 3 </li></ul><ul><li>Wizards: 15 </li></ul><ul><li>Database Tables: 602 </li></ul><ul><li>Tests: 2814 </li></ul>
  7. 7. <ul><li>Проблемы проекта при водопадной модели </li></ul>
  8. 8. <ul><li>PM: Нереалистичное планирование релизов </li></ul><ul><li>Development: Низкое качество разработки </li></ul><ul><li>QC: Неэффективная автоматизация тестирования </li></ul>
  9. 9. <ul><li>Стремление усилить конкурентоспособность продукта за счет наращивания функциональности </li></ul><ul><li>Стремление уменьшить стоимость выполнения проекта за счет сокращения ресурсов и времени на разработку </li></ul><ul><li>Неправильная оценка уровня квалификации разработчиков, необходимого для успешной реализации планов </li></ul>
  10. 10. <ul><li>Недостаточная квалификация разработчиков, не соответствующая потребностям проекта </li></ul><ul><li>Несовершенная внутренняя архитектура приложения, ограничивающая возможности наращивания функциональности и исправления дефектов </li></ul><ul><li>Необходимость работать в сжатые сроки из-за нереалистичного планирования </li></ul>
  11. 11. <ul><li>Неправильная идентификация тестов, подлежащих автоматизации </li></ul><ul><li>Неправильный процесс составления сценариев автоматических тестов </li></ul><ul><li>Отсутствие координации ручного и автоматизированного тестирования </li></ul><ul><li>Использование инструмента, непригодного для автоматического тестирования приложения </li></ul>
  12. 12. <ul><li>Несмотря на большие затраты на тестирование, клиенты несвоевременно получают низкокачественный продукт </li></ul>
  13. 13. <ul><li>Маркетинговая обстановка: появление потенциально конкурентоспособных продуктов </li></ul><ul><li>Появление новых клиентов, и, как следствие – увеличение вариабельности требований к продукту </li></ul><ul><li>Необходимость добавления новой функциональности и коренной переработки старой </li></ul><ul><li>Необходимость улучшения качества продукта для удержания существующих клиентов </li></ul>
  14. 14. <ul><li>Работа по процессу Agile </li></ul><ul><li>Как это предполагалось осуществить? </li></ul>
  15. 15. <ul><li>Минимализация объема разработки за счет реализации только необходимой клиентам функциональности ( Lean ) </li></ul><ul><li>Постоянная обратная связь PM с клиентами для выяснения и уточнения требований </li></ul><ul><li>Регулярная демонстрация клиентам промежуточных результатов, сбор замечаний и пожеланий </li></ul>
  16. 16. <ul><li>Улучшение качества поставляемого продукта </li></ul><ul><li>Улучшение качества кода (рефакторинг) </li></ul><ul><li>Качественное улучшение архитектуры </li></ul><ul><li>Тестирование продукта одновременно с разработкой </li></ul><ul><li>Раннее обнаружение дефектов </li></ul><ul><li>Исправление дефектов одновременно с разработкой новой функциональности </li></ul>
  17. 17. <ul><li>Двухнедельные итерации </li></ul><ul><li>Планирование каждой итерации ( Iteration Planning Meetings ) </li></ul><ul><li>Разработка требований для каждой итерации и их уточнение/изменение по мере разработки каждой функциональности </li></ul><ul><li>Unit -тестирование исправленного кода перед сборкой билда </li></ul><ul><li>Ежедневная автоматическая сборка билда </li></ul><ul><li>Тестирование на daily билдах </li></ul><ul><li>Завершение работы над функциональностью по результатам приемочного тестирования </li></ul>
  18. 18. <ul><li>Неформальное тестирование </li></ul><ul><ul><li>Ad-hoc тестирование на daily билдах для ознакомления с функциональностью, написания формальных </li></ul></ul><ul><ul><li>Предоставление отчетов о дефектах непосредственно разработчикам, работающим над данной функциональностью, минуя баг-трекинговую систему </li></ul></ul><ul><ul><li>Приемочное тестирование функциональности в конце итерации на QC билдах </li></ul></ul><ul><li>Формальное тестирование с регистрацией результатов тестирования и дефектов в баг-трекинговой системе ( Quality Center) </li></ul>
  19. 19. <ul><li>Работа по процессу Agile </li></ul><ul><li>Как это происходило? </li></ul>
  20. 20. <ul><li>Заказчик </li></ul><ul><li>NIX Solutions </li></ul>
  21. 21. <ul><li>Водопадная модель </li></ul><ul><li>Agile </li></ul>Manual Team Automation Team Manual Team Automation Team
  22. 22. <ul><li>Хорошее взаимодействие и взаимопонимание между PM и Q С </li></ul><ul><li>Руководство QC оказывает всяческую поддержку, прислушивается к мнению и спрашивает советов </li></ul><ul><li>Полное отсутствие взаимодействия с разработчиками, запрет на непосредственное общение с ними </li></ul><ul><li>Болезненная реакция разработчиков на обнаруженные дефекты </li></ul>
  23. 23. <ul><li>На первых четырех итерациях отсутствовало вообще, начиная с пятой итерации начало формироваться и к настоящему моменту в вошло в норму </li></ul><ul><li>Нереалистичное планирование итераций: объем запланированных работ существенно превышает возможности их реализации </li></ul>
  24. 24. <ul><li>Требования для каждой итерации разрабатываются в нужные сроки, в нужном объеме </li></ul><ul><li>Документация быстро обновляется при изменении требований </li></ul><ul><li>Из-за невозможности правильно реализовать некоторые функции в должной мере и в должном объеме, требования адаптируются под возможности реализации, либо откладываются на следующий релиз </li></ul>
  25. 25. <ul><li>Испробовано: </li></ul><ul><li>WIKI </li></ul><ul><li>Version One </li></ul><ul><li>Списки дефектов, отправляемые по электронной почте </li></ul><ul><li>Quality Center </li></ul><ul><li>Excel spreadsheet </li></ul><ul><li>В настоящее время используется: </li></ul><ul><li>Version One + Quality Center + Excel + Documentum </li></ul>
  26. 26. <ul><li>Хроническое отсутствие билда </li></ul><ul><li>Неполное покрытие unit тестами (20%) </li></ul><ul><li>Зачастую билды, поставляемые для приемочного тестирования содержат критические дефекты </li></ul><ul><li>Добавление каждой новой функциональности, либо изменение существующей, нарушает прочие функциональные области, включая уже прошедшие приемочное тестирование </li></ul><ul><li>Новая функциональность добавляется как попало, без учета требований </li></ul><ul><li>Рефакторинг каждой функциональной области приводит к ее поломке </li></ul><ul><li>При малейшей возможности протестировать какую-либо функциональность, анонсированную как завершенную, обнаруживается большое количество дефектов </li></ul><ul><li>Дефекты не устраняются в процессе работы </li></ul>
  27. 27. <ul><li>Тестирование проводится хаотично, в спешке, при каждом появлении билда </li></ul><ul><li>Из-за отсутствия билда невозможно разрабатывать тесты параллельно с разработкой функциональности, поэтому тесты разрабатываются вслепую, по требованиям </li></ul><ul><li>Обнаруженные дефекты не исправляются либо отклоняются </li></ul><ul><li>Из-за нерегулярности работы, невозможно сосредоточиться ни на тестировании ни на разработке тестов </li></ul>
  28. 28. <ul><li>Ни одна из итераций не была завершена успешно </li></ul><ul><li>К настоящему моменту условно готовой к формальному тестированию можно считать только одну функциональную область, завершение которой намечалось на второй итерации (в настоящее время выполняется десятая) </li></ul><ul><li>Практически ни одна функциональность не реализована так, как планировалось, из-за ограничений внутренней архитектуры </li></ul><ul><li>Существует огромный риск провала проекта </li></ul>
  29. 29. <ul><li>Водопад </li></ul><ul><li>Agile </li></ul><ul><li>PM: Нереалистичное планирование релизов </li></ul><ul><li>Development: Низкое качество разработки </li></ul><ul><li>QC: Неэффективная автоматизация тестирования </li></ul><ul><li>PM: Нереалистичное планирование релизов </li></ul><ul><li>Development: Низкое качество разработки </li></ul>
  30. 30. <ul><li>Неправильная идентификация основной проблемы проекта и отсутствие мер по ее устранению </li></ul><ul><li>Неготовность либо неспособность команды к работе по данному процессу </li></ul><ul><li>Отсутствие деятельности по формированию команды </li></ul><ul><li>Отсутствие подготовки и адаптации стиля работы команды к новому процессу </li></ul><ul><li>Использование старых методов, непригодных для нового процесса </li></ul>
  31. 31. <ul><li>Фактически проект выполняется не по Agile , а лишь под вывеской Agile </li></ul>
  32. 32. <ul><li>Agile может быть успешным при соблюдении следующих условий : </li></ul><ul><li>Правильная организация и подготовка к процессу </li></ul><ul><li>Подбор соответствующей команды </li></ul><ul><li>Адаптация методов и приемов к условиям конкретного проекта </li></ul>
  33. 33. <ul><li>Оцените все «за» и «против» </li></ul><ul><li>Продумайте, какие препятствия вам могут встретиться, постарайтесь представить как вы их будете преодолевать; мыслите стратегически </li></ul><ul><li>Оцените способность команды соответствовать требованиям </li></ul><ul><li>Если нужно, заблаговременно произведите необходимые замены в команде </li></ul><ul><li>Заранее продумайте процедуру и инструменты, которые вы будете использовать </li></ul><ul><li>Не придерживайтесь процедуры, если она не работает для вашего проекта, адаптируйте ее или придумывайте новую </li></ul>
  34. 34. <ul><li>The Agile Manifesto </li></ul><ul><li>Individuals and interactions </li></ul><ul><li>over processes and tools </li></ul><ul><li>Working software </li></ul><ul><li>over comprehensive documentation </li></ul><ul><li>Customer collaboration </li></ul><ul><li>over contract negotiation </li></ul><ul><li>Responding to change </li></ul><ul><li>over following a plan </li></ul>
  35. 35. <ul><li>The Agile Principles </li></ul><ul><li>1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>8. Agile processes promote sustainable development. </li></ul><ul><li>2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><li>3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. </li></ul><ul><li>10. Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>4. Business people and developers must work together daily throughout the project. </li></ul><ul><li>11. Simplicity—the art of maximizing the amount of work not done—is essential. </li></ul><ul><li>5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><li>12. The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul><ul><li>13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul><ul><li>7. Working software is the primary measure of progress. </li></ul><ul><li>  </li></ul>

×