Concrete Logo
Hamburger button

Ágil como MacGyver no Caipira Ágil – parte 4

  • Blog
  • 31 de Agosto de 2012
Share

 
Continuação da série que começou com parte 1, parte 2 e parte 3

 

Quais principais conceitos que podem nos fazer ágeis como MacGyver?

Poderia escrever muitos mas vou ficar com os dois que acho bem importantes:

MVP

    Hoje vivemos nos tempos do lean startup. Tempos dos novos conceitos surgidos no meio da primeira década deste milênio a partir do livro do Steve Blank, mais focados em empreenderismo digital ao invés de empreendedorismo tradicional ensinado nos antigos cursos de MBA.

    Quem nos lê com frequência é capaz de pensar: lá vem estes caras para falar da mesma coisa. Realmente já escrevemos muito sobre isto.

    Mas continuamos aprendendo mais cada vez que escrevemos ou cada vez que algum de nós apresenta uma palestra (Fernando de la Riva vai falar 5a feira dia 6/09 às 16:30 no Agile Brazil e participar de uma mesa redonda no Executive Summit às 11:30 do mesmo dia). O aprendizado contínuo é um dos aspectos chaves do pensamento Lean.

    De tanto que compartilhamos nosso aprendizado, nosso blog está virando uma referência em empreendedorismo e em lean startup (condensado em e-book). Concordo com o título do livro do Gil Giardelli: “Você é o que você compartilha” (vale a pena a leitura) e tenho um texto quase pronto mais ou menos sobre isto que sairá brevemente.

    O Eric Ries poderia ter escolhido o termo Agile startup para definir o movimento e isto faria muito sentido mas preferiu seguir o pensamento lean oriundo dos processos de manufatura da Toyota (TPS).

    Parece meio estranho citar processo de manufatura em texto de desenvolvimento de software ou criação de uma startup. Mas como Mary Poppendieck disse ao Kent Beck na conferência XP 2002, “The real lesson of TPS for software are in the way Toyota develops new products, not the way it manufactures”.

     
    Um princípio chave do TPS é eliminar desperdício e seu criador Taiichi Ohno, cita 7 causas em seus livros, entre elas over production. Ora, over production foi o que fiz quase que a minha vida inteira nos tempos em que a gente achava que “mais era melhor”, como aliás disse na parte 1 e também como a Microsoft faz no pacote Office.

    Daí concordo que o lean do nome Lean startup faz mais sentido e ao meu ver, remete diretamente a um dos conceitos mais importantes do movimento: o MVP, Produto Mínimo Viável.

    Isto para vocês pode não parecer novidade mas para mim, que comecei a desenvolver software há 44 anos, foi uma descoberta daquelas de quebrar as pernas.

    Desde já um bom tempo desconfiava que menos era mais, que não eram bons os exemplos como o do Word com suas milhares de “facilidades” que ninguém usa. Mas ainda ficava naquela desculpa esfarrapada de que “uma feature a mais” seria o diferencial competitivo do meu produto. Hoje sei que estava errado.

    Espero que atualmente o conceito de MVP faça parte do cinto de utilidades de todo desenvolvedor ágil.

      Outro parêntesis:

        “A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible”, esta frase está em um texto do Eric Ries que vale a pena rever. O link já foi indicado neste blog: How DropBox Started As A Minimal Viable Product.

     
    Importante: não basta apenas fazer um produto mínimo. Tem que ser também viável como está bem explicado em MVPs que realmente importam são difíceis de fazer e ilustrado na figura abaixo:

    MVPi

 

Ser pragmático com as tecnologias e comprometido com o produto e/ou com a solução

    No fundo somos mesmo resolvedores de problemas. Nossa área é muito dinâmica e o aprendizado é constante. Algumas vezes não temos a menor idéia de como resolveremos o problema ou como desenvolveremos o produto. Mas nos contratam porque sabemos encontrar a solução.

    O cliente que nos apresenta seu problema, que nos pede para colocarmos em funcionamento sua idéia de produto, nem sempre se importa como qual caminho será usado para resolver.

    É relativamente comum a preocupação de quem desenvolve software em usar a tecnologia mais nova ou a mais charmosa. Muitas vezes para obter um MVP, é preciso ser bem pragmático e usar o mais simples. O caminho direto pode passar pelo uso de coisas prontas como por exemplo wordpress, unbounce, etc. e escrever pouco código (perdeu playboy coder).

    Outra consideração que também fiz no meu workshop, é que para ter mais chances de fazer um MVP, é preciso comprometimento de toda a equipe com o produto ou com a solução.

    Não basta cada um fazer sua parte e escrever seu código limpinho. A sobrevivência de todos depende do trabalho da equipe e da satisfação do cliente. Um time que está sempre consciente disto terá mais chances de entregar software que não voltará com reclamações para retrabalho.

 
É isso.

A série para por aqui apesar de talvez ainda ter mais coisa para dizer. O recado final é que o foco deve ser “código funcionando em uso pelo cliente”. Este deve ser o objetivo dos MacGyvers.

E sempre lembrando que um sistema ou um produto nunca termina. O cliente sempre terá uma nova idéia ou algum bug precisara ser consertado e a vítima poderá ser você.

Não deixe Débito técnicoLuca Bastos no GUJ