Hola.
A Sr. Nimbus é uma empresa jovem, porém com uma grande bagagem. Atuando como “mão-de-obra sócia”, eu (
GB) e o
Luciano (Luti) trazemos nossa experiência de trabalho em desenvolvimento – eu estive por 17 anos na Hepta Tecnologia, uma das principais parceiras Microsoft no Brasil, trabalhando com consultoria, desenvolvimento e instrutoria. O Luti também esteve por lá, mas o que mais pesa no currículo dele são os 3 anos como Field Engineer em SQL Server na própria Microsoft, reconhecidos recentemente com o título de MVP (
Most Valuable Professional) em SQL Server, um dos poucos aqui no Brasil.
Digo isto porque o assunto que vou abordar necessita mais do que somente a parte acadêmica. Como empresa de desenvolvimento de soluções, e após ter visto mais de um projeto
com uma boa equipe naufragar por não ter
metodologia e não ter um
gerenciamento efetivo, nós criamos nosso processo de desenvolvimento de soluções. E o resultado está muito interessante. Tão interessante, de fato, que resolvi compartilhar um pouco da nossa experiência, na esperança que o relato de nossos acertos (e erros também, claro) venham a ser úteis para quem chegar a ler isto.
Quando fomos criar nosso processo de desenvolvimento, nos preocupamos basicamente com os seguintes pontos:
- Agilidade. Uma empresa pequena não tem muitos “recur$o$”. Temos que fazer nosso tempo render!
- Qualidade. Acho que *todas* as empresas do mercado falam em “fazer com qualidade”. São raras as que entregam com qualidade. Estranhamente, a qualidade não aparenta mais ser um diferencial, pois o cliente já está acostumado a promessas que não são cumpridas. Mas a qualidade não deixou de ser um diferencial; ela é um diferencial “a longo prazo”. Seu cliente, como gerente de uma área de TI, certamente vai reparar no seguinte: Dos sistemas que temos,
- qual é o sistema que “explode” menos na cara do usuário?
- qual é o sistema que experimenta o mínimo de downtime?
- qual é o sistema que responde mais rápido a solicitação de implementação de novas funcionalidades? E sem quebrar as funcionalidades que existiam antes?
- Transparência. O cliente investe dinheiro em nós para receber uma ferramenta que melhore o seu trabalho. Para onde este dinheiro está indo? Será que ele vê a ferramenta crescer, desde quando ela era apenas uma lista de funcionalidades, passando pelas primeiras releases, aonde ele fica meio frustrado (“pô, pensei que ia ter mais coisa…”) até a ferramenta começar a se tornar algo útil no trabalho dele? Ele se envolve? É parte da equipe, se envolvendo com a definição de rumos do trabalho? Ou fica só em pé na amurada, pronto pra pular fora caso algo dê errado e apontar o dedo pra você?
Existem muitos outros aspectos que devem ser considerados ao se criar um processo de desenvolvimento de software, mas temos que começar em algum lugar. Levando estes 3 aspectos em conta:
fazer o mais rápido possível, mantendo uma barra de qualidade alta, e mostrando isto para o cliente, selecionamos duas disciplinas – um framework de gerenciamento de projetos e uma prática de desenvolvimento de software – que, na nossa opinião, permitem alcançar quase que naturalmente estes objetivos. Estas disciplinas são o
Scrum e o
TDD.
Scrum
O Scrum é um framework para gerenciamento de projetos focado na
entrega de produtos, ao invés de focar em
fases ou
marcos, como é comum para outros frameworks. Para saber mais sobre o Scrum, o melhor é ir direto na fonte, o site
Scrum.org, fundado por Ken Schwaber, um dos criadores do Scrum. O
Guia do Scrum é uma publicação gratuita, que dá uma visão rápida de 20 páginas do Scrum. Uma visão mais rápida ainda é fornecida pelo site
ScrumAlliance:
- O Product Owner cria uma lista priorizada de características desejadas para o produto, que é chamada de Product Backlog.
- É iniciada uma iteração, chamada de Sprint, com uma reunião de Planejamento da Sprint (Sprint Planning). A equipe de projeto, ou Time, seleciona um pequeno grupo dos itens mais prioritários do Product Backlog, que irão constituir o Sprint Backlog, e decidem como implementar estes itens, acrescentando detalhes ao Sprint Backlog.
- O Time tem um período de tempo fixo – a duração da Sprint - para implementar estes itens. Uma Sprint deve durar de 2 a 4 semanas. O Time deve selecionar os itens do Sprint Backlog de forma tal que a execução do Sprint Backlog caiba dentro da duração escolhida para a Sprint.
- Diariamente, o Scrum Master (o “coordenador” do Time) organiza uma reunião rápida (Daily Scrum, de onde vem o nome do framework), de 10-15 minutos, aonde cada membro do Time responde a 3 perguntas: Quais dos itens do Sprint Backlog você fechou ontem? Em quais itens do Sprint Backlog você vai trabalhar hoje? Você vê algum impedimento para completar o seu trabalho de hoje? Isto ajuda a manter o Time focado na entrega dos produtos da Sprint, e torna visível qualquer possível impedimento, permitindo que ele seja tratado o mais cedo possível.
- No final da Sprint, o trabalho realizado deve ser “potencialmente entregável” (“potentially shippable”, de acordo com o Scrum Guide): pronto para ser entregue a um cliente, ser comercializado, ou poder ser mostrado a um patrocinador do projeto.
- A Sprint acaba com uma Revisão da Sprint (com o cliente) e uma Retrospectiva da Sprint (internamente ao Time, para correções e melhorias no processo).
- O ciclo se reinicia com uma nova reunião de Planejamento da Sprint.
Estes ciclos se repetem até que o produto seja considerado completo o suficiente, o orçamento acabe, ou seja alcançada uma deadline considerada “final” para o projeto. Independente do fato que provoca o término do projeto, Scrum guia o trabalho de forma que o trabalho mais importante esteja completado quando o projeto termina.
Scrum se adapta bem a dois de nossos pontos iniciais:
agilidade, pois é um framework “sem frescura”, com poucos artefatos, e artefatos que você pode imediatamente
ver que são úteis; e
transparência, ao tornar visível qualquer problema o mais cedo possível, tanto dentro da equipe (no
daily scrum) quanto para o cliente (na Sprint Review). Uma outra característica que nos atraiu no Scrum é que
a natureza dinâmica e incremental do Product Back e dos Sprints Backlogs permite que se comece o desenvolvimento sem que se tenha feito um levantamento completo dos requisitos do sistema. Isto é um pecado capital em outras metodologias, mas tem funcionado bem:
- Isto permite que nós entremos no desenvolvimento o mais cedo possível.
- Desenvolver logo permite que mostremos resultados para o cliente cedo.
- Mostrar resultados cedo – e frequentemente - aumenta o envolvimento do cliente com o projeto, e permite que qualquer desvio de rumo seja alcançado com pequenos ajustes.
(Sim, há uma grande questão aqui. Temos um orçamento pré-aprovado e um prazo fixo dentro do qual estamos trabalhando. Ou seja:
Não foi necessário apresentar valor global ou cronograma para o projeto inteiro. Como eu poderia fazer isto sem ter feito um levantamento detalhado? Esta será uma pergunta a responder “nos próximos capítulos”)
TDD – Test Driven Development
Scrum traz agilidade e transparência, mas ainda precisávamos de algo que nos desse
qualidade. O TDD – Test Driven Development, ou Desenvolvimeno Orientado a Testes – entrou no nosso processo com este objetivo. O TDD é uma prática de desenvolvimento de software na qual você codifica pequenos programas que testam o seu código
antes de codificar o código a ser testado. Um pequeno exemplo:
“
O sistema deve bloquear a conta de um usuário que erre o login 3 vezes seguidas, para evitar ataques ao login deste usuário.”
Testes:
Usuario.Cadastra(“gilberto.uchoa@srnimbus.com.br”, “1234”);
// Testa credencial incorreta
if (Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “6789”) == true)
throw new Exception(“Credencial incorreta passou validação”);
// Testa credencial ok
if (Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “1234”) == false)
throw new Exception(“Credencial correta não passou validação”);
// Erra 2 vezes o login. Na 3a vez o login correto deve ser aceito
Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “xxxx”);
Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “yyyy”);
if (Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “1234”) == false)
throw new Exception(“Credencial correta não passou validação com 2 tentativas erradas”);
// Erra 3 vezes o login. Na 4a vez, o login correto deve ser barrado
Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “xxxx”);
Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “xxxx”);
Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “yyyy”);
if (Usuario.Valida(“gilberto.uchoa@srnimbus.com.br”, “1234”) == true)
throw new Exception(“Credencial correta deveria ser barrada após 3 tentativas erradas”);
Neste ponto, a classe Usuario ainda nem existe. Mas
já tenho um código que a testa. Isto traz vários benefícios:
- Os testes que codifiquei representam as “situações importantes” da classe Usuario. Isto define um nível de qualidade que deve ser alcançado pelo código a ser construído para a classe.
- Já tenho um teste automatizado para a classe Usuario. Posso alterar o código e verificar se a classe continua funcionando após a alteração – basta rodar o teste.
- A classe Usuario ainda não existe, mas ao codificar o teste, “inventei” que ela terá um método bool Valida(string, string), para validar uma credencial. Ou seja, os testes geram o meu Diagrama de Classes (quais serão as classes de alto nível da aplicação e seus respectivos membros).
O ponto 1 garante um nível de qualidade na criação do código (que será tão alto quanto meus testes forem exigentes).
O ponto 2 protege a estabilidade do produto frente a mudanças no código. Isto é importantíssimo para o Scrum: como os itens do Product Backlog só são detalhados quando entram em uma Sprint, detalhes descobertos em uma Sprint podem causar modificações no código já pronto em Sprints anteriores. Se você está usando TDD, não importa: modifique o código, re-execute os testes, e verifique se tudo continua ok (ou veja que há algo errado, e use a informação dos testes para fechar rapidamente na causa do erro).
O ponto 3 mostra como a escrita dos testes cria a modelagem de classes da aplicação. Você cria as classes e seus membros ao efetivamente usá-los em código, o que traz uma grande probabilidade de que esta seja uma boa modelagem.
Isto É Tudo?
Não. Há vários aspectos de um processo de desenvolvimento de software que não são cobertos no espaço {Scrum + TDD}. Mas considere o seguinte:
- Scrum mantem o projeto andando, com revisões frequentes para correção de rumo, e com entrega de produtos.
- TDD cria um nível de qualidade, e protege este nível, além de ter um efeito colateral valioso: gerar a especificação das classes do código.
Temos que começar em algum lugar. Se você conseguir criar na sua organização um processo que naturalmente faz o barco andar, facilita detectar e corrigir desvios de rumo, e permite criar e manter um nível aceitável de qualidade, parabéns. Sua organização já faz mais do que produzir código de qualidade incerta, de forma não-controlada, e gerenciar a insatisfação do cliente com a forma de trabalho, e do usuário o produto do trabalho – o que é uma situação comum no mercado atual. Caso este seja o seu caso, se revolte :-). Revoluções, quando bem motivadas, são uma boa coisa. Procure formas de melhorar, e avalie o uso da dupla Scrum + TDD como um início para a melhoria no seu processo de desenvolvimento de software.
