Processo de Software Cl√°ssico 

Feb/12
6

No post anterior falei de como se sabe se um processo é tradicional ou não.  Hoje falarei do processo clássico.

O processo cl√°ssico se destingue do processo tradicional principalmente pelo compromisso dos intervenientes com aquilo que est√£o tentando produzir e com a comunidade que produz a mesma coisa. Aprender com as li√ß√Ķes dos outros √© importante num oficio que tem apenas 50 anos. Ainda ha muito a ser descoberto em termos de saber qual a forma mais eficiente, eficaz e barata de criar um software. Repare que “barato” tem que ver como o custo e n√£o com o pre√ßo.

O software tem que ser barato para quem o cria e livre de risco para quem o cria. Não necessáriamente o preço tem que ser pequeno ( Quanto custa o seu preço ?).

Veja que existem muitos pontos em comum entre o processo tradiciona e o clássico. Isto acontece porque quem usa o processo tradicional normalmente acha que está usando o processo clássico. Ou pelo menos essa é a sua intenção.

O processo cl√°ssico come√ßa da mesma forma que o tradicional.: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Come√ßa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta √© vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial v√™ isto como uma oportunidade e prop√Ķe que o cliente aceite conversar com algu√©m da √°rea de projetos.¬† A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.¬† Normalmente um analista e um domain expert.¬† N√£o envia apenas uma pessoa. Isso seria um erro. E n√£o envia¬† mais que 3 pessoas, porque isso seria desperdicio. A equipe √© focada em levantar os requisitos macro de forma a que seja possivel estimar o risco do projeto e o tamanho do escopo.

Repare que no tradicional o risco é ignorado e o tamanho do escopo é irrelevanta pois será fixo.

O processo de levantamento leva de 5 a 10 dias de entrevistas com v√°rios stakeholders. O objetivo n√£o √© criar codigo, mas saber o que o cliente precisa e n√£o precisa. O que ele quer agora, o que ele n√£o quer agora e o que ele nunca ir√° querer. Quanto mais as palavras “sempre” e “nunca” s√£o usadas em um requisito maior o risco do requisito.

O risco do requisito é importante para saber o quão estável é aquele requisito.

Daqui a equipe de projeto determina o prazo minimo,  máximo e expectável do projeto ( o mais provável). Determina também quais áreas/requisitos irão precisar de mais detalhamento e em que grau. Por exemplo, um requisito padrão como login, normalmente é estável e precisa de poucas entrevistas. Um requisito como integração com legado é um requisito complexo, de alto risco que precisa de mais entrevistas.

A equipe de projeto detremina tamb√©m as capacidades que a equipe de execu√ß√£o ter√° que ter. A tencologia, a estrutrua, a infra-estrutura, o processo usado, a necessidade de comunica√ß√£o, o nivel de qualidade, o tempo disponivel (baseado no time-to-market) , etc… s√£o constrangimentos ao tipo de equipe necess√°ria. 4 s√©niors s√£o uma equipe pequena , facil de gerenciar, que produzem boa qualidade e baixo numero de erros, mas mais cara. Uma equipe de 8 juniors √© mais barata, mas produz mais erros e √© mais dificil de gerenciar face √† falta de maturidade.

√Č vital que o levatamento direcione as perguntas. A conclus√£o mais importante de todas √© saber se o projeto ser√° time-driven, feature-driven ou plan-driven. Em um projeto time-driven existe um requisito temporal que limita o projeto. O chamado time-to-market. Se o cliente precisa do software para uma certa data especifica, como o natal, uma feira , etc.. e se a falha em ter o o software nessa data aborta o projeto. Os projetos tradicionais s√£o todos time-driven, mesmo quando n√£o existe de fato um time-to-market, mas um desejo do cliente em uma data alvo.

Feature -driven acontece quando o tempo não é relevante mais sim as funcionalidades. Aqui se estabelece que o software só está pronto quando tiver as features A, B e C e todos funcionarem sem problemas. Basicamente o que interessa é cumprir o escopo e não nenhum prazo em especifico.

Plan-driven acontece quando o cliente está interessado em determinar um sub-conjunto de features em um certo prazo. O projeto é dividido em releases e cada uma tem um objetivo util e comercial para o cliente. Basicamente o software é feito em forma de upgrades, mas com uma versão 1 que se pode utilizar em produção.

A somar a todas as estimativas ha a consideração do cone de incerteza. Numa fase preliminar como esta e com um cliente com quem nunca se trabalhou, a incerteza é bem grande e deve ser considerada.

Depois de pesar todos estes fatores, determinar o perfil da equipe de execução, o risco e tamanho dos requisitos e o plano de entrega a área de projetos produz um documento de visão acompanhados da proposta de prazo e custo.

O comercial então terá que avaliar a viabilidade deste projeto. Talves não seja rentável executar este projeto. Se não for, uma discussão com o cliente e o departamento de projetos pode levar a uma simplificação do projeto, dos requisitos, uma extenção dos prazos, etc.. de forma a tornar o projeto comercialmente viável.

Feito isto o departamento comercial¬† prop√Ķe ao cliente algo como “Podemos fazer um sistema de XPTO para si entre N e M meses por P reais”. Veja que um prazo m√°ximo e expet√°vel s√£o apresentados e n√£o uma data fixa.

Existem várias formas de escrever um contrato e não necessáriamente os dois limites do prazo vão aparecer explicitamente. Isto porque os clientes ficam confundidos quando veêm duas datas e assumem a menor. Um forma de por isto de uma forma mais digerivel é usar um contrato assim :

“Podemos fazer um sistema de XPTO para si em N meses por P reais. Com um pr√©mio Z que decai at√© M meses.”

P é o custo do projeto com um lucro embutido. Z é um valor calculado tal que seja igual a P ou maior até um percentual do periodo entre N e M. Este percentual depende do risco e da confiança em N. Ou seja, quanto mais confiante menor este percentual.

Existem muitas formas. O ponto é considerar que a data expectável tem uma probabilidade menor que a data máxima. A empresa e o cliente são recompensados se a data expectável for correta, caso contrário a empresa é penalizada. Este conceito de penalizar a empresa e não o cliente é completamente desconhecido no processo tradicional.
Supondo que o cliente concordou com os termos temos agora um projeto com prazo, preço e escopo definido.

A mudan√ßa de escopo √© feita segundo um processo de mudan√ßa de escopo normalmente recorrendo a um comit√© e todas as altera√ß√Ķes para cima s√£o cobradas pela empresa provedora. As altera√ß√Ķes para baixo s√£o colocadas em um “banco” para serem descontadas na seguinte mudan√ßa para cima. Isto s√≥ acontece porque todo o requisito tem um risco e um tamanho associados.

O pr√≥ximo passo √© detalhar o levantamento j√° iniciado e em paralelo come√ßar a desenhar uma arquitetura e infra-estrutura.¬† Nesta fase (analise) o levantamento mais detalhado pode levar a altera√ß√Ķes no escopo que podem levar a altera√ß√Ķes no resto do projeto.¬† Todos os requisitos s√£o detalhados e partidos em requisitos menores at√© que seja possivel transformar o requisito em tarefas de execu√ß√£o.

Durante esta fase de analise os requisitos são também analisados e sentitizados de forma a chegar num numero minimo de requisitos que atendem os requisitos iniciais.Com a arquitetura testada e aprovada e os requisitos detalhados um documento de especificação é produzido.

Em paralelo a equipe de execução é montada e os requisitos são partidos em tarefas, por ela. As tarefas são cotadas com um tamanho por um processo como o Wideband Delphi, por exemplo. A gerencia de projeto usa estes numeros para corrigir a sua estimativa inicial. Se menor, o plano original é mantido. Se maior, o cliente é acionado para modificar a prioridades dos requisitos de foram que se o tempo explodir, apenas as features menos relevantes ficarão de fora.

Passa-se ent√£o √† execu√ß√£o. Durante a execu√ß√£o, novos requisitos s√£o introduzidos, altera√ß√Ķes s√£o necess√°rias, o comit√© de mudan√ßa √© acionado e os requisitos s√£o constantemente analisados e sintetizados. Em paralelo os planos de teste come√ßam a ser construidos.

