Menu fechado

Rails + Agile na DDWorks

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….

[photopress:IMG_6230.jpg,full,pp_image]

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”.

[photopress:escolher_modelos.JPG,full,pp_image]

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.

11 Comentários

  1. Bruno

    olá Rodrigo,

    parabéns pelo sucesso do projeto.. você disse que não usou stories e nem test first, mas pelo menos algum tipo de test existiu? ou não?

    Bruno Andrade

  2. Rodrigo Yoshima

    Sim, testes existiram, lógico!!! Porém este site é tão simples e possui tão poucas regras de negócio que a maioria dos testes eram feitos diretamente na tela. Automatizamos com o Selenium via plugin do Firefox (gravando Scripts).

    Foram uns 6-8 scripts só. Na última semana o cliente pediu algumas alterações nas telas para deixar o visual mais clean e mais “popular”. Com isso vários Scripts quebraram. Vamos precisar refazê-los.

  3. Ricardo Brandao

    Olá Rodrigo. Realmente muito bom. Trabalhei algum tempo com E-commerce e sua lista interminável de firulas. Uma semana é o tempo que se leva só pra conseguir marcar uma reunião com uma agência pra passar uma “visão rápida” do objetivo do produto. Achei o resultado excelente, bem como a usabilidade. Parabéns.

  4. Charles

    Olá, Rodrigo.

    “Você considera esse projeto ágil?”

    Tecnicamente falando, me parece mais com Cowboy Coding (conotação positiva!).

    Para não confundir os novatos, Agile – assim como outros processos, bons e ruins – é gerenciável (sustentável, reprodutível, escalável, bla, bla, blável), algo que não dá para deduzir de apenas 1 semana de trabalho de 2 pessoas muito talentosas. 🙂

    Parabéns pelo projeto e pelo resultado! Achei sensacional o relato e o produto final. Valeu por compartilhar conosco!

  5. Rodrigo Yoshima

    Será que já dá para montar uma metodologia Yosha, escrever um livro, montar uma Yosha Alliance, vender treinamentos de US$ 1000 e ficar rico? Ao menos o apelo comercial é ótimo. he he he….

  6. Rafael Cruz Rubert

    Achei bacana o projeto e a forma que foi pensado e implementado mas me passou pela cabeça o porque não ter usado algo pronto como o spree ou substruct? Legal ter usado Ruby, parabéns.

  7. Rodrigo Yoshima

    Rafael, teve certos sites Rails que coloquei no ar que eram customizações do Mephisto (blog engine). Infelizmente não tive boas experiências com essas customizações.

    Como esse cliente queria o site do jeito deles, optei por implementar do zero. Seria um desafio a mais fazer com que cada incremento “entrasse” dentro de um Spree. Compreende?

    No fim, fazer do zero foi uma excelente estratégia. As vezes, entender algo “customizável” demora mais que fazer algo novo.

  8. Pingback:O Analista de Sistemas em Processos Ágeis « Ansiste

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *