Antes que você estranhe o título acima, informo que este não será um artigo sobre engenharia civil, e sim de engenharia de software. Aproveitei a relação entre as duas engenharias para fazer uma analogia entre ambas e tentar quebrar um pouco a ‘rigidez’ predominante nos processos de desenvolvimento de software atuais. Falar de modelagem hoje é uma tarefa delicada, pois modelagem é uma das etapas mais importantes e também uma das mais difíceis do ciclo de desenvolvimento de um sistema de informação. Dependendo do modelo de desenvolvimento que sua equipe pratica, a modelagem estará presente em praticamente todas as fases de seus projetos, seja durante o levantamento de requisitos até a entrega. Um trabalho de criação de modelo bem feito é – quase sempre – o detalhe que definirá o sucesso ou fracasso de sua empresa. Até então creio não ter levantado nada de novo. Se você se sente bem com suas ferramentas de modelagem atuais ou é fã de modelos como CMMI ou MPS.br, provavelmente não irá gostar do que vou dizer aqui, porém, se quer continuar a leitura, considere-se advertido de que não costumo respeitar muito a tradição, independente do prestígio gozado por ela.

A engenharia de software, assim como é abordada pela maioria dos cursos de graduação ou pós no Brasil e em boa parte do mundo, define um arsenal de artefatos dos mais diversos tipos (leia-se UML, documento de especificação de requisitos e outros) que devem ser usados como ferramentas para documentação e desenvolvimento da modelagem de um sistema de informação (SI). São eles também os responsáveis por permitirem a separação de papeis entre o analista e o programador. Enquanto um faz a modelagem, o outro ‘apenas’ a executa, convertendo o resultado de um artefato em outro (UML em código fonte, por exemplo). Considerando o que foi dito até agora, fica impossível não fazermos uma analogia com a engenharia civil (finalmente chegamos ao ponto proposto pelo título), onde o arquiteto modela o empreendimento e os construtores/pedreiros executam, convertendo um artefato em outro. Agora, vou abusar um pouco e pedir que use sua imaginação para uma pequena experiência: imagine que, ao invés de modelar usando régua, papel e lápis, os engenheiros civis pudessem modelar usando tijolos, areia, ferro e cimento! Abstraia o fato de isso ser impraticável, e observe apenas os benefícios que resultariam de tal fato se ele fosse possível (financeiramente e fisicamente). Poder ver em tempo real o resultado da modelagem poderia trazer inúmeras vantagens. Testes mais concretos poderiam ser executados. O cliente poderia ter retorno mais rapidamente e com mais frequência. Os problemas de comunicação e entendimento – sempre comuns – durante a fase do levantamento de requisitos seriam detectados bem mais cedo e eventuais alterações no projeto seriam mais fáceis e menos custosas. O quesito ROI (retorno sobre investimento) bateria próximo da casa dos cem por cento.

Se você me acompanhou até aqui, chegou a hora de extrapolarmos o mesmo raciocínio para o que realmente nos interessa: a engenharia de software. Analogamente à engenharia civil, podemos dizer que a planta está para um diagrama de classes assim como o tijolo está para o código fonte. Modelar com tijolos seria como modelar com código fonte. Fazer isso em engenharia civil está descartado por diversos motivos, onde o maior deles é o preço. Fazer e desfazer uma parede ou um cômodo até finalizar o projeto é algo no mínimo insano. Agora eu pergunto: em software, seria da mesma maneira? Não poderia modelar uma classe em C# ou Java, com direito a alterações sem que tal fato implique em um custo acima do aceitável, tendo em vista os benefícios? Arrisco responder que sim: modelar usando código é perfeitamente possível, e, se feito com critério, é mais barato, rápido e muitos benefícios serão colhidos, entre eles:

