Rails + Agile na DDWorks

Uma das maiores convicções que tenho sobre desenvolvimento de software é que não existem fórmulas mágicas, nem processos mágicos e nem certificações mágicas… O máximo de “mágico” que pode existir em desenvolvimento de software são alguns profissionais mágicos (infelizmente alguns são adeptos de magia negra). Além disso, “Processo Padrão” é uma coisa que não existe.

O projeto da DDWorks começou de maneira interessante. Numa dessas quintas-feiras de verão, um dos sócios me ligou e disse: “- Quero colocar um e-commerce no ar na semana que vêm”. (nem sei se ainda se usa a palavra e-commerce, mas ele disse assim!) As condições são:

1. Nós não temos tempo de negociar, não temos tempo de firmar contrato, não temos tempo nem de “planejar” o projeto

2. Tem que estar no ar e vendendo até sexta-feira da semana que vem

3. Tem que ter integração com e-payment ainda a ser definido (no fim optamos pelo PagSeguro)

4. O desenvolvedor tem que estar aqui presente. Vamos dar todos os subsídios e decisões em tempo hábil

5. Já falei que tem que estar no ar na semana que vem?

Qualquer pessoa poderia falar que isso é impossível, porém, o cliente estava disposto a fazer o que fosse necessário para atingir esse objetivo, e nenhum outro fornecedor deu atenção a esse projeto. Eles acharam isso “impossível”. Eu até imagino aqueles vendedores acompanhados de gerentes de projeto (ambos de gravata) dizendo “- Vamos com calma!”, “- Precisamos planejar direitinho.”, “- Vamos detalhar mais…”. O mercado está cansado dessas ladainhas! Como seria um desafio interessante topei na hora. Traçamos alguns objetivos juntos e marcamos uma reunião de planejamento na segunda-feira às 9:00.

Leia o restante do artigo e comente no blog “Débito Técnico”:
http://blog.aspercom.com.br/2009/03/03/rails_agile_ddworks/

Artigo Utilizando metáforas no design de software

Felipe Rodrigues, Diretor da Fratech IT, nos presenteia novamente com um excelente artigo chamado “Utilizando metáforas no design de software”, onde aborda questões muito pertinentes da neurociência, aplicadas ao processo criativo dentro do desenvolvimento do software.

Esse artigo através dos temas As metáforas vem para ajuda, Metáforas e os métodos ágeis, Metáforas e Domain Driven Design, Metáfora do Sistema e Criando metáforas, dá uma ênfase bem grande, na visualização e aplicação de metáforas para estimular uma melhor compreensão acerca da dialética relação de criar soluções tecnológicas alinhadas ao desejo do cliente.

Mais uma vez sugiro a leitura completa desse artigo, para ampliar a sua compressão acerca dos mistérios dessa complexa e fascinante atividade de desenvolver software (ou melhor, soluções) para os seus clientes. Portanto, o link para acesso ao artigo completo é: http://www.fratech.net/comunidade/exibir/47 .

Artigo Projetos Ágeis – Levantamento Inicial

Felipe Rodrigues, Arquiteto com larga experiência em desenvolvimento de aplicações críticas, juntamente com Flávia Oliveira Gestora de Negócio e Editora da InfoQ Brasil, escreveram no blog da Fratech IT, um excelente e breve relato de uma experiência em Gestão Ágil de Requisitos num projeto de desenvolvimento de software da sua companhia (localizada em SP).

O artigo através dos temas Definição do objetivo do projeto, Definição das áreas e operações do sistema e Construção de protótipos de telas, mostra com clareza e maestria, o processo ágil de concepção em alto nível de um produto (usando FBS da FDD com conceitos de áreas e atividades).

Outra dimensão muito interessante que artigo aborda, é o uso da Modelagem com Mapas Mentais (M3), para facilitar o processo de aprendizagem acerca do escopo do produto e também afim fomentar a descoberta iterativa e incremental dos detalhes de implementação do produto.

O link para o artigo é: http://www.fratech.net/comunidade/exibir/46

Boa leitura.

Por que usar “story points”?

*Artigo de Rodrigo de Toledo

Usar pontos ou horas é uma discussão recorrente quando se adota métodos ágeis. Por isso decidi escrever um artigo sobre o assunto que pode ser baixado aqui. Nesse artigo eu relembrando os porquês de estimar e explico o sistema de pontuação Fibonacci. 

Medir tamanho/esforço e não tempo traz diversas vantagens listadas abaixo. Vale lembrar que também é possível ser ágil usando medidas de tempo, como Homem-Dia (HDia) para classificar o custo das suas stories e, para tentar ser imparcial, listo algumas desvantagens do uso de pontos.

(Todos os itens abaixo são discutidos em detalhes no artigo)

1.    Vantagens do uso de Story Points

1.1.        Foco em estimativa relativa

Para o ser humano, é muito mais intuitivo fazer estimativas relativas do que absolutas.

1.2.        Performances individuais diferentes

Um problema inerente do uso de Homem-Dia é que essa medida depende do desempenho de quem é esse homem que está executando a tarefa.

