Antes de mais nada deixa eu avisar: eu estou vivo! Tirei um tempo de férias de escrever (aqui e na MundoJava), mas agora estou de volta! E para aquecer, vou relatar um projetinho divertido que participei.
Uma das maiores convicções que tenho sobre desenvolvimento de software é que não existem fórmulas mágicas, nem processos mágicos e nem certificações mágicas… O máximo de “mágico” que pode existir em desenvolvimento de software são alguns profissionais mágicos (infelizmente alguns são adeptos de magia negra). Além disso, “Processo Padrão” é uma coisa que não existe.
O projeto da DDWorks começou de maneira interessante. Numa dessas quintas-feiras de verão, um dos sócios me ligou e disse: “- Quero colocar um e-commerce no ar na semana que vêm”. (nem sei se ainda se usa a palavra e-commerce, mas ele disse assim!)
As condições são:
1. Nós não temos tempo de negociar, não temos tempo de firmar contrato, não temos tempo nem de “planejar” o projeto
2. Tem que estar no ar e vendendo até sexta-feira da semana que vem
3. Tem que ter integração com e-payment ainda a ser definido (no fim optamos pelo PagSeguro)
4. O desenvolvedor tem que estar aqui presente. Vamos dar todos os subsídios e decisões em tempo hábil
5. Já falei que tem que estar no ar na semana que vem?
Qualquer pessoa poderia falar que isso é impossível, porém, o cliente estava disposto a fazer o que fosse necessário para atingir esse objetivo, e nenhum outro fornecedor deu atenção a esse projeto. Eles acharam isso “impossível”. Eu até imagino aqueles vendedores acompanhados de gerentes de projeto (ambos de gravata) dizendo “- Vamos com calma!”, “- Precisamos planejar direitinho.”, “- Vamos detalhar mais…”. O mercado está cansado dessas ladainhas! Como seria um desafio interessante topei na hora. Traçamos alguns objetivos juntos e marcamos uma reunião de planejamento na segunda-feira às 9:00.
Planejamento Inicial de projeto é uma das coisas que mais gosto de fazer. Como o dead-line já estava definido (sexta-feira!!!) essa reunião seria importante para definirmos SOMENTE o que era necessário para VENDER. Toda e qualquer firula a mais deveria ser posta de lado. Este planejamento inicial não tomou mais de 30 minutos, pois o cronometro de 40 horas já estava ticando. O objetivo do projeto era “vender pela Internet”. Planejamentos exigem modelagem, então nós modelamos….
Para iniciar qualquer trabalho nós fizemos um Mapa de Navegação seguindo algo parecido com um diagrama de atividades, mas sem formalidade alguma. Nós precisamos desse modelo para saber o mínimo necessário para “vender”. Além disso nós também usamos esse modelo para saber quais telas eram mais complexas para iniciar o projeto por elas, diminuindo o risco. Sim, esse rascunho era nosso “Product Backlog” para os CSMs de plantão.
Como seriam só 5 dias as iterações eram diárias. Para o projeto, o fim da quarta-feira (a terceira iteração) era o momento crítico. Apesar de ter outras pessoas gerando conteúdo, imagens e modelos, somente eu estava programando no Rails.
Uma das perguntas que faço para meus alunos no curso Scrum da Aspercom é: Com relação a pessoas, o que você precisa para desenvolver software? Pare de ler este artigo e tente responder isso mentalmente. Se você perguntar para um gerente de fábrica de software ele vai responder algo como “1 analista de negócio, 2 analistas de sistemas, 4 programadores e 1 tester”. Acredite, eu já ouvi isso de um deles. Espero que você não tenha respondido isso mentalmente. Mas a resposta correta é que para desenvolver software você precisa de dois tipos de pessoas:
a. Alguém que sabe do negócio
b. Alguém que sabe desenvolver software
No caso da DDWorks, com iterações diárias, praticamente nós fizemos um desenvolvimento conjunto entre os caras de negócio e o programador (eu). Um “pair programming” do Developer com o Product Owner. A adoção do Rais foi definitiva para que cada pedaço de funcionalidade incrementado em 3 minutos fosse rapidamente testado junto ao cliente. Feedback rápido foi determinante para o sucesso. Eu acredito que o futuro do desenvolvimento de software é algo parecido com isso: programadores armados até os dentes com arquiteturas ágeis e clientes participando ativamente do projeto ao ponto de participar de “pair programming”.
Durante essa semana nós fizemos muita inspeção e adaptação. Muitas coisas nós mudamos durante o desenvolvimento. O próprio cliente teve que fazer concessões sobre alguns detalhes (eles são uma agência de design, assim, teve alguns desgastes sobre o tempo investido na “beleza” do site). Não achem que foi “fácil”, quer dizer, programar foi fácil, mas fazer cada detalhe solicitado caber no prazo e no orçamento sem comprometer o objetivo é que foi dureza. Na quarta-feira fizemos o primeiro deployment na Locaweb…. na sexta-feira o site estava no ar!!!! Acessem aí:
http://www.docstyles.com.br
(veja a página “aprenda mais” para saber o que a DDWorks faz)
Uma coisa que achei bastante interessante nesse projeto: nós não usamos Stories, não usamos reuniões, não usamos ScrumMaster, não usamos Kanban, não usamos “Test First”. Não teve qualquer besteirol Agile. Você considera esse projeto ágil?
Guarde esse princípio: Para coisas simples as soluções são simples.
Gostaria agradecer ao pessoal do Brazilian Rails. A contribuição de vocês ajudou muito e poupou um bocado de tempo.
