Agile в больших и очень больших проектах
Download as PPTX, PDF2 likes576 views
Документ обсуждает применение Agile-методологий в больших и очень больших проектах, подчеркивая важность деления команд и систем для повышения эффективности управления. Рассматриваются принципы Agile, такие как взаимодействие между людьми, вовлеченность разработчиков и удовлетворение заказчиков, а также предлагается использовать модульный подход для оптимизации разработки. Обсуждается необходимость создания качественных моделей для четкого понимания требований и содержания проекта.
![Для действительно БОЛЬШИХ[*]
СИСТЕМ большой разницы
нет
:-(
[*] Время итерации 2-3 недели,
время проекта 7-8 лет
55/92](https://image.slidesharecdn.com/custisagilerussia-4-06-2010agile-100609091054-phpapp01/85/Agile-55-320.jpg)
Agile в больших и очень больших проектах
- 1. Agile в БОЛЬШИХ и ОЧЕНЬ БОЛЬШИХ проектах проектирование в Agile Михаил Заборов Руководитель направления «Торговые сети» AgileDays, Екатеринбург, 2010
- 2. Очень большие проекты Agenda Большие проекты Текущая работа 2/92
- 4. Корпоративные (Enterprise) Системы Прикладное программное обеспечение предприятий и организаций Buzzword ERP / биллинг / банковские / торговые / складские системы … 4/92
- 5. В чем можно мерить размер? ? Объем данных ? Количество транзакций ? Объем изменений ? Длительность проекта ? Количество отчетов 5/92
- 6. Размеры систем 1ТБ 3млн 10млн 270млн 6/92
- 7. БОЛЬШИЕ проекты = от 10 – 15 чел. лет t 0 4 1 год мес. Маленькие Средние Наш размерчик! Команда 5-10 человек 7/92
- 8. Жизнь успешных и востребованных проектов после внедрения только начинается Высокая динамика требований 8/92
- 9. 30000 25000 Кол-во метаданных 20000 15000 10000 5000 Начало работы 0 0 10 20 30 40 50 60 70 Время (мес.) Изменение Создание 9/92
- 10. 30000 25000 Кол-во метаданных 20000 15000 10000 5000 Начало работы 0 0 10 20 30 40 50 60 70 Время (мес.) Изменение Создание 10/92
- 11. Очень большие проекты Agenda Большие проекты Текущая работа 11/92
- 12. ОЧЕНЬ БОЛЬШИЕ проекты = от 40 – 100 чел. лет t 0 1 год 10 лет Команда 30-50 человек 12/92
- 13. Как сюда впихнуть Agile? 13/92
- 14. А зачем нам вообще Agile? Спросите этих парней :-) 14/92
- 15. Нам важнее Люди и их взаимодействие, чем процессы и средства Работающее ПО, чем исчерпывающая документация Сотрудничество с заказчиком, чем обсуждение условий контракта Реагирование на изменения, чем следование плану 15/92
- 16. Удовлетворенность заказчика ранними и периодическими поставками ценного ПО Невысокая цена поздних внесений изменений в начальные требования Максимальная вовлеченность самих разработчиков в процесс проектирования и дизайна системы. Непосредственное общение разработчиков с пользователями Отсутствие лишних артефактов, в частности, write-only документации Работающее и реально использующееся ПО http://agilemanifesto.org/principles.html 16/92
- 17. Командой в 40 чел управлять очень сложно Потери на коммуникации Бутылочное горло Проблемы синхронизации Оптимальный размер команды 5-7 человек Про это нам и Agile говорит :-) 17/92
- 18. Вывод – нужно делить команды! 18/92
- 19. По каким принципам делить? 19/92
- 20. Component Team 20/92
- 21. Feature Team 21/92
- 22. С чисто организационной точки зрения по большому счету — без разницы 22/92
- 23. Но кроме организационных возникает очень много других проблем ... :-( 23/92
- 24. Сложность системы Не лезет в одну голову «оно так работает…»,почему — никто не знает. Проблемы обучения (персонал, пользователь). Непредсказуемые последствия изменений Ограничение развития. Поправили в одном месте — отвалилось в совсем другом. Стихийные внутренние связи «Ничьи» и «общие» данные, коды и проч… невозможно отследить и контролировать. 24/92
- 25. Производительность Объемы данных Подъем тестового стенда с реальными данными - 3 суток. Масштабируемость «В следующем году мы планируем увеличить бизнес вдвое» Асинхронность взаимодействия Критичные приложения ждут не критичные. Лишние блокировки Железо Увеличение аппаратных мощностей не спасает. «в один прекрасный день оно не уложится в отведенное время» 25/92
- 26. Делить нужно не только команды, но и систему! 26/92
- 27. Карта приложения Крупные модули и API между ними 27/92
- 28. Tom Demarko Закон Конвея Структура системы неизбежно повторяет структуру команд Модули продукта инкапсулируются внутри команды 28/92
- 29. Component Team vs Feature Team И тут мы солидарны :-) 29/92
- 30. А как теперь эти команды синхронизировать? 30/92
- 31. Agile предлагает Scrum of Scrum 31/92
- 32. Мы пошли другим путем 32/92
- 33. Команды максимально независимы и с минимальной синхронизацией 33/92
- 34. Критерии деления команд и системы 34/92
- 35. Процессы разработки модулей - проектирования, технической поддержки, документирования, выпуска версий, тестирования - не должны зависеть друг от друга - за исключением изменения API 35/92
- 36. Физические границы должны быть просты и понятны по данным, исполняемым модулям, исходным кодам и т.д. Нет общих данных владелец данных всегда известен Нет общих экземпляров исполняемых модулей в том числе библиотек 36/92
- 37. Должна быть возможность: Разместить модули на разные аппаратные мощности Иметь различные стратегии резервного копирования Иметь off-line связь между модулями Выполнить модули в разных технологиях. 37/92
- 38. Модуль: Может быть продан отдельно Имеет самостоятельную ценность а не только в месте с другими продуктами Может устанавливаться с продуктами других производителей 38/92
- 39. Как делить? 39/92
- 40. Гради Буч «Внутрикомпонентная связь обычно сильнее, чем связь между компонентами» 40/92
- 41. Например, по организационно й структуре автоматизируемого объекта Совет директоров Розница Опт Закупки Логистика Финансы 41/92
- 42. Связи между отделами слабее, чем внутри отделов Регламенты взаимодействия, локальная группа с которой проще договариваться Замкнутая предметная область Проще обучать сотрудников, осуществлять тестирование и поддержку Проще внедрять Локализованное внедрение Проще общаться с «верхним» руководством заказчика понятно, с какой областью идет работа. Общее руководство у всех пользователей 42/92
- 43. Этого достаточно? Agile Agile Agile Agile 43/92
- 44. К сожалению, нет :-( 44/92
- 45. Деление на крупные модули Agenda Большие проекты Текущая работа 45/92
- 46. Дело в том, каждый модуль – это все еще БОЛЬШОЙ проект = от 10 – 15 чел. лет t 0 4 1 год мес. Маленькие Средние Наш размерчик! Команда 5-10 человек 46/92
- 47. Как получить то, что действительно нужно пользователю ? 47/92
- 48. Agile предлагает инкрементальный дизайн: 48/92
- 49. 49/92
- 50. В реальности задачи в разных итерациях сильно связаны между собой Приходится переделывать ранее сделанное 50/92
- 51. http://alistair.cockburn.us/Incremental+versus+iterative+development http://alistair.cockburn.us/Incremental+means+adding%2c+iterative+means+reworking Алистер Коберн вводит различие между итеративной и инкрементальной разработкой 51/92
- 52. 52/92
- 53. 53/92
- 54. Основное отличие Инкрементальная разработка – добавление нового (add onto) Итеративная — переделывание (rework) ранее сделанного 54/92
- 55. Для действительно БОЛЬШИХ[*] СИСТЕМ большой разницы нет :-( [*] Время итерации 2-3 недели, время проекта 7-8 лет 55/92
- 56. Как из этого: Путем постоянного переделывания Получить вот это: ? 56/92
- 57. Для этого и этого этапа Опять инкремент А иногда и для этого http://lobasev.ru/2008/01/blog-post.html 57/92
- 58. При разработке короткими итерациями мы работаем с небольшим куском системы 58/92
- 59. 59/92
- 60. Где гарантия, что мы получим то, что нужно? 60/92
- 61. 61/92
- 62. 62/92
- 63. В народном творчестве это находит свое отражение: 63/92
- 65. Нужна общая картина 65/92
- 66. 66/92
- 67. При проектировании ИС такая картина — модель предметной области aka Domain Mоdel На самом деле конечно модель системы 67/92
- 68. Признаки качественной модели Простая Лаконичная обозримая Понятная заказчику ключевому пользователю Понятная разработчику всем членам команды 68/92
- 69. Признаки качественной модели Что на картинке, то и в системе… Достаточно формальная Эскиз, а не детальная спецификация 69/92
- 70. Признаки качественной модели Отражает действительность (близка к предметной области) Зависит от контекста 70/92
- 71. Модель предметной области – составляет существенную часть Vision Назначение и границы модуля Основные пользователи Основные функции 71/92
- 72. Bonus Можно оценить реализуемость проекта Можно оценить объем работ 72/92
- 73. На этом проектирование закончено? 73/92
- 74. Практически… 74/92
- 75. Деление на крупные модули Agenda Модель предметной области Текущая работа 75/92
- 76. Мы часто пишем детальные постановки на кусок системы 76/92
- 77. Пишем непосредственно перед стартом разработки Протокол Постановка Выясняем Пишем и Разрабатываем, тестируем детальные согласуем , требования постановку отгружаем Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 77/92
- 78. Согласуем с заказчиком Заказчику понятно, что для него будет сделано 78/92
- 79. Постановка не содержит технических деталей не спецификация В терминах пользователей 79/92
- 80. Не успевает «протухать» через год Ситуация не успела поменяться Заказчик и разработчики все еще в контексте 80/92
- 81. Проектирование методом «Набегающей волны» По аналогии с планированием методом набегающей волны (Rolling Wave Planning) Snorkeling & Scuba Diving Питер Хрущка 81/92
- 82. И это Agile? 82/92
- 83. Удовлетворенность заказчика ранними и периодическими поставками ценного ПО Невысокая цена поздних внесений изменений в начальные требования Максимальная вовлеченность самих разработчиков в процесс проектирования и дизайна системы. Непосредственное общение разработчиков с пользователями Отсутствие лишних артефактов, в частности, write-only документации Работающее и реально использующееся ПО Да, конечно! 83/92
- 84. Bonus Легче вводить новых людей в проект Есть история принятых решений Возможность выявить недопонимание, до начала разработки Заказчик вовлекается в принятие решений 84/92
- 85. А как иначе? 85/92
- 86. Это значит, больше Мы собираемся никакого попробовать кое-что планирования, никакой Так вот как документации. Просто Твоя под названием «Agile это начинайте писать код и школа. программирование». называется. жаловаться. Скотт Адамс (Scott Adams) Источник: http://dilbertru.blogspot.com/2007/11/20071166.html 86/92
- 87. Деление на крупные модули Модель предметной области Детальная постановка 87/92
- 88. Про это мы уже рассказывали 88/92
- 89. http://www.custis.ru/docs/publishing/secr-2008/2008-10-22-analyst-in-agile-show.pdf 89/92
- 90. Базовая методология- Планы счетов 90/92
- 91. 91/92
- 92. Спасибо! team.custis.ru 92/92