SAFe 101 no TDC de Florianópolis em mai-2015
•
7 gefällt mir•921 views
O documento descreve o Scaled Agile Framework (SAFe), incluindo sua estrutura em três níveis (Portfólio, Programa e Time) e práticas como planejamento de releases, gestão de backlogs e papéis em cada nível. O SAFe fornece uma abordagem para entregar valor aos clientes de forma contínua em grandes organizações através da adoção de princípios ágeis em diferentes níveis da empresa.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie SAFe 101 no TDC de Florianópolis em mai-2015
Ähnlich wie SAFe 101 no TDC de Florianópolis em mai-2015 (20)
SAFe 101 no TDC de Florianópolis em mai-2015
- 1. SAFe® em 25 minutos Adriano Campestrini
- 2. SAFe = Scaled Agile Framework®
- 3. SAFe = composição de boas práticas
- 4. SAFe propõe soluções para temas complicados:
- 5. SAFe From Leffingwell LLC and Scaled Agile Inc.
- 9. product backlog sprint backlog Sprint 2 weeks Daily scrum 2 Semanas de Iteração product increment
- 10. 5 a 9 membros
- 11. 50 a 125 pessoas 5 a 10 times
- 14. Iteração está para o time assim como Agile Release Trains (ART) está para o nível de Programa
- 15. product backlog sprint backlog Sprint 2 weeks Daily scrum 2 Semanas de Iteração product increment
- 16. DemoPSI H I P Based on Leffingwell LLC and Scaled Agile Inc. ReleasePlanning WSJF 10 Semanas de Release
- 17. Backlog do Programa Contém Features Gerente de Produto Arquiteto do Sistema Based on Leffingwell LLC and Scaled Agile Inc. ReleasePlanning
- 18. Alinhar fronteiras das iteraç ões Normalizar velocidade … Based on Leffingwell LLC and Scaled Agile Inc. Backlog do Programa alimenta os Backlogs dos Times System Team O sistema sempre roda! Demo do sistema
- 19. O Planejamento se torna uma rotina O calendário de planejamento pode ser definido com um ano de antecedência
- 22. Papeis no nível de programa
- 23. Gerente de Produto Papeis do nível de programa Permission of Leffingwell LLC and Scaled Agile Inc.
- 24. Papeis do nível de programa Arquiteto do Sistema Permission of Leffingwell LLC and Scaled Agile Inc.
- 25. Papeis do nível de programa UX Permission of Leffingwell LLC and Scaled Agile Inc.
- 26. Papeis do nível de programa Release Train Engenheiro Permission of Leffingwell LLC and Scaled Agile Inc.
- 27. Papeis do nível de programa Gestor Tradicional do Projeto (PMI) Permission of Leffingwell LLC and Scaled Agile Inc.
- 28. Papeis do nível de programa System Team Gestão da Release Permission of Leffingwell LLC and Scaled Agile Inc.
- 32. Portfó li o É picos Feature Histó ria s Tarefas Temas p/ investimento Programa Time
- 33. Portfó li o Programa Time Arquitetura É picos Feature Tarefas Temas p/ investimento Histó ria s
- 34. [Feature Timeline] From Leffingwell LLC and Scaled Agile Inc.
- 38. Financiamento dos Trens (ARTs)
- 39. Governança
- 40. Budget variável ao longo do tempo
- 42. Desenvolva com ritmo. Libere sob demanda. O Desenvolvimento ocorre num ritmo determinado. O Negócio decide quando lançar no mercado. Libere sob demanda Major Release Customer Upgrade Customer Preview Major Release New Feature Desenvolva com ritmo PiI PI PI PI PI
Hinweis der Redaktion
- You’ll notice that most of the slides today have attribution to Dean Leffingwell and to Scaled Agile Inc. Rally is a Scaled Agile gold partner.
- This is the familiar scrum machine, with a basic pattern of plan – do – then demo and retrospect. Every two weeks, the team produces working, fully tested software.
- Wave 1 Agile focused on reorganizing into cross-functional, self-organizing Scrum teams. Which is still an excellent way to pilot and learn and begin to reimagine an org.
- In Wave 2 of Agile, we replicate the team into a team of teams structure. This will be 50-125 people, typically organized into 5 to 10 teams. But just replicating the team structure isn’t enough, we also need to define new roles…
- This is the familiar scrum machine, with a basic pattern of plan – do – then demo and retrospect. Every two weeks, the team produces working, fully tested software.
- Close with a shippable PSI. Demo. Inspect and adapt Prioritizing next PSI using WSJF.
- Common challenge is getting everyone in the room together. This is greatly aided by a routine, calendar-able schedule. Travel gets much cheaper, key people block out time, and the drama of releases start to lose their grip on the organization.
- These new roles are required for coordinating Agile at scale. They are in addition to the familiar Product Owner, Delivery Team and ScrumMaster roles that still apply at the team level. The first program level role we’ll discuss is the product manager. The product manager at the program level is analogous to the product owner at the team level. They have content authority over the program backlog – deciding and prioritizing what the system will do.
- In addition to the idea of content authority – what the system will do, SAFe introduces the concept of design authority – how the system will do it. The system architect has design authority. There are architecture-specific backlog items that find their way into the program level backlog. The architecture specific backlog items drive an “architectural runway” which will discuss in more detail later. Note that SAFe has a lot to say about how architecture happens in an Agile environment at scale. While we’ll touch on this briefly today, to do it justice you’ll need to attend the two day class.
- In a similar manner to architecture, we also have a UX role at the program level, responsible for a consistent user experience across the teams.
- The Release Train Engineer acts as a Uber-Scrum Master at the program level. They are going to coordinate all of the train activities and run the Scrum of Scrums meetings.
- Incidentally, Traditional PMI Project Managers typically end up in one of two roles based on their skillset and desires Domain expertise implies product management/program management role – own backlog. People/coordination expertise implies RTE, release.
- A system team will handle integration, system demos, continuous integration and system health. Release management is a cross-functional team …
- Mentioned funding challenge. Funding in SAFe flows from investment themes. Defined budgetary allocations to value streams. Prescriptive hierarchy of epics – features – teams. Feature level helps avoid the “drowning in user stories” aspect of SCRUM. Business can consume, track and understand work at that level. Acknowledgement that “there’s no perfect hierarchy”. Rally ALM has strong support for this hierarchical approach to requirements. Want to be able to roll up on work grain, timeline, and team structure. Epics go through a business case validation. Work can flow for epics, but it can also be initiated at the program level by the product manager (more common). Epics that flow from the top have funding attached over and above the steady-state funding from the investment themes. SAFe does a very good job of addressing funding issues.
- The red represent architectural epics – features and stories. Separate allocation for architectural features Can initiate at the program level via the system architect or flow from enterprise architect at the portfolio level. Separate content authority for business epics/features versus architectural epics/features. Defined allocation of budget to allow business to make a single conscious architecture versus business features tradeoff.
- Architecture to get in front and lay down a runway for rapid feature velocity. Avoids anti-pattern of slow feature delivery due to inadequate foundation. Also addresses NFR’s. A lot of thought has gone into the delicate balance of “intentional architecture” versus “emergent design”. Not an ivory tower approach. Blending of intent from architecture into teams and emergent design from teams into architecture. Architects follow key epics and features into teams. Key catchphrase: “There is no monopoly on innovation”