Mudando a Cultura de umaOrganização para o Pensamento Ágil

Copyright © 2008 Luiz Cláudio Parzianello 15/10/2008 – Slide 1 ThyssenKrupp Elevadores

Mudando a Cultura de umaOrganização para o Pensamento Ágil:

O Caso da Empresa ThyssenKrupp Elevadores

Palestrante:Luiz Claudio Parzianello

[email protected]@thyssenkruppelevadores.com.br

Seminário sobre Metodologias Ágeis paraDesenvolvimento de Software

15/10/2008 (PUCRS)


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


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/ouresistências.



NÍVEIS LÓGICOS DE MUDANÇA

• Espírito/Ideal Você acredita que aquilo faz parte de sua missãode vida, mas de alguma forma você não se

senteparte do todo?

5. Identidade Você pensa que vale a pena fazer, mas dealguma forma você acha que aquilo não fazparte de sua missão?

6. Crenças/Valores Você sabe que tem a capacidade de fazermas pensa que aquilo não é importante?

7. Capacidade Você sabe o que fazer mas não tem capacidade

de executar aquilo que é necessário?

8. Comportamento Você tem informações suficientes mas nãosabe exatamente o que fazer?

9. Ambiente Você precisa de mais informações sobrea situação na qual você se encontra ou querestar?

Robert Dilts



MODELO SCORE DE MUDANÇA

Cenário Atual Cenário Futuro

Transformação

Sintomas Objetivo

Causas Efeitos

Recursos

Robert Dilts


Cenário TKE


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


Tecnologia da Informação:

35 profissionais na área;

25 analistas e desenvolvedores daUnidade 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


Cenário TKE

Integração via ESB (Enteprise Service Bus)


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


Tecnologia da InformaçãoUnidade de Sistemas de Informação

Demandasde Projeto

Demandasde Produto

Alteraçõesde Produto

NovosSistemas

Demandasde Suporte

Informaçõesde Produto

Áreasde

Negócio

Áreasde

Negócio

Programadores Analistas

Gerente de TIDiretorias Gerências

“Uma área operacionalfocada no atendimento àsdemandas de diferentes

áreas de negócio …”

“Uma área operacionalfocada no atendimento àsdemandas de diferentes

áreas de negócio …”

“Uma área submetida àinterferência do controle

individualizado dosdirigentes corporativos …”

“Uma área submetida àinterferência do controle

individualizado dosdirigentes corporativos …”

“Uma área que enfrentaum aumento da demandacontra uma diminuição dacapacidade produtiva ...”

“Uma área que enfrentaum aumento da demandacontra uma diminuição dacapacidade produtiva ...”

Cenário TKE


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


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


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


Vendendo o projeto ...


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


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.


Uma Visão Sistêmicado Processo de Software


Visão de Processo

Unidade de SistemasUnidade de Sistemas


Um ponto crítico paraa melhoria de processo!

Visão de Processo



Gestão de Projetos de SoftwareGestão de Projetos de Software

Definição de escopo emalto nível (cenários,benefícios, patrocinador,partes interessadas,impacto nos sistemase pareceres diversos)

Definição de escopo emalto nível (cenários,benefícios, patrocinador,partes interessadas,impacto nos sistemase pareceres diversos)

Definição de escopo emnível médio (processo, requisitosfuncionais, critérios de aceitação,prioridades e tamanho do problema)

Definição de escopo emnível médio (processo, requisitosfuncionais, critérios de aceitação,prioridades e tamanho do problema)

Definição de releases,equipes, iterações/cronogramae custos do projeto)

Definição de releases,equipes, iterações/cronogramae custos do projeto)

Visão de Processo


Foco crescente namanutenção de produtos


Visão de Processo


Comprometimentodos Key Users

Comprometimentocom a realidade

Visão de Processo


Foco crescente nacapacitação de usuários


Visão de Processo


Uma Visão Sistêmicado Cadeia Produtiva


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

DemandasIsoladas

DemandasIsoladas Projeto #1

Projeto #1Projeto #2

Projeto #2Projeto #3

Projeto #3

Sistema XMódulo A

Sistema XMódulo A

Sistema XMódulo B

Sistema XMódulo B

Sistema YMódulo A

Sistema YMódulo A

Sistema YMódulo B

Sistema YMódulo B

