The importance of Test Automation for Business Time to Market

Right after I woked up today, I read this Dan North’s tweet:

Screenshot from 2018-09-23 13:48:42

Trunk-based development makes the development teams integrate and test on a single code, which is the trunk (or master in Git). It is the base for Continuous Integration and Continuous Delivery. This approach brings software releases early, reducing time to market. At the extreme, Lean Startups.

Two weeks ago I was coaching an agile team for the first time, they use feature branches, having a slow cadence of deliveries. They are working on a single product with other three teams in their organization, plus other three organizations. In this case, code integration is a mess and its code is fragile. After a short time, business cannot have fast time to market anymore.

So what is missing?

It is virtually impossible having trunk-based development without test automation. When you need to integrated code, you need to test the feature and every thing related. So doing it manually is insanity. Manual testing can be easy in the beginning, but the software becomes more and more complex. You need test automation.

First of all, your team have to understand the need of test automation. Secondly, they have to learn and practice test automation. Why not try coding dojos or mob programming?

Based on the Redundancy principle of eXtreme Programming, your team can automate tests on critical features, difficult problems, so it can be approached in many ways. Developers focus on unit and integration code mostly, even functional tests. Testers automate functional and many other types of tests. They help each other. There is no right division on that.

Keep something in your mind: “Legacy code is simply code without tests” by Michael Feathers. So every code you commit without tests, it is legacy code.

So cheers for good practices on software development…

2018-08-01_10-37-45
Dionatan Moura (me, left) and Dan North (BDD creator, right) in the conference Agile on the Beach 2017. Falmouth, England.

 

TDD is a practice like swimming

A reader of our eXtreme Programming book asked us a guide to move from 0% TDD programming to 100% (or almost) TDD programming. But, there’s no manual that will really teach TDD, because it’s a practice. We could use a metaphor to explain it, TDD is like swimming, an activity that we practice.

Yes, TDD can be very hard at first time. Like swimming, you might not have enough breathing discipline, getting tired faster and giving it up. And after say “I didn’t like swimming, swimming is not for me”.

As a swimmer needs to jump in the water, a programmer needs to start with a failing test, write code until the test works, and refactor. And repeat these steps a lot of times. It’s a cycle, it’s a mantra:

image
TDD mantra: write a failing Test, Code until pass the test, so Refactor.

After a lot of TDD cycles, you will be understanding how to practice TDD. So, please, jump in the water and enjoy TDD.

— Thanks to Guilherme Motta for the review.

XP Big Picture: Visualizando as práticas do eXtreme Programming

Tudo começou na necessidade de mostrar conexão das práticas na primeira turma do curso de eXtreme Programming. Então na retrospectiva do curso, a Jamile e eu fizemos um rascunho das práticas. Foi só para esboçar o começo: Big Picture v0Simples, né? Já que não temos habilidades de desenho (percebe-se hehe), utilizamos ícones gráficos para representarmos cada prática. E surgiu a big picture abaixo: bigpicturePara baixar o PDF da Big Picture, acesse: https://github.com/dsmoura/xp-big-picture Em cada curso, distribuímos essa Big Picture para cada aluno, assim eles podem colar no ambiente de trabalho para lembrar das práticas e da sinergia entre elas.

“Não basta somente ver, tem que enxergar.” Pensamento Lean


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming

XP Playing Cards: aprendendo eXtreme Programming com muita diversão!

Que tal aprender eXtreme Programming (XP) de um modo bem divertido?

20150420_094518Em 2001, Joshua Kerievsky (Industrial Logic) criou um um baralho de cartas para jogos de XP. Depois de 13 anos, em 2014, a Jamile Alves e eu traduzimos e adaptamos essas cartas para o português, para realizar dinâmicas em turmas do curso de XP, facilitando a leitura aos alunos (e claro, cuidando da relíquia do baralho original da Industrial Logic que ganhei de presente do Rafael Helm).

Tipos das cartas

As cartas são de três tipos:

  • P – Carta de Problema
  • S – Carta de Solução
  • V – Carta de Valor
Screenshot from 2015-05-05 23:10:31
Ilustração das Cartas de Valores.

Baralho em PT-BR para download!

Junto à Industrial Logic, tornamos as cartas traduzidas para PT-BR livres para serem distribuídas, num formato PDF imprimível. Imprimimos numa impressora a laser colorida com uma folha mais grossa que a de ofício, ficou muito legal, é a primeira foto desse post.

Para fazer o download o arquivo do baralho de cartas em PDF, basta acessar: https://github.com/dsmoura/xp-playing-cards

Diversos jogos!

Existem ótimos jogos que podem ser realizados com essas cartas. O jogo que venho utilizando no curso de XP é o de associar soluções a um problema (variação do Explanations). A turma é dividida em grupos pequenos, distribuindo-se as Cartas de Solução igualmente para cada grupo. O facilitador lê uma Carta de Problema, e então o primeiro aluno que falar uma solução (e explicar, se necessário) que possui, descarta a carta. Ganha o grupo que zerar suas cartas de solução. Esse é um jogo que leva uns 45 minutos, com muita diversão. Mas o que mais interessa é que todos reconheçam o porquê de uma prática estar relacionada (ou não) a um problema.

Quer saber mais sobre os jogos da Industrial Logic? Veja no link: http://www.industriallogic.com/blog/xp-playing-cards/

Baralho autografado!

Ah, e no Agile Brazil 2014 eu levei as cartas para tirar foto com o Alexandre Freire, e autografar o baralho, óbvio (haha)!

20141106_123357Bom, esses baralhos viraram relíquia, mas espero que o formato digital seja útil para quem quiser aplicar em times e em cursos para continuar disseminando o eXtreme Programming! 🙂


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming

Scrum e Kaizen (Melhoria Contínua): uma relação de epifitismo

BromeliasEpifitas
Relação de epifitismo de uma bromélia com uma árvore. Fonte: meioambiente.culturamix.com

O Scrum precisa de Kaizen (melhoria contínua) numa relação de epifitismo, do mesmo modo que uma bromélia precisa de uma árvore para se sustentar. Uma relação epífita é quando uma espécie A precisa de outra espécie B para sobreviver, mas não prejudica a espécie B. A foto acima mostra uma bromélia que precisa de uma árvore como base.

Vamos às definições:

Scrum (n): Um framework no qual as pessoas podem resolver problemas complexos adaptativos, enquanto de uma forma produtiva e criativa entrega produtos do mais alto valor possível. http://www.scrumguides.org/

Kaizen: Melhoria contínua de um fluxo completo de valor ou de um processo individual, a fim de se criar mais valor com menos desperdício. http://www.lean.org.br

Scrum é um framework, não é metodologia, nem processo. O objetivo de ser um framework está em trazer práticas de gestão ágil para se encaixarem outras práticas (de gestão e de engenharia). As principais práticas do Scrum são:

  • Trabalhar em Sprints (iterações)
  • Realizar Reunião de Planejamento
  • Reuniões Diárias
  • Realizar Reunião de Revisão (entrega)
  • Realizar Reunião de Retrospectiva (na minha opinião é a prática mais essencial pois é o evento para a melhoria contínua)
  • Ter um papel responsável pelo valor do produto (Product Owner)
  • Ter um papel responsável pelo processo (Scrum Master)
  • Ter um papel responsável pelo desenvolvimento (Time de Desenvolvimento)

Note que o Scrum atua apenas no nível de gestão. O framework é simples de entender, mas não é fácil de utilizá-lo, por isso é essencial a melhoria contínua em sua adoção. Um dos motivos de que um time passa por problemas na adoção do Scrum é porque o time utiliza apenas o framework (que é de gestão) sem utilizar outras práticas ágeis, principalmente de engenharia. Nas reuniões de retrospectiva, utilize a melhoria contínua para evoluir nisso, tanto para práticas gestão quanto de engenharia. Algo muito interessante de investir são em práticas emergentes.

Veja que Scrum não é somente para software, tanto que em seu guia nada se diz sobre software. Ou seja, Scrum não define user stories, integração contínua, ou qualquer outra prática ágil de desenvolvimento de software. Essas práticas estão no XP (eXtreme Programming), que é uma metodologia ágil de desenvolvimento de software, sendo mais prescritiva que o Scrum (obviamente).

Muito se fala que se não adotar o Scrum exatamente, então está se fazendo ScrumBut. Ano passado (2014) no Agile Brazil em Florianópolis, eu estava trocando uma ideia no estande da Adaptworks quando falei que o “Scrum é But por natureza” (querendo dizer que devemos adaptar inclusive próprio Scrum). No mesmo momento, o Alexandre Magno falou: “Não! Scrum é Inspect&AdaptBut!”. Realmente, O Scrum define um mecanismo de inspeção e adaptação, mas proíbe que seu framework seja modificado.

Melhoria contínua no Scrum foi um dos assuntos da palestra O Julgamento do Scrum do Alexandre Magno no Agile Brazil 2013, por sorte eu estava lá assistindo, em Brasília! Essa palestra me fez reconhecer que precisamos refletir a utilidade do Scrum em cada contexto, assim como qualquer outra abordagem ágil. Seguem os slides desta palestra:

Adicionalmente, o Alexandre Magno traz a ideia de Práticas Emergentes, de resolver o problema existente com práticas criativas. Eis a palestra:

E seguem os slides dessa palestra Práticas Emergentes:

“Não é necessário mudar. A sobrevivência não é obrigatória.” William Edwards Deming


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming

Refatoração em Banco de Dados

A Refatoração é uma das práticas importantes no desenvolvimento ágil de software, fazendo parte do dia a dia de um time. O TDD (Test-driven Development – Desenvolvimento Guiado por Testes) tem origem na Refatoração, e ambas são práticas que fazem parte do eXtreme Programming.

Refatoração: uma mudança feita na estrutura interna do software para deixá-lo mais fácil de entender e barato de modificar, sem mudar seu comportamento observável. Martin Fowler.

Além de refatorar código, pode-se também refatorar banco de dados. Hoje na Quarta do Conhecimento da PROCERGS o Fabrízio Mello palestrou sobre bad smells em databases, mostrando os diversos maus cheiros em banco de dados. Segue a apresentação:

E segue também um material extra, um post do Fabrízio Mello no Coding by Example que explica em detalhes o Database Refactoring. Vale a pena conferir:
https://codingbyexample.wordpress.com/2013/07/29/database-refactoring/

“Don’t live with broken windows.” Andy Hunt e Dave Thomas


Conheça mais sobre o livro de eXtreme Programming

livro xp

Link para o livro www.casadocodigo.com.br/products/livro-xp-extreme-programming