Dirigindo o desenvolvimento com testes: ATDD e TDD (artigo traduzido)

Elisabeth Hendrickson (mais conhecida como “Test Obsessed”) fez uma apresentação bastante objetiva sobre como utilizar testes de aceitação automatizados para guiar o desenvolvimento de software (TDD com testes de aceitação, ou ATDD) nas conferências STANZ’08 e STARWest’08.

A partir de sua apresentação, ela disponibilizou um artigo bastante simples mas muito ilustrativo sobre o funcionamento de uma estratégia dirigida por testes em ATDD e TDD para equipes ágeis.  Um bom material para se mostrar a quem não tenha muita noção de como funcionam testes ágeis numa equipe de software (p.ex., aquele seu chefe que não leva muita fé em agile).  Artigo este que disponibilizamos traduzido para português aqui.

PS: Nossos agradecimentos à Test Obsessed que permitiu gentilmente a disponibilização deste material.  Thank you Elisabeth!

“Você é responsável pelo software que desenvolve”

A primeira vista você pode pensar que esta frase seja muito óbvia. É claro, afinal de quem mais será a culpa quem mais pode ser responsável pelo software que está sendo desenvolvido senão a própria equipe que o desenvolve?

Apesar de parecer óbvia, se visualizarmos as coisas no desenvolvimento de software (dito “tradicional”) por um dado ponto de vista, podemos ver que muitas vezes nem tudo acaba funcionando assim.  Ao contrário disso.

Se prestarmos atenção, no processo de desenvolvimento “tradicional” (esquema de fábrica de software de empresas 1.0) podemos ver que a cada momento os papeis responsáveis pelo software em cada momento buscam se cercar de todos os meios e se livrar da responsabilidade do software.

SFases do ciclo de desenvolvimento em cscatae não, ou vejamos. Tudo começa com um cliente que tem uma necessidade ou enxerga uma oportunidade.  Isto pode ser uma ideia, um projeto, um desejo.  O cliente tem dinheiro e quer fazer aquilo acontecer, o que ele faz?  Transfere a responsabilidade pela sua ideia, seu projeto, seu desejo –na  verdade, seu futuro software– para uma equipe de desenvolvimento.  Um contrato inicial, um prazo estipulado e… “Ufa, a bola agora já não está comigo. Estou pagando e ao final do prazo já tenho de quem cobrar resultados”.  Com isto, o cliente livra-se da responsabilidade sobre o software para a equipe.

Continue lendo ““Você é responsável pelo software que desenvolve””

Se você não testa, você não é ágil!

O colega Robson Pelegrini reportou na lista [scrum-brasil] uma situação que é comum, principalmente em equipes que estão iniciando no desenvolvimento ágil de software e que (com a devida autorização) transcrevo abaixo:

Pessoal,

Gostaria de saber como vocês tratam a questão dos bugs que surgem dentro do SPRINT, por exemplo:

  • Criam um item no SPRINT BACKLOG, “correção de bugs”
  • Bugs é responsabilidade do time concertar, não podendo esse impactar na entrega do SPRINT

Acredito que a partir da 1ª entrega feito ao PO, temos o que podemos chamar de “legado”, e então começam a surgir bugs e mudanças de requisitos e funcionalidades que geralmente afetam o planejamento feito para o próximo SPRINT.

– Isso costuma ocorrer com vocês ? Como vocês lidam com essas situações ?

Necessário pontuar algumas coisas num cenário como este.  Vamos a elas.

O QUE VEM A SER UM “BUG” DE SOFTWARE?software-bug-03

Como seres humanos, todos estamos sujeitos a erros.  Assim, mais ainda quando estamos lidando com um produto em desenvolvimento, ou seja, que está sendo construindo.  Muitos projetos de software mantém dois ramos do produto –um estável e um em desenvolvimento– justamente para diferir a quantidade de bugs em potencial que podem estar contidos no produto.