Sistema ZMódulo A

Sistema ZMódulo A

Release deProduto

Release deProduto

Visão de Produção


Fluxo em Grandes Lotes (Waterfall)

1. Novas Funcionalidades2. Melhorias em Funcionalidades3. Correções de Bugs

1. Novas Funcionalidades2. Melhorias em Funcionalidades3. Correções de Bugs



Fluxo Unitário de Produção

Fluxo em Pequenos Lotes (Just in Time)



Ferramentas de Apoio


Ferramentas


Ferramentas


Ferramentas

Placar de Kanbans paraPlacar de Kanbans paraa gestão do portfólioa gestão do portfólio

de projetosde projetos




Ferramentas

Programado

Normal

Crítico

Impedido An

álise C

ríti

ca

An

álise d

e E

scop

o

Pla

neja

men

to

Desenvolvimento

Solicitações

Encerrados

Suspensos






Ferramentas

Programado

Normal

Crítico

Impedido An

álise C

ríti

ca

An

álise d

e E

scop

o

Pla

neja

men

to

Desenvolvimento

Solicitações

Encerrados

Suspensos






Ferramentas


Definindo o Product Backlog


Product Backlog

Especificar requisitos comEspecificar requisitos como modelo de User Storieso modelo de User Stories


Product Backlog

Gerenciar a evoluçãoGerenciar a evoluçãode requisitos com ade requisitos com autilização de temasutilização de temas


Product Backlog

Organizar o Backlog por releasesOrganizar o Backlog por releasesde projetos de negócio e demandasde projetos de negócio e demandasindividuais de produtoindividuais de produto


Product Backlog

Tamanho estimado por aproximações sucessivas (Classes ABC)

(A) Problemas Pequenos(A) Problemas Pequenos (B) Problemas Médios(B) Problemas Médios (C) Problemas Grandes(C) Problemas Grandes

APequenos

BMédios

CGrandes

APequenos

BMédios

CGrandes

APequenos

BMédios

CGrandes

1 2 3 5 8 13 20 40 80

User StoriesUser Stories


Planejando Sprints


Planejamento

Os itens de backlog sãoOs itens de backlog sãoprogramados no tempoprogramados no tempoem ciclos de prazo fixoem ciclos de prazo fixo(Sprints)(Sprints)

A velocidade da A velocidade da equipe é consideradaequipe é consideradano planejamentono planejamento


Planejamento

Planejar porPlanejar porprogramas paraprogramas paragarantir o sincronismogarantir o sincronismode múltiplas equipesde múltiplas equipes


Planejamento

Testes e Tarefas sãoTestes e Tarefas sãodefinidos e planejadosdefinidos e planejadosno início do Sprintno início do Sprint


Controlando Sprints


Controle

AcompanhamentoAcompanhamentodiário de tarefas e testesdiário de tarefas e testesde verificação/validaçãode verificação/validação


Controle diário daControle diário daevolução dos releasesevolução dos releases

Controle


Controle

Previsão de cumprimentoPrevisão de cumprimentodo escopo do produtodo escopo do produto


Controle

Sprints são formalmenteSprints são formalmenterevisados e fechadosrevisados e fechados

Retrospectivas realizadasRetrospectivas realizadas


Resultados


Resultados

Em seis meses de melhoria contínua ...

1. Todos os profissionais treinados nos conceitos e práticas;

2. 50% da equipe executando Scrum com alguns “percalços”;

3. Novos projetos aderentes ao método (atividades e ferramentas), mas ainda sob “interferências externas”;

4. 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);

5. Ainda persiste a cultura da “produção empurrada”, dificultando a prática de auto-gestão dos “sistemas puxados”;

6. Reconhecimento da necessidade de capacitação dos gestores de produto como Scrum Masters (cumprimento do processo e habilidades de negociação).


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


Conclusões


Conclusões

1. 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;

2. 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;

3. Utilize o discurso certo para cada nível organizacional;

4. Não tente mudar o comportamento das pessoas com ordens ou treinamentos ... invista na construção de uma IDENTIDADE!

5. Para quebrar uma crença limitante, nada é mais poderoso do que os fatos da “triste” realidade ...

6. É 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.


Obrigado!

Perguntas?Perguntas?

Technology

Mudando a Cultura de umaOrganização para o Pensamento Ágil