1.3.        Foco em tamanho/esforço e não em duração

É natural pensar primeiro em tamanho (do esforço) para depois se calcular tempo. Mas na nossa área, as pessoas perguntam e respondem em medida de tempo sem ser criterioso com o esforço. 

1.4.        Usar HDia sempre leva a um fator de ajuste

Quando se usa medida de tempo em HDia ou acaba-se por contar com um dia cheio de trabalho o que de fato não acontece. Obrigatoriamente é necessário fazer um ajuste, calcular um percentual pelo qual você deve multiplicar seu HDia real em HDia produtivo.

1.5.        Com HDia a aceleração da equipe pode ficar mascarada

Observe que à medida que o seu time vai ganhando experiência no projeto, tarefas de esforço similares tendem a diminuir o tempo necessário para a execução. Caso a opção seja usar HDia, o resultado é uma diminuição na estimativa em horas de novas tarefas e o ganho de produtividade não ficará explícito.

1.6.        Entrada de novo membro na equipe

Quando uma pessoa nova chega ao time, é normal que ela leve um tempo para render o seu máximo. Com HDia há um aumento irreal de produtividade prevista para o time, pois aumenta-se o número de horas trabalhadas. 

1.7.        Evita-se pressões externas sobre as estimativas

É natural que em algum momento as estimativas das stories de um determinado projeto sejam apresentadas a alguém externo, como um diretor ou mesmo o product owner. Caso as estimativas estejam em HDia, se deixa uma margem para discussão podendo sofrer uma pressão para diminuir os prazos (que pode levar a uma queda da qualidade). Com o uso de pontos cria-se uma blindagem! Mesmo que haja pressão para baixar os pontos estimados, como a referência de pontuação é flexível, a conseqüência é apenas uma alteração nessa referência que será refletida na velocidade do time medida também em pontos. Ou seja, o time vai continuar tendo a mesma taxa de entrega de funcionalidades sem perda de qualidade, apenas o número de pontos entregues fica alterado.

 1.8.        Lei de Parkson

A lei de Parkson, escrita originalmente em 1957 por C. N. Parkinson [11], é um problema clássico no gerenciamento de pessoas. A lei sentencia que “o trabalho se expande para preencher o tempo disponível para sua realização”. Ou seja, se você der 5 dias para uma pessoa realizar uma tarefa ela será realizada no tempo estipulado, mesmo se pudesse ter sido feita em 1 dia. Isso acontece como resultado de duas possíveis situações: (i) atraso no início da realização, também conhecido como síndrome do estudante, pois o executor supõe poder concluir a tarefa apenas nos últimos dias; (ii) a tarefa é realizada quase toda no início do prazo, mas o executor estica a sua entrega para poder caprichar em detalhes nem sempre úteis ou mesmo para poder fazer outras tarefas paralelas. A lei de Parkson pode ser evitada se usarmos pontos ao invés de dias nas estimativas, pois se desacopla a execução de uma story a uma data exata de término (apenas a sprint tem data para terminar)! É claro que ela também poder ser evitada em times altamente comprometidos e cujas tarefas estejam bastante claras na sua descrição (especialmente em termos de requisitos de qualidade).

1.9.        A aritmética é fácil

É apenas uma conseqüência menos importante. Somar story points é muito mais simples que somar horas, minutos ou dias. Mas nada que uma planilha Excel não resolvesse…

 

2.    Desvantagens do uso de story points

Como tudo na vida, adotar story points não traz somente benefícios, eles também apresentam alguns prejuízos.

2.1.        Medida não universal

Medir em pontos é uma coisa muito particular e subjetiva, o seu significado acaba fazendo sentido apenas para um time em um determinado projeto. Portanto, não se está prometendo aqui uma medida universal ou um metro quadrado mágico para a indústria de software.

2.2.        Desconforto inicial de alguns

De fato, story points são menos palpáveis que medidas de tempo. Então, pode ser difícil convencer algumas pessoas. Especialmente porque todos sabem que ao final os pontos vão se transformar em estimativas de tempo. No entanto, usando story points, após algumas poucas sprints cria-se uma noção intuitiva de pontos.

 

3.    Conclusão

Usar story points é muito bom, mas fazer Agile continua sendo muito bom, mesmo sem story points.  Existem muitas discussões em torno deste assunto, espero estar contribuindo para resolver algumas dúvidas que tenho visto surgir no dia-a-dia de quem está implantando métodos ágeis.

 

Sobre o Autor:

Rodrigo de Toledo
Rodrigo de Toledo

Rodrigo de Toledo é graduado e mestre pela PUC-Rio e PhD pelo INRIA na França.

Na área acadêmica, tem diversos artigos internacionais em computação gráfica e lecionou por alguns anos na PUC-Rio. 
Rodrigo trabalhou por dez anos no Tecgraf onde desempenhou por um ano o papel de Scrum Master.
Atualmente é engenheiro de software na Petrobras onde atua também como Product Owner, além de se dedicar à divulgação dos métodos ágeis.