Artigo do Akita esse mês. Liberado!

Fresquinho, acabei de liberar :)

http://rubyonbr.org/articles/2006/11/16/desenvolvimento-sustentvel-com-rails/

O Akita fala sobre Engenharia de Software e pontos chaves que precisam ser considerados quando se está fazendo um projeto.

Tenho duas considerações sobre o artigo:

Uma é sobre o “Iron Triangle”. Sou mais Kent Beck: ele diz que temos quatro varíaveis, e não três. A quarta segundo ele é qualidade.

Acho que qualidade não pode ser considerada nem implícita (em 100% como se presume) nem pode ser descartada como um fator independente dos outros três eixos. Toda vez que se aperta Escopo, Prazo e Custo, a Qualidade é quem sofre, e isso é regra na nossa área: apertar tudo e entregar o sistema funcionando “meia boca” porque o cara que vendeu prometeu para o cliente que ele ficaria pronto pra hoje… frase típica: “Depois a gente arruma os bugs”.

Outro ponto que levanto é sobre “Controle”.

Os pontos que o Akita levantou são essenciais, como versionamento. No entanto, “controle” é uma palavra perigosíssima. Avidez por controle gera montes de burrocracia inútil.

Um exemplo: um relatório de code review detalhado para o gerente ver. O gerente não mexe em código e não é capaz tomar nenhuma ação sobre eles exceto: “Vocês implementaram as sugestões do review”? No máximo, um relatório listando onde as mudanças devem ser feitas e se vai tomar muito tempo ou não.

Assuma que o projeto não é um boi que você toma pelo cabresto, você não pode colocar a mão no meio do projeto e virar para onde quer, não importa quanto controle você (acha) que tenha. O que você precisa é de informação para poder detectar problemas o mais rapidamente possível e tomar decisões para corrigir o curso do projeto. Afinal, todo o problema que acontece é uma pequena perda de controle. (Me lembra algum lugar que li: “caminhar é, basicamente, uma série de pequenas quedas controladas”)

A conclusão do pensamento é que você não precisa saber de tudo e nem pode controlar tudo, você precisa saber da informação essencial o mais rapidamente possível. O resto é ruído.

Mas isso é apenas e puramente minha opinão pessoal, baseada em um tempo usando XP e observação de muita coisa nonsense ao redor.

Oi Ronie, você tem toda razão. Na realidade, o triângulo completo tem Qualidade no seu centro. Este artigo The Broken Iron Triangle Software Development Anti-Pattern deve ajudar a explicar melhor as restrições de um projeto.

Quanto ao “controle”, de fato, a palavra é perigosa, mas no fundo é o que precisamos ter. Infelizmente não podemos montar uma equipe, entregar-lhes um escopo e esperar que eles cheguem ao final do prazo com o produto pronto, dentro do custo e qualidade esperados.

Mesmo em metodologias Agile, por exemplo, definimos um Sprint de quinze dias. Então planejamos o que cada um fará dentro desse Sprint. Ao final dele precisamos “saber” o que foi cumprido, o que deu errado e porque para planejar o próximo Sprint. Se houve alguma grande discrepância, uma pendência do cliente, uma mudança de requerimentos, precisamos “gerenciar” esse problema, por exemplo documentando uma “Change Request” formal ao cliente.

A conclusão é que precisamos de “controle”, mas controle não deve ser traduzido diretamente para “burocracia”. Preencher um timesheet com hora e minuto de entrada e saída de cada um e depois fazer relatórios para discutí-los é um tipo de micro-gerenciamento que normalmente não leva a lugar algum.

Num teórico mundo ideal teríamos tempo indefinido, custo indefinido e escopo indefinido. Poderíamos consumir quantos recursos fossem necessários. Na realidade projetos sem restrições normalmente não acabam. Já vi vários projetos sem restrições que caíram no caminho ilógico onde a maioria das pessoas ficavam acomodadas, justamente pela falta de restrições. Sem metas não se chega a resultados. Controle na realidade se resume ao ato de gerenciar: definir metas e controlar resultados, realizando mudanças controladas quando necessário.

Gerenciamento de Projetos é um assunto bastante extenso, com uma instituição inteira dedicada apenas ao estudo de projetos, programas e portfolios (PMI). Para quem estiver interessado nesses conceitos, sugiro ler o bom e velho Harold Kerzner

[]’s

No artigo que linkei tem um trecho que deve ajudar a compreender o sentido do triângulo:

Reconheça que o triângulo deve ser respeitado (o completo, com qualidade no centro). O Iron Triangle se refere ao conceito que, dos três fatores críticos – escopo, custo e tempo – pelo menos um deve variar, caso contrário a qualidade do trabalho sofrerá. Ninguém quer um sistema de baixa qualidade, senão, porque construí-lo? Portanto a implicação é que pelo menos um desses três vértices deve poder variar. O problema é que quando você tenta definir o exato nível de qualidade, o exato custo, o exato cronograma, o exato escopo a ser entregue, você virtualmente garantirá o fracasso porque não existe espaço para o time do projeto manobrar.

Por isso é um triângulo, e não um quadrado: a flexibilidade dos vértices do triângulo resulta em maior ou menor qualidade. Esse equilíbrio deve ser garantido por gerenciamento e sempre deve haver espaço para manobrar por esses vértices durante o projeto. Ou seja, baixar o custo e diminuir o escopo, ou aumentar o tempo e aumentar o custo, mas sempre tentando manter a qualidade estável.

Não implico com controle, só acho perigoso tentar controlar tudo. Como vc mesmo apontou “micro-management” não costuma resolver problemas.

Burocracia é muito bom. Quem já viveu em um ambiente burocrático que funciona, pode atestar. Agora burocracia sem objetivo, ou com objetivo de “um dia vai usar essa informação”, só serve pra torrar as bolas. Essa eu chamo de Bu*rr*ocracia :D

Qto às restrições, realmente, são parte do processo e grande parte do esforço da Engenharia de Software é justamente pra fazer o desenvolvimento caber neles :)

Qto ao triângulo.

O que acontece na maior parte dos projetos, principalmente sobre um contrato tradicional (Escopo, Prazo e Recurso fechado), é que vc varia justamente a única coisa que pode variar, Qualidade.

E digo mais, qdo Qualidade já está destruída, a próxima coisa a variar é Prazo. Se esse estoura tb, costuma ir pro brejo o Escopo.

Recurso, por mais atrativo que seja, não é uma das variáveis mais fáceis de manipular, vide a Lei de Brook

Como não é só qualidade que é afetada, mas outras variáveis também, não consigo enxergar o triângulo disso. Fico com Kent Beck e a “máquina vitoriana” :) Faz mais sentido pra minha pobre cabecinha.

Akita, excelente artigo.
o gerenciamento é o requisito principal para o nivel 2 de maturidade quando estamos falando em busca de qualidade. Antes de prosseguir em planos de melhoria continua, é necessário compreender e respeitar todos os niveis de maturidade.
Embora esses niveis de maturidade são ownados pelo modelo CMM, eles descrevem muito bem a busca da qualidade.

Então, na casca de noz, o primeiro passo para sair do nível de ‘esforço heróico’ é o gerenciamento.

A partir desses simples gerenciamentos, como dito por vocês acima, já é possível tomar decisões e descrever parcialmente um processo de software.

uma pergunta, vocês tem usado Scrum?

se sim, pode dizer ha quanto tempo e os pros/contra?