• Diminuição do hiato existente entre levantamento de requisitos e entrega de resultado significativo (usável);
• Fusão do papel de analista e programador, com aproveitamento maior do potencial dos membros de sua equipe (aprofundarei mais esse item em outro artigo);
• Detecção de falhas de projeto mais cedo e consequentemente com menores custos;
• Código fonte mais legível e autodocumentado (clean code com TDD);
• Maior autonomia para a equipe de desenvolvimento, que, se bem usada, deve render inúmeros benefícios, como o uso de tecnologias mais eficientes e soluções mais criativas;

Saliento aqui que, ao contrário do que parece, não basta esquecer as ferramentas de modelagens existentes e partir para a anarquia. Modelar com o código requer muita prática e conhecimento de técnicas como o TDD (que falei e voltarei a falar aqui no AgileZ) que suprirão as necessidades que antes eram exclusividade de ferramentas como a UML. Outro ponto que deve ser considerado é a maturidade de sua equipe. Geralmente times formados com ênfase em especialistas (olá CMMI!) com grupos de analistas, dbas, programadores, arquitetos e testadores não são candidatos a esse tipo de abordagem. Equipes agiles (olá scrum!) quase sempre tem mais probabilidade de trabalhar dessa forma com sucesso.

Há uma diferença nem sempre valorizada entre equipes agilistas e as tradicionais, que fazem com que essa primeira se destaque. Entre os motivos pra isso destaco a liberdade de criação proporcionada pelo ambiente ágil relacionada à menor segregação de papeis por pessoas distintas. Mas isso rende assunto para vários outros artigos, que espero aprofundar mais em breve. Até lá.

Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência.

Vale notar que eu enfatizei que as discussões devem ser breves. Esse ponto é muito importante, pois tem o objetivo de evitar longas argumentações técnicas, que não devem de forma alguma ser o foco de uma estimativa.
Exemplo: quatro membros da equipe jogaram o valor 3 para uma determinada tarefa, e um quinto jogou o valor 8. Houve uma diferença muito grande, e por isso o quinto jogador deve argumentar brevemente porque entendeu que a tarefa demanda mais esforço. Pode ser porque ele não entendeu bem o que deve ser feito, ou porque tem mais experiência naquele tipo de tarefa e conseguiu prever algumas dificuldades que os demais não conseguiram.

Algumas vantagens do Planning Poker:

· Equipe mais comprometida, pois todos participam;

· Força a equipe a ter um conhecimento de negócio mais homogêneo;

· Aumenta bastante a precisão das estimativas, pois considera a experiência de todos;

· Mais atraente (divertida) que as demais técnicas.

Se seu time está tentando implementar o scrum, algumas considerações:

· Estórias são funcionalidades, na forma como tem valor para o cliente (no scrum, o PO ou Product Owner). Exemplo: Eu como usuário quero poder cadastrar um produto;

· Tarefas são as implementações que devem ser feitas para que a funcionalidade seja entregue. Uma estória pode possuir uma ou mais tarefas;

· Nós só conseguimos estimar com precisão as tarefas pequenas. Se estiver estimando em horas, um valor maior que oito já é considerado um ‘chute’, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto, é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia;

· Nem todas as estórias precisam ser detalhadas durante as estimativas. Se você trabalha com scrum, durante o backlog estimate (reunião, geralmente semanal, onde estimamos apenas as estórias de usuário) todas as estórias são reestimadas, e as estórias grandes são quebradas de acordo com a priorização do Product Owner. Dessa forma, as estórias com prioridade mais baixas podem ser estimadas com valores mais altos, e seu detalhamento pode ser postergado para quando se tornarem mais próximas de serem selecionadas para o sprint;

· Estimativas por horas devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaríamos para concluir a tarefa em um dia ideal;

· Estimativas por pontos é uma técnica muito boa para se estimar as estórias de usuário e não as tarefas, que usamos estimativas por horas em dias ideais (veja mais sobre estimativas por pontos aqui).

Existe um site bem interessante onde é possível jogar online o Planning Poker com sua equipe: planningpoker.com. Mas note que o poker real, com cartas de papel, é mais recomendável e geralmente mais ágil. Existem vários sites que fornecem as cartas para impressão, como: sprintplanning.com (para mais, deem uma olhada nas referências da Wikipedia).

