Posts Tagged "integração contínua"
Agile e Lean Startups
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 |
Bluesoft Podcast: Um podcast sobre Métodos Ágeis em Português
É 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.
Speaker por DRB62
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.
Software Craftsmanship com Uncle Bob Martin
O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.
Sobre o Arquiteto de Software
Foto por Anirudh Koul
Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.
Documentação
O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.
Software Crafsmanship
O termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.
- Você deve sentir orgulho da forma que você trabalho.
- Sinta orgulho de poder fazer Test Driven Development.
- Sinta orgulho de ter alta cobertura de código.
- Sinta orgulho de desenvolver software de alta qualidade.
- Sinta orgulho de ter um bom design de código.
- Sinta orgulho de desenvolver software que realmente agregue valor de negócio aos clientes.
Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.
Qualidade e Relacionamento com Clientes
Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.
Produtividade
Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.
Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves e simples de usar.
Use ferramentas para teste como jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.
Desenvolvimento de Carreira
A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.
Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.
Recado de Uncle Bob no Rails Conf 2009
Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo
