Estimar não é uma arte. É matemática.
Quando erramos “para mais” (ou seja, quando o projeto extrapola o cronograma, os custos ou o esforço mensurados) ficamos cheios de respostas para tudo e ainda mentimos para nós mesmos que simplesmente a culpa não foi nossa: foi o contexto que mudou (como se essa mutabilidade não fosse uma variável que precisasse estar na nossa equação...).
Quando erramos “para menos” (ou seja, quando o projeto é concluído com êxito antes do prazo ou com menor custo ou esforço) ficamos boquiabertos com nosso poder de gerência, gestão e capacidade de inferência. Em suma, ficamos aguardando os louros da “vitória” e a enxurrada de parabéns dos colegas, com a certeza de que fizemos tudo melhor do que o esperado. Triste ilusão.
Errar para menos é errar, ora pois! Quando erramos para menos, sub-utilizamos recursos e tempo, e consequentemente, estamos perdendo algo. Mas que algo é esse? Podem ser recursos humanos que não foram utilizados em outras tarefas ou projetos; podem ser recursos físicos, que não puderam ser usados ou realocados; podem ser recursos abstratos, como a compra demasiada de licenças de software, enfim, pode ser uma panacéia de coisas este desperdício.
Assim, para termos a precisão adequada, não podemos nos valer apenas de achismos. Estimar não é uma arte, é matemática.
Introdução 2 – Os apressados podem pular novamente se quiserem
Sistemas complexos são dirigidos por inúmeras variáveis.
Na meteorologia, por exemplo, considerar o atrito causado pela passagem ocasional de bandos de Andorinhas pelo ar em uma massa polar continental para saber se vai chover quando formos para a Praia da Joaquina no próximo Sábado não traz muito benefício no final das contas.
Assim, elencar as variáveis corretas e saber como utilizá-las na equação pode ser a chave do sucesso das estimativas.
No mundo dos projetos de software, felizmente, as mesmas regras se aplicam.
Introdução 3 – É bom não pular
Neste post - ou quasi-artigo - descrevo uma técnica muito interessante, que aprendi lendo sobre PU Ágil – uma das minhas metodologias preferidas – em trabalhos como os do Mike (COHN, Addison Wesley 2005), que é um grande cara!
Essa técnica foi estendida e fundida a conceitos da Feature Driven Development (FDD) [técnica de análise], da Domain Driven Design (DDD) [técnica de projeto] e da Extreme Programming (XP) [técnica de desenvolvimento], dando origem a uma proposta que é aplicada no nosso processo de desenvolvimento ágil gerenciado, o 3PUP (http://3layer.no-ip.info/confluence/3PUP).
A técnica se aplica a projetos de software de quaisquer tamanho, sendo mais beneficiados os maiores e aqueles em que poucas informações de requisitos e detalhamentos de baixo níveis estão disponíveis – ou seja, a maioria dos projetos ;)
Como já disse, ela vale-se de recursos do PU Ágil, XP, FDD e DDD, e deve ser executada por pessoas com conhecimento de Orientação a Objetos, UML e, principalmente, experiência na construção de Casos de Uso, como aqueles defendidos maestrealmente pelo nosso colega Alistair (COCKBURN, Addison Wesley 2000). Não obstante, precisa ter clientes “que abracem a causa” (conceito da XP).
Caso esses elementos não façam parte da sua sopa de letrinhas, sugiro desconsiderarem o resto do texto. Digo isso porque, se outros projetos, técnicas ou pessoas estiverem presentes (como analistas – desculpem o termo – ermitões da Análise Estruturada e do Mundo Relacional), é muito provável que a abordagem não funcione, e que acabem dizendo que ela é errônea ou inaplicável. Uma pena. Para eles.
O Cenário
Para ser mais realista, considere o ambiente: Uma empresa de varejo quer desenvolver um novo sistema. O sistema precisa ser “enterprise”, cobrindo o core do negócio da empresa e ser usável por sua matriz e filiais. Deve ser de fácil uso, utilizável por navegador web e com pontos essenciais com acesso desktop. Deve se integrar com sistemas legados, como RH, Orçamento e Custos, construídos em Clipper, Cobol e SAP, e usar várias bases de dados. Precisa ter dados online para todos envolvidos e atuar nas áreas de vendas, estoque, caixa, integração bancária e com operadoras de crédito; fazer projeções para vendedores, comissões, estoque, logística de armazenamento, faturamento, emissão de notas, contra-notas e integração com operadoras telefônicas, dando mensagens SMS em diversas situações. Idealmente, o sistema precisa ser extensível e com suporte para serviços futuros, com interfaces seguras para WebServices, SOA e mecanismos plugáveis externos, como relatórios de Business Intelligence. Tudo isso importando dados dos sistemas atuais e com os processos de negócio em funcionamento.
Completando, como política da nova gestão da empresa, e com verbas de fundos setoriais, a organização está revendo seus conceitos de trabalho, e busca otimização nos seus processos atuais, visando eliminar gargalos, pessoas e atividades burocráticas ou de baixo retorno. Em suma, ela é uma típica adepta do conceito de Engenharia de Processos, vogado nos anos 90.
Esse cliente chega até nós e nos indaga: quanto custa fazer esse sistema, e quanto tempo vai levar para estar completamente em operação?
A resposta não é simples, e estimar isso é como acertar se vai chover na Zona Leste de Cingapura na tarde do centésimo quadragésimo terceiro dia a partir de hoje. E claro, se a chuva será torrencial ou esparsa. Ah, e claro novamente, quantos metros cúbicos de água irão despencar nesse interim...
Mas independente desses detalhes, precisamos dizer algo para o cliente, caso contrário, ele não será nosso cliente....
Passo 1 – Identifique as Áreas de Negócio
Para que isso funcione, o cliente precisa abraçar a causa. E você precisa convencê-lo que isso é importante. Se você for perspicaz, vai conseguir isso. Se não conseguir, não adianta seguir daqui: esqueça do negócio, ou minta para o cliente.
Passo 2 – Mapeie os Fluxos de Trabalho
Mapear os fluxos de trabalho que ocorrem na empresa.
Passo 3 – Identifique as Atividades
Para cada fluxo de trabalho, identifique as atividades que o compõem, os atores envolvidos, responsabilidades, artefatos consumidos e produzidos e relações entre as atividades, incluindo restrições e segurança.
Passo 4 – Extraia os Casos de Uso
Para cada atividade em cada fluxo de trabalho, identifique os casos de uso relacionados a ela. Geralmente é um, mas nem sempre.
Passo 5 – Tipifique os Casos de Uso e Bordas
Identificar os casos de uso que serão implementados pelo software e aqueles que serão realizados manualmente. Para os que são realizados por software, marque os casos de uso manuais que se relacionam diretamente com ele – esses terão um tratamento especializado também (abaixo).
Passo 6 – Defina a Complexidade
Todos os Casos de Uso identificados precisam ter sua complexidade definida. Isso é essencial para a estimativa do projeto e pode ser feito com uma boa taxa de acerto sem muito trabalho de longo prazo. O post http://telasdecadastro.blogspot.com/2007/12/estimativa-de-projeto-por-pontos-de.html fala sobre isso.
Passo 7 – Agrupe os Semelhantes
Muitos casos de uso têm igual semântica. Em outras palavras, fazem a mesma coisa. Por exemplo, temos vários Casos de Uso para envio de emails (diversas áreas da empresa precisam enviar emails, embora cada uma o faça de forma singular) ou mesmo, muitos Casos de Uso fazem importação de dados externos (embora cada um importe um arquivo diferente ou o faça em uma base de dados distinta), etc. Mas fora isso, são semelhantes.
Passo 8 – Mensure o Esforço
Para cada tipo de Caso de Uso identificado na etapa anterior, compute o esforço relacionado usando a técnica Use Case Point (UCP). O mesmo post acima fala sobre isso. Preste atenção, eu disse para “cada tipo” de Caso de Uso, e não “cada instância” de Caso de Uso. Observe que, se um tipo tiver mais de uma complexidade identificada (o que é comum), você deve mensurar o UCP para cada uma das complexidades identificadas. Por exemplo, tem-se o Caso de Uso do tipo “Relatório Linear”, ondem foram identificados relatórios lineares (sem agrupamentos) complexos, médios e simples. Assim, deve-se obter a UCP para relatórios lineares complexos, médios e simples.
Passo 9 – Derive o Esforço
Nesse momento, existem centenas de Casos de Uso (ou mais). Mas, devido o agrupamento por semelhanças, existem apenas dezenas de tipos deles (ou menos – no 3PUP, nós temos menos de 20 tipos de Casos de Uso). Agora a regra é simples: somar a multiplicação da quantidade de tipos pela quantidade de instâncias de cada tipo, considerando as diferentes complexidades. Para um exemplo prático, considere que foram identificados 600 Casos de Uso de várias complexidades, os quais foram agrupados em 15 tipos diferentes (como CRUD, Mestre-Detalhe, Mestre-Detalhe Isomórfico, Relatório Linear, Relatório com Agrupamento, Integração De Entrada, Integração de Saída, Integração Bidirecional, Impressão Física, etc).
Um histograma desses Casos de Uso seria algo como:
Relatório Linear Simples.....: 7 UCP, 3 instâncias
Relatório Linear Médio.......: 18 UCP, 8 instâncias
Relatório Linear Complexo....: Nenhum
CRUD Simples.................: 2 UCP, 24 instâncias
CRUD Média...................: 8 UCP, 63 instâncias
CRUD Complexa................: 20 UCP, 33 instâncias
Mestre-Detalhe Simples.......: 12 UCP, 11 instâncias
Mestre-Detalhe Médio.........: Nennhum
Mestre-Detalhe Complexo......: 33 UCP, 4 instâncias
...e assim vai, sendo no total 600 instâncias de Casos de Uso.
Assim, basta somar a multiplicação da quantidade de instâncias de Caso de Uso pela UCP em cada item. Como resultado, tem-se o esforço total dos casos de uso do projeto.
Por exemplo, digamos que tivemos um total de 852.440 UCP (chutei). Uau, um sistema realmente grande. Eu diria, um ERP ;)
Passo 10 – Transforme UCPs em Horas/Homem
No Post acima, comento como transformar UCPs em horas de projeto. E isso é vital para a empresa que vai desenvolvê-los, bem como para a que vai comprá-los ;)
Felizmente, o processo é fácil. Mas, ironicamente (e infelizmente), é aqui que morrem a segunda parte dos candidatos.
Calcular UCPs é uma matemática que exige um esforço considerável e que pode necessitar também um histórico de projetos para que tenha sucesso (claro, esperamos que a sua empresa já tenha um bom Portfólio de projetos, e que esses reflitam a realidade...).
Usando a literatura básica, 850.000 UCPs são cerca de 42.500 horas de projeto, que deve dar algo em torno de 1,5 anos de trabalho em um time de 20 bons desenvolvedores. Claro, isso considerando uma arquitetura Enterprise já bem consolidada, extensível, homologada, praticada e.... documentada. E nem falei nas ferramentas de apoio: repositório versionado integrado com ferramenta de projeto, wiki, email, web-conference, fórum, etc. Tudo integrado, óbvio.
Mas bem, já temos os números: Tempo = 18 meses; Pessoas = 20.
Passo 11 – Monte o Cronograma
Com os valores definidos de tempo e pessoas, monte os cronogramas do projeto. Anexe seus custos e defina os marcos etapas-macro.
Coloque numa panela, chacoalhe e observe a espuma. Sirva para o cliente.
Moral da História
Em princípio, vocês podem argumentar que isso não é nada rápido de ser feito. E eu concordo.
Podem dizer que isso é complexo, que vai demandar um esforço enorme para ser realizado, que vai exigir uma “mini-equipe” somente para mapear os processos da empresa e que as pessoas necessárias para isso precisam de expertise em várias tecnologias e processos. E eu também concordo.
Da mesma forma, vocês podem argumentar que fazer o cliente “abraçar a causa” pode ser extremamente difícil e que os custos gerais para criar essa estimativa inicial podem ser, hum, absurdos?! Sim, também concordo.
Mas nada disso é diferente do que o velho Mike e outros gurus já não tenham nos avisado. Estimar tem um custo. Se não quiser esse custo, não estime. O gráfico abaixo mostra isso direitinho.
Porém, não estimar, ou ignorar essas variáveis é – ou geralmente será – muito pior. Fazendo isso, você simplesmente está fazendo como todos os outros. E aí, você não está usando matemática, e sim, brincando de chutar resultados.
A grande moral aqui pode ser assim resumida: Custoso não é estimar, mas sim, definir as variáveis corretas dessa equação e, claro, seus valores e variações aceitáveis. O resto, bem, o resto é matemática.
Num próximo post, eu coloco um passo-a-passo visual desse processo todo. Por hora, é isso.
0 comentários:
Postar um comentário