AgileZ

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.

Leia mais…

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:

Leia mais…

Como um amigo meu disse certa vez… ‘na internet nada se cria, tudo se copia’. Acabei me rendendo a essa frase, e publicarei uma estorinha já contada em outros blogs. Essa eu peguei do blog do André Dourado (blog muito bom, recomendo). O post original é de Henrik Kniberg, autor do livro ‘Scrum e XP direto das trincheiras’.

É 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. Leia mais…

Estimativas de tamanho são diferentes das estimativas de duração. Ao estimar a duração tentamos estabeler quanto tempo será necessário para concluir uma tarefa. Mas, ao estimar pelo tamanho, analisamos quanto esforço (ou quanto trabalho) será necessário dispender para executar a tarefa.

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.

Leia mais…

Há alguns meses vi um post muito interessante e criativo sobre a montagem do agile board da BlueSoft. Os curiosos podem acessá-lo aqui. Desde então fiquei tentado a aplicar a idéia na empresa onde trabalho e montar para minha equipe um quadro magnético na parede. No entanto, não é uma solução muito barata, a sala é pequena, e se nossa equipe aumentar teremos que mudar de sala… e lá se vai todo o trabalho de pintura.

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. Leia mais…