Estas leis são muito importantes e são para o mundo da criação do software o que as leis de Newton são para a física ou as leis de Asimov para  a robótica.  As leis de regem o desenvolvimento devem ser a base para novos trabalhos, inovações e progresso da forma como fazemos software. É preciso entender que estas leis não dependem da tecnologia utilizada e por isso são válidas em qualquer tempo.

1. Lei Fundamental Do Desenvolvimento de Software

“O tempo necessário para criar um software completo é infinito“

Esta lei é simples, mas tem consequências muito complexas. Significa que nunca você poderá alcançar o software completo. Isto pode parecer castrador, mas significa realmente que temos que aproveitar melhor o tempo e tentar não criar o software completo, mas o software “completo o suficiente”. O conceito de “suficiente” leva a considerações de necessidade, disponibilidade de recursos e outros constrangimentos. Por outro lado, deixar o tempo ser uma variável em vez de uma constante levará um resultado absurdo. Ou seja, se você tem um software suficiente você deve estipular um período para o seu desenvolvimento.Concluímos , portanto, que o prazo do desenvolvimento nunca é uma variável. É a condição de “suficiente” que é a variável. Dito de outra forma, o prazo sempre é fixo e o conjunto de funcionalidades sempre é variável.

2.Leis de Parkinson’s

“O trabalho se expande pelo tempo disponível”

Isto significa que em qualquer tarefa, projeto, atividade aquilo que houver para fazer será diluído no tempo que for estabelecido para a realização desse trabalho. Ou seja, em outras palavras dado um certo trabalho e um certo periodo de tempo, nunca a atividade será realizada no inicio do perido, deixando o final do periodo sem nada para fazer. Isto é outra forma de dizer que : o trabalho nunca estará pronto antes da data final do prazo.

Sindrome do Estudante

“O inicio do trabalho acontece no ultimo momento possível antes do final do prazo”

Isto significa que você designar alguém para uma tarefa e lhe der um prazo, a pessoa irá protelar o inicio da atividade até o ultimo momento possível. Este limite é imposto pela própria pessoa que irá realizar a tarefa. A pessoas faz isto para poder aproveitar o principio do prazo que lhe deram para fazer outras coisas. Se chama “do estudante’ por é exatamente assim que um estudantes se comporta com o estudo ou deve de casa. Sempre é feito na ultima hora. Mas sabemos que nem todos os estudantes fazem isto. Logo, o síndrome do estudante, como outros síndrome pode ser controlar através de treinamento. O síndrome do Estudantes aliado à lei de Parkinson torna um problema em um risco e um potencial desastre. A Lei de Parkinson não pode ser alterada, mas outros fatores devem ser minimizados.

3.Lei de Pareto

“80% das consequências se devem a 20% das causas”

Este principio tem várias aplicações práticas. A primeira é que 80% dos bugs resultaram de 20% do código. A segunda é que 80% do trabalho será feito por 20% da equipe.  O problema do principio é que você não sabe à partida quais 20% causarão quais 80%.  É por isto que sempre ha que vigiar por um bom design e uma boa codificação porque você sabe que irá alterar pelo menos 20% do software porque irá causar 80% dos problemas. É também por isto que é tão importante a disseminação de informação e cultura na equipe , pois se acontece alguma fatalidade com os 20% que realizaram 80% do trabalho, a empresa terá um problema muito grave, sendo possível até que não consiga acabar o software.

4. Navalha de Occam

 ”A explicação de um fenômeno deve ser baseada no minimo possível de premissas, eliminando aqueles que não fazem diferença para as predições observáveis”

A Navalha de Occam ( também conhecido como Principio de Parcimônia)  é uma ferramenta de raciocínio muito aplicada em ciências naturais. Ela pode ser aplicada no mundo do software de várias formas. Duas são realmente importantes. Durante o levantamento de requisitos aprenda o máximo possível sobre as regras de negocio. Esta fase é chamada Coleta.  Depois analise como essas regras de relacionam. Esta fase se chama Analise. Por fim, simplifique e remova as regras que não são necessárias e/ou que derivam de outras regras. Esta terceira parte é chamada Síntese.  Hoje em dia as pessoas falam muito em analise. Temos até os Analistas. Mas o que realmente é importante é a sintese. É a sintese que cria um software mais simples porque em vez de implementar 100 regras você implementa 10 que produzem o mesmo resultado. Por outro lado, ao escrever código, o código deve envolver o menor numero possível de parâmetros. Sempre que um parâmetro poder ser inferido de um conjunto de outros, esse parâmetro é desnecessário

A redação desta lei pode ser escrita então em temos mais adequados ao desenvolvimento de software :

 ”A especificação de uma regra do sistema deve ser baseada no minimo possível de premissas e parametros, eliminando aqueles que podem ser derivadas das outras.”

