0

James Shore e o status de equipes ágeis (XP)

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:

http://www.jamesshore.com/Agile-Book/assess_your_agility.html

Lista de capítulos do livro – http://www.jamesshore.com/Agile-Book/

art of agile - shore map

collaboration - shore developing - shore planning - shore releasing - shore shore - thinking

 

1

“Da Visão ao Produto”

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:

  1. A semana de trabalho de 4 horas
  2. Teoria das restrições – A Meta – Eliyahu M. Goldratt
  3. My job went to India (Pragmatic Programmers) – Chad Fowler
  4. Ócio Criativo – Domenico de Masi
  5. Nadismo – Marcelo Bohrer
  6. The seven-day weekend – Ricardo Semler
  7. Voce esta louco? – Ricardo Semler
  8. Rework – 37 Signals
  9. The Lean StartUp – Eric Ries
  10. Paper Prototyping – Carolyn Snyder
  11. Business Model Generation – Alexander Osterwalder, Yves Pigneur
  12. Running Lean – Ash Maurya
  13. The Lean Canvas – Ash Maurya

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 !     🙂

  • Definindo uma identidade:
    • O trabalho nos dias de hoje
    • Ambiente de trabalho
    • O profissional de hoje
  • Um novo movimento:
    • Simplicidade e inovação
    • Entendendo prioridades e propósito
  • Startups:
    • O que é uma startup
    • Seu modelo de negócio (regra 10/20/30)
    • Lean Startup
    • O ciclo Build-Measure-Learn
    • Entendendo experimentos
    • Validando sua ideia
  • Foco no Build-Measure-Learn:
    • Metodologias Ágeis
    • Lean
    • eXtreme Programming
    • Paper Prototyping
    • Métricas
    • Business Model Canvas
    • Lean Canvas
  • Mais algo?
    • Entendendo roadmap x MVP
    • Construindo sua reputação
    • Promovendo seu business
    • E quando mudar? Entendendo o pivot.
1

TDD – Test Driven Development

TDD – Test Driven Development
Kent Beck – 2003

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:

  1. 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.
  2. O passo seguinte é fazer o teste passar, construa um mínimo de código de forma que o teste passe OK.
  3. 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.

Na WikipPedia tem uma página com várias laudas, extensa e didática:
http://pt.wikipedia.org/wiki/Test_Driven_Development

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:

Floripa – http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/
Rio de janeiro – http://dojorio.org/material/
Brasilia – http://www.dojobrasilia.org/pages/sobre_coding_dojo

Também encontrei um vídeo de uma palestra da LocaWeb sobre Dojo que eu gostei muito, é bem extenso, mas muito didático, eu sugiro dar uma olhada:

2

XP – Extreme Programming

XP – Extreme Programming – 1996
Kent Beck, Ward Cunningham e Ron Jeffries
http://www.extremeprogramming.org/

É 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.

Apresentação sobre XP – http://www.argonavis.com.br/palestras/xp/xp.pdf
Material sobre XP + JAVA – http://www.argonavis.com.br/cursos/xpjava/