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

  • 1,946 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,946
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
89
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Este primeiro encontro com os Analistas de Sistemas tem como objetivo principal provocar nos participantes uma reflexão sobre os seus papéis e suas responsabilidades nas dificuldades que eles encontram no dia-a-dia. Ou seja, é fato que os Analistas de Sistemas encontram dificuldades em suas atividades devido à estrutura e demais recursos que eles tanto necessitam para tornarem mais eficazes suas tarefas. Por outro lado, também é fato, que as maiores dificuldades e limitações se encontram nos processos de comunicação e nos relacionamentos entre colegas, gerências, programadores e demais atores no processo de desenvolvimento de sistemas da informação.

Transcript

  • 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.
    • LUIZ CLÁUDIO PARZIANELLO
    • Mestre em Engenharia de Sistemas (USP)
    • Engenheiro Eletricista - Eletrônica (PUCRS)
    • Diretor Executivo da Surya Gestão Digital (Palestrante / Instrutor)
    • Coordenador da Unidade de Sistemas da ThyssenKrupp Elevadores
    • Vice-Coord. do Grupo de Usuários de Métodos Ágeis (SUCESU-RS)
    • + 20 anos de experiência em informática (prog., análise e gerência)
    • + 10 anos como consultor e instrutor em Engenharia de Software
    • 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.
    Sobre o Palestrante
  • 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.
  • 5. Estrutura da Mudança
    • NÍVEIS LÓGICOS DE MUDANÇA
    • 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?
    • Identidade Você pensa que vale a pena fazer, mas de alguma forma você acha que aquilo não faz parte de sua missão?
    • Crenças/Valores Você sabe que tem a capacidade de fazer mas pensa que aquilo não é importante?
    • Capacidade Você sabe o que fazer mas não tem capacidade de executar aquilo que é necessário?
    • Comportamento Você tem informações suficientes mas não sabe exatamente o que fazer?
    • Ambiente Você precisa de mais informações sobre a situação na qual você se encontra ou quer estar?
    Robert Dilts
  • 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
  • 8. Cenário TKE
    • ThyssenKrupp Elevadores :
    • É 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.
    • 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.
    • 44 unidades de negócio na América Latina
    • 2.000 funcionários
  • 9.
    • Tecnologia da Informação :
    • 35 profissionais na área;
    • 25 analistas e desenvolvedores da Unidade de Sistemas
    • Plataformas SAP R/3 (8), Oracle (4), Progress (10) e Java (3)
    • + 50 produtos de software
    • + 50 projetos de software
    • Integração via ESB (Enteprise Service Bus)
    • Gerente de TI = CIO
    • Analistas = Desenvolvedores
    Cenário TKE
  • 10. Cenário TKE Integração via ESB (Enteprise Service Bus)
  • 11.
    • Demandas das áreas de negócio e alta direção ...
    • “ A TI não entrega nada no prazo!”
    • “ Eu quero profissionais dedicados exclusivamente para a minha área!”
    • “ Acho que vocês deveriam contratar mais pessoas!”
    • “ O meu projeto é o mais importante!”
    • “ Todos os projetos são prioritários!”
    • “ Você poderia fazer só isso aqui para mim ... ?”
    • ...
    Cenário TKE
  • 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.
    • As necessidades da mudança ...
    • Cada vez mais os sistemas se tornam interdependentes na organização;
    • A produtividade da equipe de sistemas não está acompanhando a crescente demanda de novos projetos de negócio;
    • A demanda constante de melhoria de produtos está entrando em conflito com as demandas de projetos de negócio;
    • A demanda constante para correção de determinados produtos demonstra baixa qualidade no processo;
    • A demanda por conformidade a padrões de segurança da informação (COSO e COBIT) está demandando um maior controle do processo produtivo;
    • Os “custos” da TI não são compartilhados com as áreas de negócio.
    Cenário TKE
  • 14.
    • Os caminhos da mudança ...
    • Uso de princípios e práticas de consagrados modelos de gestão industrial (Lean Manufacturing, TOC, etc.);
    • Uso de metodologias ágeis para a melhoria dos processos de software (Lean Software Development, Scrum, Extreme Programming);
    • Uso de diretrizes baseadas em modelos e normas internacionais para garantir aderência a padrões de mercado (PMBoK, COSO, COBIT, etc);
    • Uso de ferramentas de software e de gestão visual (placares) para o planejamento e controle quantitativo de processos;
    • Capacitação permanente da equipe de sistemas e de seus respectivos usuários (treinamento e coaching);
    • Product Owner = Key User + Gestor de Produto
    • Analistas de Negócio passam a liderar projetos de TI.
    Cenário TKE
  • 15.
    • As implicações da mudança ...
    • Necessidade de conscientização da Diretoria e dos key users sobre a necessidade de melhoria e sistematização dos processos de software;
    • Sistematização da Unidade de Sistemas com a definição de um modelo de realização e gestão dos processos de software (SGQ);
    • Capacitação da equipe de Sistemas em gestão de processos, produtos e projetos;
    • Consolidação das ferramentas de apoio ao planejamento e controle de projetos de software;
    • Redefinição e capacitação dos key users como apoiadores dos processos de software;
    • Organização da TI como uma “ empresa prestadora de serviços ” cujo foco é o lucro da organização.
    Cenário TKE
  • 16. Vendendo o projeto ...
  • 17.
    • Vocês aceitariam ...
    • 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.?
    • 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?
    • 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?
    • Ouvir por que grandes empresas estão migrando para a denominada “Cultura Ágil”?
    Métodos Ágeis
  • 18. Métodos Ágeis
    • Algumas ações realizadas ...
    • Diagnóstico da situação atual e possíveis causas - JANEIRO;
    • Estruturação de macro-processos e análise do ambiente (pessoas, ferramentas e métodos) - ABRIL;
    • Palestras informativas para conscientização da equipe do cenário desejado - MAIO;
    • Avaliação de ferramentas de apoio ao planejamento e controle de projetos – JUNHO;
    • Implantação da ferramenta VersionOne – JULHO/SETEMBRO;
    • Trabalho individualizado com grupos considerados “gargalos” do processo – JULHO A SETEMBRO;
    • Consolidação do processo – OUTUBRO.
  • 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
  • 28. Fluxo em Grandes Lotes (Waterfall) Visão de Produção
    • Novas Funcionalidades
    • Melhorias em Funcionalidades
    • Correções de Bugs
  • 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
  • 52. Resultados
    • Em seis meses de melhoria contínua ...
      • Todos os profissionais treinados nos conceitos e práticas;
      • 50% da equipe executando Scrum com alguns “percalços”;
      • Novos projetos aderentes ao método (atividades e ferramentas), mas ainda sob “interferências externas”;
      • 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);
      • Ainda persiste a cultura da “produção empurrada”, dificultando a prática de auto-gestão dos “sistemas puxados”;
      • Reconhecimento da necessidade de capacitação dos gestores de produto como Scrum Masters (cumprimento do processo e habilidades de negociação).
  • 53.
    • Objetivos de Curto prazo (2008) :
      • Capacidade de atender as demandas de software da empresa somente com o aumento de produtividade da equipe;
      • Observar o crescimento de resultados financeiros mediante o foco estratégico dos projetos de software;
    • Objetivos de Médio Prazo (2009-2010) :
      • Produzir e manter os sistemas de informação da empresa com melhor qualidade, mais rapidez e menor custo;
      • Consolidar a Unidade de Sistemas como Centro de Lucro para a empresa;
    • 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.
    Resultados
  • 54. Conclusões
  • 55. Conclusões
    • 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;
    • 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 ;
    • Utilize o discurso certo para cada nível organizacional;
    • Não tente mudar o comportamento das pessoas com ordens ou treinamentos ... invista na construção de uma IDENTIDADE!
    • Para quebrar uma crença limitante, nada é mais poderoso do que os fatos da “triste” realidade ...
    • É 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.
  • 56. Obrigado! Perguntas?