Esta lei é conhecida na cena de desenvolvimento pelo acrónimo KISS (Keep it simple, stupid. Particularmente eu acho acrônimo ofensivo. Realizar a síntese não é trivial e a pessoas não conseguir fazê-lo não a torna estupida. O principio KISS realmente utiliza a palavra estupido no sentido contrário. O principio KISS parte do principio que a pessoa irá se esquecer de detalhes e do por quê de certas decisões. Ou seja, assuma que você é estupido, e por isso mantenha as coisas simples. Eu acho que a Navalha de Occam é muito mais elegante, e aplicando a Navalha de Occam ao principio KISS podemo facilmente concluir que a premissa que a pessoa é estupida é irrelevante.

5. Lei de Brook

“Adicionar pessoas a um projeto não diminui o seu tempo de execução, só o aumenta”

Esta lei é bem conhecida e tem várias outras redações possíveis. A redação mais simples e conhecida de todos nós é :

“A tarefa de gestação de uma criança  demorará 9 meses. Não importa quantas mães forem designadas à tarefa”

Basicamente esta lei representa que as tarefas têm um tempo que lhes é inerente e que mesmo com todas as ferramentas do mundo e a melhor inteligencia não dá para realizá-las mais cedo que um certo limite. Por outro lado, adicionar pessoas a um projeto multiplica a rede de canais de comunicação. Se você tem 2 pessoas em uma sala, A e B,  você tem 1 canal de comunicação (A-B). Com 3 pessoas você tem 3 canais (A-B, B-C, C-A). Com 4 pessoas você tem12 canais … em geral com N pessoas você tem N*(N-1)  canais de comunicação. A cada pessoas adicionada você gera 2(N-1) canais. Para resolver estre problema as empresas tendem a usar um modelo de hirarquia como no exercito. Isto funciona se um dado grande grupo de pessoas faz a mesma atividade. No exercito quando a cavalaria ou a infantaria são mandadas “atacar” cada individuo sabe o que tem que fazer, e o que ele tem que fazer é igual ao que o outro está fazendo. Não ha instruções especiais para cada individuo. Contudo, mesmo no exercito, o grupos de operações especiais não funcionam neste modelo. O modelo usado em comandos especias é um modelo em estrela. O grupo é pequeno, e cada pessoa tem comunicação apenas com um individuo que lhe passa instruções com pormenor. Ou seja, quanto mais especifico são as instruções ao individuo, menos um modelo hierárquico é adequado. No modelo em estrela adicionar uma pessoa cria apenas 1 canal, e não 2(n-1) canais.

6. Revelação de Sturgeon

“90% de tudo é CRUD”

Esta revelação é chocante. Se você não se sentiu chocado por ela, você não entendeu direito.Lei de novo. Ah! claro, CRUD significa “Create, Retrive, Update, Delete” as 4 operações básicas em um sistema de dados. Várias implicações saem desta revelação. A primeira é que se você não tem um mecanismo de persistência robusto, fácil de usar, você está indo para um buraco negro e profundo. A outra é que, mesmo mecanismos que não parecem CRUD são de fato CRUD. Repare que a revelação não diz que 90% é cadastros  e sim que 90% é crud. Cadastros são uma parte do problema, e cadastros em si mesmos são 90% CRUD, mas a revelação é o sistema, como um todo é 90% crud.

A revelação é chamada assim porque dá base interpretativa à  Lei dos 90%, que diz :

“Os primeiro 90% do código são responsáveis pelos primeiros 90% do tempo de desenvolvimento. Os outros 10% do código, são responsáveis pelos outros 90% do tempo de desenvolvimento.”

Confuso ? Sim. Por isso que a Revelação de Sturgeon é tão importante e tão profunda. Podemos entender da seguinte forma. Se 90% de tudo é crud, então CRUD é sempre parte de 90% de tudo.Portanto, 90% do projeto é criar o CRUD em sim. Os outros10% é usar o CRUD. Mas os outros 10% são a razão de porque você precisou criar o crud em primeiro lugar, logo 10% são responsáveis pelos 90% do tempo de desenvolvimento.

A leis dos 90% lida na sua forma pura, leva a considerar que o projeto demora 180% do tempo. Claro que é uma provocação, mas a Revelação de Sturgeon torna explica realmente muitas coisas, sem provocação.

7.Lei da Ação-Reação

“Para cada ação de engenharia acontece uma ação social igual e oposta”

Esta lei é uma paráfrase da segunda lei de Newton também chamada Segunda Lei de Augustine. Esta lei explica várias coisas, mas entre elas a dificuldade que o corpo técnico tem em fazer seja o que for sem a interferência do resto das pessoas do projeto. Quem é técnico se preocupa com mecanismos, variáveis,  razões, e emoções que são irrelevantes ao software ou a criação do software. E por simples desconhecimento, qualquer ação que parte dos técnicos é vista com preocupação e descrédito o que leva a uma pressão social de a contrariar. “social” aqui não significa “da sociedade” mas “por meios sociais” em oposição a “por meios técnicos”.  É por isto que soluções brilhantes podem ser destruídas por gostos e desgostos do cliente, gerentes, diretores ,  com base em … Bom, com base em nada , realmente. Não existe nenhuma razão racional, apenas um desconforto em aceitar a ação técnica. O curioso é que nas poucas vezes que uma ação técnica consegue vencer o obstáculo da reação social, as pessoas quase sempre se surpreendem com os resultados.

 8. Lei dos Falsos Alertas

“À medida que a frequência de falsos alertas de problemas aumenta, a credibilidade de alertas subsequentes diminui”

Quando tudo o que o usuário não espera ver na tela é um bug, mesmo quando é um aviso do sistema dizendo que o usário fez algo errado (ou seja, mesmo quando é um erro previsto). Quanto todos os bugs são críticos e impeditivos, menos críticos impeditivos eles são de fato.  Esta lei representa o desconhecimento que os usuários e clientes têm do software que eles mesmos encomendaram e a tentativa estupida de manipular o fornecedor dizendo que tudo é erro e tudo é impeditivo para. Esta lei é fortemente presente em contratos de risco em que o cliente consegui colocar o fornecedor em uma posição de dívida e recompensa futura. Ou seja, tudo o que o cliente quer mudar, ele considera um erro. Isto porque o contrato considera que apenas quanto todos os erros estão resolvidos é que o software está pronto e o fornecedor irá receber seu dinheiro. Ora, isto é uma falácia (Lei fundamental do software – nunca todos os erros estarão resolvidos) . Assim o fornecedor se colocou em um situação em que perde sempre que o cliente encontra um erro. Então, tudo o que o cliente encontra é um erro para forçar o fornecedor e fazer o que se pede. O mesmo principio é usado com a prioridade. Tudo é impeditivo para que o fornecedor sinta que não irá receber o seu dinheiro se não resolver aquele problema.

Sabendo desta lei os fornecedores devem realizar bons contratos, com estipulação especifica do que significa “impeditivo”  e “erro”. Os fornecedores deve aconselhar e treinar o cliente a entender a escala. O fornecedor deve medir a razão “falsos alertas” / “todos os alertas”  e a sua frequência. Sempre conversar e mostrar estes números ao cliente explicando que isto está atrazando o projeto e causando esforço desnecessário. Claro, que medidas de minimização do problema devem ser propostas e aplicadas tais como o treinamento, a redação de manuais e o teste acompanhado.

 9. Lei de Hoare

“Dentro de cada grande problema, existe um pequeno problema lutando para aparecer”

Considerado a Lei de Pareto é sabido da probabilidade  de um grande problema pode ser originado um pequeno problema. O que a lei de Hoare no diz não isso. O que ela no diz é que depois de resolver um grande problema ou enquanto um grande problema é resolvido, pequenos problemas aparecem.  Isto leva à multiplicação dos problemas e por consequência a um aumento no esforço de corrigir o problema original.  Por outro lado, podemos interpretar que todo o grande problema é constituído de pequenos problemas.

Esta lei está diretamente relacionada com o problema da manutenção e como o design do sistema têm que ser simples de forma a que cada pequeno problema seja o mais facilmente solucionável, já que é bem provável os encontremos quando resolvemos problemas grandes.

10. Lei de Hofstadter

“Uma atividade sempre consome mais tempo do que esperado, mesmo quando você leva em consideração a Lei de Hofstadter”

Está é uma lei recursiva. A recursividade dá-lhe um ar nerd, mas realmente é necessária. Esta lei significa que você sempre irá estimar errado a duração de uma atividade e/ou ela sempre demorará mais do que esperado por si, mesmo quando você conhece esta lei, ou seja, mesmo quando você estima a mais do que a sua intuição. Aconteceu comigo quando escrevi este post. Afinal quão dificil é elencar o top 10 das leis do software. Bem, é mais dificil do que parece…

Existem muitas outras leis e corolários relacionados ao software [1][2]. Tomeis as 10 que são mais genéricas e com as quais me deparo todos os dias. Existem muitas outras especificas de tecnologias, situações, tipos de software , algumas ligadas a harware como a famosa Lei de Moore ou algumas demasiado genéricas para serem elencadas como leis de desenvolvimento como a Lei de Murphy ( “Se algo errado poder acontecer, irá”)

Em próximos posts irei discorrer sobre como estas leis se relacionam ao Scrum tentando demonstrar que porque o Scrum se aproveita destas leis, ele funciona. Também tentarei falar sobre leis mais próxima ao código e ao design que deriva destas leis mais genéricas.

A palavra “Design” refere-se à moldagem de abstrações para alcançar um objetivo prático. Podem ser abstrações de textura e cor da roupa (Fashion Designer), as abstrações de formas de objetos (Car Designer) ou até de cabelos (Hair Designer) mas podem também ser as abstrações de construções mentais como aquelas usadas em Orientação a Objetos ou em código de programação. A palavra é de difícil tradução para o português já que não distinguimos desenho no sentido de “esboço” como “desenho animado” de desenho no sentido de plano ou projeção. O inglês e o espanhol são mais ricos com duas palavras diferentes (design/drawing e deseño/dibujo). É por isto que a expressão “design pattern” é em português “padrão de projeto“. Só que “projeto” pode significa outra coisa no mundo do software e se quisermos falar de “Project patterns” a tradução seria a mesma. Isto é um problema para os linguistas, mas nos deixa com um problema também: a falta de percepção da diferença entre fazer esboços e planejar.

Comumente ouvimos falar de arquitetos de software. Um cognome popularizado por Gates nos seus últimos momentos na microsoft e popularizado no mundo java pelo conceito de separação de papeis e com a famosa certificação. E por isso todos almejam ser arquitetos. E o que faz um arquiteto de software ?

Normalmente as pessoas ou dirão que um arquiteto faz diagramas (desenhos no sentido de esboços) ou que é responsável por decisões referentes a requisitos não-funcionais como segurança e performance. Alguns dirão ainda que são lideres ou responsáveis por equipes, mas isso não é verdade já que arquitetos normalmente atual como especialistas que finda sua contribuição ao projeto migram para outro. A visão tradicional do arquiteto como alguém que faz esboços em papel daquilo que será a realidade do software é uma imagem bem presente. Ouvimos, até, falar de “software blueprints” ou “plantas de software” no sentido de desenhos imensos que estabelecem o como as coisas serão. Esta comparação entre o arquiteto civil e o arquiteto de software é muito querida a aqueles que comparam fazer software com fazer pontes e edifícios.

No lingo do software falamos de andares e nodos que podemos comparar com edifícios , se realmente quisermos, mas essas abstrações estão muito longe daquilo que os programadores fazem no dia a dia: escrever software. São abstrações importantes para transmitir ideias como distribuição e organização de responsabilidades, mas muito pouco uteis no dia a dia. Se formos usar a comparar com edifícios temos que dizer que a planta é algo bem longe do trabalho do pedreiro que dia após dia ergue o edifício.

O Designer não está preocupado com esboços e bonecos em papel, está procurando uma harmonia entre as partes constituintes os materiais que tem à disposição e o objetivo ultimo do objeto que está desenhando. Está preocupado com um sentido estético que não apenas agradável à visão, mas principalmente à capacidade humana de entender o abstrato, as relações, e se maravilhar pela simplicidade de uma boa ideia. O objetivo do designer é que menos adições levem a mais efeitos. Em software isso significa menos código, menos classes, menos conceitos, levem aos mesmos resultados , ou a melhores resultados.

Da minha experiência projetos precisam de designers, pessoas que têm na cabeça como o software foi, é e será e como chegar lá. Arquitetos são apenas as pessoas de demonstram aos leigos como chegar lá, e programadores são quem chega lá. Sem designers na equipe os programadores não sabem que padrões seguir ou que código escrever, nem que objetivo estão tentando alcançar porque não ha um desenho, no sentido de ‘não ha um plano”. Por outro lado, muitos designers na mesma equipe pode ser problemático. Seria como dois pintores pintando o mesmo quadro ou dois escultores esculpindo a mesma pedra. Funciona se eles estiverem em sincronismo, mas se não, é um desastre.

Hoje se inventou o papel de Lider Tecnico e ha algumas coisas que esta pessoa deve alcançar, e muitas delas são as mesmas das que um Designer teria que alcançar, como derivar em termos tecnicos o significa dos requisitos e assegurar uma visão técnica clara do projeto , mas um Designer não tem atribuições de gerencia como ser responsável pelo o que a equipe é ou não capaz de fazer. Lider Tecnico é apenas uma expressão para “Responsável pelos resultados da equipe que sabe falar tecnikês com a equipe” e por isso é normalmente uma pessoa diferente do Gerente. No mundo ágil não ha tanto este sentido mais burucrático do termo, mas ainda fica a responsabilidade pelos resultados. Em termos ágeis o lider tecnico é responsável pelo débito tecnico da sua equipe. Ser um bom designer pode ajudar muito um lider tecnico, mas nem todo o lider tecnico precisa ser um designer. Pode, por exemplo, apenas ajudar a equipe a concretizar a visão do designer. Afinal estes são todos papeis, de que estamos falando, e não de pessoas. Portanto os papeis podem ser acumulados ou não.

Se um Arquiteto está para o modelo tradicional de fazer software e para as Fábricas de Software ( afinal só de pode produzir em massa o que está esquematizado em algum lugar) O Designer está para o modelo moderno de fazer software e para os Ateliês de Software. Talvez a analogia mais próxima seja a da fabricação de carros. Existe um fase de atelier onde o carro é desenhado, no sentido de conceptualizado e planejado. Isso é esquematizado em esboços e depois produzido em fábricas. A diferença é que em software só temos a parte da concepção porque o código que escrevemos para idealizar algo, já é o produto final e ‘produzir em massa” é apenas gravar mais CDs ou publicar para download. Algo que o mundo tradicional ainda não entendeu, já que continuam achando que fabricar software é um processo semelhante a uma linha de produção. Pobres coitados.

Bom, agora que sabe o que é um designer de software talvez queira reconsiderar se realmente você quer ser um arquiteto que fica escrevendo um monte de documentos e fazendo um monte de diagramas, ou se quer um de designer que sabe moldar o código à sua vontade. Afinal, a vantagem que o designer de software sobre os outros designers de outras áreas é que ele trabalha com material etéreo que ele mesmo pode criar, como, quando e quanto quiser. É muita liberdade criativa …

Ao contrário que podem lhe dizer, e podem lhe ensinar nas faculdades por ai, software não se faz em fábricas nem se planeja no papel. Se visiona e se molda, como um estilista que mentaliza o resultado que quer obter e molda o pano até que o resultado físico seja igual ao que ele mentalizou.

Bons desenhos.

Escopo de Projeto vs Escopo do Projeto

O escopo é o conjunto de todos os requisitos que o cliente exige que estejam contemplados no software a quando da entrega final. E aqui está o problema: o que o cliente exigiu no inicio do projeto, não é o que ele exige no final. É preciso entender que  o escopo não é aquilo que o software deve ser, o que o produto deve ser, mas sim o que o projeto irá realizar. O software pode ter muitos requisitos, tantos que pode levar levar vários anos até que todos tenham sido completados. Contudo, a realização de um software pode ser partida em vários projetos.  Olhemos de outra forma. O software tem um conjunto de requisitos a serem completados e o projeto tem um subconjunto desse conjunto. Em particular, o projeto pode conter todos os itens do conjunto original (qualquer conjunto é subconjunto de si mesmo) , mas isso não é uma obrigação.

Está claro que o escopo do projeto é o conjunto de requisitos que serão realizados no âmbito (no escopo) do projeto, enquanto simultaneamente existe um conjunto maior de requisitos que compõem o escopo do produto que estamos construindo.

Quando o cliente lhe paga para você realizar um projeto de construção de software, ele lhe paga para realizar o escopo do projeto, não o escopo do produto. Se é por isso que ele lhe paga, como você cobra ? Escreva a sua forma num pedaço de papel que já voltamos a ela.

Insumos

Se você constrói algo, você sempre tem algum tipo de insumo que é usado nessa construção: matéria prima. A matéria prima de um software são idéias, transformadas em requisitos (frases imperativas) e é sensato cobrar pela inclusão dessa matéria prima no produto. Não apenas o trabalho que a colocar lá, mas o trabalho da obter e usar.  Matéria prima de melhor qualidade promove produtos de melhor qualidade, e matéria prima ruim promove um produto final ruim, não importa quanto esforço você coloque.

Quando uma noiva escolhe o tecido do seu vestido e entrega  a uma costureira para o realizar , a matéria prima é provida pelo cliente. Isso não significa que seja possivel realizar um vestido de noiva com aquele tecido. Isso apenas é possível se a noiva teve a sensatez de escolhe  um tecido adequado (vestidos de noiva de lã ? … talvez no frio… ). Da mesma forma, ao realizar um software a matéria prima é entregue pelo cliente. É ele que conhece os requisitos. Mas da mesma forma que o tecido, podem não se apropriados aos objetivos finais. A arte de adequar os requisitos aos objetivos finais é chamada “Analise”. Uma das ferramentas da analise é o Levantamento de Requisitos (também chamado Analise de Requisitos, embora esse nome não seja cronologicamente adequado pois a analise real acontece depois do levantamento). A Analise é um passo comum a todas as profissões que começam com a recepção de materia prima de outrém. Ha que avaliar a conformidade do que é recebido.

Para conseguir avaliar o quão adequado um requisito é com os objetivos finais é necessário, primeiro, conhecer os objetivos finais. Eles são como axiomas que guiam tudo o resto. Em software esses objetivos (goal em inglês) são mapeados logo no inicio durante a vida do produto. Repare que estamos falando na vida do produto ainda, não na do projeto. A Concepção (Inception em inglês) é a fase do ciclo do produto onde os objetivos são encontrados com base em um objetivo maior que é a causa da realização do software. Este objetivo maior é chamado Visão e os objetivos do produto conspiram para que esta visão seja possível.  O famoso Documento de Visão descreve a Visão (objetivo ultimo) e os Objetivos (goals) do produto. Do produto.

Da posse do Documento de Visão (que pode ser um papel de pão , embora seja simpático que não seja) e da lista de requisitos para o Produto (Escopo do Produto), será feita uma triagem para agrupar os requisitos de forma a poder realizar um ou mais projetos que os realizarão, alcançando assim os objetivos, e por consequência a Visão.

Aqui podemos ter várias opções. Podemos realizar um único projeto , vários projetos ou um projeto com múltiplos sub-projetos. A decisão que realmente importa é concluir quantas entregas queremos/precisamos para finalizar todo o Escopo do Produto.  Talvez se tivermos uma versão mais simples que possamos vender ou demonstrar no ajude a angariar fundos para as próximas. Existem decisões estratégicas, comerciais e de mercado envolvidas na decisão de como dividir o Escopo de Produto para formar um ou vários Escopo de Projeto, que poderemos então realizar.

Dado um Escopo de Projeto, depois de consciensiosamente analisado teremos que pensar em constrangimentos temporais, ou outros, que nos obrigarão a fazer ainda mais divisões. Esta decisão do escopo do Projeto, acontece no âmbito do Projeto  e é utilizada para mitigar determinadas dimensões do projeto ( como custo, ou risco) e/ou para otimizar outras ( como prazo ou retorno de investimento). Estas divisões são chamadas Release (não ha uma boa palavra portuguesa para isto, talvez a mais próxima seja Publicação?). Os requisitos que serão completados no âmbito do Release formam o Escopo de Release. A união de todos os Escopos de Release formam o Escopo de Projeto. É claro que pode ser decidido que o projeto terá apenas um Release, mas isso é um caso particular e previsto no mesmo modelo.

Portanto, uma empresa que constrói software demanda Requisitos como insumo. Faz Analise para validar ou melhorar esses Requisitos. Forma o Escopo do Produto  com esses requisitos. Ajuda o Cliente a separar o Escopo do Produto em um ou vários Escopos de Projeto e finalmente em um ou vários Escopos de Release.  Esta empresa irá cobrar pelo trabalho que realizar o Escopo de Projeto, num certo Prazo, por um certo Preço, com uma ditada Qualidade, dentro de uma margem de Risco, para conseguir obter o Beneficio (Valor) descrito pelos Objetivos e pela Visão.

Cobrando pelo Trabalho

Voltamos então ao como cobrar o trabalho. Estamos pensando que o Preço deve incluir o Custo e o Lucro ( num modelo simplista). O que me custa dinheiro ? Os meus insumos:

• As instalações da equipe (incluido equipamentos, cafezinho, faxineira, tudo o que proporciona o ambiente, inclusive a energia gasta e despesas de comunicação e transporte) .
• A velocidade. O quão depressa o escopo tem que ser convertido em funcionalidade. Veja que para que o escopo seja feito mais depressa isso é mais caro do que ser feito devagar (andar de avião é mais caro que andar de carroça, não apenas pelo veiculo, mas pela economia de tempo). E este fator não tem que ver com o item anterior e sim com a habilidade das pessoas envolvidas e o numero de imprevistos e impedimentos que possam ocorrer
• A equipe. Os salários e prémios das pessoas que realizarão o trabalho.

O custo , C, é portanto composto do custo das instalações, I, que depende linearmento do tempo ( para simplificar), do “preço da equipe” W que também depende linearmente do tempo, mas que depende também da habilidade H do seus membros ( seniors são mais caros que juniors)  e da velocidade V, que também depende da habilidade dos membros da equipe H, da frequencia r, e tamanho dos imprevistos e impedimentos , M.

C = I(t) + W(t, H) + V(H, r ,M)

Todos temos uma noção que um escopo maior (com a mesma equipe) demora mais que um escopo menor. Portanto o tamanho do escopo é um fator essencial do custo. O tempo que demora a realizar o escopo (t) é proporcional ao tamanho do escopo (E) e à velocidade em que podemos converter os requisitos do escopo em funcionalidades do software. Velocidade maior significa menor tempo.

t = E / V

O que nos dá o resultado:

C = I(E,  V) + W(E, V, H) + V(H, r ,M) = >

C = f ( E , H , r , M )

Olhe a sua anotação que fez no inicio e verifique onde o tamanho do escopo entra na sua forma de calcular o custo.
Veja que o custo depende apenas do Escopo,  da Habilidade da equipa, da freqüência de impedimentos e do tamanho dos impedimentos.

Se você é como a maioria você inclui o tamanho do escopo através de chutes que você obtém comparando com projetos anteriores ou simplesmente usando um modelo qualquer de ajustes. Ou seja, algo robotico, matemático e sem sequer ter olhado o que é o escopo realmente : quais são os requisitos; e qual é  sua equipa, então não está olhando para o que interessa.

O Tamanho do Escopo

É portanto claro que necessitamos quantificar o Tamanho do Escopo do Projeto para poderemos comparar o escopo do projeto A com o do projeto B de forma objetiva : comparando números.

O que acontece, então, quando o cliente fixa um Prazo ? Ele está, básicamente, definindo o seu tempo máximo (tmax) para um certo valor P. Isto significa que ele está lhe dando um certo Escopo de Projeto, E para ser cumprindo em um certo Prazo, P

P = E / V =>  V = E/ P

Ou seja, ele está definindo a sua velocidade mínima.  O que acontece se o escopo aumenta e o prazo continua igual ? A velocidade tem que aumentar. Isto, significaria automáticamente que a habilidade da equipa tem que aumentar ou a frequencia e/ou tamanho dos impedimentos tem que diminuir. E isso custa dinheiro. De fato um projeto de prazo fixo é mais caro que um de prazo aberto. Isto porque temos que contar com uma equipe mais capacitada ( individualmente e como equipe) e controlar riscos muito melhor ( para mitigar r e M )

O tamanho do Escopo do Projeto é essencial para planejar a execução do projeto, e esse tamanho tem que ser medido nas mesmas condições que a habilidade da equipe. É por isso que vários autores recomendam que seja a equipe que vai realizar o trabalho a estimar o tamanho do escopo. Assim o “fator de habilidade” está incluso no tamanho do escopo ( oque a equipa estima) e na velocidade( o que ela realiza de fato) , exatamente como a formula acima mostra que seria necessário.

A forma atualmente de maior sucesso para alcançar este objetivo de quantificar o escopo é o uso de uma escala de tamanhos relativos (Story Points) e Planning Poker (Poker de Planejamento) onde a equipe estima o tamanho usando a escala fixa, pré-determinada, o conhecimento nas suas habilidades e o esclarecimento dos requisitos que compõem o Escopo do Projeto, ou o Escopo do Release (quando o projeto é dividido em vários releases).

Contrato de Custo-Alvo (Target-Cost Contract)

Um modelo de contrato de custo-alvo muito interessante que faz uso das relações anteriores.  Neste modelo, após definido o Escopo do Projeto ele é estimado e se chega num Tamanho Inicial do Escopo do Projeto. Este tamanho é dado como imutável.

O Contratado de posse da velocidade por iteração da sua equipe , calcula o numero de  iterações necessário para executar esse escopo.    Por exemplo, em agile, usando sprints como iteração  o contratado indicaria quantos Sprints são necessários.  Num projeto tradicional é o numero de entregas intermediárias.  O tempo não é realmente importante já que estará ligado à determinação da iteração. O que é importante é que no fim de cada interação haja uma entrega que funcione de fato. O contratado fixa um custo por iteração e traduz esse numero  interações num valor de custo. Esse é o Custo-Alvo.

As partes acordam também um numero máximo de iterações para o projeto.

O contratante obriga-se a fazer o pagamento de um valor inicial  igual a metade do custo-alvo mais uma parcela a cada iteração conforme metade do custo por iteração. O Contratante é livre de terminar o projeto no fim de qualquer iteração. O contratante obriga-se a pagar as iterações até ao numero de iterações previsto ou até que o escopo seja completado ( o que acontecer primeiro).

O que acontece com este contrato é muito interessante. Se o contratado ( a empresa de software) pensou direito e apresentou um custo-alvo com alguma margem de lucro, então é porque espera terminar antes do numero previsto de iterações. Se isso acontece ela ganha metade do valor do custo multiplicado pelo numero de iterações que sobraram pois já foi pago com antecedência. O mesmo se o cliente desiste do projeto e nesse caso o valor restante serve de “multa”. É claro que o cliente não vai parar antes, mas como o tamanho do escopo é finito  o projeto acaba quando o escopo acabar não deixando que o cliente force o uso de todas as iterações previstas.

Se algo correr errado ou a empresa de software for “preguiçosa” e o projeto for além das iterações previstas no contratado o prejuizo é da empresa de software, mas só até ao limite das iterações máximas previstas. A partir dai o projeto é extinto ou foi completado. De qualquer forma existe um software funcionando com um conjunto substancial de funcionalidades, e todos ganham.

Repare-se que este contrato fixa o tamanho do escopo, e não o escopo em si. Ou seja, os requisitos podem mudar, ir e vir, desde que o tamanho total não seja alterado.  A adição de novas funcionalidades obviamente irá aumentar o tamanho do escopo, e por conseqüência alterar o contrato que terá que ser recalculado ( na realidade será calculado o custo extra em numero de iterações extra). O que é simples e deixa claro as alterações de escopo evitando o aumento “invisivel” do tamanho do escopo sem o aumento do custo que vemos em outros tipos de contratos. Portanto, embora parece inflexivel, este tipo de contrato é mais flexivel que o tradicional contrato de escopo fixo + preço-fixo, pois prmite alterar o que o cliente vai querer no software desde que isso não interfira no tamanho.

É preciso dizer que este tipo de contrato não é desenhado para ser usado apenas com disciplinas ageis com scrum ou XP. Ele pode ser usado em qualquer modelo que seja iterativo e que estime o tamanho do escopo do projeto numericamente.  Ou seja, sempre que você saiba o tamanho do problema …

O fracasso dos processos stage-gate usados nas outras engenharias é hoje óbvio a qualquer um que tenha tido o mínimo de interesses para ler sobre o assunto ou a hombridade para olhar os resultados dos projetos em que participou nestas últimos décadas. O conceito de que projetos grandes e complexos de software podem ser tratados da mesma forma que projetos de engenharia civil ou aeronáutica ainda assombra muitos projetos hoje em dia, mas uma nova geração de desenvolvedores está entendendo que esse não é o caminho da força. O caminho da força é exatamente a disciplina e o rigor mental de um conjunto de pessoas trabalhando para e por um mesmo propósito. Os desenvolvedores finalmente entendem que sem conversar com o cliente nada acontece, ou pior, más coisas acontecem muito freqüentemente.  Conversar é a chave para um bom software.

Mas ainda existem alguns achando que tudo isto é magia e jogo de espelhos e fumaça… Entre estes existem os que enfim são incapazes de raciocinar fora da caixinha onde vivem, mas existem bastantes que ainda pensam assim por falta de lhes ser mostrado um melhor caminho, ou por descrédito de já terem ouvido esta historia antes ou terem experimentado e falhado. Esta atitude é a mesma da pessoa que pensa que se o homem da TV engole facas, ela também pode. E ao tentar, e se cortar toda, acha que o homem da TV é uma fraude, um engano e uma estupidez. O fato é que é a esta pessoa falta a destreza para entender que para chegar naquele nivel é preciso treino, esforço, compreensão dos perigos e sobre tudo : profissionalismo e dedicação.

Como saberão as disciplinas metodológicas com Lean, Kanban, Scrum, XP e outros da linha ágil, propõem o seguimento de um conjunto de práticas. Algumas ainda propoem conjuntos de regras, cerimónias, mecanismo de temporização e papeis que as pessoas devem desempenhar. Isto é o equivalente, nas artes marciais ao ensinamento dos golpes fisicos. Como, onde e quando colocar o braço, as pernas, a cabeça, etc…  como usar a espada, a vara, a faca, etc … Mas os golpes não são a razão da arte marcial, são apenas a parte observável. Aquilo que é a essência das artes marciais está no porquê daqueles movimentos.  Da mesma forma, a essência das disciplinas metodologias está no porquê das mecanicas, regras, papeis e cerimónias. Em ultima análise existe uma filosofia que guia o desenvolvimento e uso destas coisas observáveis.  Se você é um curioso destas coisas, provavelmente já notou que a maior parte das práticas já existia antes da era ágil. O murro também existia antes das artes marciais. Isso não as torna menores. A vantagem não está no murro, mas no como, quando, onde e por quê usá-lo. O mesmo para as práticas.

A existência de uma filosofia que premeira todas as práticas de um disciplina metodológica é a grande diferença para os processos clássicos (eu disse clássicos, não disse tradicionais) baseados no stage-gate como o Unified Process e seus derivados. Estes processos se baseiam em metáforas e analogias entre o mundo do software e outros mundos, especialmente os das engenharias civil e aeronáutica. Repare que não há uma filosofia ou disciplina inerente a estas engenharias. Basicamente existe uma matemática e uma ordem de dependência e precedência entras atividades. Nada mais. O fato de que a casa se constrói de baixo para cima,  é porque simplesmente as fundações são feitas no chão, não no ar. E todo o resto vai em cima disso. É simples. É sempre assim, e é simplesmente óbvio. Não há uma disciplina envolvida, porque simplesmente não ha escolhas a serem feitas.

As disciplinas metodológicas foram criadas a partir do conceito de que construir software  é uma atividade complexa. Mais complexa que engenharia civil e aeronautica e que por isso, é necessário que siga outro tipo de princípios e regras. Mas quais regras ? Ninguém sabe. Esta que é a mudança de paradigma que é dificil explicar e demonstrar para alguém que não entende que estamos falando de disciplinas e não de um bando de regras. Isto não é um jogo onde cada um aplica as regras que mais gosta. Tente fazer isso com uma arte marcial e sairá machucado.  Ninguém são, é louco, para fazer isso. Então, porque as pessoas insistem em pensar que podemos escolher um conjunto de mecanismos, ou regras, ou cerimônias das disciplinas ágeis e simplesmente criar nosso próprio processo.  Atente, com atenção, às palavras da ultima frase. As pessoas querem escolher regras para criar seu próprio processo. É só isso que um processo é: um conjunto de regras. E quem pensa assim ainda não entendeu que os processos não funcionam. Não no mundo da construção de software.  O Mundo está indo para as disciplinas metodologicas e deixando para trás o conceito de processo de produção, mas estas pessoas insistem em querer criar um processo usando as “melhores regras” que estas metodologias usam. É como querer criar uma arte marcial usando os melhores golpes das artes marciais. É possível ? É. Mas um conjunto de golpes é uma arte marcial ? Não. É apenas marcial, não uma arte. Falta personalidade, falta alma, moral, disciplina.  Falta o por quê, a razão. E principalmente falta o Objetivo.

Porque não podemos usar um quadro kanban junto com um daily meating e não usar Scrum  ? Porque não funciona. Não está a disciplina. O daily meating é vazio sem a responsabilidade partilhada que o Scrum procura. Não ha razão para conversar, em conjunto, sobre as atividades de todos, se não ha unidade.  Porque não podemos usar planning poker num projeto waterfall ? Porque o planning poker não é um jogo de numeros, é um processo de aprendizando, dialogo e acordo. Este processo visa criar a unidade em vez da impor. Visa procurar a visão do projeto como um todo e um acordo de como o executar. A disciplina está em chegar nessa unidade através da prática, da mesma forma que a arte marcial procura a clareza da mente através do movimento físico.  Para muitos um sprint é uma unidade de tempo. Ela é uma unidade de tempo, também, mas é principalmente uma unidade de foco. É um tempo onde o desenvolvedor pode desenvolver o que estava acordado, sem interrupções ou alterações do acordo. É um período importante para criar e fortalecer a responsabilidade do desenvolvedor e o respeito dos outros para com ele. Num processo tradicional pede-se que o desenvolvedor faça algo, mas nunca se respeita o pedido inicial ou o tempo que o desenvolvedor tem que ter de paz, para realmente desenvolver. Então do que serve ter um cronometro ? Só para apressar ? ( a tradução de sprint poderia ser “apressar até à meta”).  Não. “Estamos nos sprint” é a forma educada de dizer “Estamos trabalhando. Deixe-me em paz!” Mover papeizinhos num quadro branco não é kanban, nem scrum. É apenas um quadro branco com papeis em diferentes posições. Significam algo? Claro que sim. Significam o que você quiser. As cartas do tarot também significam algo quando estão em certas posições da mesa , mas e daí ? Isso basta ? Não.  O quadro branco com os papeis não é para dar visibilidade. É para dar visibilidade, também, mas principalmente é para encontrar problemas e com isso melhorar o processo. Ah! melhorar o processo.. então o processo não é fixo ? Não. O processo não é fixo. As práticas não são fixas, as regras não são fixas, a filosofia é que é. A disciplina, os objetivos. Não o caminho. O que as disciplinas metodológicas nos dão é uma filosofia e um conjunto de regras iniciais do processo, e um mecanismo para melhorar esse processo continuamente, dependendo dos intrevenientes! É um processo adaptativo por natureza.  As regras inicias são iguais para todos, mas onde cada um vai chegar é totalmente obra de melhoria continua. Exatamente como um praticante de uma arte marcial.

Então por quê não podemos simplesmente pegar uma coleção de práticas, colocá-las no mesmo saco, baralhar, e cria nosso próprio processo ? Porque estaremos apenas criando um processo, não uma filosofia. Não uma disciplina.  Uma disciplina implica que haja coerência entre as práticas, que elas se complementem e fortaleçam umas às outras e para isso é preciso um conjunto de principio maiores que as práticas em si mesmas, e isso só podemos alcançar através de uma disciplina completa.

Finalmente, queria deixar uma palavra para quem acha que pode começar a usar uma disciplina metodologia, como Scrum, ou XP, por exemplo, sem se comprometer com ela. Sem se empenhar, e sem a seguir completamente. Se você é um dos que pensa que pode começar a usar estas disciplinas “por partes”, pense no desastre que seria tentar partir um bloco de cimento com os dedos sem o devido preparo físico e mental da disciplina marcial completa. Muitos podem emitar os movimentos que veêm um mestre de artes marciais executar, mas imitar os movimentos não é praticar a arte. A arte está em entender os movimentos. Da mesma forma, a boa forma de base software está em entender os principios por detrás das disciplinas metodologia e não em imitar os movimentos das suas práticas. Ninguém aprende a partir uma pedra com as mãos por tentativa e erro. É feito com treino. E treino é algo diferente de tentativa e erro.

Para entender as disciplinas é requerido estudo. E sem estudo, tentar praticar é um insulto. É como um cara que aprendeu a imitar meia-dúzia de golpes dos filmes querer se denominar mestre de artes marciais. Não é apenas um insulto aos verdadeiros praticantes da arte, mas ao Mundo, por querer que acreditemos nesse embuste.

Se você gosta das disciplinas metodológias modernas, se realmente vê vantagens nelas, e sente que ha algum mérito nelas, antes de mais as estude. Tente entender a filosofia primeiro, para depois começar a exercitar as práticas.

Fiz questão de fazer um curso não programático na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu estágio em física. Afinal a física prática passa pelo processamento de sinal, e este passa por usar computadores.  Com o passar do tempo as práticas que observava na realidade não batiam com o que os livros diziam e o insucesso de vários projetos me fez entender que para entrar no mundo do software antes de saber programar é preciso saber escolher entre filosofias de desenvolvimento.  O Rational UP da  Rational Rose, depois IBM no tempo do CASE lançou o mote. A ideia era ter ferramentas onde especificar o software, apertar um botão e simplesmente teriamos um software funcionando. Não resulta. Ferramentas ainda são burras e precisam de alguém que as saiba usar.  Alguém muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pacóvios com esta artimanha. Repare que o engano advém de quem compra e não de quem vende. É quem compra que é muito desonesto, tapado, analfabeto ou burro para não entender a enganação.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Então por que é tão difícil fazer software? Fazer software não é dificil. O que é difícil é fazer software que alguém compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto já pronto que o produtor já criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas características (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como pão, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de alfaiataria), carros (Rolls Royce), aviões e também software. Qual é a diferença? Volume.  A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos têm o seu quinhão de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como também é chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equação é como será feito o produto. A tecnologia que será usada para realizar o produto afeta o preço, a qualidade, a durabilidade, e até o aspecto e usabilidade do produto.  Existem tecidos específicos para certos tipos de roupa e circunstâncias específicas. Existem razões técnicas de porque o mesmo casaco precisa ser de algodão em umas regiões e de lã em outras.  Se formos fazer um produto que nunca ninguém fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias será diferente daquele que utiliza uma tecnologia já muito entendida e aperfeiçoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opinião – adora comparar “fazer software” com “fazer casas, carros e aviões”. Não, essas coisas não são nem de longe tão complexas. Por quê? Porque os requisitos são muito bem conhecidos e a tecnologia também. Não há surpresas – tijolo é tijolo e metal é metal. Não há mudança de ideia no último momento. Não há uma tecnologia que surgiu no último momento e tornou tudo obsoleto.  Um pouco mais semelhante seria um carro costumizado ou um avião costumizado como Air Force One. Mais próximo ainda seria um vestido de noiva. A tecnologia é muito simples e conhecida, mas os requisitos são muito voláteis. É por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos são simples – evitar a doença , mas a tecnologia tem que ser criada. E algumas , como a da AIDS não tiveram sucesso até hoje.  A vacina é um exemplo muito mais próximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. Dá-lhes uma margem maior de segurança emocional (se bem que uma plataforma de aplicação velha é um empecilho em si mesmo).  Armas de energia com o phaser do Star Trek ainda são uma ilusão, mas as armas  taser estão bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o adversário, mas a tecnologia é simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira  TARDIS , pois não apenas ela é um ser vivo que viaja no tempo e no espaço, como é maior por dentro do que por fora. Um desafio ao raciocínio humano mais fundamental, o que dizer ao raciocínio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princípio básico – “princípio zero”, poderíamos chamá-lo – é fundamental para conseguir fazer software. Isto era verdade a 50 anos atrás, e com a velocidade com a tecnologia evolui,  é muito mais verdade hoje. Não é por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma âncora que nos ajuda a diminuir a complexidade. Mas a âncora não durará por muito tempo e novas âncoras precisarão ser desenvolvidas.

Entendendo que fazer software é algo complexo, as pessoas esperam que a forma de gerenciar a produção do software tenha que ser igualmente complexa. E este é outro paradigma difícil de quebrar:  o complexo pode ser gerenciado com o simples.  O truque é mantermos os olhos nos objetivos. E são estes que têm que estar claros desde o dia um, e refinados todos os dias. Como já disse Dwight D. Eisenhower ”O plano não é nada, planejar é tudo”. Ou seja, a complexidade é tratada facilmente se o plano não for fixo e evoluir conforme as circunstâncias. Mas veja, o plano muda e é descartável, mas não os objetivos  (e se você tem algum sentido de ética, nem todos os caminhos são aceitáveis).  Algumas pessoas entendem esta frase assim: “não faça planos”. É errado. A mensagem é “Faça planos, e continue fazendo planos. Não pare de fazer  planos até chegar no objetivo”. A cada plano temos um mapa do caminho para os próximos tempos  ( horas, dias, semanas, meses, anos… não interessa), quando replanejarmos teremos um plano que vai um pouco mais à frente e assim continuamente. A mal intrepretação deste simples conceito leva a aberrações como a recusa de criar uma plataforma de aplicação coerente e coesa ou simplesmente achar que é possível levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Será que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princípios? Quero crer que não. Todos os processos clássicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e aviões (!). Este tipo de processo simplesmente não funciona quando a principal energia é a criatividade,  e é por isso que muitos de projetos de software falham.  Em qualquer outro ramo de atividade, tantos projetos falharem é inadmissível. Em software, fazemos de conta que não é verdade.

O que não é admissível é que seja possível viver construindo software sem ter um processo-base para tal.  Práticas de laboratório até temos algumas (vide práticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software.  O Processo Unificado não é bom o suficiente porque ele é muito semelhante a um processo Stage-Gate  e é corrompido muito facilmente se transformado num processo que tradiconalmente é usado em empresas produtoras de software. Um processo criado “in-house”, híbrido e muito parecido com um Frankeistein , um monstro fabricado de partes de outrém.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos – que por exemplos os alfaiates têm – que nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.

Existem diferentes tipos de produtora de software. Temos a produtora interna. Aqui estamos falando de um departamento da empresa que produz software para a empresa. Normalmente produz alguma ferramenta (ERP) ou um meio de comunicação com os clientes (site e-commerce). O produto de software criado assim visa ajudar a empresa no seu fim, mas o produto não é comercializado.  Temos depois as produtoras on demand que fazem software sob medida (tailored) e finalmente as que fazem software como um produto. Aqui distinguimos entre  as que fazer produtos de prateleira (compre e costumize você mesmo ) e os implantáveis (compre, e costumizamos para você antes de começar a usar). A primeira linha é muito comum para produtos ao consumidor geral (empresas e individuos) como sejam o Office, os sistemas operacionais, os anti-virus, e os tocadores de musica. No segundo bloco temos os produtos de ERP e produtos mais especializados que precisam ser condicionados ao ambiente da empresa onde serão utilizados.

Vou me concentrar nos casos dos produtos de software feitos sob encomenda e/ou sob media. Aqui temos um cliente que deseja um software, e uma empresa que provê o serviço de produzir esse software. Entre eles deverá existir um contrato. Ora, o objetivo deste contrato é a realização do software e para isso temos que saber o que “é o software?”. O software será um conjunto de funcionalidades que permitirá ao cliente atingir certos objetivos. Estes objetivos devem ser claros para cliente e produtor, ou todos estarão em problemas. Nem todas as funcionalidades que o produtor incluir no software ajudarão o cliente a alcançar os objetivos. O conjunto de todas essas funcionalidades é chamado: Escopo. Algumas funcionalidades ajudarão mais, e outras menos, e a unica forma de saber qual é qual é deixar o cliente experimentar o software e decidir.  Então como criamos um contrato que permita alcançar isso ?

Existem vários tipos de contrato no mercado. Conforme o tipo de contrato que as partes escolherem isso formará um vinculo entre eles.  Nem sempre as partes são conscientes do vinculo que estão formando e nem sempre elas se apercebem dos riscos que estão enfrentando.

É interessante olha um contrato de software à luz do Dilema do Prisioneiro sendo o cliente um dos presos e a empresa que provê a construção o outro. A “policia” seria o mercado em si. Se ambas as partes não cooperarem, ambas  terão prejuízo. Qualquer contrato de software que leve a uma relação diferente da cooperação irá beneficiar apenas um dos lados , e no extremo, nenhum dos dois.

Falarei dos contratos de forma geral, já que se aplicam no mercado a diferentes ramos e conforme diferentes objetivos, em seguida especificarei o que acontece quando usamos esse contrato para contratos de software.

O contrato mais comum  é conhecido como Time and Materials. Neste tipo de contrato o provedor do serviço de construção cobra um valor fixo por unidade de trabalho. Normalmente a hora-homem. Este contrato não impõe limite ao prazo nem ao escopo do que será feito e portanto lança todo o risco no colo do cliente. A vantagem do cliente é poder terminar o contrato quando quiser, mas a desvantagem é que o trabalho pode se arrastar indefinidamente. Este contrato cria um vinculo de indiferença. O provedor não ganha nada terminando o trabalho antes e o cliente fica sempre aguardando que o trabalho termine sem poder fazer nada. O escopo aberto parece dar ao cliente a possibilidade de cortar quando quiser, mas na prática o cliente sim tem um escopo mínimo que ele quer ver completo. No mundo do software este é o famoso “cobrar por hora e vamos ver onde chagamos…”. O produtor cobra por hora pelo resto da vida e o cliente que saiba o que quer.Se o cliente se engana e ha retrabalho, tanto melhor : mais horas. Se o produtor se engana, tanto melhor : mais horas para resolver o problema.  Porque o cliente não quer pagar pelos erros do provedor, este contrato causa muitos problemas e não cria uma relação de colaboração entre as partes – bem pelo contrário o cliente está submetido à boa vontade do provedor, porque ele pode simplesmente preferir realizar o trabalho de outro cliente que lhe paga mais por hora. Claro que o cliente pode sempre mudar de provedor, mas a realidade é que só o fará quando for realmente insuportável continuar com o atual e normalmente o provedor tem lábia suficiente para ludibriar o cliente.

Uma variante é estabelecer um teto para o custo total e fixar um escopo. Isto, claro,  funciona quando o escopo é realmente fixo. Caso contrário , porque o custo é fixo, o provedor irá resistir a qualquer alteração do escopo. No caso extremo irá cobrar extra por novas coisas, caso em que ele estimula o cliente a definir o escopo errado para depois poder cobrar alterações.  No final este tipo de contrato é ainda pior para o cliente. Para software isto é um desastre. Não apenas o provedor não tem qualquer incentivo para definir bem o escopo, ele tem incentivo para o definir mal.  O fato do custo ser fixo, que deveria proteger o cliente, acaba fazendo lhe ainda mais mal.  O resultado é o mesmo em um contrato do tipo Fixed Price, Fixed Scope , onde o cliente paga um preço, fixa um escopo e o projeto anda até que tudo esteja completo sem prazo para terminar. Mais uma vez o provedor se faz valer de uma cláusula de alterações que oneram o cliente cada vez que forem feitas. Conclusão, se o cliente não tem o escopo bem definido, o provedor não irá se esforçar para o definir, pois toda a alteração será cobrada à parte.

Alguns acham que isso pode ser resolvido fixando também o prazo. Isto nos leva ao contrato do tipo Fixed Everything em que prazo, escopo e preço estão fixos. Aqui os papeis se invertem e é o provedor que fica na mão do cliente. O cliente incha o escopo com tudo que imaginar e estabelece um prazo e um preço para tudo isso. O provedor ou aceita, ou não aceita. Se aceitar, porque o cliente que estipula o escopo, o cliente pode sempre adicionar mais detalhes ao escopo, realmente tornando-o maior na prática, mas não no papel e portanto impedindo o provedor de cobrar por isso.  Este tipo de contrato é comum em licitações em que o cliente já fixa previamente tudo, mas deixa margem para inchar os detalhes ou espera fazer pressão econômica depois, ameaçando não pagar o provedor se ele não incluir mais aquela “pequena alteração”. Em software, porque os escopo é inerentemente  variável,  o provedor está automaticamente em desvantagem. Muitos provedores aceitam este tipo de contrato com medo que a sua concorrência os aceite primeiro. Este é o erro que alimenta a prática dos clientes estipularem este tipo de contrato.  Sendo que este tipo de contrato é altamente arriscado para o provedor, o fato do concorrente o tomar deveria ser entendido como bom, já que o risco está agora no concorrente e não com o provedor. O provedor pode então procurar outro tipo de contrato com outros clientes que sejam mais proveitosos e no longo prazo desfalcar o concorrente pois ele está metido até ao pescoço num contrato sanguessuga. Mas por alguma razão juvenil de “tentar ganhar do outro” os provedores de software acham que é melhor ser sugados por clientes com contratos fixed everything do que deixar os seus concorrentes serem sugados.  Sobretudo quando estamos perante uma licitação e o cliente é o governo. Aqui todo o senso empresarial vai para o espaço, porque o provedor acha que trabalhar para o governo é seguro ( não vai ficar sem trabalho), mesmo quando  isso significa que o governo o levará à falência. No mundo do software  não existe razão comercial que suporte aceitar este tipo de contrato, seja com quem for a menos que você tiver um às na manga (mais sobre isso em outra oportunidade ).

Se reparou bem, até agora, todos os tipos de contrato oneram uma das partes. Não ha nenhum que estabeleça metas comuns. O resultado é que – no mundo do software – estes contratos sempre falharão. Cada tipo de contrato é bom para determinadas circunstâncias de escopo. Quanto mais conhecido e fixo o escopo, mais simples o contrato porque menor o risco.   O problema é que, em software, o escopo é sempre mutável.

A moral desta recapitulação é que não podemos usar qualquer contrato para serviços de construção de software. Muito menos nos podemos guiar por modelos de contratos utilizado em outros ramos de atividade onde o conhecimento dos requisitos é estável. Nada de usar contratos como se o software fosse uma casa, uma ponte ou um avião. Isso são coisas com requisitos muito estáveis, logo, com contratos mais simples.

Bom, resta então, desenhar um contrato que seja vantajoso para ambas as partes e seja compatível com um escopo variável. Para isso temos que entender que o escopo tem duas propriedades : tamanho e característica. A característica do escopo é aquilo que a funcionalidade é. O tamanho se relaciona ao esforço para  construí-lo .

A primeira aproximação é o tipo de contrato baseado em Time and Materials mas com escopo variável e custo fixo. Nste tipo de contrato o tamanho do escopo é fixo – e portanto o custo é fixo, mas a característica é variável. Ou seja, o escopo definido no inicio é a base para uma estimativa de tamanho. Essa estimativa de tamanho é usada para estimar custo e prazo, mas o cliente pode mudar a característica do escopo, ou seja, pode mudar as funcionalidades ou o que as funcionalidades fazem. Isso deve ser feito de forma controlada de forma que nunca ha aumento de tamanho. Em software, este tipo de contrato é muito usado na cena ágil porque o cliente pode modificar o escopo conforme o valor das funcionalidades e conforme vai conhecendo, vendo, e experimentando o software. Uma variante consiste em deixar aberta a possibilidade  do cliente terminar o projeto antes de utilizar todo o custo/tamanho planejado. Esta variante de Valor Máximo, divide o custo não utilizado pelo cliente e o provedor, oferecendo aos dois vantagem se o projeto não chegar no custo, e portanto, incentivo para a colaboração e o alcance do valor máximo o quanto antes. Acontece que este tipo de contrato é fortemente baseado na estimativa inicial o que significa que se o provedor estimou mal ele estará se beneficiando em detrimento do cliente.  Isto nos leva ao ultimo tipo de contrato.

Este tipo de contrato é muito semelhante mas adiciona um limite máximo de expansão do custo. O provedor estima o tamanho e o custo da mesma forma que antes, mas em seguida adiciona uma margem. Se tudo correr bem e o cliente der o projeto como terminado antes de atingir o custo, os ganhos são repartidos como antes, metade-metade. Se o projeto passar do custo estimado, e até chegar no limite da margem, o prejuízo é partilhado metade-metade. Se o custo passar do limite da margem o prejuízo é totalmente por conta do provedor (já que isso significaria que o provedor estimou mal e conduziu mal a construção).

O mecanismo de estimativa de tamanho não é relevante, o que é relevante é que o provedor tenha um bom conhecimento entre a relação desse tamanho com o custo. Em horas-homem, meses-homem ou pontos de estoria, tanto faz.  O que interessa é que haja uma unidade e uma forma de a converter em custo. Vejamos um exemplo utilizando uma aproximação mais comum hoje em dia, o custo por hora-homem.  O provedor estima o projeto em 1000 horas-homem a um custo de 80 reais por hora-homem equivale a um projeto de 80 mil reais. Se tudo correr bem, esse é preço certo do projeto. Consideremos então uma margem de 20 mill reais (250 horas-homem) . O projeto custará no máximo 100 mil reais.

No espírito do contrato anterior, temos que repartir ganhos e prejuizo até chegar em 100 mil. O cliente paga 40 mil à cabeça e 40 reais por hora-homem até atingir o valor máximo do projeto de 100 mil reais.  Veja que isso significa que se o projeto terminar no tamanho estimado, o preço pago será o estimado (40  mill + 40* 1000 horas-homem) e o cliente terá pago exatamente 80 mill reais. Se o projeto terminar antes, gasntando apenas , digamos 600 horas, porque o cliente estava pagando metade do preço-hora o projeto termina com vantagem dos dois lados. Se o projeto vai além do tamanho estimado, digamos 200 horas ambos terão prejuízo de 40*200  = 8 mil reais.

Este tipo de contrato não coloca as partes em competição mas sim em colaboração com objetivos concretos e vantagens concretas.  Repare que o tamanho do escopo é fixo, o que significa que o custo só aumenta por atraso na execução e nunca por aumento de escopo como nos outros contratos. Porque o cliente não pode aumentar o custo, e também terá prejuízo se o projeto atrasar ele é incentivado  a escolher funcionalidades mais valiosas e mais “simples”.

Obviamente este tipo de contrato só funciona se as partes  tem capacidade de entender o seu funcionamento e o conceito de que nem todas as funcionalidades têm o mesmo valor e por conseqüência as mais valiosas e importantes devem ser feitas primeiro e algumas delas não serão feitas.  Este tipo de contrato estimula também o provedor a ter que trabalhar de uma forma que lhe permita terminar o quanto antes e responder rapidamente a alterações nas características do escopo. O que é muito simples se a empresa segue práticas ágeis de gerência e desenvolvimento.

Finalmente é importante notar que o fato das empresas colaborarem obriga à comunicação sincera e isso leva à criação de vínculos de confiança que permitem novos projetos no futuro. Além disso o impacto psicológico de terminar antes do custo faz o provedor se diferenciar no mercado face a outros concorrentes e deixa o cliente contente o suficiente para recomendar aquele provedor a outros parceiros.

Se você é responsável por contratos de software, pense bem nisto, e tente melhorar a sua forma de se relacionar com o seu cliente. Ele não é seu patrão e nem você é o cafetão dele. Vocês são colaboradores.

No mundo real, contudo, o Product Owner tem que responder a vários stakeholders e o valor advém principalmente da expectativa e demanda que esses stakeholders têm em relação às features desenhadas nas estórias. Isto deixa o Product Owner numa posição muito subjetiva de ter que adivinhar os desejos de prioridade de todas as partes interessadas e, pior que isso, conseguir ordená-las.

O método

No seu livro “Software Requirements“, Karl Wiegers demonstra um método que poderia ajudar nesta situação. Embora o método não tenha sido desenhado para aplicar num ambiente agil,  o conceito é simples o suficiente para ser adaptado.A atratividade é uma relação entre o valor, o custo e o esforço.

O Valor

Para chegar no valor da  estoria pedimos a cada parte interessada que pontue de 1 a 9 o beneficio que aquela estoria traz, sendo 1 uma estoria com o menor beneficio e 9 com o maior beneficio. Depois pedimos que pontue de 1 a 9 a penalidade de abandonar aquela estoria, sendo 1 uma estoria que não traz penalidade abandonar ( ninguém iria sentir falta dela) e 9 uma estória que tem maior penalidade ao ser abandonada (muitas pessoas iriam reclamar).

O valor será então a soma do beneficio com a penalidade. Assim, uma estoria que tem beneficio 1 mas penalidade 9 é equivalente em valor a uma que tem beneficio 9 e penalidade 1.

Esta pontuação pode ser definida apenas pelo PO no caso em que as partes interessadas não são tão interessadas assim para as fazer responder um questionário. O PO continuará confiando no seu tato e feeling, mas pelo menos será obrigado a colocar isso numa escala. Um trabalho semelhante ao que a equipa faz para pontuar o tamanho das estorias.  No caso geral, contudo, ele elaboraria um questionário e pediria que fosse respondido pelos stakeholders. Esta é uma prática já comum na área de jogos, por exemplo, onde as features são avaliadas por questionário respondidos por potenciais jogadores antes de serem incluídas para desenvolvimento.

Este método permite ao PO atribuir ao parâmetro de valor um numero, em uma escala relativa, que está diretamente relacionada à demanda e expectativa dos stakeholders em relação à estoria.

Pode acontecer que existam poucos stakeholders com que o PO pode interagir, por limitações variadas. Neste caso o PO deve procurar por mais partes interessadas ainda que “remotamente interessadas” e atribuir pesos diferentes às opiniões dadas pelos stakeholders principais e pelos secundários.  A ideia é que o PO deve aumentar a abrangência do grupo de stakeholders de forma a ter uma melhor ideia das suas demandas e expectativas. O tamanho do grupo, os papeis que essas pessoas desempenham em relação ao produto e a forma como pesar as demandas de cada um varia conforme o produto e as próprias pessoas envolvidas. O PO deve equacionar isso quando estabelecer critérios de como será levantada a pontuação de beneficio e penalidade. No caso extremo o PO necessitará de uma equipa própria que o possa auxiliar nessas tarefas.

O Custo e o Tamanho

O custo no método descrito por Wiegers é equivalente ao conceito de Tamanho em ágil. Estamos interessados numa medida relativa do quão grande é cada estória. Então, no caso agil, o PO usará as estimativas de tamanho em pontos de estoria estimada pela equipa por métodos como o planning poker.

O Risco

O risco também é avaliado pela equipa junto com o tamanho. O risco é a probabilidade de 1 a 9 de que a estoria não vai atender à demanda dos stakholders à primeira.  O risco não está relacionado à probabilidade de completar a estoria no sprint, nem relacionado ao cone de incerteza. Este  risco do método descrito por Wiegers está relacionado  à probabilidade de, uma vez ponta, a funcionalidade incluída pela estoria não satisfaça os stakeholders interessados.

As razões para o risco são muitas. Desde de um fraco levantamento de requisitos a uma equipa inexperiente nas tecnologias necessárias passando por uma fraca usabilidade ou um aspecto gráfico “feio”.

No modelo explicado por Wiegers existe a opção deste fator ser ignorado num primeiro uso do método e integrado na medida em que descobrir que as estorias não satisfazem os stakeholders. Isso pode ser controlado pelo numero de vezes que uma mesma funcionalidade, cenário de uso, ou tecnologia usada na implementação são modificados depois de estarem pontos.

A atratividade

Baseado no valor  (calculado pela soma do beneficio com a penalidade) no tamanho e no risco , calculamos a Atractividade da estoria ( que Wiegers chama também de Prioridade,mas em agil esse nome tem outro significado). A atratividade (A)- o quanto a estória é atrativa – é calculada da seguinte forma:

Onde v é o valor da estoria, t é o tamanho da estoria e r é o risco da estoria. V é a soma de todos os valores de todas as estorias, T é a soma de todos os tamanhos e R de todos os riscos. Este conceito de “todos” pode ser aplicado ao product backlog ou ao release backlog. Estamos interessados em ter uma medida relativa. Porque as estorias no backlog mudam (entram e saiem) a atratividade irá mudar nesse momento, o que é exatamente o que seria esperado empiricamente.

Se desconsiderarmos o risco, numa primeira aproximação, a formula se transforma em :

O fator T/V será igual para todas as estorias e igual a uma constante que apenas afetará o valor numérico da Atratividade mas não o seu valor relativo. Neste caso, simples, em que removemos o fator de risco, a atratividade se resume ao quociente entre o valor e o tamanho.

Atratividade e Prioridade

A razão pela qual não podemos considerar diretamente que a atratividade é equivalente à prioridade é  que a prioridade implica num valor diferente para cada historia, coisa que a formula da atratividade não garante. Então, no fim, o PO ainda terá que desempatar algumas estorias com atratividade igual, mas pelo menos agora ele terá que fazer isso apenas em alguns casos e não em todos. A atratividade é um coeficiente que pode ajudar a guiar a decisão do PO, mas é apenas uma formula matemática que não está sujeita a pressões de stakeholders.

Adaptação

O método descrito por Wiegers usa escalas de 1 a 9 para pontuar o beneficio, a penalidade o risco. Escolher uma escala decimal é natural ao ser humano, portanto a escolha de numeros menores que 10 é muito feliz neste método. Contudo, das práticas de estatística, sabemos que escalas impares fazem com que respostas a questionários tendão para o valor central sendo sempre melhor oferecer um numero par de opções. Por estas razões poderiamos aumentar a escala até 10, diferenciando o 5 e o 6 como uma indecisão mas com peso para um dos lados.

Um outro detalhe é que o valor numérico da atractividade vai variar entre numeros menores que um ( 1/13) e maiores que 1 ( 10 /1). O que pode confundir o PO ao comparar o numero 0, 00769 com 10, por exemplo. Além de implicar em regras de arredondamento chatas. Por outro lado, como a Prioridade normalmente usa numeros bastante grandes poderiamos aplicar um fator numérico à atractividade descrita por Wiegers para ter uma escala mais “humana” apenas com números inteiros e mais próxima da escala de Prioridade. Multiplicando por 100 mil, teríamos valores mais compráveis, por exemplo 1.000.000 e 7.692 eliminando o problema do arredondamento.

A ditadura dos números

Com esta técnica não apenas ganhamos uma forma de atribuir um numero e uma escala relativa ao Valor, mas ganhamos uma forma de comparar o Valor com o Tamanho de uma forma simples, que pode atuar como uma forma rudimentar de priorização. Contudo não podemos encarar este método como uma forma à prova de falha ou que substitui o discernimento do PO. É apenas uma ferramenta auxiliar para ajudar o PO a decidir, mas de nenhuma forma pode ser considerada a resposta definitiva que dita a prioridade das estórias.

Não é porque a teoria “maistream” das metodologias ágeis ignora os problemas do dia-a-dia do Product Owner e confia no seu senso de valor que temos não podemos sugerir uma forma um pouco mais “cientifica” de fazer as coisas olhando as boas práticas das metodologias clássicas. Afinal queremos um Product Owner que tome decisões baseado em fatos, não em suposições. E definitivamente não queremos um Product God que toma controle de tudo baseado nos sues próprios interesses.

Em desenvolvimento de software existem diversos riscos associados ao projeto, mas vamos focar hoje nos riscos associados ao código.

A qualidade do código é proporcional ao quão limpo ele está. Manter a qualidade do software é a principal forma de minimizar o risco.

Em um desenvolvimento desatento presume-se que a única função do código é prover a funcionalidade requerida nos requisitos funcionais, o velho e bom “está funcionando”. Este tipo de desenvolvimento é tão comum que gerou a máxima “Primeiro faz funcionar, depois faz funcionar bem. Depois faz funcionar rápido.” Este tipo de pensamento pode funcionar no meio acadêmico quando você está descobrindo um algoritmo novo,  mas fora do mundo acadêmico esse pensamento é uma anti-regra. Ele viola o mais fundamental propósito de qualquer empresa: lucro, pois obriga à re-edição do software pelo menos 2 vezes.

Em código feito para compor produtos de software essa regra não pode ser seguida, contudo, sabemos que não é fácil acertar à primeira em um bom modelo ou em uma implementação performática. Ser capaz de alterar o software é um requisito constante, e é a essência de toda a teoria por trás de todos os paradigmas de programação (de orientado a instruções a orientado a objetos): queremos nosso código fácil de mudar. Então porque não o mudamos mais frequentemente?

A principal razão está no fato do código ter sido escrito de forma confusa e suja (não limpa). O código escrito dessa forma viola o requisito constante de ser capaz de alterar o software facilmente. A grande maioria de desenvolvedores produz código assim e não é simples treinar uma pessoa a fazer de forma diferente.

A segunda razão é a escolha de modelo falhos ou falidos. Modelos falidos são aqueles que parecem resolver o problema e são tradicionalmente passados de boca em boca como solução para certo problema, mas com o passar do tempo eles não resistem. Formas de programação que eram consideradas o topo da qualidade num paradigma, caem para anti-padrões em outro. Um exemplo simples: o modelo do Struts 1 funcionou durante um tempo, mas é hoje um modelo falido.

Modelos falhos são aqueles que resolveram o problema num certo momento mas não resistem à adição da necessidade de mais funcionalidades.  Um exemplo é a classe java.util.Date. Conseguiu resolver o problema de trabalhar com datas durante um tempo, mas o modelo era fraco para abarcar todas as necessidades do contexto de datas. É um modelo falho.

Modelos podem ser compostos de várias classes ou poucas, não é relevante. O problema acontece quando detectamos que o modelo falhou ou faliu e precisamos remodelá-lo. Quem vai querer mexer naquele código legado escrito há mais de 3 anos por um pessoa que não está mais na empresa ?

A primeira reação a esta situação é medo. Medo de alterar um código que está funcionando mas que precisa ser alterado, no todo ou em parte; de forma que mantenha as funcionalidades atuais e novas sejam adicionadas. O medo advém da falta de controle sobre o estado de funcionamento do código.

Código limpo pode ajudar a entender melhor o código que está escrito, mas não o ajuda a verificar que após uma alteração ele ainda funciona como esperado. Precisamos de algo mais eficaz, mais dinâmico. Precisamos de testes.

A escrita de testes não é um luxo, é uma necessidade inerente à produção de código. Escrever testes para o seu código é equivalente a colocar mecanismos de segurança em centrais nucleares. Não podemos apenas confiar que nunca vai acontecer nenhum problema ou que nunca precisaremos de fazer alguma manutenção.

Porque a principal preocupação da maioria dos desenvolvedores é colocar o código a funcionar mas sem criar nenhuma forma de verificar que o código continua funcionando, os mesmos desenvolvedores são depois dominados pelo medo de mudar o código que eles mesmos escreveram.

A escrita de código que verifica a consistência das funcionalidades do código de produção é uma necessidade e não uma opção. A menos é claro que você esteja disposto a gastar rios de dinheiro e tempo em alterações arriscadas, ou se o seu software for para durar 3 meses.

Como escrever esses testes e quais testes escrever?

O relacionamento entre as operações necessárias num projeto de software e as respectivas áreas de teste apresentadas pelo V-model mostra que existem vários tipos de teste conforme o objetivo e o nível de certeza que queremos ter.  Isto nos leva a 4 tipos principais de teste: Teste Unitário, Teste de Integração, Teste de Sistema e Teste de Aceitação.

A responsabilidade de cada nível não é um assunto pacífico, mas vou deixar uma ideia do que estamos falando. O Teste Unitário verifica que a unidade de codificação está em conformidade. A unidade de codificação depende do paradigma de programação usado. Em Orientação a Objetos pode ser uma classe ou um pacote de classes. O teste de integração verifica que o funcionamento de várias unidades de codificação trabalhando juntas está em conformidade. O teste de sistema, verifica que o sistema funciona em conformidade em diversos ambientes, com diversas níveis de carga, com diversos níveis e tipos de recursos (memória, CPU, banco de dados, etc..) , em diversas configurações e distribuições em rede. O teste de aceitação verifica que o sistema atende os requisitos funcionais especificados para ele.

Existem outros tipos de teste como teste de mercado que determina como os usuários reagem ao sistema, como o utilizam, com que frequência, etc. Este tipo de testes não faz parte do desenvolvimento do software e está mais ligado a como o software é aceito enquanto um produto no mercado. Este tipo de testes não são cobertos aqui, mas também eles tendem a minimizar o medo e as falhas (comerciais, neste caso).

O cenário necessário é que todos os 4 tipos de teste sejam automatizados e verificados constantemente.  Este é o conceito de Integração Continua. Embora  o nome remeta aos testes de integração, todos os 4 tipos de teste podem ser avaliados continuamente.

A correção de um defeito nos requisitos funcionais é muito mais caro que um defeito na unidade de codificação.  Por esta razão os testes de aceitação devem ser escritos primeiro para testar se o requisito realmente atende o usuário. Caso não, o requisito é abandonado antes mesmo do código que o faz funcionar ter sido escrito. No inicio a codificação necessária ao funcionamento desse requisito é simulada com valores fixo para permitir que o requisito em si mesmo seja validado. Coisas como navegação, regras de validação de dados e outros tipos de input, são também validados por estes testes. Lembrar que estes testes são automatizados e executados continuamente. Se o requisito mudar, o teste terá que mudar em conformidade.

Os desenvolvedores partem então para a escrita do código real que irá prover aquelas funcionalidades. Na medida em que esse código é escrito também os seus respectivos testes de integração e unidade são escritos. Estes testes garantem que o código funciona, e os testes de aceitação garantem que este funcionamento está em conformidade com os requisitos funcionais.

Contudo, todo o sistema conta com requisitos não funcionais que devem também ser atendidos pelo software. Para testar estes, testes de sistema são incluídos. Estes testes completam os outros três, garantindo que o código está em conformidade com os que os usuários esperam tanto do ponto de vista do objetivo do software, como do ponto de vista da usabilidade,  instalação, manutenção, atualização, etc…

Entenda-se que dado um conjunto de testes para um software é sempre possível criar mais testes que completem esse conjunto. Em teoria este crescimento não tem limite. Na prática ele tem que ser limitado pelo grau de confiança que precisamos do software. Algumas métricas como a cobertura (número de linhas de código executadas durante os testes)  podem ajudar a definir esses graus de confiança, ou testes específicos podem ser desenhados para medir esse grau.

A raiz de todos os medos, que os desenvolvedores sentem face a um código que não escreveram, ou que não lembram que escreveram, é a falta de mecanismos automáticos de verificação da continuidade da consistência da funcionalidades.

A adição de testes automatizados é uma necessidade do desenvolvimento de software, é um “osso do ofício” e não uma opção, embora possamos argumentar que a profundidade e tipo dos testes está relacionada a variáveis como o tempo espectável para a vida do software, a facilidade em atualizar o código depois de instalado (impossível num software que controla uma sonda espacial, por exemplo) e o nível de risco associado à falha do software (elevado em software de que depende a vida de alguém). Estas variáveis alteram o pormenor associado à escrita e detalhe dos testes e não o fato deles serem necessários.

Agora pense: quão apavorado você fica ao mexer no código do seu projeto atual?

A Plataforma de Aplicação é a Plataforma mais próxima à aplicação que fica em cima da Plataforma Virtual. Você deve dar uma olhada no cubo arquitetural e no conceito de plataforma antes de prosseguir.

A Plataforma Virtual é ocupada pela Plataforma Java ( ou .NET, ou outra similar). A Plataforma provê tipos de dados comuns à vasta maioria de aplicações que podemos querer desenvolver mas quase nunca fornece tipos úteis para o domínio de negócio da aplicação.

A Plataforma de Aplicação fornece os tipos e mecanismos úteis à aplicação em si mesma ou a um conjunto de aplicações no mesmo contexto, por exemplo, a uma familia de produtos.

A Plataforma de Aplicação sempre está presente em todos os projetos. Ela é conhecida como “a infra” ou “o framework que fizemos para …“, ou “a arquitetura“,  ou “as classes de base“, ou outros nomes semelhantes. Repare que o uso destes nomes e expressões já é um indicativo da falta de conhecimento e respeito, em geral, pela Plataforma de Aplicação.

A Plataforma de Aplicação não inclui as entidades nem as classes de domínio onde estão as regras especificas do funcionamento do software como serviços ou repositórios. Contudo ela é a base para a construção dessas classes. Ela fornece formas de ORM , I/O, decisões baseadas em ambientes, componentes UI, entre outras coisas.

Normalmente os desenvolvedores utilizam um conjunto de bibliotecas de terceiros para “facilitar” a criação da aplicação. Frameworks como o Hibernate, o Spring e o Stuts são comuns hoje em dia, além do onipresente Commons-Upload em aplicações web e o Swing em aplicações desktop. O “encaixe” destes frameworks forma, para a maioria dos projetos a sua Plataforma de Aplicação, mas a maioria dos desenvolvedores não vê que está decidindo como será a plataforma de aplicação.

A plataforma de aplicação é responsável pela evolução do software enquanto peça de tecnologia e pela maioria dos requisitos não-funcionais, enquanto a aplicação em si, é responsável pelos requisitos funcionais. Contudo, quando mal desenhada é a responsável pela obsolescência tecnológica da aplicação e pelo impedimento na evolução da aplicação.

O problema de definir uma plataforma de aplicação é garantir que ela poderá evoluir no tempo de forma independente da aplicação ao mesmo tempo que a aplicação evoluir independente da plataforma. Se a plataforma e a aplicação evoluem ao mesmo tempo ou com dependências isso significa que não existe realmente uma plataforma de aplicação, ou ela é fina demais, e a aplicação como um todos depende diretamente da Plataforma Virtual.

Muita gente não entende porque Java tem tantos frameworks, sendo a grande maioria para a “mesma coisa”. A razão para isso é que a Plataforma Java sempre se posicionou como uma plataforma virtual, ou seja, espera-se que o desenvolvedor crie uma plataforma de aplicação em cima dela e não saia programando diretamente sobre a plataforma virtual ( o Java “puro”). Mas poucos fazem isso, a maioria porque não sabe que deveria fazer isso e o resto porque acha que não tem tempo para isso.

O problema é mais evidente em Java para desktop onde existem menos frameworks de terceiros. O programador tende a cair na tentação de utilizar o Swing diretamente, por exemplo sem prensar que isso significa amarrar as capacidade da aplicação às capacidades “puras” do swing. Quando for necessário criar algo diferente o programador luta em procurar alguma API de terceiros, ou simplesmente modifica os requisitos para evitar problemas.

Porque o desenvolvimento com Java depende da escolha/construção de uma plataforma de aplicação ele tente a ser mais complexo e demorado que em outras tecnologias. Mas isto só acontece porque tantos os desenvolvedores quantos as empresas falham em entender que o custo do desenvolvimento da aplicação está na sua maioria no desenvolvimento da plataforma de aplicação e não na aplicação em si.

Ao ignorar a existência desta plataforma por baixo da aplicação as empresas não tiram vantagem dela deixando o custo de criar dita plataforma se multiplicar para todos os projetos da empresa. Exemplos como a Apache  Foundation  que partem sua plataforma de aplicação em pedaços independentes ( os famosos commons) são ainda raros.

Construir uma plataforma de aplicação que possa ser usada por mais do que uma aplicação não é trivial, mas nunca vai conseguir construí-la se não tentar. Errar ao construí-la é fácil e caro, portanto,  prepare-se. Mas não construí-la é mais caro ainda.

A Plataforma de Aplicação pode ser tanto um bem (asset) como um risco (liability) dependendo da sua qualidade. Entender o que significa isto requer ter desenvolvido mais de três tipos de aplicação com mais de três tipos de arquitetura e não é uma tarefa para estagiários e juniors … às vezes nem para seniors. Desenvolver uma plataforma de aplicação própria deve ser a primeira preocupação de uma produtora de  software pois é o seu centro de maior  custo e maior risco. Deixar cada equipe desenvolver sua plataforma torna o ambiente heterogêneo e impossível de migrar os benefícios de uma aplicação para outra. Obviamente, se a produtora de software utiliza mais do que uma plataforma virtual, deverá ter mais do que uma plataforma de aplicação, mas mesmo assim, muitos conceitos podem ser comuns variando apenas na implementação. Hoje em dia com linguagens que funcionam em mais do que uma plataforma virtual – como Ruby em Jruby (Java) e IronRuby (.NET) e na Ruby VM –  é possível até antever a possibilidade de desenhar uma plataforma de aplicação única para diferentes plataformas. No extremo a plataforma de aplicação pode até implicar em desenvolver uma linguagem própria que funcione em várias plataformas para eliminar mais esse fator de diferença. Obviamente o perigo de desenhar errado aumenta quando mais fundo você que ir ( até o nivel da linguagem) ou mais abrangente (diversos tipos de arquitetura e aplicação).

Criar e manter uma Plataforma de Aplicação não é simples,  não é rápido, e não é barato, mas é essencial para cortar custos.  Um modelo atual para lidar com o imenso esforço que é criar e manter uma Plataforma de Aplicação passa por oferecê-la como Open Source. Afinal, ela não contém nenhum “segredo” da sua aplicação. Ao disponibilizá-la como Open Source mais pessoas a irão usar, mais bugs serão corrigidos, mais flexível e expansível será e o custo será rateado entre todos os utilizadores. Este modelo é seguido por diferentes companhias como a Apache Foundation , já mencionada, a Eclispe Foundation e a Nokia, por exemplo.

Seja como for que você decidir seu modelo de negocio em relação à Plataforma de Aplicação, esteja pelo menos consciente da sua inexorável existência, os risco que implica e os custos que trás a cada projeto.

Em qualquer opção o(s) empresário(s) responsável(eis) pelo software precisam suportar a idéia de criar uma plataforma de aplicação e a ver como um investimento para cortar custos e não como um forno de queimar dinheiro. Contudo, têm que saber escolher as pessoas para a equipe que poderá concretizar esse projeto e ter sempre em mente que ninguém com menos de 3 a 5 projetos de experiência poderá alcançar esta meta. Ou seja, precisará de pessoas competentes e capacitadas.

Se você é free-lance, não muda muita coisa. É mantendo uma Plataforma de Aplicação que você poderá ganhar mais e produzir mais depressa. Claro que sendo sozinho é complicado manter uma, portanto, neste caso é melhor partir para a integração de framework já existentes e ir criando classes que os vão abstraindo aos poucos. Assim, a sua plataforma cresce a cada projeto e cada projeto tem menos custo que o anterior. Outra opção é aproveitar-se do Open Source da mesma forma que uma empresa normal.

Se você trabalha numa filosofia ágil entenda que é a Plataforma de Aplicação que lhe dá a velocidade na implementação. Sendo que ela é comum a mais do que uma aplicação ela é mais estável, mais bem testada e isso ajuda a se concentrar apenas nas features da aplicação. O seu backlog técnico diminui cada vez mais à medida que sua plataforma matura. Em particular é possivel ter duas equipes uma para a plataforma e outra para a aplicação tal que os seus membros sejam intercambiáveis dando a todos o conhecimento de ambos os lados do problema.

Agora, volte no seu projeto e entenda o que é aplicação e o que é plataforma de aplicação …

]]> http://sergiotaborda.javabuilding.com/2010/02/a-importancia-de-uma-plataforma-de-aplicacao/feed/ 3 http://sergiotaborda.javabuilding.com/2010/02/quanto-custa-o-seu-preco/ http://sergiotaborda.javabuilding.com/2010/02/quanto-custa-o-seu-preco/#comments Wed, 03 Feb 2010 13:28:07 +0000 sergiotaborda http://sergiotaborda.javabuilding.com/?p=961 Uma das coisas mais difíceis em desenvolvimento de software não é o domínio das linguagens ou o levantamento dos requisitos: é saber quanto cobrar por tudo isso.  Como determinar o preço do seu software ?

O primeiro conceito a entender é que preço é diferente de custo.  Isto é economia básica mas muita gente esquece isto. A diferença entre os dois é o lucro, que pode ser negativo.  O que você cobra de um cliente é o preço, não o custo. Entenda isto bem antes de continuar lendo.

Escolher um preço para o seu software não tem nada que ver com o custo do software. Muita gente acha que um preço é obtido calculando o custo e somando uma “gordura”. Isso é simplesmente idiota. Para mais detalhes de como e por quê o preço não deriva do custo leia este livro gratuito.

Vejamos as diferenças. O custo parte diretamente do esforço econômico que representa criar o software. Provavelmente você precisa de um computador, ligado a uma fonte de energia electrica e hoje em dia, provavelmente de uma ligação à internet. Muitos destes custos são continuos como a energia, que quanto mais  usar, mais paga.  Outros custo são mais difíceis de contabilizar com o custo do computador. O custo pode ser modificado por fatores como a qualidade. Processos com mais qualidade têm menos custo porque são mais afiados e não se perde esforço com coisas futeis. Deslocamentos são outra fonte de custo. Se você precisa conversar com o cliente você precisa ir até ele. A menos que use o telefone, mas ai terá um custo da linha telefônica … Mas nem tudo o que você gasta é custo. O almoço que você come não é custo, você tem que comer esteja ou não fazendo o software. Portanto, primeiro que tudo, você precisa listar todas as fontes de custo que existem quando você cria um software. Isto só por si é uma arte e existem especialista em avaliar custos. Para grandes empresas custos incluem os salários e alugueis além da energia e comunicações. Para o freelancer o custo inclui não estar trabalhando em outro projeto que pague mais.

