O documento descreve a mudança da cultura organizacional da empresa ThyssenKrupp Elevadores para o pensamento ágil, utilizando métodos como Scrum e Extreme Programming. Inicialmente, a unidade de sistemas enfrentava demandas conflitantes e baixa produtividade. Após seis meses de melhoria contínua, metade da equipe adotou Scrum, com alguns desafios. Novos projetos também usaram as ferramentas, mas enfrentaram interferências. A empresa busca consolidar a unidade como centro de lucro e servir de modelo para out

1. Mudando a Cultura de uma Organização para o Pensamento Ágil: O Caso da Empresa ThyssenKrupp Elevadores Palestrante: Luiz Claudio Parzianello [email_address] [email_address] Seminário sobre Metodologias Ágeis para Desenvolvimento de Software 15/10/2008 (PUCRS)

3. Estrutura da Mudança

4. Estrutura da Mudança CONDIÇÕES BÁSICAS: Para haver qualquer tipo de mudança num ser humano, é necessário que três condições básicas aconteçam: 1) Querer mudar – Motivação! Crer que o motivo vale à pena e é possível. 2) Saber como mudar – Meios ou Recursos! Conhecer os passos necessários para alcançar o objetivo. 3) Ter a oportunidade – Ter ou dar-se a chance! Saber manejar de forma eficaz as interferências e/ou resistências.

6. Estrutura da Mudança MODELO SCORE DE MUDANÇA Cenário Atual Cenário Futuro Transformação S intomas O bjetivo C ausas E feitos R ecursos Robert Dilts

7. Cenário TKE

10. Cenário TKE Integração via ESB (Enteprise Service Bus)

12. Tecnologia da Informação Unidade de Sistemas de Informação “ Uma área operacional focada no atendimento às demandas de diferentes áreas de negócio …” “ Uma área submetida à interferência do controle individualizado dos dirigentes corporativos …” “ Uma área que enfrenta um aumento da demanda contra uma diminuição da capacidade produtiva ...” Cenário TKE Demandas de Projeto Demandas de Produto Alterações de Produto Novos Sistemas Demandas de Suporte Informações de Produto Áreas de Negócio Áreas de Negócio Programadores Analistas Gerente de TI Diretorias Gerências

16. Vendendo o projeto ...

19. Uma Visão Sistêmica do Processo de Software

20. Visão de Processo Unidade de Sistemas

21. Visão de Processo Unidade de Sistemas Um ponto crítico para a melhoria de processo!

22. Visão de Processo Gestão de Projetos de Software Definição de escopo em alto nível (cenários, benefícios, patrocinador, partes interessadas, impacto nos sistemas e pareceres diversos) Definição de escopo em nível médio (processo, requisitos funcionais, critérios de aceitação, prioridades e tamanho do problema) Definição de releases, equipes, iterações/cronograma e custos do projeto)

23. Unidade de Sistemas Visão de Processo Foco crescente na manutenção de produtos

24. Comprometimento dos Key Users Comprometimento com a realidade Visão de Processo

25. Unidade de Sistemas Visão de Processo Foco crescente na capacitação de usuários

26. Uma Visão Sistêmica do Cadeia Produtiva

27. Demandas Isoladas Projeto #1 Projeto #2 Projeto #3 Sistema X Módulo A Sistema X Módulo B Sistema Y Módulo A Sistema Y Módulo B Sistema Z Módulo A Release de Produto Visão de Produção Versão 1.3.0 Versão 3.2.1 Versão 3.2.2 Versão 3.3.0 Versão 5.0.1 Versão 6.0.0 Versão 0.7.1 Versão 0.8.0 Versão 6.1.0 Versão 1.2.0

29. Fluxo Unitário de Produção Fluxo em Pequenos Lotes ( Just in Time ) Visão de Produção

30. Ferramentas de Apoio

31. Ferramentas

32. Ferramentas

33. Ferramentas Placar de Kanbans para a gestão do portfólio de projetos

34. Ferramentas Programado Normal Crítico Impedido Análise Crítica Análise de Escopo Planejamento Desenvolvimento Solicitações Encerrados Suspensos Placar de Kanbans para a gestão do portfólio de projetos

35. Ferramentas Programado Normal Crítico Impedido Análise Crítica Análise de Escopo Planejamento Desenvolvimento Solicitações Encerrados Suspensos Placar de Kanbans para a gestão do portfólio de projetos

36. Ferramentas

37. Definindo o Product Backlog

38. Product Backlog Especificar requisitos com o modelo de User Stories

39. Product Backlog Gerenciar a evolução de requisitos com a utilização de temas

40. Product Backlog Organizar o Backlog por releases de projetos de negócio e demandas individuais de produto

41. Product Backlog Tamanho estimado por aproximações sucessivas (Classes ABC) (A) Problemas Pequenos (B) Problemas Médios (C) Problemas Grandes A Pequenos B Médios C Grandes A Pequenos B Médios C Grandes A Pequenos B Médios C Grandes 1 2 3 5 8 13 20 40 80 User Stories

42. Planejando Sprints

43. Planejamento Os itens de backlog são programados no tempo em ciclos de prazo fixo (Sprints) A velocidade da equipe é considerada no planejamento

44. Planejamento Planejar por programas para garantir o sincronismo de múltiplas equipes

45. Planejamento Testes e Tarefas são definidos e planejados no início do Sprint

46. Controlando Sprints

47. Controle Acompanhamento diário de tarefas e testes de verificação/validação

48. Controle diário da evolução dos releases Controle

49. Controle Previsão de cumprimento do escopo do produto

50. Controle Sprints são formalmente revisados e fechados Retrospectivas realizadas

51. Resultados

54. Conclusões

56. Obrigado! Perguntas?