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:
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.
Dia 03/11/2015 (terça-feira) haverá o workshop GUMA Pizza Kanban facilitado pelo Cristiano Basso, no horário das 18:30 às 21:30, na PUCRS. Esse evento é organizado pelo GUMA-RS, o Grupo de Usuários de Métodos Ágeis do Rio Grande do Sul. A ideia é aprender lean e kanban na prática, construindo pizzas (feitas de papel). Show! Né? 🙂
O Kanban Pizza Game é uma dinâmica do agile42, e mostra na prática os princípios do lean, agile e kanban, numa divertida de um jogo. Veja só como fica o quadro de kanban durante o jogo:
Buscando algumas memórias, lembro do FISL 2009 onde estávamos no estande do OpenSolaris (vide fotos a seguir). Naquele ano, o pessoal da Sun compareceu em peso, e veio até o ex-presidente Lula visitar o FISL, ele colocou o boné do OpenSolaris e assinou a camiseta do OpenSolaris! Bom, mesmo anos depois, a participação dele na comunidade de TI permace, dessa vez com uma dinâmica para mostrar o kanban e o ágil na prática.
Cristiano Basso ao centro da foto.O ex-presidente Lula no estande do OpenSolaris no FISL em 2009.Camiseta assinada pelo ex-presidente Lula.
Saiu na InfoQ Brasil a palestra que fiz na trilha de Testes do TDC 2014! Nesta palestra, falo de como o Lean pode potencializar a Qualidade no Software. Segue o link:
Ontem (23/07/2015) realizamos o Lean Beer em Porto Alegre, no mezanino do Lagom Brewery & Pub do bairro Moinhos, unindo o GUMA-RS e o Lean Coffee Porto Alegre. O Lean Beer possui a mesma dinâmica que o Lean Coffee, porém com cerveja! 😉
O Lean Coffee, ou Lean Beer, é uma forma inovadora de discutir assuntos, um modelo muito enxuto em relação às reuniões tradicionais, que por vezes desperdiça tempo e energia das pessoas, além de dinheiro.
A sensação de participar de um Lean Coffee é a de querer mais, os assuntos fluem com foco de uma maneira muito eficiente.
Assuntos discutidos
Quadro de kanban com os assuntos discutidos no Lean Beer.
Os assuntos discutidos foram nesta ordem:
Quais os problemas de gestão que mais incomodam?
Como ser criativo mantendo a produtividade no trabalho, com qualidade de vida?
Aplicação de ágil fora da área de software.
Como escalar o Lean Beer?
O único assunto que ficou de fora, por falta de tempo, foi sobre Management 3.0: salários e considerar desempenho?
Como funciona um Lean Coffee?
Basicamente, o grupo de pessoas realiza os passos:
Definir o escopo dos assuntos (normalmente qualquer assunto é válido).
Escrever em post-its os assuntos que desejam discutir;
Colar os post-its num quadro de kanban com as três raias: todo/a discutir, doing/discutindo e done/discutido;
Cada pessoa vota uma numa quantidade fixa de assuntos. Normalmente, são dois a três votos.
Ordenar os post-its no quadro de kanban de acordo com a quantidade de votação. Quanto mais votos, mais no topo estará na raia todo/a discutir.
Movimenta-se o post-it de maior prioridade para a raia doing no quadro de kanban, discutindo-se abertamente o assunto entre o grupo num período cronometrado de 5 a 10 minutos. Preferencialmente, quem deu a ideia do assunto pode fazer um briefing, explicando a importância daquele assunto.
Ao finalizar-se o tempo (5-10min), o grupo vota caso desejar mais um ciclo de 3 a 5 minutos para continuar discutindo o assunto. Caso a maioria vote que não deseja continuar, então o post-it atual é movimentado para a raia done e volta-se ao passo 6 e discutindo o próximo assunto de maior votação.
Onde posso aplicar um Lean Coffee?
É possível utilizá-lo em muitas situações, basta que se encaixe bem no contexto. Eu já utilizei na minha empresa para discutir assuntos gerais e ideias para a própria empresa. Foi uma ótima fonte de incentivar a inovação. Sei que times ágeis que utilizam para realizar retrospectivas, principalmente quando se tem muitos assuntos para conversar. E participei ontem, no Lean Beer.
Como escalar um Lean Coffee?
O que se faz quando houver mais de 15 ou 20 pessoas para discutir os assuntos? Bom, existem diversas alternativas. Eis algumas:
Restringir o escopo;
Restringir a quantidade de assuntos por pessoa;
Restringir o tempo para escrever os assuntos em poucos minutos;
O “Eureka!” de relacionar métodos ágeis e software livre veio no FISL (Fórum Internacional de Software Livre) no ano de 2013, enquanto eu assistia uma palestra no evento. Dois anos depois, no FISL16, estarei apresentando com a Jamile Alves a palestra métodos ágeis para o desenvolvimento de software livre. Falaremos de Lean Software Development, Kanban, Scrum e eXtreme Programming! 😀
Qual a relação do Pensamento Enxuto e o Desenvolvimento Ágil de Software? Posso dizer que possuem a mesma essência. 🙂 Na Quarta do Conhecimento na PROCERGS em abril de 2015, a Jamile Alves e eu palestramos sobre Lean Thinking, Mentalidade Enxuta para Desenvolvimento Ágil de Software, fazendo a relação entre o mundo Lean e o mundo Ágil.
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: Simples, 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: Para 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
Que tal aprender eXtreme Programming (XP) de um modo bem divertido?
Em 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
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.
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.
Ah, e no Agile Brazil 2014 eu levei as cartas para tirar foto com o Alexandre Freire, e autografar o baralho, óbvio (haha)!
Bom, 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! 🙂
O Nexus é o exoesqueleto para escalar Scrum. Ele guia o coração da questão de escalar – continuamente identificando e removendo dependências criadas pelo aumento da complexidade. Ele é construído no framework do Scrum e valores existentes. O resultado é um grupo efetivo de desenvolvimento acima de 100 pessoas utilizando as melhores práticas da indústria. Para maiores iniciativas, criando famílias de produtos ou interoperando unidades funcionais, foi criado o Nexus +, uma unificação de mais de um Nexus.
Backlog do Produto
Uma lista ordenada de uma única fonte de requisitos para o Nexus. O trabalho de todos Times Scrum individuais é contido neste único Backlog do Produto.
Time de Integração
Um Time Scrum cujo trabalho primário é coordenar e guiar o trabalho dos Times Scrum Nexus. O Time de Integração consiste de um Scrum Master, Dono do Produto, e pessoas com habilidades necessárias.
Reunião de Planejamento da Sprint Nexus
Um evento que cria um plano para o próximo trabalho de Sprint para todos os Times Scrum dentro do Nexus. Esta reunião é estruturada para extrair as dependências, habilitar o trabalho coordenado, e entregar um Incremento integrado.
Backlog da Sprint Nexus
Um plano de alto nível que coordena o trabalho para todos os Times Scrum dentro do Nexus, ressaltando dependências entre times.
Reunião Diária Nexus
Uma reunião de planejamento diário onde os representantes dos Times Scrum de um Nexus avaliam e replanejam o trabalho no Backlog da Sprint.
Revisão da Sprint Nexus
Um evento que coordena totalmente o progresso por inspecionar o Incremento integrado e fazer adaptações apropriadas para o trabalho futuro planejado.
Incremento Integrado
O incremento da funcionalidade criada por todos os Times Scrum ao final da Sprint. A definição de “Pronto” é compartilhada entre os múltiplos Times Scrum.
Retrospectiva da Sprint Nexus
Um evento onde o Time de Integração e representantes dos Times Scrum do Nexus avaliam e melhoram como o Nexus opera.
Em seu blog, o autor Ken Schwaber comentou no dia 01 de fevereiro que mais materiais estão por vir nas próximas semanas (nada ainda surgiu). E também deixou um recado:
“Aqueles de vocês que tem investido e tentado metodologias comerciais para escalar tais como SAFe vão descobrir que esse workshop poderá preencher bem a lacuna que você notou quando teve que realmente estabelecer e rodar um desenvolvimento de software escalado.” Ken Schwaber
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
Dionatan Moura 
Você precisa fazer login para comentar.