Se você escreveu o programa em 3 dias, o desenvolvimento não durou 3 dias. O desenvolvimento começou no momento que você concordou com o cliente que iria fazer o software. Aliás, começa na primeira conversa com o cliente sobre a idéia de criar o software. Quantos dias você precisou para chegar nos requisitos do software, quantas reuniões teve com o cliente, quanto gastou nos deslocamentos, etc… tudo isso é custo.

O preço é o valor que o cliente lhe pagará pelo serviço. Este valor nada tem a haver com o custo. Ele tem a haver com o mercado, ou seja, com a concorrência. Se o outro cara faz por 300 e você por 100 provavelmente você ganha o projeto. Veja que o cliente não está nem ai para o seu custo. Se o preço não cobrir o custo é problema seu. De mais ninguém. Existem razões reais e lógicas de porque você iria cobrar um preço abaixo do custo, a maioria delas ilegais, mas algumas licitas como querer “ganhar o cliente”, ou lançar a sua empresa, ou fixar-se no mercado. O objetivo do preço é fazer o cliente comprar de si, não é cobrir o seu custo. Se você tentar fazer isso sem entender as consequencias você não vai durar muito.

Aqui entra o conceito de volume. A idéia é que não é uma única venda que cobre o custo, são várias vendas. Você deve estar pensando como você vende um produto por encomenda mais do que uma vez. A resposta é: componentização. Muitas das coisas que você coloca no software não são diretamente necessárias ao serviço que o software irá fazer pelo cliente. A maior parte delas você inclui para você se proteger de situações inesperadas. Por exemplo, você inclui validação de campos para impedir a corrupção dos dados e a correta execução dos processos. Ao contrário do que muitos pensam isso não é incluído para ser bonito ou para você poder cobrar mais. Mecanismos como esse serão reutilizados em vários softwares – em todos os softwares – que você fizer. Construir esses componentes tem um custo, mas o seu uso em vários sistemas rateia esse custo. Você está na realidade vendendo sempre a mesma coisa com um pedacinho diferente que são as regras especificas para aquele cliente.

