Em primeiro lugar vale a pena lembrar o nosso leitor de que a Lambda3 não é apenas uma empresa de consultoria e treinamentos. Também temos uma frente de atuação em projetos de software e esta frente vem crescendo cada vez mais.

Recentemente fizemos a entrega de mais um projeto e a idéia aqui é aproveitar este encerramento para refletir sobre o resultado deste trabalho. Fatalmente, surgem lições aprendidas.

O projeto surgiu da necessidade de uma instituição financeira modernizar a nível sistêmico e tecnológico o software que suporta um de seus produtos. Vamos então às lições aprendidas.

• SPA já é uma arquitetura madura

  Implementar Single-page Applications hoje não é tão difícil. Muita gente já apostou nisto e muitas tecnologias que sustentam esta arquitetura estão amadurecendo cada vez mais.
  Para este projeto nós apostamos nesta arquitetura e nos apoiamos em tecnologias como RequireJS, CoffeeScript, Backbone.js e Jasmine.

  Combinadas estas tecnologias suportaram ciclos de desenvolvimento cada vez mais produtivos, sempre amparados em práticas como integração contínua e TDD. O resultado final foi muito bom, tanto para o usuário do software quanto para os desenvolvedores responsáveis por evoluir a base de código daqui para frente.

  Esta não foi a primeira e nem será a última vez em que apostamos em SPA.
  Se você se interessou por esta arquitetura hoje nós oferecemos dois cursos focados em alguns destes elementos.

• Uma arquitetura evolutiva que gerou bons frutos

  As primeiras sprints são sempre mais difíceis de entregar, por conta de todo o setup de tecnologia necessário.
  Apostando em uma arquitetura evolutiva, adiamos algumas decisões e preocupações. Para o setup restante foi muito valoroso o apoio de alguns especialistas da Lambda3. O resultado foi a conquista do cliente logo no início dos trabalhos.

• Distribuído sim. Distante nunca!

  Por todo tempo nosso time esteve distribuído. O time do projeto foi composto por dois Lambdas em São Paulo e dois profissionais de nosso cliente, sediado em outra cidade.
  Reuniões diárias viabilizadas pelo Google Hangout ajudaram bastante. Mas não pode ficar só nisto. Nosso time se entrosou cada vez mais e conversávamos várias vezes ao dia.

• Times pequenos se auto-organizam mais facilmente

  Auto-organização por si só já é uma grande quebra de paradigma. Como você já deve saber a Lambda3 não tem gerentes ou chefes.
  Para este projeto algumas coisas não saíram da maneira que gostaríamos. Mas de maneira bastante natural cada integrante do time aprendeu a contribuir da melhor maneira possível. Tomar, comunicar e inspecionar decisões técnicas foi mais fácil do que nunca.
  Claro que a postura de cada integrante do time sempre é muito determinante, mas o tamanho do time tornou tudo isto mais fácil.

• Cuidado com a capacidade

  Ainda que historicamente as estimativas do time sejam assertivas, é arriscado comprometer toda a sua capacidade no planejamento de uma sprint.
  O comprometimento excessivo da capacidade foi causa raiz para o aparecimento de alguns débitos técnicos.
  Também houveram duas sprints em que o time precisou fazer uso de overtime para conseguir cumprir a meta.
  É importante observar que o uso de overtime foi moderado, pontual e iniciativa do próprio time.
  Não apelar ao overtime e falhar o cumprimento da meta demandaria mais atenção ao problema na retrospectiva da sprint. Possivelmente surtindo um bom efeito a médio e longo prazo.

• Potencialmente entregável

  Deixar de fazer com que o software seja potencialmente entregável ao final de uma sprint é como roubar de você mesmo.
  Fizemos uma manobra que permitiu a entrega de mais funcionalidades mas nenhuma delas era potencialmente entregável. No final nós pagamos um preço por isto mas tudo terminou bem.

• Revise seu planejamento de releases

  Seguimos um planejamento de releases definido cedo demais e ainda influenciado por uma mentalidade waterfall do cliente. Com todo o aprendizado que ocorreu no decorrer do projeto, desperdiçamos a oportunidade de revisar aquele plano para quem sabe, tomar melhores decisões.

• Indisponibilidade do PO

  Em um projeto guiado por um processo Scrum é muito bom quando você sente que o Product Owner entendeu como o time trabalha e se dispôs a colaborar da melhor maneira possível. Por outro lado a falta de disponibilidade deste mesmo PO tira o brilho de sua atuação e impacta o trabalho do time e o andamento do projeto.
  Entre outras coisas, este impacto se apresentou em forma de requisitos confusos e reuniões com perda de foco e demoradas.

Além de lições aprendidas para todos nós, também é importante que cada um cresça como indivíduo.
Particularmente, aprendi que gosto muito mais de JavaScript do que eu poderia imaginar.
Que um browser moderno é uma ferramenta poderosa mas normalmente subutilizada.
E que trabalhar na Lambda3 é melhor do que lasanha.