Инкрементальная и адаптивная архитектура @ AgileDays'16
•Download as PPTX, PDF•
0 likes•358 views
Разработка выходит на сверхзвуковые скорости, и мы не можем позволить себе роскошь тормозить процесс через техническое несовершенство. Инженерия должна помогать, а местами и подгонять процесс в целом :) В разное время мы ценили различные ее качества и свойства, по-разному принимали архитектурные решения. Мы прошли путь от монолита до микро- и даже наносервисов. Мы научились (хорошо, все еще учимся) автоматически деплоить качественные продукты. Сегодня, как никогда, для нас важны инкрементальность и адаптивность архитектуры. И если об инкрементальности слышали многие, то адаптивность (иначе — антихрупкость) — термин не столь распространенный.
Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Similar to Инкрементальная и адаптивная архитектура @ AgileDays'16
Similar to Инкрементальная и адаптивная архитектура @ AgileDays'16 (11)
Инкрементальная и адаптивная архитектура @ AgileDays'16
- 1. Кто она, инкрементальная и адаптивная архитектура? Сергей Баранов «ScrumTrek»
- 5. BDUF
- 10. BDUF риски изменения Emergent Design риски изменения Just Enough Design нечто среднее
- 12. ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ важнее СЛЕДОВАНИЯ ПЕРВОНАЧАЛЬНОМУ ПЛАНУ #АДАПТИВНОСТЬ
- 18. ПРАКТИКИ
- 20. #Vision Удобный сайт конференции AgileDays, максимально автоматизирующий работу с докладами
- 21. #Stories Регистрация участника Регистрация докладчика Подача доклада Отображение докладов
- 22. #Stories Регистрация участника Регистрация докладчика Подача доклада Отображение докладов
- 23. #DomainModel
- 25. #WalkingSkeleton
- 27. #WalkingSkeleton Какие [шаги|правила..] нужны? Все ли [шаги|правила..] необходимы сейчас? Могут ли какие-то [шаги|правила…] сейчас быть упрощены?
- 28. Как бы вы решили проблему не будь у вас компьютера?
- 29. #WalkingSkeleton:workflow Подача доклада Выбрать тип: «Докладчик» Заполнить форму подачи доклада Отправить информационное письмо
- 30. #WalkingSkeleton:businessRules Заполнить форму подачи доклада Все поля обязательные Не более 3-х докладов Описание не менее 2048 символов Название на русском языке
- 31. #WalkingSkeleton:businessRules Заполнить форму подачи доклада Часть полей — обязательные Не более 3-х докладов Описание не более 2048 символов Название на русском языке
- 34. #OCP OPENED FOR EXTENSION but CLOSED FOR MODIFICATION
- 36. #OCP
- 37. #Strategy 50 км
- 38. #Strategy изменение профиля свободное через уведомление и подтверждение
- 39. #Simplicity «The art of maximizing the amount of work not done — is essential.»
- 40. #Simplicity vs over-engineering Действительно ли этот участок кода нужен сейчас?
- 41. #ShotgunSurgery A выполняет A, X, Y, Z B выполняет B, X, Y, Z C выполняет C, X, Y, Z «Поправь X, там работы на 15 минут…»
- 44. https://agiledays.ru/edit ?data={“name”: “Bruce”, “band”: “Iron..”} Тестируем что угодно #Testability
- 45. Архитектура — лишь один из аспектов проекта, управляемый тем же процессом и теми же принципами инкрементальность, адаптивность, обратная связь, совместное принятие решений, реакция на изменения
Editor's Notes
- Говоря Agile мы обычно подразумеваем процессы. Но работая с самыми различными командами можно нередко можно заметить, что какими бы правильно исполняемыми ни были процессные приседания, упершись в инженерку мы начинаем топтаться на месте. Если количество фич в минуту падает не смотря на идеальную сыгранность команды, то возможно проблема где-то еще. И это где-то почти наверняка в другой плоскости, возможно даже архитектура. Я расскажу о том, что такое инкрементальная и адаптивная архитектура и каким образом она коррелирует с процессами разработки, разделяющие ценности agile.
- Что-то может выглядеть достаточно хорошим в теории, но не работать на практике, бизнес требует изменений в ногу со своим развитием, очень трудно наладить быстрые и ранние поставки и, конечно, невозможно предсказать абсолютно все. И даже более того, в скрам явно прописано, что Product Backlog может расти и меняться по мере того, как мы узнает больше о продукте и пользователях. К термину BDUF очень крепко прилипли такие метафоры, как PowerPoint-архитектура, архитектурный астронавт в башне из слоновой кости.
- No design Отлично работает, когда команде надо очень быстро реагировать на изменения и нет существенных архитектурных рисков, которые следовало бы адресовать до начала разработки
- Simon Brown, основатель сайта Coding the Architecture: «нечто между BDUF и Emergent Design». Столько, сколько надо! Но возникает вопрос: достаточно — это сколько, это что, это как?
- Традиционные методы фокусируются на детальных спецификациях требований, как функциональных, так и не функциональных. В современном мире мы должны извлекать требования через эксперименты, эмпирически. Например, Lean нам говорит: «строй Minimum Viable Product (MVP) откладывая все решения, какие только возможно до наступления Last Responsible Moment». Разумеется, здесь не обойтись без инженерных практик, позволяющих построить гибкую платформу, позволяющую проводить эффективные, с точки зрения стоимости, эксперименты. Томас Эдисон провел множество экспериментов. Если бы он только и делал, что переписывал спецификации, он бы так ничего и не добился.
- Workflow Какие шаги должен предпринять пользователь, чтобы получить ценность? Все ли шаги сейчас необходимы? Могут ли какие-то шаги сейчас быть упрощены? Бизнес-правила Какие правила применимы к этому workflow? Все ли правила необходимо применить прямо сейчас? Можем ли мы сейчас упростить какие-то правила? Какие должны поддерживаться платформы? Все ли платформы необходимо поддерживать прямо сейчас? Реализация для каких-то из платформ сложнее, чем для других? То же самое с входными параметрами, ролями. Почему так? Реализация по горизонтали, по слоям, не поставляет ценность пользователю.
- Workflow Какие шаги должен предпринять пользователь, чтобы получить ценность? Все ли шаги сейчас необходимы? Могут ли какие-то шаги сейчас быть упрощены? Бизнес-правила Какие правила применимы к этому workflow? Все ли правила необходимо применить прямо сейчас? Можем ли мы сейчас упростить какие-то правила? Какие должны поддерживаться платформы? Все ли платформы необходимо поддерживать прямо сейчас? Реализация для каких-то из платформ сложнее, чем для других? То же самое с входными параметрами, ролями. Почему так? Реализация по горизонтали, по слоям, не поставляет ценность пользователю.
- Требования регуляторов диктуют что мы должны делать, но не объясняют почему.
- not affected by the passage of time or changes in fashion.
- "The more tied components are to each other, the less reusable they will be, and the more difficult it becomes to make changes to one without accidentally affecting another" ” Rebecca Murphey, author of jQuery Fundamentals Blasting your code to make a change, making the same or similar change in many places. How painful is it to change your implementation? How painful is it tracking down bugs you didn't realize your changes had caused?