Pular para o conteúdo principal

Quem conta um Ponto, Aumenta um Conto

Bem, hoje o assunto é ponto de função, e como tem se tornado nos poucos post, começarei com uma historinha minha dentro da área.

Eu estudo ponto de função a 2 anos. Do início dos meus estudos em PF até começarmos a utilizar esta técnica na empresa foram 2 meses. Antes do ponto de função, nossa estimativa era bastante empírica, utilizávamos nossa experiência e estimávamos no "olhômetro" cada funcionalidade ou caso de uso do sistema. Nem preciso dizer que em 2 anos, após começar a utilizar o PF já temos uma pequena base histórica da nossa produtividade, nossas taxas de erros de previsão e diversos fatores que influenciam em nossos projetos. O que vale ressaltar aqui é que com as informações desta base de dados, juntamente com a experiência adquirida, hoje nos é possível prever e orçar com muito mais certeza um projeto.

Mas não foi pra ficar falando dos benefícios da APF que eu vim discutir hoje, meu ponto hoje é o papel e o uso da APF no mercado hoje em dia. Desde que iniciei os meus estudos neste assunto, uma metáfora sempre ficou na minha cabeça e sempre a tomei como a melhor forma de explicar "o que é ponto de função", a metáfora da casa e o metro quadrado: "O Ponto de Função é o metro quadrado do software. Posso lhe dizer que existe uma casa de 200 m² e isso lhe dará uma boa noção do tamanho desta casa, porém isto não lhe dará informações sobre custo ou esforço desprendido na construção desta casa, afinal ela pode ter piso de mármore e torneiras folheadas a ouro ou ser feita de materiais mais comuns, ela pode ter sido construída em um bairro de classe média próximo ao centro da cidade ou no alto de um penhasco." (Coloquei entre aspas pois não me lembro onde ouvi esta história, nem achei a fonte)
Coloquei em destaque o que mais me marcou desta história, é que o ponto de função não lhe determina o esforço, nem o custo do seu projeto.

Bem, fazendo uma pequena pausa, vamos ao que me inspirou a este post. Na minha empresa, hoje temos uma noção de quanto temos capacidade de desenvolver, temos inclusive alguns números que envolvem nossa produtividade em PF. Na semana anterior nos veio um cliente e durante nossa reunião questionou quanto nossa fábrica era capaz de produzir em PF/mês, e prontamente informamos os dados que temos. Neste ponto o cliente nos perguntou quanto tempo demoraríamos para absorver uma demanda maior, informávamos que dependia do tamanho da demanda e de como planejaríamos este aumento. Bem o cliente gostou dos números, saiu satisfeito e espero que tenhamos um bom negócio. Porém ao sair da reunião algo me incomodava, e fiquei meditando no assunto. O que me incomodou foi o fato de termos tratado PF como uma unidade "padrão", como se minha fábrica de software produzisse "balinhas" e eu dissesse que produzo X balinhas por mês e se você quer uma produção de 3X basta eu comprar mais maquinário. Meu problema é que eu não produzo "balinha", o problema que eu enxerguei (e que me causou desconforto) foi que tratamos PF como "balinhas", desconsiderando o fato que o custo de 1 PF é bastante distinto de um sistema para outro.

É importante ressaltar esta questão, pois isto nos volta ao que serve o PF (nosso m²). Pois imagine você que alguém lhe diga que tem um sistema de 2000PF para ser desenvolvido, lhe pede um prazo e custo sem mais informações. É impossível determinar, afinal podemos ter um imenso sistema CRUD, ou mesmo termos um sistema de simulação aeroespacial, que terão esforços por PF bastante distintos. Eu compreendo que nós, que cuidamos de muitas equipes, precisamos de alguns números para nos auxiliar em planejamento e a acompanhar o andamento dos projetos. Minha crítica aqui vem de utilizarmos estes números sem critérios, afinal falarmos em produtividade sem noção do negócio do cliente é, no mínimo, voltarmos a técnica do "chutômetro", agora porém, com números.

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

TDD como ferramenta de aprendizado

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão: Será que o TDD não atrapalha no aprendizado de novas tecnologias?  A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final. Caso do dojoBrasília No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias ( Backbone.js , Undescore , CoffeeScript , Jasmine , etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão. A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 cas

De Híbrido a 100% remoto - o caso da bxblue

A bx nasceu como uma empresa remota. Durante os primeiros 18 meses, os três fundadores --  eu, Guga e Roberto -- trabalhamos de nossas casas. Passado esse período inicial de maturação da idéia, nosso time começou a crescer, e acabamos optando por seguir um modelo híbrido. Nele tecnologia e marketing permaneceram remotos porém nosso time de atendimento e vendas ficou atrelado ao nosso escritório. Mas, como em muitas outras empresa, isso mudou nas últimas três semanas. Depois de tantos anos, nos tornamos uma empresa 100% remota. O O grande incentivo veio da situação que vivemos no mundo atualmente. Tendo o isolamento social como uma medida necessária a todos que tem o privilégio de poder fazê-lo, era nossa responsabilidade fazer tal mudança. Pois minha intenção aqui é contar um pouco tem sido essas 3 semanas que marcam o começo de um período que a ainda tem muito pela frente. Porque Híbrido? Antes, deixe-me explicar por que escolhemos o caminho de ser uma empresa híbrida, tendo na