Recentemente Joshua Kerievsky, postou as principais diferenças entre as práticas da comunidade ágil e da comunidade de lean startups.
Segundo Joshua, Lean Startup é um método disciplinado, cientifico e lucrativo para descobrir e construir produtos e serviços em que as pessoas se apaixonem.
Lean Startup faz o melhor de ágil ficar mais lean e combinado ao brilhante processo de Customer Development.
Na minha visão, ágil e lean startups tem muito em comum, e na verdade podem ser complementares. Não entendo que as práticas adotadas pelas startups de maneira alguma possam ferir principios ágeis. Lean Startups utiliza formas diferentes (inclusive mais eficazes em muitos contextos) de representar a mesma essência. É importante porém entender que Lean Startups tem uma intersecção com ágil, no diz respeito ao desenvolvimento de software, mas vai além.
A idéia portanto, não é provar o que é melhor, mas explorar as diferenças. Isso dito, vale analisar algumas diferenças das práticas das duas comunidades, destacados por Joshua:
Agile |
Lean Startup |
|---|---|
| Product Roadmap | Business Model Canvas |
| Product Vision | Product Market Fit |
| Release Plan | MVP (Minimal Viable Product) |
| Sprint | Kanban |
| Sprint Review | Pivot or Persevere Decision |
| On-Site Customer | “Get Out Of The Building” |
| User Story | Hypothesis |
| Backlog | “To Learn” List |
| Definition of Done | Validated Learning |
| Red-Green-Refactor | Learn-Measure-Build |
| Customer Feedback | Customer Validation |
| Acceptance Test | Split Test |
| Velocity | AARRR |
| Mock Object | Feature Fake |
| Continuous Integration | Continuous Deployment |
| Certified Scrum Master | Customer Success Manager |
Por favor, deixe seu feedback através de um comentário.
Siga-me no twitter para ficar por dentro das novidades.
Um dos pilares que sustentam a filosofia da Toyota é respeitar as pessoas, e em se falando de Lean Software Development e Desenvolvimento Ágil de Software, não poderia ser diferente.
Respeitar as pessoas significa dar a elas um ambiente de trabalho limpo e seguro, permitir que tenham metas praticáveis e realistas, confiar nelas, significa também, desenvolver uma organização onde as pessoas possam pensar e descobrir as melhores formas de executar seu trabalho ao invés de simplesmente receber ordens de o que e como fazer. É permitir que as pessoas tenham oportunidade de conhecer profundamente seu trabalho, refletir sobre ele e melhorá-lo. E não há trabalho algum que não possa ser melhorado.
Pare e pense. O que você pode fazer para melhorar o seu próprio trabalho?
Lendo o livro Rework de Jason Fried e David Heinemeier Hansson, a famosa dupla da 37 signals, me deparei com um tópico que tenho visto ser abordado na comunidade ágil há algum tempo e estou cada vez mais certo de que se aplica não somente a software mas a qualquer tipo de negócio: Ignore os Detalhes de Antemão.
Isso não quer dizer que os detalhes não fazem diferença. Sim, fazem. Porém, você deve ser preocupar com eles apenas pouco antes de precisar implementá-los de alguma forma. No início de seus projetos ignore-os. Simplesmente decida sobre eles depois. Preocupe-se em fazer o básico primeiro. Lembre-se, você não precisa manter suas decisões para sempre, pode mudá-las no meio no caminho. Mantenha o equilibrio entre rigidez e flexibilidade, os dois extremos são prejudiciais.
Essa mesma linha de pensamento explica porque métodos extremamente prescritivos e burocráticos geralmente não levam a bons resultados. Levantar requisitos com muita antecedência e nível exagerado de detalhes, é um exemplo de engano desse tipo, como sabemos, requisitos mudam, o cliente não sabe bem o quer desde o inicio, e o software deve ser flexível e capaz de evoluir em conformidade com as necessidades de negócio do cliente. Essa abordagem precipitada de levantamento de requisitos é chamada de BRUP (Big Requirements Up Front).
Outro grande erro é o famoso Big Design Up Front (BDUF) em que se tenta criar todo o design de um software antes de sua implementação, novamente a falta de flexibilidade em abordagens como essa geralmente levará qualquer projeto ao completo fracasso.
Em Lean Software development qualquer coisa que termine com Up Front pode ser vista como desperdício. E desperdício é algo que deve ser eliminado porque não agrega valor algum.
Você prática BRUP ou BDUF em sua organização? Tem bons resultados com abordagens assim? Qual é a sua opnião a respeito? Deixe um comentário.
É com grande satisfação que anuncio o Bluesoft Podcast, um podcast em português que tem como objetivo difundir as metodologias ágeis e desenvolvimento de software apresentado por mim e Luiz Faias Jr.
O Podcast já está em seu 4º episódio e abordou temas como:
“Cultura de Aprendizagem”
“Batman da Iteração”
“Restrospectiva do Seis Chapéus”
“Programação em Par“.
Além do tema principal, o podcast apresenta as principais novidades da última quinzena das comunidades ágeis nacional e internacional.
Disponível em aúdio e vídeo, possui um feed que pode ser assinado e um canal no iTunes.
Convido todos a ouvir ao podcast. Sugestões e críticas serão sempre muito bem vidas, mande-as para podcast arooba bluesoft ponto com ponto br.