Pensando Lean

Nesta ultima sexta-feira, 3/set, eu participei de um fórum organizado pela OnCast sobre Lean em São Paulo.
O Pensando Lean contou com a presença de Mary e Tom Poppendieck, Katia Sullivan, Rodrigo Branas, Luiz Parzianello e Samuel Crescêncio.



Antes de tudo, vou justificar minha ida ao evento. Estou iniciando as pesquisas para meu TGI (Trabalho de Graduação Interdisciplinar - equivalente ao TCC de outros cursos), nesse projeto estou levantando dados sobre o RUP e as novas metodologias para desenvolvimento de software (Scrum, XP, Lean). Por esse motivo comecei a encontrar novos contatos no Twitter, procurando por informações sobre essas metodologias ágeis.
No meio dos tweets desses novos contatos "ouvi falar" sobre o fórum e fiquei muito interessado. Pareceu ser uma boa oportunidade para saber por onde começar e para onde guiar meus estudos.
Confesso que até chegar no evento eu sabia que aquilo afetaria minha vida, mas não tinha idéia do quanto.
Em poucas palavras, para facilitar a compreensão de todos, posso dizer que não sei quanto tempo eu demoraria para saber das existências das coisas que descobri durante o fórum.
Ter contato com pessoas do nível dos Poppendiecks foi uma honra. Confesso que não sabia quem eram, e não sei quanto tempo eu demoraria para saber sobre pessoas tão importantes para a realização desse meu trabalho
O fórum iniciou com a apresentação de Mary Poppendieck que nos trouxe a importância de um Product Champion e do Competency Leader.
Product Champion é responsável por compreender o trabalho do cliente e saber quais são suas reais necessidades, podendo ser um ou mais pessoas (é importante que o product champion tenha grande conhecimento do negócio e também das tecnologias que farão daquele produto um produto campeão)

A winner product has a product champion

Competency Leader atua como um professor (mentor). Esse possui alto conhecimento técnico e capacidade de integrar a equipe. Seu papel é identificar as qualidades da equipe e trabalhar na motivação.

Durante sua apresentação, Mary soltou algumas frases que servem de lição de vida, como:

Comece a produzir seu produto e não pare até estar acabado (aprovado e entregue)
O grupo deve confiar no sucesso do produto, pois ninguém trabalha suas capacidades num produto que não acredita.
Se algo é difícil, deve-se repetir freqüentemente tornando isso mais fácil. (Prática Deliberada)
Quer um bom desenvolvimento, faça em open source pois você terá o feedback de toda uma comunidade.
Você não sai da faculdade pronto para criar o software mais eficiente do mundo. Isso leva tempo, as pessoas que conseguiram fazer um bom produto nessa idade, trabalharam nisso desde os 12 anos.

Quando Mary terminou sua apresentação conheci Rodrigo Branas que veio nos falar sobre o Kanban.
Mantendo a qualidade do fórum, Rodrigo deu uma aula sobre essa coisas até então nebulosa para mim.
Kanban surgiu para viabilizar a organização do processo de manufatura.
Kanban consiste em 3 etapas básicas: Visualizar WORKFLOW -> Limitar Work in Progress -> Medir e Otimizar the flow. Isso tudo visando o Fluxo Contínuo.

Busque a simplicidade, o mínimo que realmente agrega.

Por ser uma variante do Just-in-time, a maior preocupação do Kanban está em tomar cuidado com o estoque. Evitar processos parados (blocks), se algo parou de funcionar, a equipe deve parar o fluxo, resolver aquele problema e então seguir em frente.

Focar em muita coisa, faz você perder o foco sobre todas elas.

Kanban tenta evitar que alguns processos sejam executados somente por comodismo, ou por convenção. Parte do princípio que nem todo projeto é igual. Então para que tratar todos da mesma forma?
Se você trabalha com Scrum, por exemplo: Seria realmente necessário num determinando projeto fazer reuniões diárias com o Product Owner? Será que é sempre necessário fazer iteração, reuniões?

Em seguida, tivemos a apresentação do Luiz Cláudio Parzianello.
O Parzianello trouxe o conceito de Business Analysis. A apresentação foi muito dinâmica e rápida, por isso não consegui anotar muitas coisas. Mas entrando no blog do Parzianello você encontra alguns post sobre o assunto.

Samuel Crescêncio trouxe the Lean Pyramid. Uma imagem muito bacana que traz as iterações dentro do Lean. Não encotrei a imagem para poder disponibilizar aqui para vocês, mas assim que possível atualizo e incluo ela.
Ele também trouxe a teoria sobre o Lean. Seu mais importante Princípio é: cada real entregue pelo cliente deve retornar para ele na forma de um software que agrega valor. Ao contrário de outras metodologias, onde há a presença de um elicitador de requisitos que fala para o programador o que ele deve fazer, sem que esse saiba para que está fazendo aquilo. Num processo lean, cada linha de código que o desenvolvedor escreve, ele sabe como aquilo afetará a vida do usuário.

O principio fundamental é: identificar e separar gasto de valor. Gasto é tudo que sub-utiliza tempo, dinheiro ou espaço

Katia Sullivan deu continuidade no fórum apresentando a ferramenta da VersionOne para desenvolvimento ágil. Katia foi Scrum Master da NASA, e ter contato com alguém que esteve na NASA foi muito legal, ainda mais por sua simpatia e paciencia em tentar compreender meu ingles barato ela também tentou compreender meu espanhol (mas nem isso saiu).

Para o fim estava a apresentação de Tom Poppendieck, Stop-The-Line Quality.

Se voce tolerar defeitos, voce vai tê-los. Portanto, não tolere!

Tom nos trouxe números impressionantes sobre erros de sistema e comentou muito sobre o TDD (Test Driven Development)

A única forma de construir um produto de qualidade é criando a qualidade interna do produto.

No momento do Painel muitas coisas discutidas complementaram essas idéias e ajudaram também a compreender a posição de cada um dos palestrantes.

Quando questionados sobre a diferença entre Equipes auto-organizáveis e Equipes Lideradas, Tom Poppendieck disse que as equipes devem ter uma liderança, dependendo do tamanho da empresa, pois quanto maior, maior também é a necessidadde de manter um padrão de serviço. Porém uma equipe auto-organizável não é uma equipe que não recebe ordens. A diferença entre as duas é que Equipes auto-organizáveis recebe o "What" e sabe o "How".

No Scrum, uma falha apresentada por todos é que a presença de um Product Owner causa falhar no processo de desenvolvimento. Segundo eles, a lista de prioridade não pode ser definida somente pelo P.O, mas sim num consenso de toda equipe. A equipe deve estar envolvida com o projeto a ponto de saber o que vai agregar mais valor e deve ser feito antes.

Por fim, uma analise futurista aponta para um novo perfil de profissional:

É necessário um novo tipo de profissional. Um profissional que tenha além do conhecimento de programação e testes, o conhecimento do negócio para que todos da equipe saibam o que priorizar no projeto.

Concluindo esse post, quero agradecer a todos que tornaram essa oportunidade de amadurecimento profissional possível. Mesmo que eu não tenha absorvido todo conteúdo que precisava para meus estudos, agora tenho uma base e referências bibliográficas que talvez eu não encontraria ainda só seguindo com minha pesquisa acadêmica. Até por que as pesquisas sob metodologias ágeis, a meu ver, ainda não conquistaram a atenção do mundo acadêmico. Por isso a maioria das referências que eu tinha até o momento era TCC ou TGI de anos anteriores. E nem nesses trabalhos eu havia encontrado referências tão boas como os livros dos Poppendiecks.

Tweet