Лилия Алексеева, Весь этот Agile: гибкость в корпоративной среде в трех мифах и четырех вопросах
•Download as PPTX, PDF•
2 likes•879 views
Мифы и правде об Аgile с которыми постоянно сталкивается человек, который начинает внедрять всё это в тяжелой корпоративной стреде.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Лилия Алексеева, Весь этот Agile: гибкость в корпоративной среде в трех мифах и четырех вопросах
Similar to Лилия Алексеева, Весь этот Agile: гибкость в корпоративной среде в трех мифах и четырех вопросах (20)
More from ScrumTrek
More from ScrumTrek (20)
Лилия Алексеева, Весь этот Agile: гибкость в корпоративной среде в трех мифах и четырех вопросах
- 1. Весь этот Agile: гибкость в корпоративной среде в трех мифах и четырех вопросах Лилия Алексеева «Сбербанк»
- 2. Лилия Алексеева Сбербанк Лидер внедрения Agile Ранее: Руководитель проектов по дизайну и оптимизации процессов Аналитик
- 4. Ценности как путеводитель по Зазеркалью
- 5. Миф №1 Agile работает только в «простых и маленьких» проектах
- 7. • Первый в мире небоскреб круглой формы • На момент старта проекта участок земли под строительство еще не существовал • Необычная форма здания и специфика места строительства потребовали выработки ряда новых решений ввиду отсутствия в истории архитектуры аналогичного опыта • Здание выполнено в соответствии со всеми современными экологическими требованиям
- 8. • Первый в мире небоскреб круглой формы • На момент старта проекта участок земли под строительство еще не существовал • Необычная форма здания и специфика места строительства потребовали выработки ряда новых решений ввиду отсутствия в истории архитектуры аналогичного опыта • Здание выполнено в соответствии со всеми современными экологическими требованиям Строительство заняло 7 месяцев!
- 9. • На момент старта детального проектирования и разработки чертежей до планового начала оставалось 2 месяца • Как мы помним, сроки сдвигать было нельзя • Разработка чертежей вместе с опытными испытаниями в лабораториях велись параллельно с ходом строительства
- 10. • На момент старта детального проектирования и разработки чертежей до планового начала оставалось 2 месяца • Как мы помним, сроки сдвигать было нельзя • Разработка чертежей вместе с опытными испытаниями в лабораториях велись параллельно с ходом строительства Неизвестно, понимали ли строители Aldar HQ, что используют гибкую методологию, но она однозначно привела их к успеху
- 13. Опыт, на котором базируется DAD
- 14. Основы DAD Люди в первую очередь Ориентация на обучение Agile Гибридный подход Фокус на решение Полный цикл поставки Goals driven Risk and value driven Вся компания в курсе
- 16. …и варианты его имплементации Расширенный Scrum + RUP Lean Lean continuous delivery Lean Startup
- 19. Принципы LESS
- 21. LESS Huge
- 23. Принципы SAFe Держитесь экономической точки зрения Используйте системное мышление Предполагайте изменения, сохраняйте варианты Разрабатывайте инкрементально быстрыми интеграционными циклами Определяйте вехи на объективной оценке работоспособности системы Визуализируйте и ограничивайте WIP, уменьшайте объем партии и управляйте длиной очереди Используйте каденции, синхронизированные кросс- доменным планированием Дайте проявиться внутренней мотивации Децентрализуйте принятие решений
- 24. Миф №3 Выберите что-то одно
- 26. Вопрос №1 Как строить команды
- 27. Закон Конвея «Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
- 28. Вопрос №2 Независимость тестирования, или Очень страшно «упасть»
- 29. Опыт Google Отдельная функция Обеспечение качества, а не тестирование Тестируем лучших
- 30. Обратимся к теории • Непрерывная интеграция • Test-First • Рефакторинг • Парная работа • Коллективное владение LESS Департамент, которого не должно существовать
- 31. Вопрос №3 Поставка: что считать готовым продуктом и как часто выпускать
- 35. Нет ничего сильнее идеи, время которой пришло Виктор Гюго
Editor's Notes
- Добрый день.
- Меня зовут Лилия Алексеева, я лидер внедрения Agile в Сбербанке и сегодня мне бы хотелось рассмотреть вопросы, с которыми приходится сталкиваться в процессе внедрения гибких методологий в крупных организациях. В первой – основной – части доклада мы рассмотрим мифы, живущие в энтерпрайз-среде, во второй попробуем ответить на несколько практических вопросов, которые ставит внедрение agile в масштабе.
- Для начала хочу спросить – как вам кажется, почему agile становится все более востребован в крупных организациях?
- Я тоже много думала об этом последний год. Сторонники вотерфола часто говорят о том, что при правильном подходе можно и по вотрефолу внедрять много, часто и быстро. И вот какая мысль пришла мне в голову. Питер Друкер сказал: «Культура ест стратегию на завтрак». Не в последнюю очередь, возросший интерес к гибким методологиям можно объяснить тем, что они основаны на ценностях – эволюционно мы пришли к пониманию того, что процессы, правила и артефакты не работают без культурного фундамента. Культура – нить Ариадны, которая позволяет нам находить дорогу в иррациональном мире ИТ, так похожем на Зазеркалье Кэролла. Но, осчастливленные этим «открытием», мы сталкиваемся с тем, что не все так просто.
- … Самый первый и самый ключевой миф энтерпрайза о гибких методологиях звучит так – эджайл применим только для чего-то маленького и простого. Вы ведь не будете строить космические корабли спринтами? – снисходительно улыбаясь, говорят вам. Бог с ними с кораблями, продолжают другие, вы ведь не будете строить свой дом по эджайлу. Полноте, деточка, это невозможно. Еще совсем некоторое время назад, только начав заниматься задачей по анализу целесообразности и применимости гибких методологий, я много размышляла над этим вопросом. С точки зрения теории мне было очевидно, что инкрементальный подход не имеет ограничений по области применения, вот только теории было явно недостаточно. Но как-то вечером меня зацепил рассказ, шедший на экране соседнего ноутбука.
- Мой муж архитектор и тем вечером он смотрел программу нэшнл джиографик о строительстве небоскреба Aldar HQ –штаб-квартиры Aldar Properties. Это уникальное здание в Абу-Даби, не имеющее аналогов в мире.
- История проекта впечатляет – заказчику требовалось, чтобы здание было готово к моменту проведения в эмирате состязаний Формулы-1. При этом это должно было быть нечто действительно впечатляющее, а дополнительно были поставлены требования к абсолютной экологичности здания. Стоит также отметить, что участка под строительство не существовало, точнее им являлась полоска воды, на которой еще предстояло создать подобие земли, достаточное для возведения здания. Разработанный проект круглого небоскреба показался заказчику соответствующим его замыслу, но инженерам он бросал массу вызовов – ведь посмотреть пример было не у кого. Знаете, что интересно?
- Строительство заняло 7 месяцев и проект уложился в сроки. А знаете, что еще интереснее?
- За два месяца до старта строительства был готов только архитектурный проект. Я поясню – если вкратце, это проект, содержащий картинки и планы этажей, но не содержащий конструкторских расчетов и чертежей, по которым можно было бы начинать строительство. И, как мы уже отметили ранее, ряд придуманных решений все еще требовал выбора, уточнения и проверок технологий, так как многие из них ранее не использовались в подобных зданиях либо и вовсе использовались впервые. Команда Aldar HQ пошла рискованным, на первый взгляд, путем –чертежи начали отдавать в работу строителям по мере готовности, испытания технологий в лабораториях велись параллельно стройке. То есть, например, сейчас мы строим первые 5 этажей и параллельно в лаборатории проверяем устоит ли здание, когда будет готово полностью при, например, шквальном ветре, подводных волнах и пр.
- Я не знаю, знали ли архитекторы слово Agile, но здесь налицо итеративно-инкрементальный подход, причем сверх успешно примененный. Так я получила ответ на вопрос о целесообразности гибкости в сложных больших проектах. Но дальше мы столкнулись со следующим предубеждением.
- Ок, вы говорите, что это возможно. Но как? Как ваш прекрасный скрам заработает на сотнях команд, когда все системы так или иначе взаимосвязаны. На этот раз вопрос лежал уже явно в области теории, но у нас опять не было готового ответа. Мы обратились к заходящему солнцу и нашли несколько интересных решений.
- DAD – фреймворк второго поколения, который был разработан Скоттом Эмблером во время его работы в качестве главного методолога IBM Rational. Эмблер опирался на то, что большинство существующих на тот момент agile-подходов требовали доработки и совмещения. Если Agile манифест в свое время создавался как попытка обобщить опыт успешных проектов, то фреймворк DAD был создан в результате многолетней работы по анализу успешных практик масштабирования Agile. Среди использованных методов сами создатели выделяют следующие:
- Как мы видим, здесь есть даже SAFe, о котором еще поговорим.
- People first. DAD team members should be self-disciplined and DAD teams should be self organizing and self aware. The DAD process framework provides guidance which DAD teams leverage to improve their effectiveness, but it does not prescribe mandatory procedures. In DAD we foster the strategy of cross-functional teams made up of cross-functional people (generalizing specialists). Learning oriented. Продолжая заветы манифеста DAD выделяет три ключевых области обучения: 1) как выявлять требования стейкхолдеров 2) как улучшить процесс – свой, команды, компании? 3) техническое развитие Agile. Hybrid. IT solution focused. The DAD approach will advance your focus from producing software to providing solutions --which is where real business value lies for your stakeholders. Full delivery lifecycle. DAD addresses the project lifecycle from the point of initiating the project through construction to the point of releasing the solution into production. We explicitly observe that each iteration is NOT the same. Projects do evolve and the work emphasis changes as we move through the lifecycle. To make this clear, we carve the project into phases with light-weight milestones to ensure that we are focused on the right things at the right time, such as initial visioning, architectural modeling, risk management, and deployment planning. This differs from mainstream agile methods, which typically focus on the construction aspects of the lifecycle; details about how to perform initiation and release activities, or even how they fit into the overall lifecycle, are typically vague and left up to you. Goals driven. Ключевой вызов при описании процессов заключается в том, чтовам нужно дать подробное описание людям, чтобы помочь разобраться, но здесь вы рискуете стать излишне предписывающими. Подход DAD заключается в том, чтобы сформулмровать цель каждого процесса и оставить возможности для тейлоринга и адаптации. Risk and value driven. Из UP Enterprise aware. With the exception of start-up companies, agile delivery teams don’t work in a vacuum. There are often existing systems currently in production, and minimally your solution shouldn’t impact them although your solution should leverage existing functionality and data available in production. There are often other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa. There may be a common vision which your organization is working towards, a vision which your team should contribute to. There will be a governance strategy in place, although it may not be obvious to you, which hopefully enhances what your team is doing. Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you.
- DAD addresses the project lifecycle from the point of initiating the project through construction to the point of releasing the solution into production. We explicitly observe that each iteration is NOT the same. Projects do evolve and the work emphasis changes as we move through the lifecycle. To make this clear, we carve the project into phases with light-weight milestones to ensure that we are focused on the right things at the right time, such as initial visioning, architectural modeling, risk management, and deployment planning. This differs from mainstream agile methods, which typically focus on the construction aspects of the lifecycle; details about how to perform initiation and release activities, or even how they fit into the overall lifecycle, are typically vague and left up to you. Inception Phase Form Initial Team Develop Common Project Vision Align with Enterprise Direction Explore Initial Scope Identify Initial Technical Strategy Develop Initial Release Plan Form Work Environment Secure Funding Identify Risks Construction Phase Produce Potentially Consumable Solution Address Changing Stakeholder Needs Move Closer to Deployable Release Improve Quality Prove Architecture Early Transition Phase Ensure Solution Is Consumable Deploy Solution Ongoing Goals Fulfill Project Mission Grow Team Members Address Risk Improve Team Process and Environment Leverage/Enhance Existing Infrastructure
- An agile/basic version that extends the Scrum Construction lifecycle with proven ideas from RUP; An advanced/lean lifecycle; A lean continuous delivery lifecycle; An exploratory “Lean Startup” lifecycle.
- What is the strength of Scrum? That is not an easy question to answer. Of course, the concepts and principles behind Scrum, such as Transparency, Empirical Process Control, Iterative development, and Self-managing teams are critical. Those principles have been around for quite a while, however, so their inclusion does not explain Scrum’s success. After much discussion, we have concluded: Scrum hits the sweet spot between abstract principles and concrete practices. Thus, in order to keep Large-scale Scrum as Scrum, we’ll need to find a similar balance, so that we will be able to say: For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process control.
- Large-Scale Scrum is Scrum Large-Scale Scrum is Scrum scaled up to multiple teams. It isn't a bigger process that includes Scrum, but is Scrum at its core. Empirical Process Control and Transparency These principles are directly taken from Scrum where the product and process has to be evolved following inspect-adapt cycles or experiments. The content of the product and the process used for development is never fixed but constantly evolving. Transparency is required in order to see the current reality and improve. More with LeSS When scaling up development, there is a tendency to add more process, more roles, more artifacts, more control. These additions often cause overhead and rigidity. The More with LeSS principles assume there is a way of scaling up without adding this additional overhead. It assumes that tailor down is fundamentally wrong. Instead, concepts and processes need to be scaled up based on experiences of the people in the development. Whole-Product Focus Customers don't want components but whole products. When scaling up development, it is easy to lose the focus of the whole product and the whole experience. Therefore, we need to constantly remind everyone involved in development to have the whole-product focus so they make decisions with the whole product in mind. Customer-Centric When working on the technical parts of a large system, it is easy to forget the actual users and customers and this often leads to sub-optimal decisions in the development. Keeping the customer-centric focus is essential for maximizing value delivered. Lean and Continuous Improvement Towards Perfection Lean Manufacturing and Lean Product Development have fundamentally altered the way organizations work. One-piece flow has replaced big-batch development. The focus on people and continuous improvement changes how systems work by continuously applying kaizen and focusing on improvements. Systems Thinking In large-scale development, lots of things happen and it is hard or even impossible to see how everything relates to everything. Systems Thinking provides concepts and tools that help in trying to "see the whole" and how things influence each other, leading to decisions that optimize the total value rather than locally optimize a step or phase. Теория очередей Product Development has lots of queues... places where the information flow stops and waits. Understanding the impact of these queues and how queues affect throughput is essential for improving product development.
- LeSS Structure Structure the organization using real teams as the basic organizational building block. Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived. The majority of the teams are customer-focused feature teams. ScrumMasters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A ScrumMaster does not focus on just one team but on the overall organizational system. A ScrumMaster is a dedicated full-time role. One ScrumMaster can serve 1-3 teams. In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system. Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance”. For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption. The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders. All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders. The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred. One Definition of Done for the whole product common for all teams. Each team can have their own stronger Definition of Done by expanding the common one. The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently). LeSS Sprint There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product. Sprint Planning consists of two parts: Sprint Planning One is common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items. Each Team has their own Sprint Backlog. Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs. Each Team has their own Daily Scrum. Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces. There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and adaptation. Each Team has their own Sprint Retrospective. An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, ScrumMasters, Team Representatives, and managers (if any). LeSS Huge Framework Rules LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations. All LeSS rules apply to LeSS Huge, unless otherwise stated. Each Requirement Area acts like the basic LeSS framework.
- LeSS Huge is the second LeSS Framework, which is suitable for LeSS adoptions of more than eight teams. Conceptually is it LeSS scaled up further by having multiple (smaller) LeSS frameworks stacked on top of each other. Что общего One Product Backlog, one Definition of Done, one Potentially Shippable Product Increment, one (overall) Product Owner, one Sprint. All Teams in one Sprint with one delivery. Что нового? Role changes: Area PO. Artifact changes: “Requirement areas” in Product Backlog; Area Backlog. Meeting changes: LeSS Huge is a set of parallel (per requirement area) LeSS Sprint executions LeSS Huge Structure Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas. Each Team specializes in one Requirement Area. Teams are there “long term”; this won’t change each Sprint but Teams will change Requirement Area when others grow in value. Each Requirement Area has one Area Product Owner. Each Requirement Area has between “4-8” teams. Avoid violating this range. LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach. Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor. LeSS Huge Product Each Requirement Area has one Area Product Owner. One (overall) Product Owner is responsible for product-wide prioritization and deciding which teams work in which Area. He works closely with Area Product Owners. Area Product Owners act as Product Owners towards their teams. There is one Product Backlog; every item in it belongs to exactly one Requirement Area. There is one Area Product Backlog per Requirement Area. This backlog is conceptually a more granular view onto the one Product Backlog. LeSS Huge Sprint There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product. The Product Owner and Area Product Owners synchronize frequently. Before Sprint Planning they ensure the Teams work on the most valuable items. After the Sprint Review, they further enable product-level adaptations.
- Меньше так как много докладов 1) Меньше работы, больше прибыли 3) Set based
- Системы упорядоченные: в этом случае система ограничивает ее агентов, она основана на упрощениях и правилах, детерминистическая и независимая от наблюдателя. Пример: представьте себе процесс производства табуреток, армию или тюрьму. Системы хаотичные: агенты системы не ограничены и независимы друг от друга. Пример: представьте здание в которое только что упала бомба. Что куда летит, и что как развалится просто непредсказуемо. Системы запутанные: системы слегка ограничивающие своих агентов, где агенты в свою очередь изменяют систему взаимодействуя с ней и друг с другом, они ко-эволюционируют и этот процесс необратим. Пример: представьте себе любой живой организм, или экосистему, или организацию. В зависимости от того в какой из систем мы находимся в данный момент времени наши действия должны очень сильно отличаться. Давайте посмотрим на это более подробно. На рисунке справа мы видим четыре области (упорядоченные системы мы разделили на упорядоченные простые и упорядоченные сложные). И давайте проговорим, чем же они отличаются и как должно меняться наше поведение в зависимости от того где мы находимся. Системы упорядоченные простые (правый нижний квадрант) Характеризуются своей простой, взаимосвязи в этих системах очевидны любому разумному человеку, причинно следственные связи в этих системах тоже ясны и находятся на поверхности. Образ действия в подобных системах: Ощути — Категоризуй — Реагируй В таких системах существует понятие Наилучшей практики (Best practice), потому что в них реально найти тот единственно правильный способ достижения результата. Есть некий оптимальный процесс изготовления табуреток, и отклонения от этого процесса, сделают его не таким эффективным. Системы упорядоченные сложные (правый верхний квадрант) Система по прежнему упорядоченна, причинно следственные связи есть, но уже не столь очевидны. Это область в которой тон задают эксперты. При наличии необходимых знаний, взаимосвязи можно обнаружить. Образ действия в подобных системах: Ощути — Проанализируй — Реагируй В этой области по прежнему есть правильные ответы, однако их становится несколько. Спросите двух экспертов как достичь того или иного результата и вы получите два совершенно разных ответа, и каждый из экспертов будет с кровью в глазах доказывать, что его способ наилучший :). Точно также два программиста никогда не напишут одинаковый код, хотя возможно и достигнут одного и того же результата. В этой области пропадает понятие Наилучшей практики, и появляются просто Хорошие практики (можешь делать так, можешь сяк, и так и так достигнешь результат). Системы запутанные (левый верхний квадрант) Характеризуются настолько запутанными и разнообразными связями между агентами, и содержат такое количество агентов, что в этих системах уже без пол-литра невозможно не разобраться. Причинно следственные связи в них не ясны. При двух одинаковых воздействиях на систему результаты могут оказаться совершенно различными. В этой области можно найти достаточное количество фактов, чтобы доказать всевозможные и даже противоречащие друг-другу теории. Минимальное воздействие на систему, может оказать громадный эффект. Образ действия в подобных системах: Прозондируй — Ощути — Реагируй То есть, в этих системах мы начинаем строить гипотезы и создавать всевозможные эксперименты, чтобы эти гипотезы подтвердить или развеять. Для каждой возникшей вменяемой точки зрения или теории мы создаем эксперимент или серию экспериментов. Эти эксперименты не обязательно должны увенчаться успехом, но должны обеспечить проникновение в суть и добавить понимания происходящего. Эксперименты могут запускаться в параллели и противоречить друг-другу. В этой области нет ни наилучшей ни хороших практик. Практики тут возникают по мере проведения экспериментов. Хаотичные системы (левый нижний квадрант) Хаос состояние временное. Полный хаос в природе существует очень недолго и лишь в качестве некого переходного состояния. В момент взрыва бомбы был хаос, но 5 минут спустя система снова приобрела некое стабильное положение (руины, воронка, обломки и тп, все уже устаканилось). Причинно-следственных связей нет. Ничего не понятно. Невозможно делать никаких выводов. Образ действия в хаосе: Действуй — Ощути — Реагируй Перво-наперво в состоянии хаоса надо действовать и действие наше должно быть направлено на стабилизацию положения. Покуда мы будем оставаться в хаосе, ничего хорошего ждать не приходится. Хаос это часто состояние кризиса и/или инноваций (кризис и инновации всегда идут бок о бок). Из состояния хаоса есть два возможных выхода: введение в систему жестких ограничений и ее переход в упорядоченную и простую, либо быстрыми действиями снижающими турбулетность позволить системе перейти в состояние запутанной. Практики в состоянии хаоса будут новыми и придуманными впервые. Теперь попробуйте взглянуть на окружающий мир через призму только что полученного знания. Какие-то вещи упорядоченные и простые, какие-то упорядоченные сложные, что-то запутанное, а что-то хаотичное. Только не пытайтесь категоризовать все окружающие вас процессы по этим четырем областям. Помните, что в различных контекстах и в различные промежутки времени, один и тот же процесс может оказаться в совершенно разных квадрантах. Это не модель для категоризации, это модель, которая призвана дать вам чуть большее понимание окружающего мира. О серебрянных пулях Ну и теперь мы достаточно подкованы теоретически, чтобы поговорить о серебрянных пулях. В правом нижнем углу водопад (waterfall) рулит. В простых упорядоченных системах нет ничего более эффективного, чем водопад. Процесс описан, разложен по полочкам (категоризован), настроен оптимально (Наилучшая практика). Использовать что-то другое для достижения цели в подобных системах, трата времени на ненужное дрыгание по сторонам. В правом верхнем углу мы окунаемся в мир экспертов. Тут находится проектное управление (PMI, Prince2 и им подобные). Хотите построить мост, спросите инженеров как, воспользуйтесь многолетними наработками и сделайте как надо. В левом верхнем углу дайте дорогу скраму. Это позволит ставить эксперименты внутри спринтов, подтверждать или опровергать ваши гипотезы. Часто менять направление движения в зависимости от поставленных вами экспериментов. В левом нижнему углу, все средства хороши. Хотите пригласите диктатора, и он насадит в вашей организации простоту и порядок переведя систему вправо вниз, а хотите пригласите человека с видением, который будет открыт к восприятию разных мнений и воспользуется кризисом, чтобы попробовать создать инновации и переведет систему вправо вверх. Итак, для разных ситуаций, необходимы разные инструменты, и пользоваться скрамом для решения всех проблем так же глупо, как и пытаться все делать по водопаду.
- Все фреймворки сходятся Традиционно мы используем платформенный подход, как выстроить кроссфункциональность – новые продукты, прекращение работы, планирование и пр. При компонентных командах даже небольшие изменения отнимают много времени из-за необходимости кросс-командного взаимодействия. Это приводит к тому, что команды размещают любую логику на тех слоях, к которым имеют доступ. Микросервисный подход к разбиению подразумевает разбиение на сервисы в соответствии с потребностями бизнеса. Такие сервисы включают в себя полный набор технологий, необходимых для этой бизнес-потребности. Кросс-функциональные команды, имеющие полный набор необходимых навыков, обеспечивают быстрое развитие бизнес-продуктов.
- Гугл приводят одним из первыз примеров, когда речь заходит о диджитал-лидерах и эджайл-компаниях, однако у них
- В DAD не нашла. Undone department—This department, ideally, does not exists. But unfortunately sometimes the teams are not yet able to create a true shippable increment every Sprint. This is reflected by their “Definition of Done” not being equal to “Potentially Shippable.” Undone departments such as test, QA, architecture, or business analysis groups should never exist in the smaller LeSS framework groups as they should be integrated into the teams from the start. On the other hand, we unfortunately frequently still see an operations or production undone department in LeSS adoptions, as they often cross organizational boundaries.
- DAD – SAFe – LESS –
- Ключевые принципы: бюджетируется не объем, но цель бюджетируем продукт Бюджетировать value streams, а не проекты Высвобождать право определять контент Утверждать эпики Динамическое бюджетирование