RSM Boucinhas, Campos & Conti Auditores Independentes

Veja em formato PDF

O objetivo deste artigo ?ostrar como os princ?os Lean, empregados pela primeira vez em otimiza? de processos na ind?a automobil?ica japonesa, podem contribuir para o desenvolvimento de software.

Os problemas que acontecem no desenvolvimento de software costumam se repetir nos mais variados tipos de projetos e de organiza?s no mundo todo. Existe a percep?, correta, de que pessoas capacitadas atuando em um processo adequado produzem um produto (software) de qualidade. Mas o que ?m processo adequado?

Podemos considerar tr?linhas de processos: tradicional (em cascata), unificado (RUP-like) e ?l (XP ? exemplo mais t?co).

O processo unificado foi o primeiro a consolidar tr?caracter?icas que s?extremamente ben?cas e que est?incorporadas em todos os processos mais modernos: iterativo, incremental e ?time-boxed?.

O processo tradicional tem sido formalmente abandonado, embora as empresas o pratiquem sob outros r?os.

• Assumir que pode se saber tudo o que se quer do software num primeiro momento.
• Deixar os testes para os ?os momentos.

O processo unificado se divide em itera?s (pequenos peda? de tempo) nas quais s?gerados incrementos de software pronto (constru?, testado, integrado).

As itera?s s??time-boxed?, ou seja: as datas de t?ino previsto n?podem ser adiadas e representam uma oportunidade de atua? gerencial que coloca em pr?ca o modelo: planeja, executa, mede, aprende.

Este processo permite um aprendizado crescente dos analistas em rela? ao neg? e dos clientes em rela? ao sistema.

Os processos mais ?is s?iterativos, incrementais e ?time-boxed?. Mas, em busca de maior rapidez nas entregas, eliminam parte do formalismo na mesma medida em que agregam maior disciplina. N?contrariam radicalmente o processo unificado, mas enfatizam alguns pontos de maneira diferente; n?seria errado, portanto, pensar nestes processos como sendo uma ?leitura ?l? do processo unificado.

• Processos ?RUP-like? est?se tornando mais ?leves?. De maneira a serem mais ?is.
• Processos ?is est?buscando pr?cas que permitam atacar problemas e projetos mais amplos, para al?dos casos de sucesso iniciais.

Mas onde encontrar os princ?os que podem nos ajudar a tornar nossas pr?cas de desenvolvimento de software adequadas a este novo entendimento resultante de algumas d?das de procura?

Na forma Lean de pensar processos.

• ?Muda?: desperd?o, aquilo que n?agrega valor ao produto;
• ?Mura?: opera? n?linear;
• ?Muri?: estresse de pessoas e equipamentos.

Opera? n?linear (um pico de demanda, por exemplo) gera estresse, o que baixa a qualidade, o que exige mais opera? n?linear para corrigir falhas; sendo que tudo isso n?s?eta nossos esfor? de eliminar desperd?o como aumenta o desperd?o pela utiliza? de iniciativas desnecess?as (mais controles extras, por exemplo).

• 1. Descobrir o qu?/li>
• 2. Descobrir como; e
• 3. Construir.

Seus objetivos s?entregar produtos que agregam valor para o neg? mantendo a habilidade de continuar adicionando valor rapidamente no futuro.

• Desenvolve uma vis?de produto, a ser entregue atrav?de releases,
• Cada release acontece de maneira iterativa e incremental,
• Cada itera? ?time-boxed?.

1.Respeite as pessoas

• Os softwares s?constru?s por pessoas trabalhando em equipes, portanto ?ecess?o integrar pessoas das diversas ?as envolvidas, facilitar a comunica? e a colabora? entre elas e mant?as motivadas;
• ?importante acreditar que as pessoas s?boas e querem entregar um produto de qualidade, portanto ?ecess?o dar condi?s para que realizem seu trabalho;
• Os erros ocorrem mais frequentemente por defeitos de processo do que por falha humana num processo correto;
• As pessoas devem estar capacitadas e autorizadas para customizarem o processo (on-the-fly) conforme as necessidades.

2. Elimine desperd?o