Aqui tem uma explicação bem legal sobre como funciona a dinâmica do jogo: www.crisp.se/planningpoker

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners. O André fez uma tradução livre para o português. O post original pode ser visto em One Day in Kanban Land.

Quando trabalhamos com equipes mais enxutas, utilizando metodologias ágeis (como o Scrum), temos um considerável poder de decisão e planejamento sobre o que será implementado em cada build. Digo considerável pois existem vários fatores que influenciam o que fará parte do seu sprint (sprint é uma interação que segue o ciclo PDCA e entrega incremento de software pronto), como a priorização do Product Owner (o cliente), tamanho estimado para cada uma das user stories que farão parte da interação, restrições técnicas e outras.

Durante o processo de estimativa, é comum decompormos as user stories em várias tarefas menores, com o objetivo de facilitar a pontuação de cada uma delas. Esse processo é adequado e, se bem feito, aumenta muito a precisão das estimativas, porém, ao quebrar uma solicitação em atividades menores, corremos um sério risco de perdermos de vista o real objetivo de cada uma das tarefas, que é contribuir para a conclusão de um recurso solicitado pelo cliente. Convém não esquecermos que, para o cliente, essas pequenas atividades geralmente não possuem valor por si, a não ser que todas sejam feitas e a feature solicitada seja entregue.

No parágrafo anterior, introduzi dois conceitos chaves para este artigo: o conceito de feature e valor. Uma Feature pode ser definida como um recurso/funcionalidade e geralmente é escrita da seguinte forma: <ação><resultado><objeto>. Por exemplo <emitir><a nota fiscal><de venda> (para mais detalhes, veja FDD – uma metodologia ágil guiada por funcionalidade). Já valor, neste contexto, é toda feature que traga algum benefício para o cliente, ou seja, é seu cliente (no scrum chamado de Product Owner) quem deve valorar o recurso.

Tendo isto em mente, podemos dizer que uma interação deve ter como principal objetivo entregar uma nova versão/build com novas funcionalidades para o cliente. Toda implementação que não contribua para a inclusão das novas features deve ser considerada tempo perdido e ser removida do sprint. Um pouco radical? Vejamos: refactoring, melhorias visuais, troca de tecnologia, otimizações e outras, será que tudo isto pode ser considerado tempo perdido? A resposta é sim e não. Não se a alteração for necessária para dar estrutura ao desenvolvimento de um novo recurso, e sim se for somente para satisfazer o ego do programador. É claro que tudo tem sua exceção, e uma refatoração visual pode, por exemplo, ser uma necessidade de mercado e ser solicitada pelo departamento de marketing, e por esse motivo ser considerada uma feature de valor devido ao seu significado estratégico para o  mercado.

Ao planejar seu sprint focando em funcionalidades, deverá tomar cuidado para que nenhuma funcionalidade seja entregue pela metade. Por isso, verifique a possibilidade com o cliente de desmembrar recursos maiores em partes, e entregue uma parte a cada final de interação, deixando claro que a cada fim de sprint ele deverá ter uma versão do programa funcionando e com um novo valor agregado.

Relatórios como o Parking Lot, que nos dá uma visão de progresso por feature, são indispensáveis para gerenciar o andamento do sprint e antecipar qualquer problema que implique na não entrega de uma funcionalidade completa para o cliente. Veja abaixo um exemplo:

