Blog

Lean Thinking: Mentalidade Enxuta para Desenvolvimento Ágil de Software

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.

Seguem o vídeo compacto da palestra:

E os slides:

“Be lean, be agile!”


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

O Nexus: para escalar e gerenciar grandes projetos ágeis

Essa é a tradução do artigo “The Nexus: for scaling and managing large agile projects” da Scrum.org.

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.

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

Os termos foram mantidos da tradução existente do Guia do Scrum http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf Tradução realizada por Dionatan Moura.

Links referenciados:
https://www.scrum.org/Resources/Nexus
https://kenschwaber.wordpress.com/2015/01/30/more-on-scaling-scrum/
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf

Observações:

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

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

Meditação em um Instante: uma prática de Mindfulness para Agile Coaching

Lyssa Adkins, em seu livro Coaching Agile Teams,  traz diversas dicas para o trabalho de um coach ágil. Um dos capítulos fala apenas sobre “dominar a si mesmo”, porque para ajudar os times você precisa estar em dia consigo mesmo.

Como um coach ágil, você deve estar presente no momento para entender o contexto do que está acontecendo na equipe, poder ver a “big picture”. Para isso, é preciso concentração tendo foco no Agora para saber ouvir, ter certeza no que está falando, falar com clareza, e impactar o time com as palavras. A intervenção de um coach ágil faz diferença no time.

Uma das práticas que ajuda um coach ágil a estar presente no agora é o Mindfulness. Uma prática que gostei bastante é a “Meditação em um Instante” (One Moment Meditation). O vídeo a seguir traz um treinamento rápido para essa técnica.

E tem o app mobile deles (http://www.onemomentmeditation.com/app/), para utilizar em qualquer lugar em qualquer hora do dia.

Vale a pena experimentar essa técnica, nem que seja por um minuto. =)

Aprimore sua produtividade com 25 técnicas de foco e organização pessoal. Conheça o livro do Mantra da produtividade!

livro mantra da produtividade

Link para o livro www.casadocodigo.com.br/products/livro-mantra-produtividade