Concrete Logo
Hamburger button

Os dez maiores erros da abordagem de fábrica de SW, parte 2

  • Blog
  • 27 de Fevereiro de 2013
Share

6) “…Você sabe qual é o problema que você tem que resolver e como vai resolve-lo, por isto podemos prescrever o processo. O processo de trabalho é rígido.”

No primeiro capítulo de The Toyota wayFujio Cho faz a seguinte abertura,

We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based on action, one can rise to the higher level of practice and knowledge.”

Colocando isso no domínio de software, processos que buscam melhoria continuada e desenvolvimento de produtos de sucesso tem que ser iterativos pois se tratam de uma jornada de aprendizado focada no cliente.

Esta jornada deve ser feita através criação de times multidisciplinares que se mantenham juntos, trabalhando num mesmo domínio e mesmo cliente e mais importante próximos ao cliente, o que leva a um aumento contínuo da fluência ágil ou seja fazer de forma cada vez mais eficiente. Criamos músculo intelectual pelo aprendizado baseado na prática.

7) Conseguimos estimar corretamente o esforço de um produto através de técnicas top down ou bottom up ou de uma regressão e interpolação linear simples (pontos de função ou UC Points).

Primeiro ponto é a discussão de comportamento passado explicando corretamente comportamento futuro, o que é neste caso especialmente não se aplica.

Segundo, a amostra não é aplicável, não existe uma série histórica válida a não ser que eu tenha o mesmo time, no mesmo ambiente de negócio e tecnologia, fazendo a mesma coisa e esta informação realimenta as métricas. Eu nos 18 anos que estou neste negócio nunca vi isto acontecer.

A criação de uma taxonomia que sirva para criar uma série (e um modelo de previsão) para descrever um fenômeno tão amplo como desenvolvimento de software, ignorando a necessidade de condições de contorno estritas é simplesmente e completamente desprovido de rigor, seja pela visão da academia ou pela visão da comunidade que faz software (“practitioners”).

Abaixo um gráfico com 800k hh de projetos de uma amostra da Concrete, tirando 200k de outliers o tratamento estatístico da amostra não mostrou nenhum modelo linear de que explicasse o dimensionamento de projeto.

amostraCS

Pior do que a inacuracidade da abordagem é a falsa sensação de previsibilidade que este tipo de abordagem dá para celebração de contratos na esfera privada e governamental.

8) Conseguimos prever o futuro, criando um gantt detalhado sobre os eventos que ocorrerão nos próximos n meses

Fazendo um paralelo é como se um gestor de fundo de investimento mandasse uma lista detalhada de todos os “Trades” que ele vai fazer nos próximos seis meses, ignorando o mercado e te garantisse o nível de retorno desta estratégia,

E VOCÊ ACREDITASSE NISSO.

9) Documentação e modelos ajuda a construir um produto digital de forma profissional

Fazendo um paralelo com projeto de construção civil, Glenn Vanderburg na sua palestra “Craft and SW Engineering” traçou o seguinte relação. O código é o projeto de arquitetura, o binário é a casa, o trabalho de baixo valor agregado e repetitivo de executar o plano é feito pelo compilador e como este trabalho é virtualmente gratuito não faz sentido fazer modelos e simulações.

Modelos só precisam ser feitos em ambientes em que a construção do produto em si é muito cara como na indústria aeronáutica e militar para que a iteração em espiral seja mais eficiente e menos custosa no início. Em SW, o código é o melhor modelo e o único que vai representar uma solução real, para aquele problema, naquele ambiente dinâmico e complexo. O SW e consequentemente o próprio produto que deve ser usado nas iterações de aprendizado.

10) Conseguimos definir corretamente o escopo, estimar o esforço, executar num prazo determinado com qualidade, isso passando a informação com sucesso entre todos os departamentos da fábrica

Se analisarmos o processo de criação do produto como uma cadeia de valor eficiente , gostaríamos que ela tivesse:

  • Integração perfeita entre os praticantes,
  • Estoque zero,
  • Transferência instantânea de informação

num fluxo perfeito de trabalho “Just in Time” onde cada participante especialista fizesse seu trabalho melhor que uma empresa só. A melhor representação disto no nosso contexto é um Time Multi Disciplinar trabalhando junto, dentro de um framework empírico qualquer de desenvolvimento de produto.

Finalmente só conseguimos controlar 2 das três variáveis, Tempo/Custo, Qualidade ou Escopo, como não podemos abrir mão de qualidade e temos que controlar custo a variável livre é o Escopo.