O custo é definido pelo esforço econômico necessário e decorrente da atividade de criar o software. O preço é o valor econômico que o cliente está disposto a pagar pelo serviço que o software realiza.

Em uma situação hipotética você desenvolveu um software que lhe custou 1000 reais. O cliente comparou seu preço com o mercado e não está disposto a pagar mais que 500 reais. Você teve lucro ? À primeira vista parece que não. Afinal os 500 reais não cobrem o custo. Mas isso só é verdade se essa for a sua única venda. Se você sabe à partida que apenas irá realizar uma única venda do software ( da licença de uso para ser mais exato) é bom que o preço cubra o custo, caso contrário seu trabalho é inútil.  Neste caso é bom que você saiba orçamentar o software antes de o fazer. Dessa forma você pode discutir o preço com o cliente e não realizar o projeto caso não seja compensatório para si.

A compensação nem sempre é monetária. Às vezes seu objetivo é “ganhar o cliente”, ou seja, vincular o cliente à sua empresa ou aos seus serviços. Isso por si só pode ser uma compensação, mas apenas no caso em que você sabe que ele irá pedir mais projetos, ou através de publicidade, lhe trazer mais clientes.

Orçamentar software não é simples. Isto porque o orçamento sempre se baseia nos requisitos e os requisitos sempre são incompletos. A forma mais simples é inverter os papeis. É perguntar ao cliente quando está disposto a pagar e incluir no software o máximo de funcionalidade que cabe nesse preço (veja bem, no preço).  O cliente lhe deu um objetivo : um site para a minha empresa por 1000 reais. Impossível ? Não.  Você lista tudo o que precisa para construir esse site e qual o preço de cada coisa.