Se por um lado tudo isso é verdade, por outro, quando tratamos de desenvolvimento ágil de software, deve-se partir da premissa de que a cada iteração no ciclo de desenvolvimento um item de valor deve ser entregue ao cliente.  São os releases curtos.

Isto posto, cabe nos perguntarmos: afinal o que é um “bug” de software?

Continue lendo “Se você não testa, você não é ágil!”

Por que estudar agile?

Programar para muitos é um “saco”, tarefa para monges budistas. Talvez por culpa de seus professores que empurraram garganta abaixo linguagens e metodologias que os fizeram criar uma repulsa sobre o assunto, ou pelo fato de acharem uma função para cdf’s, pelo contrário existem muitos desenvolvedores que são ditos “normais” e alguns que não são da área de computação e exerce a função pelo prazer de solucionar problemas, superar desafios, exercitar a lógica. Assim como a matemática, a lógica faz parte do nosso cotidiano. Utilizamos “if’s” para analisar um sinal de trânsito e avaliar se devemos atravessar a faixa ou não, “switch case’s” para escolher a refeição de um cardápio, “loop’s” para aproveitar uma festa: comendo, bebendo, dançando enquanto não estiver cansado e tantos outros comandos e operadores lógicos.

A academia nos dá a base para um futuro promissor, mas não é bom acreditar em tudo o que dizem. Questione, duvide, pergunte, pesquise, não se conforme. Falando especificamente de Engenharia de Software, para uma empresa de médio/grande porte é importante uma boa documentação de um sistema, mas será que é preciso documentar de forma demasiada? Será que o cliente ficará satisfeito com um calhamaço de páginas repleto de diagramas, tabelas, cronogramas ou o sistema funcionando? Será que é melhor entregar um sistema “robusto”, “estável” e “completo” no final do projeto e ver que boa parte do que o cliente pediu não foi implementado como ele queria, mas pelo menos as cores das telas estão combinando?

O Manifesto Ágil, criado em 2001 por especialistas em processos de desenvolvimento de software, possui quatro preceitos:

  • Indivíduos e interações em vez de processos e ferramentas;
  • Software executável em vez de documentação;
  • Colaboração do cliente ao invés de negociação de contratos;
  • Respostas rápidas a mudanças em vez de seguir planos.

Cito um exemplo prático: Imagine você pedir para construir sua casa e só vê-la após a obra ter sido concluída. Poderá encontrar surpresas desagradáveis, heim?

Aprenda sobre os métodos tradicionais como: CMMI, PMBOK, RUP, MPS.BR e depois sobre desenvolvimento ágil, para começar formar opinião. Com o tempo se acostumará com terminologias como: Modelagem Ágil, SCRUM, XP, FDD, Lean, Coaching, Sprint Backlog e muitas outras. Você pode se perguntar: Caracas, mais siglas para aprender? Então é melhor rever se você está na área correta. Nunca é tarde para mudar.

Em nossa área, as coisas mudam constantemente. A programação estruturada deu lugar para a orientada a objetos. Sistemas web-based estão tomando o lugar de aplicações desktop. Novas linguagens de programação surgem mais enxutas, rápidas, flexíveis, dinâmicas e adaptáveis. Sistemas de banco de dados são realmente banco de dados e não apenas arquivos de tabelas de dados que não se relacionam.

Por isso, faça o que você gosta e não pare no tempo, porque o tempo não para, já disse o poeta Cazuza.

Usando mapas conceituais para entendimento das regras de negócio

Resumo
Gostaria de apresentar aqui uma prática que me ajudou muito no início de um projeto de software com um nível de conhecimento científico alto. Esse projeto ainda está em andamento, e hoje – depois de um ano – eu posso ver o quanto a adoção dos mapas conceituais me ajudou a entender as regras de negócio e a estabelecer o escopo do sistema e posteriormente o detalhamento das suas funcionalidades.

Desafios
Quando eu entrei no projeto, me deparei com um desafio: criar um software a partir das melhores práticas de zootecnia, estudadas e comprovadas durante anos por especialistas e que agora deveriam ser estruturadas para desenvolver um produto que trouxesse ao produtor rural todo esse conhecimento de forma acessível e que fornecesse benefícios práticos para o seu negócio.

