Vale a pena dar uma olhada no livro, no assessment e no mapa gerado a partir dele, proposto pelo grande James Shore e que proporciona uma visão muito interessante. Tanto em uma pesquisa transversal comparativa entre times de uma mesma organização ou de diferentes organizações, como longitudinal acompanhando uma equipe passo-a-passo em sua trajetória de adoção ágil.
Tomei conhecimento do assessment através do Alejandro Olchik da Ionatec, consultor de grande atuação na comunidade ágil Gaúcha e nacional. É um instrumento pronto para ser usado, uma pesquisa interessante e útil, passível de ser analisada qualitativa e quantitativamente, cruzando com diferentes fontes de dados ou pela aplicação de cálculos estatísticos.
De quebra, ele sugere boas práticas para o desenvolvimento de cada quesito a luz da extreme programming (XP), o que nos abre a oportunidade de pesquisas evolutivas, quem sabe experimentos, com grupos de controle, inserção de novas técnicas e medições de evolução … no site da fera tem muito mais, a seguir o link para o assessment e entender o que há em cada capítulo do livro que o suporta:
Participei do workshop “Da Visão ao Produto” ministrado pelo Daniel Wildt na sede da SUCESU-RS, na companhia de vários colegas de TecnoPUC, a Marines e a Fernanda da RAIAR!, o Felipe e Totti da Develop IT e o Pedro Belleza da HP.
Evento que contou com relatos baseados na grande experiência do Daniel como profissional, empresário, consultor e instrutor. A seguir quais foram os tópicos trabalhados e enriquecidos com as trocas de percepções durante debate entre os 18 participantes, em formato Fishbowl, após exercício prático de StartUp e Business Model Canvas.
Sou casado com a Marines da incubadora RAIAR, que me passou a dica de um site muito didático e completo sobre Lean StartUp, eu já li bastante coisa lá e esta nos meus favoritos – http://www.manualdastartup.com.br/blog/
Quanto a temas e bibliografia sugeridas, listei algumas interessantes e linkei:
Para quem participar dos Workshops o Daniel irá abrir um grupo de discussão para que o conhecimento continue sendo consolidado, onde poderemos perguntar, responder e sugerir entre nós, excelente iniciativa ! 🙂
Qualidade não pode ser avaliada ou pretensamente alcançada através de testes em um produto já construido. Com o uso de TDD temos por objetivo prevenir defeitos em primeiro lugar, desde antes e durante toda a construção do software, permitindo uma medida real de qualidade, que podem ser assim traduzidas:
1. A cada decisão construida e não testada, existe uma grande probabilidade da decisão ou da sua implementação estar errada; 2. Funcionalidades de software que não podem ser demonstradas através de testes automatizados não são confiáveis; 3. Testes garantem que refletiremos sobre o que e onde queremos chegar, independente da forma como a solução será implementada.
Comecei a entender o que de fato era TDD após assistir um Coding Dojo, você inicia pela classe de teste, evoluindo seu código aos poucos, sempre a partir do seu teste unitário. Algumas vantagens desta abordagem são:
• Ajuda na documentação: testes bem construidos são mais simples de ler pela equipe que o próprio código, como se fossem critérios de aceitação; • Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que se foque no imprescindível; • Aumenta a confiança: todos os testes são montados antes e durante a construção do software, dando-lhe maior confiança; • Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer e entregar refactorings.
O código de testes têm 2 funções principais: 1. De especificação, para definir uma regra que seu software deve obedecer. 2. De validação, para verificar que a regra é obedecida pelo software.
Para tornar a construção de testes mais produtivas, existem no mercado frameworks e plugins, como por exemplo o jUnit e Mocks, que são objetos que simulam o comportamento de objetos reais de forma controlada.
O processo de criação de programação orientado a testes segue um ciclo contínuo de desenvolvimento, conforme a seguir referenciado. Estes 3 passos são repetidos até que não se consiga pensar em novos testes, pois a funcionalidade está 100% desenvolvida e testada:
Escrevemos um teste que falhe, ainda para uma classe/método que não existe. Como se fossemos declarar os critérios de aceitação, pensamos primeiro no teste e só depois que o teste estiver pronto, crie somente o suficiente de código necessário para que ele compile e falhe ao rodar.
O passo seguinte é fazer o teste passar, construa um mínimo de código de forma que o teste passe OK.
Agora que temos o mínimo viável de código, refatore e melhore ele um pouco, otimizando-o naquilo que for possível, em pequenos passos. Existe uma técnica chamada FAKE IT,por duplicação através de constantes.
Descobri uma página que diz que aqui na UFRGS, na sala 104 do Prédio 67, tem Coding DOJO toda Segundas-Feira as 15:30 da tarde … quem é da UFRGS tem que verificar e comentar aqui se isso esta rolando mesmo (site).
Uma frase recorrente é, “qual o desafio para nosso primeiro Coding DOJO?”, pois acabei com este impecilho, pois encontrei um site só de desafios sugeridos … lá diz que as sugestões foram utilizadas em 1577 Dojos, eu acredito: http://dojopuzzles.com/
Várias cidades, como Brasilia, RJ, Floripa, etc, tem blogs com a agenda e muito conteúdo sobre TDD e Coding Dojos, achei o de Floripa muito legal, com conteúdo, vídeos, exemplos, livros e tudo o que precisa-se para iniciar:
É uma metodologia ágil para equipes pequenas e médias que atuam em desenvolvimento de software com requisitos em constante mudança, que para solução adota um ciclo iterativo-incremental muito curto, na escala de horas.
Seus valores são a comunicação, simplicidade, feedback, coragem e respeito.
O SCRUM e XP são complementares, enquanto o método Scrum promove um framework com boas práticas de gerenciamento, o XP diz respeito a práticas integradas de engenharia de SW. O nome vem da alusão de se utilizar boas práticas e valores ao extremo, como:
Se revisar código é bom, revise o tempo inteiro, programe em pares;
Se testar é bom, todos testarão o tempo inteiro, teste de unidade e funcionais;
Se o projeto é bom, refatorá-lo será parte das funções diárias de todos;
Se simplicidade é bom, o sistema deve ter o projeto mais simples possível;
Se arquitetura é importante, todos trabalharão para definir e redefini-la;
Se testes de integração são importantes, vamos integrar e testar todos os dias;
Se iterações curtas é bom, faremos elas na escala de minutos e horas;
O cliente esta sempre disponível, para dúvidas e repriorizações cotidianas;
Adotar padrões de codificação em consenso, sempre o mais simples possível;
Só 40 horas semanais de trabalho, descansar garante mais energia e idéias.
Também li sobre seis fundamentos da XP que considerei elucidativas:
1. Distinguir as decisões do negócio e aquelas da alçada da equipe;
2. Escrever testes de unidades antes de programar e manter executando sempre;
3. Praticar Pair Programming, um pouco a cada dia;
4. MVP em produção e seguir na direção que se mostra mais favorável;
5. Integrar e testar todo o sistema várias vezes ao dia;
6. Começar simples e ir refatorando – mais flexibilidade e menos complexidade.
Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas, que devem ser estudadas e praticadas:
Jogo de Planejamento (Planning Game)
Pequenas Versões (Small Releases)
Metáfora (Metaphor)
Projeto Simples (Simple Design)
Time Coeso (Whole Team)
Testes de Aceitação (Customer Tests)
Ritmo Sustentável (Sustainable Pace)
Reuniões em pé (Stand-up Meeting)
Posse Coletiva (Collective Ownership)
Programação em Pares (Pair Programming)
Padrões de Codificação (Coding Standards)
Desenvolvimento Orientado a Testes (Test Driven Development)
Refatoração (Refactoring)
Integração Contínua (Continuous Integration)
Se voce se interessou e leu até aqui, provavelmente vai se interessar pelo link a seguir, tem muita informação, apresentações, palestras, dezenas de exemplos e muito mais … foi um achado e estou compartilhando, se alguém (desenvolvedor Java) descobrir que os exemplos e material não são adequados, por favor, comente aqui, Ok.
