O slideshow foi denunciado.
Mudando a Cultura de uma Organização para o Pensamento Ágil: O Caso da Empresa ThyssenKrupp Elevadores Palestrante: Luiz C...
<ul><li>LUIZ CLÁUDIO PARZIANELLO </li></ul><ul><li>Mestre em Engenharia de Sistemas (USP) </li></ul><ul><li>Engenheiro Ele...
Estrutura da Mudança
Estrutura da Mudança CONDIÇÕES BÁSICAS: Para haver qualquer tipo de mudança num ser humano, é necessário que três condiçõe...
Estrutura da Mudança <ul><li>NÍVEIS LÓGICOS DE MUDANÇA </li></ul><ul><li>Espírito/Ideal   Você acredita que aquilo faz par...
Estrutura da Mudança MODELO SCORE DE MUDANÇA Cenário Atual Cenário Futuro Transformação S intomas O bjetivo C ausas E feit...
Cenário TKE
Cenário TKE <ul><li>ThyssenKrupp Elevadores : </li></ul><ul><li>É uma empresa do Grupo ThyssenKrupp, holding com sede na A...
<ul><li>Tecnologia da Informação : </li></ul><ul><li>35 profissionais na área; </li></ul><ul><li>25 analistas e desenvolve...
Cenário TKE Integração via ESB (Enteprise Service Bus)
<ul><li>Demandas das áreas de negócio e alta direção ... </li></ul><ul><li>“ A TI não entrega nada no prazo!” </li></ul><u...
Tecnologia da Informação Unidade de Sistemas de Informação “ Uma área operacional focada no atendimento às demandas de dif...
<ul><li>As necessidades da mudança ... </li></ul><ul><li>Cada vez mais os sistemas se tornam interdependentes na organizaç...
<ul><li>Os caminhos da mudança ... </li></ul><ul><li>Uso de princípios e práticas de consagrados modelos de gestão industr...
<ul><li>As implicações da mudança ... </li></ul><ul><li>Necessidade de conscientização da Diretoria e dos  key users  sobr...
Vendendo o projeto ...
<ul><li>Vocês aceitariam ... </li></ul><ul><li>Experimentar a realização de alguns ciclos de melhoria dos processos de sof...
Métodos Ágeis <ul><li>Algumas ações realizadas ... </li></ul><ul><li>Diagnóstico da situação atual e possíveis causas - JA...
Uma Visão Sistêmica do Processo de Software
Visão de Processo Unidade de Sistemas
Visão de Processo Unidade de Sistemas Um ponto crítico para a melhoria de processo!
Visão de Processo Gestão de Projetos de Software Definição de escopo em alto nível (cenários, benefícios, patrocinador, pa...
Unidade de Sistemas Visão de Processo Foco crescente na manutenção de produtos
Comprometimento dos Key Users Comprometimento com a realidade Visão de Processo
Unidade de Sistemas Visão de Processo Foco crescente na capacitação de usuários
Uma Visão Sistêmica do Cadeia Produtiva
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ódu...
Fluxo em Grandes Lotes (Waterfall) Visão de Produção <ul><li>Novas Funcionalidades </li></ul><ul><li>Melhorias em Funciona...
Fluxo Unitário de Produção Fluxo em Pequenos Lotes ( Just in Time ) Visão de Produção
Ferramentas de Apoio
Ferramentas
Ferramentas
Ferramentas Placar de Kanbans para a gestão do portfólio de projetos
Ferramentas Programado Normal Crítico Impedido Análise Crítica Análise de Escopo Planejamento Desenvolvimento Solicitações...
Ferramentas Programado Normal Crítico Impedido Análise Crítica Análise de Escopo Planejamento Desenvolvimento Solicitações...
Ferramentas
Definindo o Product Backlog
Product Backlog Especificar requisitos com o modelo de User Stories
Product Backlog Gerenciar a evolução de requisitos com a utilização de temas
Product Backlog Organizar o Backlog por releases de projetos de negócio e demandas individuais de produto
Product Backlog Tamanho estimado por aproximações sucessivas (Classes ABC) (A) Problemas Pequenos (B) Problemas Médios (C)...
Planejando Sprints
Planejamento Os itens de backlog são programados no tempo em ciclos de prazo fixo (Sprints) A velocidade da  equipe é cons...
Planejamento Planejar por programas para garantir o sincronismo de múltiplas equipes
Planejamento Testes e Tarefas são definidos e planejados no início do Sprint
Controlando Sprints
Controle Acompanhamento diário de tarefas e testes de verificação/validação
Controle diário da evolução dos releases Controle
Controle Previsão de cumprimento do escopo do produto
Controle Sprints são formalmente revisados e fechados Retrospectivas realizadas
Resultados
Resultados <ul><li>Em  seis meses  de melhoria contínua  ... </li></ul><ul><ul><li>Todos os profissionais treinados nos co...
<ul><li>Objetivos de Curto prazo (2008) : </li></ul><ul><ul><li>Capacidade de atender as demandas de software da empresa s...
Conclusões
Conclusões <ul><li>Scrum  tem sido uma excelente opção para a implantação dos conceitos e práticas de Lean Thinking e TOC ...
Obrigado! Perguntas?
Próximos SlideShares
Carregando em…5
×

Mudando a Cultura de uma Organização para o Pensamento Ágil

2.065 visualizações

Publicada em

Apresentação do caso de estudo da implantação de metodologias ágeis na equipe de desenvolvimento de sistemas da ThyssenKrupp Elevadores Brasil.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Mudando a Cultura de uma Organização para o Pensamento Ágil

  1. 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)
  2. 2. <ul><li>LUIZ CLÁUDIO PARZIANELLO </li></ul><ul><li>Mestre em Engenharia de Sistemas (USP) </li></ul><ul><li>Engenheiro Eletricista - Eletrônica (PUCRS) </li></ul><ul><li>Diretor Executivo da Surya Gestão Digital (Palestrante / Instrutor) </li></ul><ul><li>Coordenador da Unidade de Sistemas da ThyssenKrupp Elevadores </li></ul><ul><li>Vice-Coord. do Grupo de Usuários de Métodos Ágeis (SUCESU-RS) </li></ul><ul><li>+ 20 anos de experiência em informática (prog., análise e gerência) </li></ul><ul><li>+ 10 anos como consultor e instrutor em Engenharia de Software </li></ul><ul><li>Atuou como pesquisador, consultor e instrutor nas seguintes empresas e organizações: Incor-HCFMUSP, Citibank (Caribe), Sicredi, Banrisul, FAURGS, SBC, ThyssenKrupp Elevadores, Refap/Petrobrás, Min. Planejamento Angola, Mercador-Neogrid, Pref. de Novo Hamburgo, Pref. de Santa Cruz do Sul, FUNTEC (Argentina), FIERGS, entre outras. </li></ul>Sobre o Palestrante
  3. 3. Estrutura da Mudança
  4. 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.
  5. 5. Estrutura da Mudança <ul><li>NÍVEIS LÓGICOS DE MUDANÇA </li></ul><ul><li>Espírito/Ideal Você acredita que aquilo faz parte de sua missão de vida, mas de alguma forma você não se sente parte do todo? </li></ul><ul><li>Identidade Você pensa que vale a pena fazer, mas de alguma forma você acha que aquilo não faz parte de sua missão? </li></ul><ul><li>Crenças/Valores Você sabe que tem a capacidade de fazer mas pensa que aquilo não é importante? </li></ul><ul><li>Capacidade Você sabe o que fazer mas não tem capacidade de executar aquilo que é necessário? </li></ul><ul><li>Comportamento Você tem informações suficientes mas não sabe exatamente o que fazer? </li></ul><ul><li>Ambiente Você precisa de mais informações sobre a situação na qual você se encontra ou quer estar? </li></ul>Robert Dilts
  6. 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. 7. Cenário TKE
  8. 8. Cenário TKE <ul><li>ThyssenKrupp Elevadores : </li></ul><ul><li>É uma empresa do Grupo ThyssenKrupp, holding com sede na Alemanha e atuação nas áreas de Siderurgia, Automotiva, Elevação, Tecnologia e Serviços. O Grupo é um dos líderes mundiais no segmento de elevadores. Sua produção é descentralizada com fábricas na Europa, Ásia e América. </li></ul><ul><li>Atua na industrialização, comércio, exportação, modernização e conservação de elevadores. Também atua no setor de escadas e esteiras rolantes, fingers (passarelas para aeroportos), equipamentos para pessoas com mobilidade reduzida e armazéns robotizados. </li></ul><ul><li>44 unidades de negócio na América Latina </li></ul><ul><li>2.000 funcionários </li></ul>
  9. 9. <ul><li>Tecnologia da Informação : </li></ul><ul><li>35 profissionais na área; </li></ul><ul><li>25 analistas e desenvolvedores da Unidade de Sistemas </li></ul><ul><li>Plataformas SAP R/3 (8), Oracle (4), Progress (10) e Java (3) </li></ul><ul><li>+ 50 produtos de software </li></ul><ul><li>+ 50 projetos de software </li></ul><ul><li>Integração via ESB (Enteprise Service Bus) </li></ul><ul><li>Gerente de TI = CIO </li></ul><ul><li>Analistas = Desenvolvedores </li></ul>Cenário TKE
  10. 10. Cenário TKE Integração via ESB (Enteprise Service Bus)
  11. 11. <ul><li>Demandas das áreas de negócio e alta direção ... </li></ul><ul><li>“ A TI não entrega nada no prazo!” </li></ul><ul><li>“ Eu quero profissionais dedicados exclusivamente para a minha área!” </li></ul><ul><li>“ Acho que vocês deveriam contratar mais pessoas!” </li></ul><ul><li>“ O meu projeto é o mais importante!” </li></ul><ul><li>“ Todos os projetos são prioritários!” </li></ul><ul><li>“ Você poderia fazer só isso aqui para mim ... ?” </li></ul><ul><li>... </li></ul>Cenário TKE
  12. 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
  13. 13. <ul><li>As necessidades da mudança ... </li></ul><ul><li>Cada vez mais os sistemas se tornam interdependentes na organização; </li></ul><ul><li>A produtividade da equipe de sistemas não está acompanhando a crescente demanda de novos projetos de negócio; </li></ul><ul><li>A demanda constante de melhoria de produtos está entrando em conflito com as demandas de projetos de negócio; </li></ul><ul><li>A demanda constante para correção de determinados produtos demonstra baixa qualidade no processo; </li></ul><ul><li>A demanda por conformidade a padrões de segurança da informação (COSO e COBIT) está demandando um maior controle do processo produtivo; </li></ul><ul><li>Os “custos” da TI não são compartilhados com as áreas de negócio. </li></ul>Cenário TKE
  14. 14. <ul><li>Os caminhos da mudança ... </li></ul><ul><li>Uso de princípios e práticas de consagrados modelos de gestão industrial (Lean Manufacturing, TOC, etc.); </li></ul><ul><li>Uso de metodologias ágeis para a melhoria dos processos de software (Lean Software Development, Scrum, Extreme Programming); </li></ul><ul><li>Uso de diretrizes baseadas em modelos e normas internacionais para garantir aderência a padrões de mercado (PMBoK, COSO, COBIT, etc); </li></ul><ul><li>Uso de ferramentas de software e de gestão visual (placares) para o planejamento e controle quantitativo de processos; </li></ul><ul><li>Capacitação permanente da equipe de sistemas e de seus respectivos usuários (treinamento e coaching); </li></ul><ul><li>Product Owner = Key User + Gestor de Produto </li></ul><ul><li>Analistas de Negócio passam a liderar projetos de TI. </li></ul>Cenário TKE
  15. 15. <ul><li>As implicações da mudança ... </li></ul><ul><li>Necessidade de conscientização da Diretoria e dos key users sobre a necessidade de melhoria e sistematização dos processos de software; </li></ul><ul><li>Sistematização da Unidade de Sistemas com a definição de um modelo de realização e gestão dos processos de software (SGQ); </li></ul><ul><li>Capacitação da equipe de Sistemas em gestão de processos, produtos e projetos; </li></ul><ul><li>Consolidação das ferramentas de apoio ao planejamento e controle de projetos de software; </li></ul><ul><li>Redefinição e capacitação dos key users como apoiadores dos processos de software; </li></ul><ul><li>Organização da TI como uma “ empresa prestadora de serviços ” cujo foco é o lucro da organização. </li></ul>Cenário TKE
  16. 16. Vendendo o projeto ...
  17. 17. <ul><li>Vocês aceitariam ... </li></ul><ul><li>Experimentar a realização de alguns ciclos de melhoria dos processos de software da empresa (PDCA) utilizando conceitos e práticas provenientes de métodos bem conhecidos de vocês como “Sistemas de Produção Enxuta” (Lean Production), “Teoria das Restrições” (TOC), Seis Sigma, etc.? </li></ul><ul><li>Experimentar um conjunto de práticas simples de planejamento e controle de projetos, de um método denominado Scrum, que podem triplicar a produtividade da equipe (no mínimo) e minimizar os riscos por ações constantes de prevenção? </li></ul><ul><li>Aumentar a qualidade dos produtos de software enquanto aumentamos a competência dos integrantes de sua equipe de desenvolvimento com um métodos denominado Extreme Programming? </li></ul><ul><li>Ouvir por que grandes empresas estão migrando para a denominada “Cultura Ágil”? </li></ul>Métodos Ágeis
  18. 18. Métodos Ágeis <ul><li>Algumas ações realizadas ... </li></ul><ul><li>Diagnóstico da situação atual e possíveis causas - JANEIRO; </li></ul><ul><li>Estruturação de macro-processos e análise do ambiente (pessoas, ferramentas e métodos) - ABRIL; </li></ul><ul><li>Palestras informativas para conscientização da equipe do cenário desejado - MAIO; </li></ul><ul><li>Avaliação de ferramentas de apoio ao planejamento e controle de projetos – JUNHO; </li></ul><ul><li>Implantação da ferramenta VersionOne – JULHO/SETEMBRO; </li></ul><ul><li>Trabalho individualizado com grupos considerados “gargalos” do processo – JULHO A SETEMBRO; </li></ul><ul><li>Consolidação do processo – OUTUBRO. </li></ul>
  19. 19. Uma Visão Sistêmica do Processo de Software
  20. 20. Visão de Processo Unidade de Sistemas
  21. 21. Visão de Processo Unidade de Sistemas Um ponto crítico para a melhoria de processo!
  22. 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. 23. Unidade de Sistemas Visão de Processo Foco crescente na manutenção de produtos
  24. 24. Comprometimento dos Key Users Comprometimento com a realidade Visão de Processo
  25. 25. Unidade de Sistemas Visão de Processo Foco crescente na capacitação de usuários
  26. 26. Uma Visão Sistêmica do Cadeia Produtiva
  27. 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
  28. 28. Fluxo em Grandes Lotes (Waterfall) Visão de Produção <ul><li>Novas Funcionalidades </li></ul><ul><li>Melhorias em Funcionalidades </li></ul><ul><li>Correções de Bugs </li></ul>
  29. 29. Fluxo Unitário de Produção Fluxo em Pequenos Lotes ( Just in Time ) Visão de Produção
  30. 30. Ferramentas de Apoio
  31. 31. Ferramentas
  32. 32. Ferramentas
  33. 33. Ferramentas Placar de Kanbans para a gestão do portfólio de projetos
  34. 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. 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. 36. Ferramentas
  37. 37. Definindo o Product Backlog
  38. 38. Product Backlog Especificar requisitos com o modelo de User Stories
  39. 39. Product Backlog Gerenciar a evolução de requisitos com a utilização de temas
  40. 40. Product Backlog Organizar o Backlog por releases de projetos de negócio e demandas individuais de produto
  41. 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. 42. Planejando Sprints
  43. 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. 44. Planejamento Planejar por programas para garantir o sincronismo de múltiplas equipes
  45. 45. Planejamento Testes e Tarefas são definidos e planejados no início do Sprint
  46. 46. Controlando Sprints
  47. 47. Controle Acompanhamento diário de tarefas e testes de verificação/validação
  48. 48. Controle diário da evolução dos releases Controle
  49. 49. Controle Previsão de cumprimento do escopo do produto
  50. 50. Controle Sprints são formalmente revisados e fechados Retrospectivas realizadas
  51. 51. Resultados
  52. 52. Resultados <ul><li>Em seis meses de melhoria contínua ... </li></ul><ul><ul><li>Todos os profissionais treinados nos conceitos e práticas; </li></ul></ul><ul><ul><li>50% da equipe executando Scrum com alguns “percalços”; </li></ul></ul><ul><ul><li>Novos projetos aderentes ao método (atividades e ferramentas), mas ainda sob “interferências externas”; </li></ul></ul><ul><ul><li>Conquista de um case de sucesso para fortalecimento do moral da equipe (projeto entregue em 1/5 do tempo esperado pelos usuários e cumprimento do prazo acordado); </li></ul></ul><ul><ul><li>Ainda persiste a cultura da “produção empurrada”, dificultando a prática de auto-gestão dos “sistemas puxados”; </li></ul></ul><ul><ul><li>Reconhecimento da necessidade de capacitação dos gestores de produto como Scrum Masters (cumprimento do processo e habilidades de negociação). </li></ul></ul>
  53. 53. <ul><li>Objetivos de Curto prazo (2008) : </li></ul><ul><ul><li>Capacidade de atender as demandas de software da empresa somente com o aumento de produtividade da equipe; </li></ul></ul><ul><ul><li>Observar o crescimento de resultados financeiros mediante o foco estratégico dos projetos de software; </li></ul></ul><ul><li>Objetivos de Médio Prazo (2009-2010) : </li></ul><ul><ul><li>Produzir e manter os sistemas de informação da empresa com melhor qualidade, mais rapidez e menor custo; </li></ul></ul><ul><ul><li>Consolidar a Unidade de Sistemas como Centro de Lucro para a empresa; </li></ul></ul><ul><li>Objetivos de Longo Prazo (> 2010) : Ser referência como modelo de gestão de projetos e processos, possibilitando um “rollout” para outras áreas de negócio. </li></ul>Resultados
  54. 54. Conclusões
  55. 55. Conclusões <ul><li>Scrum tem sido uma excelente opção para a implantação dos conceitos e práticas de Lean Thinking e TOC nos processos de software da TKE; </li></ul><ul><li>Se a tecnologia não ajuda, não limite um projeto de melhoria baseado em métodos ágeis somente por não conseguir implantar as práticas de engenharia da XP ; </li></ul><ul><li>Utilize o discurso certo para cada nível organizacional; </li></ul><ul><li>Não tente mudar o comportamento das pessoas com ordens ou treinamentos ... invista na construção de uma IDENTIDADE! </li></ul><ul><li>Para quebrar uma crença limitante, nada é mais poderoso do que os fatos da “triste” realidade ... </li></ul><ul><li>É muito difícil DEIXAR de aprimorar uma equipe e um processo de software de uma organização rodando ciclos de PDCA a cada duas semanas. </li></ul>
  56. 56. Obrigado! Perguntas?

×