Para isso eu contava – e ainda conto – com uma equipe de especialistas que me dão suporte para esse desenvolvimento. Então eu pensei: “beleza, tenho várias pessoas que sabem tudo sobre o assunto, então construir o sistema vai ser fácil”. Mas peraí, quem vai desenvolver sou eu! Eu preciso conhecer o assunto para poder estruturar o sistema, construir a lógica executada por trás de todas as tarefas e decisões que o sistema deve tomar. Além do mais, cada especialista tem conhecimento construído durante anos sobre um determinado assunto. O que eu realmente devo aprender? Qual parte desse conhecimento deverá entrar no sistema? É preciso filtrar as informações e para isso eu preciso entender como funciona o negócio.

Para responder a essas perguntas e entender como funciona o negócio, eu adotei os mapas conceituais, que me foram apresentados ainda na graduação pela minha amiga e mentora Silvana Rossy. Um mapa conceitual é uma representação do conhecimento utilizada para diversos fins, mais popularmente para potencializar o ensino e aprendizado. Através dos mapas podemos organizar nosso conhecimento. Isso é feito através de conceitos conectados por palavras de ligação, formando uma proposição. Existe muito assunto para se falar sobre mapas conceituais que não cabem a este artigo. Uma interessante representação do que são mapas conceituais pode ser encontrada no site do Cmap Tools, onde eles utilizaram um mapa conceitual para explicar o conceito do próprio mapa conceitual.

Ferramenta
Não é necessário nenhuma ferramenta para criar mapas conceituais, bastam lápis e papel. Porém o uso de uma ferramenta ajuda muito para fins de documentação e modelagem junto aos stakeholders. A ferramenta que eu uso é o Cmap Tools. Ela é fácil de usar e bem prática, permite que várias pessoas modifiquem os mapas remotamente, exporta os mapas para diferentes formatos e os disponibiliza na internet.

Utilizando os mapas conceituais para entender o negócio
A princípio eu li alguns livros e artigos sobre zootecnia de forma geral, para começar a criar alguma coisa. Escrevi minhas primeiras proposições, para então discuti-las separadamente com cada especialista, cada um responsável por uma área do negócio.

Várias reuniões aconteceram, e durante cada uma delas os mapas aumentavam, se modificavam, dúvidas iam surgindo e outras eram solucionadas. O interessante dos mapas conceituais é que através deles é possível construir conhecimento de forma fácil e divertida. Tudo o que eu fiz foi criar alguns pequenos mapas no início. A partir das reuniões, eles cresceram colaborativamente e naturalmente.

É muito difícil abordar um assunto desconhecido para alguém com uma pessoa que sabe muito sobre ele. Como explicar para ela o que eu quero saber? Se deixar, a pessoa fala durante meses sobre aquilo. Os mapas realizam perfeitamente essa tarefa. Foram tantas as vezes que eu entreguei um pequeno mapa para um especialista e ele começou a complementá-lo instintivamente. Cada proposição nova gerava uma conversa e outras proposições surgiam facilmente. No final eu tinha algo parecido com isso:

Mapa conceitual do manejo alimentar
Mapa conceitual do manejo alimentar

É engraçado como diferentes formas de abordar um assunto podem fazer com que o conhecimento se desenvolva de formas tão variadas. Os mapas conceituais me permitiram entender uma área grande de forma rápida e surpreendente; permitiram orgazinar, representar e compartilhar conhecimento.

Além de tudo isso os mapas são úteis para a especificação de requisitos. Através deles é possível delimitar o escopo e definir quais atividades devem compor o sistema. Foi a partir dos meus mapas conceituais que eu escrevi os casos de uso que usei para detalhar cada atividade.

Conclusão
Utilizar mapas conceituais como auxílio ao entendimento das regras de negócio é uma ótima prática que eu recomendo sempre que um projeto de software abordar um assunto de difícil entendimento e/ou com altos níveis de conhecimento científico agregado. Eles ajudam a criar uma ponte entre as pessoas que detêm conhecimento e os desenvolvedores, guiando as reuniões, através de uma linguagem de fácil entendimento e que não necessida de conhecimentos de informática para ser aplicada e entendida.

Peço que, se alguém utilizar os mapas conceituais do jeito que descrevi ou de qualquer outra forma que beneficie um projeto de desenvolvimento de software, poste um comentário ou me mande um e-mail contando como foi a experiência.

Obs: post publicado originalmente no meu blog.

Scrum Overview

Recentemente escrevi meu artigo de conclusão de curso de Sistemas de Informação (IESAM) sobre gerenciar de forma ágil uma implantação de sistemas ERP com Scrum. Com isto resolvi postar um resumo sobre Scrum para aqueles que ainda não o conhecem.

Figura 01
Figura 01

1. Scrum
Scrum é um framework com conjunto de práticas objetivas, papéis bem definidos e totalmente adaptáveis, seu ciclo de vida se resume em interações e funcionalidades incrementais, é um método ágil voltado para gerenciamento de projetos. Com isso, permite um melhor acompanhamento do que está acontecendo durante o projeto, facilitando o ajuste durante o projeto e fazendo com que possamos alcançar os objetivos do projeto de forma ágil. Ou seja, Scrum não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados.

2. Ciclo do processo Scrum
O Scrum é baseado em interações bem definidas, com duração de uma a quatro semanas, também chamados de Sprint. Antes de cada Sprint é realizado todo planejamento inicial do objetivo que o cliente almeja. A partir desse momento é criado o Product Backlog, baseado na visão de negócio do cliente, com todos os requisitos a serem implementados. Depois de preparado todo Product Backlog, é realizada a primeira reunião de planejamento do Sprint, onde são selecionados os itens pelo Product Owner e o Scrum Master a serem desenvolvidos que agregarão mais valor ao negócio do cliente naquele momento e depois colocado na ordem de maior prioridade, em seguida realizamos a segunda reunião de planejamento do Sprint, onde a própria equipe estima o esforço das tarefas, faz a divisão das tarefas entre os diferentes membros e compromete-se a concluir as tarefas no final da interação e define de quanto tempo vai ser a Sprint. A partir desse momento é criado o Sprint Backlog que são as tarefas selecionadas pela equipe para ser executada na Sprint.
A próxima etapa é a execução do Sprint com base nos itens do Sprint Backlog, durante a execução as tarefas são acompanhadas por reuniões diárias que não podem passar 15 minutos e a equipe deve responder três perguntas diante dos envolvidos: O que você desenvolveu até o momento? O que você irá desenvolver? Quais impedimentos você está tendo? Com base nessas perguntas o Scrum Master consegue ter uma visão de como está o andamento do projeto, conhecendo os impedimentos que estão acontecendo.
No final da Sprint é realizada uma reunião de Revisão da Sprint, com o objetivo, de mostrar ao Product Owner e todas as partes interessadas as funcionalidades que foram concluídas. A equipe apresenta os resultados obtidos durante o Sprint e possíveis modificações nos itens do Product Backlog. Logo após é realizado outra reunião de Retrospectiva do Sprint, onde é feito uma “lavagem de roupa suja”, onde os membros da equipe devem responder duas perguntas: O que aconteceu de positivo durante esse Sprint? O que pode ser melhorado para o próximo Sprint?

Figura 02
Figura 02

3. Papéis
No Scrum temos três papéis principais: Product Owner, Scrum Master e a Equipe, abaixo a figura 2 que representa a responsabilidade que esses três papéis têm em relação ao Scrum:

3.1. Product Owner
É o dono do produto, geralmente é representado pelo o cliente. Ele é responsável por definir as características do produto a ser desenvolvido, identifica os requisitos do produto, tira dúvida da equipe quanto ao entendimento dos requisitos. É o único que define a ordem em que esses elementos serão desenvolvidos, de acordo com o valor apresentado pelos clientes e usuários de cada negócio, alimenta o Product Backlog para o planejamento da Sprints. E define as metas e toma decisões relativas Release planejamento. Uma pessoa que desempenha esse papel deve ter as seguintes competências:
– Bom conhecimento de negócio.
– Ser capaz de demonstrar uma liderança, respeitado pelos interessados externos (clientes e usuários). – Ser capaz de tomar decisões no momento certo (não muito cedo, nem muito tarde). – Flexível a mudanças. – Boa comunicação com a equipe. – É importante que ele esteja disponível para responder às perguntas da equipe.

3.2. Scrum Master
É responsável pelo andamento do projeto, pela aplicação das práticas do Scrum. Levando para o lado tradicional é o Gerente de Projeto. Durante o desenvolvimento, ele acompanha a equipe no dia a dia, retirando os impedimentos e ajudando a equipe a se auto-gerenciar, buscando melhor resultado da equipe. Para conseguir isso ele executa as seguintes tarefas:
– Tem como objetivo através das reuniões do scrum animar e motivar a equipe.
– Eliminar impedimentos, tendo em consideração os acontecimentos ocorridos em qualquer momento do projeto, a fim de resolvê-los o mais rápido possível, ao mesmo tempo proteger a equipe e priorizar o comprometimento da equipe com o projeto.
– Certifique-se de que a equipe permanece centralizada no projeto com objetivo proposto inicialmente, que é desenvolver os Itens do Backlog e estreitar colaboração com o Product Owner, e permanece produtivo.

3.3. Equipe
É composta por seus membros (desenvolvedores), que é capaz de realizar todas as diversas tarefas para as quais ele tem responsabilidade coletivamente durante cada Sprint. É capaz de determinar o que precisa ser feito para alcançar o sucesso do Sprint, a equipe deve ser capaz de executar as diferentes tarefas para as quais assume responsabilidade coletivamente durante o Planejamento do Sprint. Isto significa que devem ser de amplo conhecimento, tais como análise, projeto, codificação, testes e outras tarefas. A equipe é geralmente feita de 3 a 10 membros.

3.4. Stakeholder
São aqueles que não participam diretamente do projeto, mas podem influenciar no produto a ser desenvolvido, ou seja, não participa do desenvolvimento, mais está interessado no desenvolvimento do produto e pode ter valores que podem influenciar no crescimento do produto.

4. As práticas do Scrum (Conceitos, Artefatos e fases)

4.1. Product Backlog
A partir de uma reunião inicial com todos os envolvidos e interessados do projeto, são levantadas todas as implementações a serem desenvolvidas a partir da necessidade do negócio do cliente, contém uma lista de requisitos a serem desenvolvidos durante o projeto. É visível a todos, e regularmente atualizado. É apresentado na primeira reunião de Planejamento do Sprint, uma vez aprovado, temos os itens necessários para compor o Sprint Backlog.

4.2. Reunião de Planejamento do Sprint
A reunião de planejamento se divide em duas partes:

4.2.1. Primeira Reunião de Planejamento do Sprint
Com duração de no máximo quatro horas, o Product Owner junto com a Equipe discutem os itens do Product Backlog, são selecionadas neste momento as tarefas que tem mais prioridade para o cliente.

4.2.2. Segunda Reunião de Planejamento do Sprint
Com duração de quatro horas, a Equipe define as tarefas necessárias, estima o esforço das tarefas, a própria equipe faz a distribuição das tarefas entre os membros da equipe, o Product Owner deve está presente para esclarecimento de dúvidas e por fim a Equipe compromete-se em concluir as tarefas.

4.3. Sprint Backlog
São as tarefas que foram selecionadas na reunião de planejamento do Sprint pela Equipe junto com o Product Owner e Scrum Master, é o ponto inicial de cada Sprint.

4.4. Sprint
São pequenas séries de interações que podem ter uma duração de uma a quatro semanas, no final da interação a equipe tem que ter alcançado o objetivo inicial do Sprint, onde a equipe está focada em não como fazer, mas sim em vamos fazer. A equipe executa as tarefas compõem o Sprint Backlog. O objetivo final de cada Sprint é ter um produto incremental e funcional para o cliente. É a fase principal do Scrum, pois é nesta hora que ocorre a execução das tarefas, depois de todo o planejamento inicial. É importante que os restantes das Sprint tenham o mesmo tamanho da inicial para que não causem perda de ritmo da Equipe. É imprescindível que no primeiro Sprint alcance o sucesso, pois é um período delicado, pois as partes envolvidas e interessadas estão com expectativa muito grande em cima do resultado (produto incremental).

4.5. Reunião Diária do Sprint
Reuniões diárias que ocorre todos os dias durante a execução do Sprint, com duração em média de 15 minutos. O grande objetivo dessa reunião é que todos os envolvidos tenham conhecimento de como está o andamento do projeto e também fazer com que cada um relate os impedimentos que estão enfrentando ao executarem as suas respectivas tarefas.
O Scrum Master é o responsável pela condução da reunião, é muito importante que todos envolvidos no projeto estão participando principalmente a equipe, basicamente a equipe responde com clareza a três perguntas durante a reunião:
a. O que foi concluído desde a última reunião? (Neste momento o Scrum Master registra as tarefas que foram concluídas e as que ainda estão pendentes).
b. Quais impedimentos estão tendo durante a tarefa? (O Scrum Master registra os impedimentos relados por cada membro da equipe, e após o termino da reunião irá propor solução para os problemas citados).
c. Qual será a próxima tarefa a ser executada? (Neste momento todos ficam sabendo quais tarefas cada membro da equipe está executando).
O Scrum Master tem como objetivo nessa reunião não deixar com que a reunião perca seu foco, basicamente responder as três perguntas, ter uma visão que a equipe não perdeu o objetivo final do Sprint, e gerenciar os impedimentos que vão acontecendo durante a execução da Sprint. O ponto forma desta reunião é responder apenas as perguntas feitas pelo Scrum Master e ponto.

4.6. Produto Incremental
No final de cada Sprint há uma entrega parcial do produto. O principal resultado de um Sprint é a entrega incremental e funcional de um produto, os impedimentos para entrega dessa etapa e os novos requisitos adicionado durante o desenvolvimento deste Sprint.

4.7. Reunião de Revisão da Sprint
Esta reunião é realizada no último dia do Sprint com duração de no máximo 4 horas e de responsabilidade do Scrum Master, a Equipe não de gastar mais de uma hora na preparação da reunião. Neste momento é apresentado o resultado da Sprint que é o produto incremental com suas funcionalidades pela Equipe e o Scrum Master para Product Owner e os envolvidos do projeto (cliente). Analisaram junto se foi alcançado o objetivo inicial do Sprint, e já discutem novas funcionalidades para atualizar os itens do Product Backlog que vão sendo identificada ao final de cada Sprint.

4.8. Reunião de Revisão da Sprint
É realizada logo após a reunião de revisão do Sprint com duração de no máximo 3 horas com a participação da Equipe, Scrum Master, Product Owner e os envolvidos e interessados. Os membros da Equipe devem responder a duas perguntas?
a. O que aconteceu de bom durante o último Sprint?
b. O que pode ser melhorado para o próximo Sprint?
O Scrum Master registra as respostas e prioriza na ordem que deseja discutir as melhorias e tem como papel também facilitar ao time melhores formas de aplicar as práticas do Scrum.
Por ser uma reunião de lavagem de roupa suja, deve se ter cuidado para não levar pontos pessoais, pois podem ser fundamentais para prejudicar a aplicação das práticas do Scrum. Essa reunião é fundamental para o progresso e sucesso do projeto, é fundamental a clareza e objetividade para que os participantes alcancem o sucesso da reunião.

FabioGr.com