Passa-se então à execução dos testes. A equipe de QA tem o documento de requisitos e os planos de teste para se guiar e não precisa inventar casos ou cenários que não estejam ali. Contudo, falhas, hiatos funcionais ou de implementação levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

A taxa de testes com sucesso versus a taxa de bugs s√£o computadas pela gerencia e considerando o cone de incerteza obtemos uma nova estimativa de sucesso ou n√£o do projeto. Novas prioriza√ß√Ķes s√£o feitas pelo cliente.

Emquanto os testes est√£o sendo feitos,o cliente revisa os requisitos finais com a equipe de requisitos. Modifica√ß√Ķes, disparidades, hiatos levar√£o a equipe a recome√ßar por analizar os requisitos, modific√°-los , modificar o codigo e a documenta√ß√£o.

No fim deste processo, os testes ter√£o garantido a qualidade tecnica do produto e a revis√£o dos requisitos ter√£o garantido que o software faz o que o cliente quer. Finalmente temos a fase de homologa√ß√£o em que o cliente usa de fato o software. Quaisquer pedidos de modifica√ß√£o s√£o comparados com os requisitos. Quando o pedido n√£o base com o requisito ele n√£o √© realizado. Esta n√£o √© uma fase onde o cliente pode inventar coisas novas. Altera√ß√Ķes que n√£o sejam devido a bugs ser√£o simplesmente deixadas para outro projeto no futuro.

O processo classico não começa com promessas irrealistas. As coisas são medidas e estimadas by the book ( seguindo os livros). O andar do projeto é medido em certo pontos o cliente faz os ajustes. A empresa nunca prometeu realizar tudo, mas sim cumprir o objetivo inicial ( time-driven, feature-driven ou plan-drive).  Ou seja, a empresa está comprometida em cumprir um plano e não em cumprir o desejo do cliente. O cliente é livre de mudar o plano, basta que pague a diferença.

A equipe é contratada depois que se sabe o que o sistema irá fazer. Os requisitos já estarão detalhados o suficiente para quando a equipe existir ela poder realizar a quebra em tarefas. O risco de escolher uma equipe junior uma sênior, ou um misto é imputado nas estimativas e não é deixado ao acaso. Nada é deixado ao acaso excepto o real andamento do projeto. O projeto é devidamente documentado para que nem o cliente nem a empresa tenham duvidas sobre o que é para fazer e o que não é. O resto é superfluo, não necessário, e relegado para um próximo projeto.

A equipe sabe exactamente o que tem que fazer e pode ser organizada da melhor forma para cumprir esses objetivos no minimo tempo possivel já que o objetivo interno da empresa é alcançar a data expectável (e não a data máxima, que está no contrato). Internamente o projeto é guiado de uma forma e com um objetivo, enquanto que externamente ele é guiado de outra forma com objetivos iguais mas tempos mais dialatados

O processo classico é, portanto, marcado pelos seguintes aspetos:

  • N√£o se¬† faz nada sem estimar antes e as estimativas n√£o s√£o viciadas. Para n√£o viciar as estimativas processos padr√£o explicitos na literatura s√£o usado.
  • As fazes do projeto s√£o respeitadas e executadas √† risca: Negocia√ß√£o, Levantamento, Analise, Desenvolvimento, Teste¬† e Homologa√ß√£o.
  • N√£o s√£o feitas promessas. √Č estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a n√£o esperar. Tudo √© feito de comum acordo e sem mecanismos de submiss√£o.
  • O cliente √© respeitado. √Č informado de todos os problemas e todos os riscos. Todas as suas decis√Ķes s√£o guardadas para futuro uso ou confrontamento. Se o cliente se enganar, ele se enganou. Se n√≥s nos enganarmos, n√≥s nos engan√°mos. Sem problemas.
  • O escopo √© controlado rigidamente e qualquer desvio afeta o resto do projeto. O plano √© modificado e o contrato com ele.
  • Conhecimento das capacidades e fun√ß√Ķes dos membros da equipe. Responsabiliza√ß√£o pela equipe que montou.
  • Sempre que ha um problema qualquer pessoa pode levant√°-lo e alertar.

 