(imagem de: http://www.featuredrivendevelopment.com/node/1038)

Existem vários outros conceitos utilizados neste relatório, como a divisão de funcionalidades por área de negócio, que não irei explicar aqui neste artigo. Para se aprofundar mais sobre o desenvolvimento dirigido à funcionalidade, leia o excelente livro do Alexandre Magno: FDD em uma casca de banana e veja o que se encaixa na realidade de sua equipe.

Times ágeis estimam pelo tamanho e separam essa estimativa da estimativa de duração. Utilizarei uma metáfora como exemplo para entendermos melhor essa distinção.

Suponha que, em uma bela manhã de domingo, minha esposa me incumba de recolher uma grande pilha de folhas e lixo de um canto do nosso jardim. Após um café da manhã reforçado, posso olhar aquela enorme pilha, analisar e avaliar minhas ferramentas (uma pá e um carrinho de mão) e estimar imediatamente que levarei 5 horas para terminar o trabalho. Para chegar a esse valor, ignorei qualquer estimativa de tamanho e parti diretamente para uma estimativa de duração.

Agora, imagine que eu olhe para a pilha e estime seu tamanho. Baseando-me nas suas dimensões, estimo que a pilha contem cerca de 10 metros cúbicos de sujeira. Essa é minha estimativa do tamanho da tarefa. Mas, nesse caso, somente uma estimativa de tamanho não é lá muito útil. Como no domingo tem um joguinho de futebol, quero saber quanto tempo vou demorar para limpar toda a sujeira. Ou seja, preciso converter minha estimativa de tamanho em uma estimativa de duração.

Uma etiqueta no meu carrinho de mão informa que o mesmo possui uma capacidade de 0,2 metros cúbicos. Dividindo os 10 metros cúbicos de sujeira pela capacidade do carrinho, concluo que precisarei de 50 viagens para dar um fim na bagunça. Ainda estimo que levarei cerca de 3 minutos para carregar o carrinho, mais 2 minutos para movê-lo até a lixeira e outro minuto para retornar com o carrinho vazio. Isso dá um total de 6 minutos por viagem. Como antecipei que precisaria de 50 viagens, chego à uma duração total de 300 minutos, ou 5 horas, para minha tarefa doméstica.

Em ambas as estimativas cheguei a 5 horas de duração. No entanto, a segunda estimativa é mais confiável, pois analisamos uma dimensão absoluta: o tamanho (ou esforço) da tarefa. Na primeira estimativa trabalhamos diretamente com a duração, que é uma dimensão relativa, pois se meu carrinho tiver uma capacidade de carga maior, a duração da tarefa será menor. E se o carrinho possuir uma capacidade menor, a duração da tarefa será maior.

Similarmente, o processo que agilistas utilizam para estimar um projeto de software segue os seguintes passos:

1. Definir as funcionalidades desejadas;
2. Estimar o tamanho das tarefas;
3. Estimar a duração das tarefas;
4. Programar as datas de entrega.

Existem duas medidas de tamanho que podemos utilizar no desenvolvimento de software: pontos de estória (story points) e dia ideal (ideal time). O que são, quais as diferenças entre essas medidas e como podemos utilizá-las será assunto de um próximo tópico.

Enjoy it!

Utilizávamos um quadro de feltro verde que não recomendo. Por baixo do feltro o que existe é um papelão fajuto (isso mesmo!) que após alguns furos perde o tônus e não segura mais nada. Por sorte, encontramos uma alternativa bem legal e de baixo custo. São placas de cortiça auto-colante que podem ser fixadas diretamente na parede.

Na foto abaixo mostramos um pacote com 6 placas dessas. Cada pacote custa R$ 26,90 e cobre meio metro quadrado.

A montagem é muito simples; basta remover o plástico protetor e posicionar a placa no local desejado. Deve-se ter cuidado com a colocação da primeira, pois as outras placas serão alinhadas com ela. Se ela estiver torta o quadro ficará fora de prumo.

Após a colocação da primeira placa, continue colando as placas seguintes, montando o resto do quadro.

Após várias colagens, este é o resultado final.

O legal é que podemos aumentar o quadro se necessário. Basta acrescentar mais placas. Além disso, a cortiça não tem o problema do quadro de feltro, pois ela se fecha quando removemos o alfinete.

Para montar este quadro usamos 3 pacotes de placas, com um custo total de R$ 80,70. É uma ótima opção, que recomendo a todos que quiserem montar um agile board. Espero que gostem da idéia.