Listagem de produtos: 200 reais. Pesquisa simples : 50 reais Pesquisa avançada : 500 reais. visual meia-boca : 500 reais : Visual profissional : 20000 reais. …

E simplesmente manda o cliente escolher. Se ele escolher a listagem de produtos com pesquisa simples e visual meia boca cabe perfeitamente no orçamento dele. Claro que o site será um fracasso mas isso não é problema seu ( consultoria : 5000 reais).

Fazer orçamentos desta forma deixa bem claro ao cliente o que ele está pagando. Isso lhe permite remover, escolher, alterar, incluir , etc… Este tipo de orçamento é uma ferramenta para você não sair perdendo e satisfazer as necessidades e desejos do cliente.

Mas por que razão a listagem de produtos custa 200 reais ? Não ha razão. É um preço justo por essa feature. Se a sua concorrência fizer por menos, talvez você deva considerar, mas no caso 200 reais é o dobro de cem e é maior que o custo. É razão suficiente. Já o visual meia-boca tem um custo muito maior que 500 reais, mas esse é o preço que quero cobrar.  Se alguém fizer por menos, reconsidere. Se alguem fizer mais bonito pelo mesmo preço, reconsidere. O preço sempre é comandado pelo mercado. Sempre. É por isso que você precisa conhecer a concorrência.

Para minimizar o risco de se dar mal, comece a estimar tudo o que faz. E depois compare com o valor real. Isso vai ajudá-lo da próxima vez a ter uma estimativa melhor. Estimar requer prática. Quanto mais estimar, melhor será estimando. Pesquise o mercado. Sonde por quanto a concorrência está vendendo os seus produtos. Compare a qualidade dos produtos e as suas características.  Finalmente sempre tenha em mente que preço e custo são coisas diferentes e independentes. Tenha em atenção o efeito do volume. Pense sempre em reaproveitar componentes pois isso irá diminuir o seu custo de produção , podendo vender pelo mesmo preço, você estará ganhando.

Saiba listar os custos da criação do seu software. Saiba estimar o volume, ou seja, a quantos clientes você poderá vender. Se só poder vender para um cliente a sua estratégia é diferente de se poder vender para 3, ou 10, ou 100.  Entenda que o lucro vem no fim, mas o fim não acontece no momento da venda.

Se você decide cobrar um valor fixo por hora isso lhe dá pouca margem para negociar porque o cliente não tem noção do esforço em horas (aliás, nem mesmo você tem a maior parte das vezes) e além disso você está ligando preço a prazo o que o limita ainda mais. Não cobre por hora se o poder evitar, cobre por funcionalidade.

Entenda que você sempre estará vendendo uma licença de uso e nunca o software em si. Se você estiver vendendo os seus direitos autorais, ou seja, faz o software para o cliente e ele é que será o dono do software, obviamente o preço é mais alto. Veja que você não gasta nada ao vender os direitos autorias, mas está sendo impedido de ganhar dinheiro no futuro através daquele software. Isso também é custo.

A licença de uso é apenas uma das coisas que você pode vender. A mais comum. Serviços de manutenção e evolução são outra fonte de renda. O custo será abatido e rateado entre todas estas coisas. Não altere uma vírgula do software original a menos que haja um contrato para isso.

Estabelecer um plano de negócios, ou seja, como você/ a sua empresa vai ganhar dinheiro não é simples. Ha muita teoria econômica que pode ajudar, mas no fim tudo depende do mercado e da imagem que você tem nesse mercado. Você precisa se conhecer a si mesmo para conhecer o custo, conhecer o mercado e o cliente para estabelecer um preço; e precisa decidir os seus objetivos e estratégia: O que eu quero alcançar com esta venda ? Procurar lucro em todas as vendas nem sempre é uma boa estratégia.

]]> http://sergiotaborda.javabuilding.com/2010/02/quanto-custa-o-seu-preco/feed/ 6