O processo cl√°ssico √© bem estricto. √Č um processo Stage-Gate com a possibilidade de em cada gate haver uma avalia√ß√£o do projeto e novos planos serem feitos e novas dire√ß√Ķes sendo tomadas. Contudo tudo isto e feito com base em numeros e dados e n√£o em chutes ou promessas.

Este processo √© extremamente r√≠gido e para funcionar a contento as pessoas que o usam tem que ter uma certa experiencia. √Č por isso que √© importante seguir o processo by the book. O que acontece na pr√°tica √© que as pessoas le√™m os livros mas logo interpretam ou subjugam o que o livro diz para o seu caso sem nunca ter dado uma chance ao processo can√≥nico. √Č isto que gera a inventividade dos processos tradicionais. A inten√ß√£o das pessoas √© boa, mas sua arrog√Ęncia √© maior e se acham capazes de desafiar o que os autores levaram anos para descobrir e documentar. O exemplo cl√°ssico √© desconsiderar o cone de incerteza, ou sequer saber o que ele √©. Outro √© n√£o for√ßar um processo de mudan√ßa de escopo como deve ser com medo que o cliente se assuste quando a empresa disser que n√£o ir√° fazer tal coisa e o cliente v√° embora.¬† Os medos e inseguran√ßas das empresas de software levam a que rapidamente alterem o que est√° escrito e come√ßem o processo tradicional. √Č um mecanismo semelhante ao que acontece com a biblia. um escrito, mil interpreta√ß√Ķes.

Por outro lado, seguir as regras by the book não significa que as tenha que seguir mesmo quando estão erradas ou não correspondem com o seu caso. Contudo é preciso ser humilde e disciplinado para apenas mudar a regra quando so dados demonstram que ela não é eficaz no seu caso, e que, por algum motivo, o seu universo amostral é estatisticamente  diferente daquele usado pelo autor do livro.

O processo cl√°ssico deixa margem de manobra para altera√ß√Ķes, s√≥ que ele exige provas de a mudan√ßa √© necess√°ria. Como a maioria dos gerentes faz um pessimo trabalho coletando dados do projeto nunca ha como provar nada e √© a√≠ que entra o chute, a artimanha e a politica. E mais uma vez a porta est√° aberta para o processo tradicional.

Sendo um processo rigido e dificil de seguir, embora muito simples de entender, o processo classico fácilmente se trasnforma no processo tradicional porque os intervenientes não têm a indole moral ou a retidão necessária para executar o processo como deve ser.  Contudo, se você perguntar, muitos irão dizer que estão usando a tecnica A ou B do autor X ou Y, mas se olhar de perto não estão. Simplesmente porque subverterem o que a tecnica significa e deturparam o seu significado

Se seguir o processo como deve ser, verá que ele é muito lento e burucrático. A burocracia advém do fato de constantemente ter que saber se o requisito A ou B está ou não no escopo e algumas vezes isso é subjetivo. Isto levou algumas pessoas a considerar que se dá muita importancia ao processo e pouca ao interesse do cliente ou da execução do software. Ou seja, o cliente é honorado pelo seu próprio desconhecimento do software que ele quer. mas se o cliente soubesse o que ele quer, ele mesmo teria feito o software sem contratar a empresa.

Daqui nasceram tentativas de melhorar o processo classico deixando o seu core de boas pr√°ticas, medi√ß√Ķes, auferi√ß√Ķes, mudan√ßa de planos mas modificando as regras de forma a que o processo fosse mais simples, menos burucr√°tico, mais √°gil.

Da próxima falarei do processo ágil. Até lá.

 

 

Um comentário para “Processo de Software Cl√°ssico”

  1. […] posts anteriores falei de como se sabe se um processo √© tradicional ou n√£o e como se define o processo cl√°ssico.¬† Hoje falarei do processo […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos