A busca por um design perfeito, que esteja preparado para aceitar mudanças e evoluir de forma simples, é difícil. Por esse motivo, a prática de TDD tem sido muito comentada pois, segundo seus praticantes, ela ajuda o programador a criar um design melhor.

Mas, a mais famosa frase da área de engenharia de software já nos diz que não existe bala de prata. Nenhuma prática garante o sucesso de um projeto ou um código de qualidade. As práticas estão lá para tentar manter o programador nessa direção.

E é a mesma coisa com TDD: a prática não resolverá todos os problemas de design que um programador enfrentará. O programador, na verdade, utiliza os testes para guiar o design. É através dele que o programador sabe se está indo no caminho certo ou não. Isso não quer dizer que TDD faz o design sozinho para o programador. É óbvio que o programador precisa ter experiência e conhecimento necessários para que o design saia realmente com qualidade.

Mas um programador que tenha alto conhecimento e experiência em desenvolvimento também pode criar um design com a mesma qualidade. A diferença é que TDD (e os testes gerados) dão feedback muito mais rápido sobre a qualidade. O gráfico abaixo, feito pelo Gleen Vanderburg, mostra o tempo de feedback de várias práticas ágeis. Veja que TDD dá feedback em minutos, ou seja, em alguns minutos o programador tem informações sobre o seu design. Através dos testes ele pode obter informações como a coesão da classe, o acoplamento, a simplicidade, etc. Novamente, o programador usa sua experiência para receber e entender esse feedback.

Figura 1. Práticas e tempo de feedback

Essa é na verdade a grande diferença para o design feito pelo arquiteto-astronauta, famoso no modelo Waterfall, para os designs ágeis. O arquiteto pode ter muita experiência, mas o design que ele faz leva tanto tempo para ser validado e receber feedback que, quando isso acontece, o custo de mudança é altíssimo.

Além disso, o programador ao usar TDD (e por consequência guiar seu design através dos testes) é “forçado” a utilizar bons princípios de orientação a objetos. Os tão falados princípios SOLID passam a fazer mais sentido no momento em que o programador precisa escrever um código que seja fácil de testar. Parafraseando Feathers, existe uma grande sinergia entre código fácil de testar e código bom. Esses bons padrões facilitam o programador a escrever um código mais fácil de testar, apesar do Mark Seemann discordar.

Novamente, a experiência do programador conta. O programador experiente sabe que deve gerenciar as dependências entre classes (DIP), sabe que as classes devem ser coesas (SRP), sabe que elas devem evoluir sem a necessidade de reescrevê-la (OCP), e etc. Programadores que não usam TDD também podem fazer uso desses bons princípios. A diferença é que TDD dá feedback quase instantâneo: a necessidade da utilização dessas ideias aparece após alguns minutos programando, o que não é verdade quando o programador não faz TDD.

Enfim, TDD não faz milagre. Mas ele fica lembrando o programador constantemente sobre a necessidade de manter o código limpo. E a necessidade disso é evidente. Com certeza outros programadores irão encontrar outras práticas que também dão feedback sobre qualidade de design ao desenvolvedor. Mas, enquanto isso não acontece, eu recomendo a utilização de TDD.

Mas lembre-se: é design guiado pelos testes (Test-Driven Design) e não design feito pelos testes!

Suponha o seguinte código:

public class Copiadora {
  public void copiar() {
    var leitor = new LeitorDeXML();
    var escritor = new EscritorPelaSerial();
    while (leitor.TemCaracteres()) {
      escritor.Escreve(leitor.LeCaracteres());
    }
  }
}

Veja que essa classe é fortemente acoplada com duas classes: LeitorDeXML e EscritorPelaSerial. Se quantificarmos isso, podemos dizer que o acoplamento dessa classe é igual a “2″ (já que ela está acoplada a 2 classes).

Mas, ao fazer TDD, você naturalmente criaria um código parecido com isso:

public interface ILeitor {
  bool TemCaracteres();
  string LeCaracteres();
}
public interface IEscritor {
  void Escreve(string conteudo);
}
public class Copiadora {
  private ILeitor leitor;
  private IEscritor escritor;
  public Copiadora(ILeitor leitor, IEscritor escritor) {
    this.leitor = leitor;
    this.escritor = escritor;
  }
  public void Copiar() {
    while (leitor.TemCaracteres()) {
      escritor.Escreve(leitor.LeCaracteres());
    }
  }
}

Veja que agora a classe é acoplada com as interfaces ILeitor e IEscritor. Ainda assim, a métrica de acoplamento nos informaria “2″.

Qual a diferença? A diferença agora é que a classe está acoplada com módulos (classes, interfaces) mais estáveis. A estabilidade, segundo Bob Martin [1], mede o quão difícil (ou improvável) é realizar uma mudança na classe.

As classes LeitorDeXML e EscritorPelaSerial muito provavelmente são acopladas com outras classes (a classe EscritorPelaSerial, por exemplo, deve ser acoplada com alguma outra classe que auxilia na troca de mensagens pela porta serial) e isso faz com que elas possam eventualmente sofrer alterações; são classes mais voláteis. Já as interfaces ILeitor e IEscritor não dependem de nada, são independentes. Além disso, essas interfaces serão implementadas por várias outras classes, e isso faz com que essas interfaces sejam ainda mais difíceis de mudar (afinal, se você mudar uma delas, você vai ter que mudar a implementação em N classes que as implementam), tornando-as assim altamente estáveis.

Podemos dizer então que uma boa dependência é uma dependência com um módulo (ou classe) estável, e uma má dependência é uma dependência com um módulo (ou classe) instável. TDD faz com que o programador acople suas classes com módulos geralmente mais estáveis! Por quê? Porque TDD obriga você a pensar apenas no que você espera das outras classes, sem pensar ainda em uma implementação concreta. Esses comportamentos esperados acabam geralmente se transformando em interfaces, que frequentemente se tornam estáveis.

Para garantir um design de qualidade não basta apenas reduzir o acoplamento, mas sim acoplar com boas dependências! E para medir qualidade de design, também não bastam apenas métricas de acoplamento!

Referências

Esse post é fortemente baseado no trabalho do Bob Martin sobre princípios e métricas de qualidade em design de sistemas orientados à objetos.

[1] Martin, Robert C. Stability (http://www.objectmentor.com/resources/articles/stability.pdf)
[2] Martin, Robert C. Agile Principles, Patterns and Practices in C#

Obrigado a quem compareceu na apresentação! Os slides estão aqui!

Desvios comuns em TDD

View more presentations from mauricioaniche.

Qualquer dúvida, sugestão, crítica, por favor me mandem!

TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.

Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.

Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].

Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!

[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino

You can find the survey at http://spreadsheets.google.com/viewform?formkey=dFlITDZfSTNkVmd5bEVQSFl4cTB3cHc6MA

I also twitted about it (http://twitter.com/mauricioaniche/status/7493800359), so it would nice if you re-tweet!

A primeira palestra foi dada pelo Phillip Calçado, consultor da ThoughtWorks. “Tudo o que eu gostaria de saber antes de virar líder técnico” são um conjunto de dicas que ele aprendeu ao longo do tempo. Uma das lições foi sobre ENTREGAR VALOR o tempo todo, no momento exato e antes que fosse tarde demais! Outra lição interessante foi que IMPREVISTOS ACONTECEM, então ajude a evitá-los! Outras dicas importantes, como TDD, builds rápidos, integração contínua, criação de ambiente de testes parecido (o máximo possível) com o ambiente de produção, cliente sempre por perto, domain-driven design e entregas incrementais e frequentes foram citadas como “barreiras” para ajuda a evitar os imprevistos. Outra dica é para não se desesperar caso a barreira quebre (apenas garanta que você saiba quando ela quebrar). Ele disse uma frase que achei bastante interessante sobre isso: “Não é ser a prova de falhas, e sim tornar seguro falhar”.

A próxima palestra foi do Fábio Kung, sobre Cloud Computing. O Fábio parecia bem animado com o problema que tem em mãos! Foi bastante interessante, mostrando as possíveis diferentes classificações para uma cloud (IaaS, PaaS, SaaS). Explicou muito bem a diferença de cada uma delas, de maneira clara. Além disso mostrou dois vídeos engraçadíssimos sobre um tal de Dr. Cloud (ou algo assim)! Não peguei o link, assim que conseguir coloco aqui!

O lightning talk do Rafael Martinelli sobre Flex também foi bastante interessante. Mostrou vários exemplos de aplicações RIA feitos pela DClick, realmente impressionantes. Ele comentou também que RIA não é apenas “deixar bonito”; há um propósito por trás disso. Uma boa experiência do usuário traz mais retorno para a empresa.

A palestra sobre RESTful Web Services do Luiz Costa e do Sérgio Junior começou com eles contando uma história de uma aplicação que precisava se integrar com outras. E a partir dessa história, mostraram cada tentativa de integração até se chegar em web services. Quando chegaram em REST, explicaram bem as idéias e conceitos. Terminaram falando algumas das vantagens e desvantagens do uso de REST. Os slides estão em http://www.slideshare.net/sergiorjunior/rest-teoria-e-pratica

O Guilherme Silveira e o Filipe Sabella falaram sobre o novo VRaptor3, framework  MVC Java para Web, criado pela Caelum. Contaram a evolução do framerowk desde sua primeira versão em 2004 até agora. Mostraram como é fácil integrar o VRaptor com outros frameworks famosos no mercado como Spring, DWR, Flex. Uma característica interessante é que ele é refactor friendly (se você refatorar um método de um controller, não é necessário alterar XMLs para arrumar os redirecionamentos!). Você pode construir suas aplicações utilizando conceitos de REST também, de maneira fácil (basta utilizar algumas anotações e está pronto). Além de um monte de funcionalidades que já vem de graça com ele, como uploads e downloads de arquivos de maneira fácil, views em JSON, XML, e etc. Enfim, sugiro você avaliar o VRaptor como seu próximo framework para Web. (Ah, detalhe da palestra foi a foto do Filipe dormindo no sofá!).

O Cauê Guerra falou sobre “O Ano do Rails no Brasil”. Mostrou as diversas facilidades do desenvolvimento Rails e mostrou uma série de empresas que já o utilizam. E pra quem pensa que só empresas pequenas usam, ele mostrou uma lista de empresas de grande porte que já utilizam Rails em algumas de suas aplicações! No final, mostrou que já existem boas vagas para profissionais Rails (detalhe para a foto das meninas procurando por Railers!). Os slides da palestra dele estão em http://www.slideshare.net/caueguerra/2009-o-ano-do-ruby-on-rails-no-brasil-caelumday-2009.

O lightning talk do Paulo Silveira sobre Persistência Java foi bastante interessante. Ele mostrou a evolução do processo de persistência de dados em Java, indo desde a conexão direta com o banco até JP, discutindo os prós e contras de cada abordagem. Muito legal o link que ele fez no final com todas as outras palestras do evento.

A última palestra entitulada NoSQL (Not Only SQL) do Nico Steppat comentou sobre banco de dados não-relacionais. Mostrou como é realmente difícil escalar bancos de dados relacionais, comentou sobre banco de dados como CouchDB, Project Voldemort, Bigtable, e etc,  e discutiu sobre técnicas que eles usam para distribuir. Mostrou que conseguimos controlar apenas dois elementos desses três: Consistência, Disponibilidade e Tolerância à Partição (Brewer, 2000). E cada um deve fazer sua escolha dependendo da sua necessidade.

O evento acabou aí, e eu tive que correr pro aeroporto, pois meu avião saia do Galeão! Resumindo, o evento foi muito bom e valeu muito a pena! Espero ir de novo ano que vem!

Por fim, gostaria de agradecer ao Paulo Silveira pelo convite!

O evento acontecerá dentro da Universidade de São Paulo (USP). Os dias 10 e 11 de outubro estão reservados para discussões, trocas de experiências e palestras de especialistas em Programação eXtrema, Scrum, Crystal e nas metodologias mais produtivas do mercado.

Conheça os profissionais que já usam métodos ágeis. Junte-se ao grupo que está revolucionando a maneira de produzir software. Participe das discussões mais atuais do mercado, tire suas dúvidas e descubra como as técnicas ágeis podem ajudá-lo a aumentar a produtividade da sua equipe e a qualidade do seu software.

Este ano, nossos convidados especiais são Jutta Eckstein e Joe Yoder, que ministrarão keynotes e tutoriais durante o evento.

Mais informações em http://www.encontroagil.com.br

Espero vocês lá!

A palestra inaugural foi dada pelo Daniel Wildt e pelo Luiz Parzianello, e o tema foi “Os desafios da cultura Lean no desenvolvimento de software”, e como o próprio título diz, eles nos contaram muito da experiência deles com Lean. A palestra foi muito interessante!

A partir daí, começou a parte difícil: escolher uma das três palestras simultâneas. Todas elas pareciam excelentes. Optei por assistir a “Java Meets Agile” do Giovani Salvador (Dell/RS) e do Guilherme Elias (FUJA). Um detalhe interessante é que a palestra “Introdução ao Scrum” do Samuel Crescêncio (OnCast/SC) lotou, tiveram que fechar a porta da sala porque não cabia mais ninguém! Voltando a palestra do Giovani, ela foi muito interessante, a primeira parte da apresentação sobre conceitos de métodos ágeis, ele pulou, não era necessário repetir tudo de novo para quem estava ali. Em seguida, falou um pouco da perspectiva do arquiteto de software, onde, segundo ele, os arquitetos não devem utilizar arquiteturas genéricas demais quando não necessário, devem “sujar as mãos” e provar a arquitetura, e não devem fazer do projeto do cliente um verdadeiro laboratório de tecnologias! Da perspectiva do desenvolvedor, ele disse que o desenvolvedor deve sempre desenvolver as atividades de maior prioridade antes (e com isso, os problemas aparecerão antes), escrever testes automatizados junto com alguma ferramenta de cobertura de código e constante refatoração. Sugeriu também alguma técnica de pair programming ou peer review. Os slides dessa apresentação podem ser encontradas aqui.

Após a palestra. fomos almoçar em um restaurante dentro da própria PUC-RS. Barato e bom, aprovado!

Na volta, optei por ver a palestra “Anti-Práticas e Anti-Valores Ágeis” do José Peleteiro (Globo.com). A palestra foi bacana também pra ver que todos podemos errar utilizando métodos ágeis, e inclusive grandes empresas como o Globo.com! Houveram muitas perguntas dos participantes, tornando a palestra ainda mais dinâmica. Detalhe aos slides, que foram muito bem trabalhados. Ao final, o ótimo apelo do “salvem os bebês-foca” rendeu palmas dos participantes!

No último horário do dia, optei por ver o workshop de “Simulação de um Projeto Scrum com uma Mini-Fábrica de Aviões”, feita pelo Flávio Steffens (W3Haus/RS) e pelo professor da PUC, Rafael Prikladnicki. A idéia deles foi bem interessante, onde todos nó, em equipes de cinco pessoas, tínhamos que fazer aviões. Mostrou também como nós fazemos coisas sem perguntar primeiro ao cliente, e depois “ficamos bravos” por isso! Mostrou também como nossas estimativas tendem a melhorar depois de alguns sprints.

No segundo dia, a palestra de abertura “A agilidade está no ar – um case na força aérea brasileira” foi dada pelo Alexandre Gomes, Bruno Pedroso e Renato Willi, todos da SEA Tecnologia. A palestra apresentou o case de um aplicativo GED que eles desenvolveram para a aeronáutica brasileira. Muito interessante que eles aplicaram Scrum aos poucos no projeto, mostraram os erros e depois como fizeram para corrigir os mesmos. Mais um exemplo que métodos ágeis só se aprende na prática. Na minha opinião, essa foi a melhor palestra de todo o evento. Os slides estavam muito bem feitos, todos eles com fotos relacionados a aeronáutica!

Em seguida, fui assistir a palestra “Scrum com Soluções simples e de baixo custo”, dada pelo Luiz Faias Jr. (Bluesoft/SP). Muito motivadora também, eles mostraram como eles aplicam Scrum. Detalhe para a tinta magnética junto com os imãs que eles usam para “colar” as histórias na parede, ao invés de usar o tradicional quadro branco. A única partequa não foi tão baixo custo assim, foi quando ele disse que uma tela de plasma avisa quando o build falhou! O problema é que telas de plasma ainda não são de baixo custo!

Fui direto para a palestra do Gustavo Casarotto (Metadados/RS) sobre “Métodos Ágeis x Gestão do Negócio”, onde ele abordou como gerenciar uma empresa que utiliza métodos ágeis. Falou dos principais problemas que temos com isso, e como tentar evitá-los.

Acho que a única parte mal organizada do Agile Weekend ocorreu no almoço de domingo, pois todos os restaurantes da faculdade estavam fechados e tivemos que comer na lanchonete do próprio prédio. Essa, por sinal não suportou 400 pessoas pedindo ao mesmo tempo, e eu levei quase 1h pra conseguir meu X-Frango!

Fui correndo então para a sessão livre sobre “Métodos Ágeis no Ensino Superior”, liderada pelo Daniel Wildt (professor da FACENSA) e pelo Rafael Prikladnicki. Tinham poucas pessoas na sala (por volta de umas 6, 7), e a discussão girou muito em torno de como ensinar e embutir métodos ágeis nas atuais disciplinas dos cursos de computação. Alguns tópicos foram levantados, anotados e farão parte das próximas reuniões.

A última sessão livre “Eu Odeio Métodos Ágeis!”, dada pelo Daniel Wildt também foi legal. Ele discutiu muito sobre pessoas que não aceitam métodos ágeis, sem nem ao menos terem lido ou experimentado. E que após algum uso, acabam mudando de idéia e gostando da metodologia. Pena que ele estava sem conectividade na sala, pois iria mostrar posts e artigos relacionados.

Esse foi o Agile Weekend 2009. Considero uma experiência super positiva, pude ouvir várias experiências pessoais sobre implantação métodos ágeis, cada um com seu problema e solução específicos. Foi muito legal também estar perto de entusiastas de métodos ágeis e ver que o Rio Grande do Sul está realmente interessado no assunto também!

A maioria dos slides ainda não foram disponibilizados, mas irei colocando os links assim que receber.

Pedi também ao Paulo Henrique Martins, amigo que me acompanhou no evento, para dar a opinião dele também. E aí vai:

<Paulo Henrique Martins>

Fui com o Mauricio no evento e posso dizer que ele foi bastante interessante, especialmente para mim, que não tenho um conhecimento muito aprofundado sobre o tema.
Sobre as palestras que o Mauricio não conseguiu assistir:

Enquanto ele assistia a palestra do Jose Peleteiro, da Globo.com, eu assisti uma verdadeira aula, muito interessante, do Luiz Parzianello e do Rafael Prikladnicki – “Jogos Estatísticos para a Promoção de Práticas Ágeis”. Assim como a palestra seguinte, de “simulação de scrum em uma mini-fábrica de aviões”, foi muito interativa e divertida, mostrando na prática situações que os métodos ágeis realmente funcionam. Um dos jogos usados inclusive gerou uma interessante discussão confrontando a necessidade de um time contra a ambição pessoal, tocando no assunto de que as equipes precisam se comportar cada vez mais como times onde todos se dispõem a fazer qualquer tarefa, não especificando radicalmente a função de cada um. Assim, um analista deve ter o bom senso de, quando necessário, “se rebaixar” e programar, fazer testes, colocar a mão em todo o sistema visando o bem geral do grupo.

Outra palestra que eu vi foi o case de “Desenvolvimento Ágil num projeto Global”, de Giovani Salvador, da Dell Computer, enquanto o Mauricio assisita a palestra da Bluesoft. Foi também uma interessante demonstração de métodos ágeis, desta vez em um gigantesco projeto que envolvia 3 equipes de tamanho médio em 3 cidades diferentes. Giovani provou com essa palestra que é possível usar métodos ágeis em projetos de longa distância, mantendo a equipe sempre em comunicação por conferências e revezando o papel de Scrum master entre as equipes a cada sprint.

Por fim, ao invés de assistir a palestra “Métodos Ágeis no Ensino Superior”, acompanhei “Agilizando seu Projeto de Software”, do Bruno Pedroso, da SEA Tecnologia. Ele passou algumas dicas para iniciar a implementação de métodos ágeis nos projetos. Foi interessante e o pessoal da SEA Tecnologia comprovou que realmente sabe dar palestras interessantes e divertidas – a primeira palestra (“A agilidade está no ar – um case na força aérea brasileira”) foi muito bem apresentada, com uma divertida seqüência de slides.

Como desenvolvedor, já estou começando a tentar introduzir algumas técnicas aprendidas aqui na empresa. Foi um evento onde eu realmente aprendi bastante. Parabéns à organização, e, devo dizer que a PUC-RS é uma faculdade muito bonita e moderna.

</Paulo Henrique Martins>

E que venha o Agile Weekend 2010! (ou será Agile Week 2010?)

Assim que voltar, postarei sobre a conferência!:)

Na primeira parte da retrospectiva, a idéia era colocarmos nossas respostas em post-its para três perguntas:

• O que foi bom? O que fizemos bem?
• O que podemos melhorar?
• O que atrapalhou? O que foi ruim? O que não queremos mais?

Havíamos combinado antes que não haveria nenhum tipo de ataque pessoal (nada de respostas do tipo ‘fulano não faz nada’), e que ninguém precisaria identificar-se como autor da resposta. Gastamos então aproximadamente 15 a 20 minutos preenchendo nossos post-its e colando-os na lousa.

A segunda parte e mais interessante da retrospectiva foi a discussão dos problemas. Começamos primeiro pela terceira pergunta: O que nos atrapalhou? A maioria das respostas se encaixou em problemas com o ambiente (falta de café, máquinas lentas, falta de plugins no Eclipse), problemas com testes de interface (realmente não conseguimos até agora executar um teste automatizado de interface no GWT), falta de experiência do time com métodos ágeis (realmente, esse é o primeiro contato da maioria com XP). A única coisa um pouco mais pessoal que rolou foi um ‘pessoas atrasadas nas reuniões gera a necessidade de rediscutir os assuntos’. Eu anotei que senti ‘pouca comunicação com os clientes durante a interação’. Alguns outros problemas como ‘retrabalho por falta de comunicação’ também foram levantados.

Já na segunda pergunta, levantamos que deveríamos ‘melhorar nossas estimativas das histórias’ (estimamos muito mal essas histórias, algumas muito longe do que foi a realidade), ‘mais estudos fora do horário’, ‘comunicação da equipe’, ‘participação maior do time na lista de discussão’, ‘procurar atender melhor as necessidades do cliente’, ‘tarefas acopladas’ e uma muito interessante: ‘validação de histórias concluídas’ (tivemos muitas histórias marcadas como concluídas, mas na verdade, elas precisavam de mais alguns ajustes). Vimos também que deveríamos melhorar no desenho do fluxo de telas do projeto, pois não tínhamos nenhum rascunho e isso estava criando muitas dificuldades para o time (muitos post-its sobre isso!). Houveram sugestões também para refatoração de código, pois alguns membros estavam achando o código muito complicado.

Já para a primeira pergunta (parece ser a mais fácil de responder, mas não é!), a maioria das respostas foram sobre a união e humor da equipe. Algum dos integrantes, provavelmente membro de algum grupo esotérico, escreveu ‘energia do pessoal’ ! Realmente, o time está muito integrado, se ajudando o tempo todo na resolução dos diversos problemas que surgiram durante a interação. Muitos gostaram também de programar pareado, já que a produtividade e qualidade do código cresce muito! Outro detalhe interessante é que houveram muitas respostas do tipo ‘tracking realmente ajuda a ver o andamento do projeto’. Durante toda a interação, tratamos de manter todos os indicadores atualizados, e com isso, tínhamos a visão exata do estado do projeto naquele momento.

Após uma rápida leitura de todos os post-its, resolvemos agrupá-los por categorias, para então acharmos soluções para nossos problemas:

• Sobre os testes de interface, decidimos que não iríamos fazer testes de interface por enquanto, e que nos concentraríamos nos testes da camada de domínio. Para os diversos problemas levantados, foi sugerida a criação de um quadro de dúvidas, e que ao final do dia, iríamos resolvê-las todas com o cliente. Decidimos também que nossas reuniões diárias serão feitas em horários pré-determinados (antes não tínhamos horário fixo!), e que todos devem participar mais das questões levantadas na lista de discussão via e-mail. Sugerimos também o “sino da atenção”, para que quando algum membro do time precisar se comunicar com todos, este deve conseguir chamar a atenção de todos de uma só vez, para não ter que ficar repetindo a mesma informação.
• Combinamos também que tentaríamos refatorar os códigos que estavam por demais complicados. Sobre os problemas de falta de atenção com a interface, decidimos também trabalhar em um rascunho de fluxo das telas, para que todos tenham pelo menos uma visão básica das telas do projeto. Esses mesmos rascunhos serão validados com o cliente antes de serem implementados efetivamente. Sobre as estimativas, acreditamos que nessa segunda interação elas serão melhores. Sobre o problemadas tarefas acopladas, decidimos que vamos trabalhar mais juntos no momento de quebras as histórias em tarefas.
• A parte boa, não há muito o que comentar! Vamos tentar continuar assim, por enquanto não houveram feridos no time!

Fazendo uma análise geral da retrospectiva, vimos que nosso grande problema foi a COMUNICAÇÃO, pois olhando para as ações que definimos, a maioria delas tenta resolver problemas relacionados a comunicação! Ficamos surpresos ao perceber isso! Como já dizia o manifesto ágil, “Individuals and interactions over processes and tools”. E realmente, eles estavam certos!

Criamos um quadro na nossa sala, com as principais ações definidas na retrospectiva, e agora vamos atrás delas!

Tiramos algumas fotos da retrospectiva, que você pode ver aqui, aqui, aqui e aqui.
Curioso com os indicadores? Veja eles aqui, aqui, aqui, aqui, aqui, aqui e aqui.