• Desperd?o ?udo que n?agrega valor ao produto ou que n?prepara para uma pr?a agrega? de valor;
• Uma fonte comum de desperd?o ? comunica? entre equipes;
• Outra fonte ?onstruir mais do que foi solicitado ou agregar complexidade ?solu?s de tecnologia;
• A corre? de erros tamb??esperd?o, n?podemos deixar de corrigi-los, mas estamos aumentando o custo de um valor que j?everia ter sido agregado. Os erros devem ter sua causa de processo investigada;
• Controles e documentos devem ser bastante analisados para verificar sua contribui?. Deve-se trocar formalismo por disciplina;

3. Postergue compromissos

• O processo de desenvolvimento de software ?uito sujeito a mudan?. Deve-se aceitar que o usu?o s?nhece 20 a 25% dos requisitos, mas que este valor certamente representa o ?core? do sistema;
• Implementando este ?core? se ter?portunidade para descobrir o restante (vide princ?o seguinte);
• Sobre requisitos: ?ecess?o ter a vis?de produto (ampla, mas n?detalhada) e depois efetuar just-in-time requirements ao longo do ciclo de desenvolvimento;
• Sobre arquitetura: ?ndispens?l, mas deve se praticar Emergent Design que permite elaborar uma arquitetura flex?l sem necessidade de antecipar defini?s sobre as futuras demandas.

• Pela utiliza? de um processo iterativo e incremental se promove a aprendizagem de todo os envolvidos (usu?os, desenvolvedores, etc.) no projeto.

5.Entregue rapidamente

• Deve se entregar software r?do, mas isto se obt?mais com a elimina? de desperd?os e a manuten? do time em um ritmo adequado de produ? do que satisfazendo a ansiedade de ?sair fazendo...?. Deve se produzir em uma ?velocidade de cruzeiro?;
• Deve se planejar um release de maneira a entregar um produto parcial que Possua ?Minimal Marketable Features?.

6. Construa com qualidade (embutida)

• As pessoas n?gastam muito tempo corrigindo erros, gastam muito tempo achando erros!
• ?um desperd?o muito grande gastar esse tempo nas ?as itera?s;
• As tarefas de testes devem come? muito cedo e seguir em paralelo com o desenvolvimento;
• Quem define os requisitos define os crit?os de testes da implementa? desses requisitos.

7. Otimize o todo

• Qual a experi?ia do usu?o: os seis meses desde a solicita? at? entrega ou os 40 dias de programa??
• Todas as partes do processo devem ser analisadas e otimizadas;
• Deve-se usar VSM-Value Stream Maps, identificando o fluxo de tarefas, o tempo de trabalho e o tempo decorrido em cada passo, o tempo de espera entre passos e o tamanho da fila para cada passo. Assim ?oss?l calcular a efici?ia do processo.

• Agregar valor rapidamente ao neg?
• Obter clareza sobre as necessidades do cliente
• Melhorar a ger?ia dos projetos
• Dar maior visibilidade sobre o andamento dos projetos
• Desenvolver com foco no produto
• Manter o time motivado

• Obter maior envolvimento do cliente
• Clientes fazem parte do time
• Aceitar as consequ?ias do iterativo e incremental
• O processo tradicional em cascata d?ma falsa certeza inicial com a qual as organiza?s est?acostumadas
• Praticar maior disciplina
• Para eliminar o desperd?o representado por formalismos e controles ?ecess?o o compromisso com a comunica? e a disciplina
• Aceitar ?planejar? mais
• Na pr?ca se planeja mais frequentemente que no tradicional: plano do produto, plano do release, plano da itera?, revis?di?a das tarefas do dia (plano "on-the-job")
• Trabalhar com um time ?de times?
• Pessoas se intercomunicando o tempo todo buscando um objetivo comum conhecido

• Adaptar os contratos ao processo
• Pode ser dif?l, mas vale lembrar que o que se quer ?oftware funcionando..., n?o pagamento de multas.
• Resolver os problemas que se apresentar?nas ?passagens de bast?
• ?ut?o pensar que se pode desenvolver uma ?especifica?? 100% de forma a poder cobrar uma ?implementa?? 100%; desenvolvimento de software ?m processo de descoberta!

  Continua?: num pr?o artigo abordaremos os princ?os do SCRUM dentro da perspectiva de utiliz?o no gerenciamento das itera?s de um processo definido com base nos princ?os Lean descritos neste artigo.