Швейцарія, масштабування Scrum і розподілені команди от Романа Сахарова
•Als PPTX, PDF herunterladen•
1 gefällt mir•738 views
У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Швейцарія, масштабування Scrum і розподілені команди от Романа Сахарова
Ähnlich wie Швейцарія, масштабування Scrum і розподілені команди от Романа Сахарова (17)
Mehr von Fwdays
Mehr von Fwdays (20)
Швейцарія, масштабування Scrum і розподілені команди от Романа Сахарова
- 1. Швейцарія, масштабування Scrum і розподілені команди Роман Сахаров @E5
- 2. Improve yourself continuously! Про мене Роман Сахаров Business Analysis Team Leader @EPAM Systems Co-founder and trainer @E5 Business Analyst on Agile projects Agile Project Manager BA Community and mentoring program leader BA and Agile trainer Certified Scrum Master IT Awards 2014 Business Analysis winner
- 3. Improve yourself continuously! Scrum? 1. Хто з вас працює в Agile, або Scrum? 2. Хто працює більш ніж з однією командою? 3. Хто працює в розподіленому форматі?
- 5. Improve yourself continuously! Business Process Work Management •BP Case Library •Productivity Enterprise Case Management •Escalation •Prioritisation Work Management •Advanced Routing •Escalation and Prioritisation Rules and Workflow •SWIFT •E-mail/Web access Automated Correspondence •Log every user and system action Audit trails
- 8. Зліт
- 9. Improve yourself continuously! Scrum Pulse 2-тижневі спринти Планування спринту Щоденний Standup Sprint Review Спринт ретроспектива Backlog Grooming Зустрічі для вирішення проблем
- 10. Improve yourself continuously! Хороший продукт потрібен усім • Кількість процесів в розробці зросла від 1 - 3 до 6 - 7 • Для забезпечення потреб було зібрано ще 3 (4) команди
- 11. ПОПИТ
- 12. Нові виклики Багато замовлень від замовників Замовники змагаються за команду (и) Один проект і команди Жахи пріоретизації Декілька «потоків» роботи
- 13. Improve yourself continuously! Потоки стали проблемою Кожен потік відповідає за свій бізнес процес Кожен департамент має свій потік Кожен потік має свій бюджет Не прозора кількість роботи по напрямкам Немає пріоритизації між стейкхолдерами Хаотичне вдосконалення процесу Команди не розуміють хто чим займається
- 14. Пошук рішення
- 15. Improve yourself continuously! Визначені зони для вдосконалення Scaled events Scaled artifacts Flow of requirements Role of BA/PO Operations and support acceptance procedures Capacity allocation and planning
- 16. Scaled Events Спільне планування для команд Спільні для всіх PBR (Grooming) Глобальні ретроспективи Cross team competency meeting
- 17. Improve yourself continuously! Scaled Artifacts Knowledge base Structure by competencies, which is up-to-dated by • component guardians, • managers, • BAs and other knowledge holders Process descriptions on Confluence Global Retro-points list Summarized list from all the teams to be discussed on Global retrospective meetings General backlog for all streams Rally used for EPICs, Features and User Stories Populated by Product Owner of each business process Priorities by Chef Product Owner before PBR
- 18. PBR Planning Team Support Demo Acceptance Backlog update Requirements flow and work with teams POBA
- 19. Планування в 3х частинах • 1st тільки для PO • Standard Scrum Planning • 1st Part with PO • 2nd with the team creating tasks decomposition Кожен PO має % бюджету на свій напрямок % бюджету - це % velocity команд розробки Capacity Allocation and Planning
- 20. УСПІХ!
- 21. Improve yourself continuously! Виявилось, що це LeSS
- 23. Improve yourself continuously! Ціна Час на інтеграцію результатів роботи Час на зустрічі для обміну інформацією Час на підтримання процесу Час = Гроші але… відсутність цих елементів = хаос
- 24. Отже
- 25. Improve yourself continuously! Agile і Scrum виросли Scrum довів скою користь Великі компанії використовують Agile і Scrum Але великі продукти не можуть обійтись Vanilla Scrum і ми повинні шукати рішення
- 27. Improve yourself continuously! Vielen dank! roman.sakharov@e-5.com.ua E5Trainings E5Trainings E5 www.e-5.com.ua
Hinweis der Redaktion
- У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.
- Function: Business Process Work Management tool including automation of operational processes – poiskat kartinku Technology: JAVA middle tier with.NET and JavaScript (AngularJS) User Interface Zamenit logotipami technologi Main components: component diagram Enterprise case management for improved productivity and reduced operational costs Work management functions such as advanced routing, escalation, and prioritization of work Rules & Workflow engine to drive case routing to work baskets, case prioritization, and escalation Automated correspondence for end users via SWIFT, e-mail and directed web access Audit trails log every system and user action Case Mgmt system. Provide efficient tool for Cases and related Tasks, Business Object Mgmt System Organising task in automated workflow, using BPMN-model . Automation of each step of user's collaboration with case mgmt process For example "Get work" based on tasks assigment - feature SWIFT – global provider of secure financial messaging services
- 1 продукт для декількох клієнтів (один головний) Дещо таємний Scrum
- Story about architect and release manager Kyiv From 3 to 7 Scrum teams Architect Business Analysts team Release manager Zurich – pomenyat na On-site Product owners/BAs team Production support team 1 Dev team
- Business Process Management tools means indefinite demand from business A lot of competitive stakeholders => PRIORITISATION HELL Multiple project streams using same development teams pool Priorities clashes Flexible amount of work for each stream Awards => everyone wants In order to find root cause of constantly appearing issues we investigate current development process and discover numerous communications issues: - No global retro, or in 1 team only - No global planning
- All theses problems come from the same source – indefinite demand and were tangled with each other. Integration process miscommunications So scaling should be holistic, it is an anti-pattern to focus only on a single direction or area of improvement and usually it will affect a few of them.
- 1. General planning meeting Continued in team planning. We’ll talk about this meeting later in details 2. General PBR meetings POs present USs, preliminary estimation and assignment chief product owner Before PBR 3. Global retrospective meeting Gathering key representatives from each team 4. Cross team competency meeting (Agile, BA, Java, JS, Testing) Community Of Practice
- Knowledge base on confluence, which provide know ages on: - SDLS process - Functionality details - Functional components details – architectural and development -
- PO/BA work with teams Present on PBRs Answer questions during development Accept stories on demonstrations Provide vision to what should go next
- The second mechanism, "Pull," also limits WIP by making the production velocity of the upstream process dependent on the downstream consumption velocity. The first mechanism only refers to the amount of WIP, but this second refers to the flow, its direction and speed. "Direction" - The motivation of production is given only by the downstream process. "Speed" - Kanban communicates the timing and the amount of next production. "Pull" limits WIP by making the upstream process's production dependent on the downstream process consumption in the 1st derivation order. This dependency is achieved by the Kanban exchange occurring in the store, pushing the production control information from the downstream process to the upstream.Back to Figure 3: the left-hand side of the graph explains how it makes work self-directing and promotes Kaizen. Everyone can understand what is happening and how well the process is flowing by seeing the Kanban cards posted to boards. Watching the workflow in the Gemba is the start of Kaizen. And physical Kanban cards put on the boards visually makes work self-directing without central control of management. This autonomous process provides data on its performance to support Kaizen, and shifts management attention from assigning or dispatching detailed work to Kaizen activities. As shown by the graph's arrows, terminating in the three effects, the ultimate goals of Kanban can be represented by "Limits WIP", "Continuous Flow" and "Kaizen". A Kanban system "Limits WIP" while sustaining "Continuous Flow". It buffers variability due to common cause variation, and exposes special cause variability, providing candidates for Kaizen.