Por que as Stand-up Meetings são perda de tempo

Uma Stand-up meeting padrão serve para reportar acontecimentos. E reportar acontecimentos na verdade não nos obriga a pensar.

Apenas ouvir relatórios que não são necessariamente da nossa conta também é bastante entediante. Mesmo que seja por apenas 15 minutos. Quem vem participando regularmente de Stand-up meetings entende bem esse sentimento (veja It's Not Just Standing Up: Patterns for Daily Standup Meetings).

As três perguntas padrão para uma stand-up meeting ("O que eu fiz ontem? O que eu vou fazer hoje? Quais são meus obstáculos?") não nos obriga a proagir. Sugiro alterá-las para apenas uma pergunta:

"O que eu vou melhorar a seguir?"

A idéia é fazer com que cada um reflita sobre: "O que eu vou fazer para solucionar o problema que eu estou enfrentando no momento?". É muito mais interessante discutir propostas de soluções do que relatórios de problemas.

É comum as equipes de desenvolvimento terem um monte de opiniões sobre como solucionar os problemas do dia-a-dia das empresas. Mas, infelizmente, na maioria das vezes o que acontece é que os desenvolvedores simplesmente não falam sobre isso.

O ambiente de uma empresa precisa estar acessível as soluções propostas por seus funcionários. Se a equipe de desenvolvimento não é encorajada a oferecer soluções e nem tem a autoridade para implementá-las, o interesse em propô-las é rapidamente perdido.


Quadro de Melhorias   x   Quadro de Tarefas

O conceito de melhoria aqui neste contexto tem dois aspectos:

Primeiro, a equipe de desenvolvimento geralmente é quem tem a consciência das melhores soluções para os problemas de um software, porque os desenvolvedores são as pessoas que possuem o contato mais profundo com o código fonte. Por isso, é muito importante para um ambiente de desenvolvimento Lean promover a mentalidade proativa nos desenvolvedores, ao invés de "Aqui temos o quadro de tarefas que os desenvolvedores estão executando como se fossem robôs".

E o segundo aspecto é que, por outro lado, além de garantir que os desenvolvedores estejam sendo ouvidos nas soluções propostas para o software, no desenvolvimento Lean também é muito importante que o usuário final seja diretamente envolvido nessas discussões. Porque se uma tarefa simplesmente não agrega valor nenhum para o usuário final, mesmo que seja uma excelente solução, ainda sim normalmente não passa de um desperdício de tempo e dinheiro.

Método para Desenvolver Software INCERTO

Eric Ries está brilhantemente nos ensinando a lidar com a incerteza no mundo dos negócios. Já está na hora de aproveitarmos essas técnicas de Lean Startups e aprendermos a aplicá-las em todo o processo de desenvolvimento de software, não mais somente para o mundo das Startups.

Product Backlog não mais!

"You gotta start with the customer experience and works backward to the technology. You can’t start with the technology and try to figure out where you are going to sell it." (Steve Jobs, WWDC 1997)

A realidade hoje, infelizmente, ainda é a de que 80% do software desenvolvido não está sendo utilizado (CHAOS Report Standish Group 2009). O que significa um enorme desperdício de dinheiro. Deveríamos desenvolver software somente depois de termos a certeza de que será utilizado.

É muito comum em projetos de software nem se saber quem são os usuários finais. O Product Owner do seu time de desenvolvimento é um usuário real? Ou é apenas um intermediário? Somente os usuários finais podem esclarecer de alguma forma para a equipe de desenvolvimento o que querem utilizar e como querem utilizar. Somente em uma relação muito próxima com os usuários finais é que as funcionalidades certas são reveladas.

O loop "Build, Measure, Learn", definido para as Lean Startups, deve ser aplicado também no processo de desenvolvimento de software desde o seu início. Na prática isso significa:

Ter sempre uma quantidade mínima de tarefas no Task Board, apenas o suficiente para amparar uma próxima conversa com os usuários finais. (Build)

Medir bem de perto os resultados do ambiente de produção. Como os usuários finais de fato estão utilizando as funcionalidades que já foram desenvolvidas. (Measure)

Estar completamente aberto para os novos direcionamentos que os usuários finais vão revelando ao longo do uso do software, ou seja, não ter um Product Backlog já pré-determinado, impedindo o fluxo das necessidades naturais do software. (Learn)

Figura 1: O loop Build-Measure-Learn das Lean Startups.

Mesmo em aplicações muito grandes e complexas, esse é o caso onde é ainda mais importante evitar o desperdício. O primeiro a fazer é dividir a aplicação muito grande e complexa em um monte de pequenos projetos independentes, que podem ser focados e geridos de uma forma mais precisa e realista. Depois definir com clareza quem são os usuários finais e aproximá-los ao máximo da equipe de desenvolvimento. Quando os projetos de softwares são pequenos e simples, é muito mais fácil para o usuário absorver os conceitos de negócio, entender as necessidades técnicas e prover um feedback preciso. Bem como muito mais rápido e barato para a equipe de desenvolvimento produzir os resultados certos. (Leitura complementar: Conceito de Mini Aplicações)

"(...) And some mistakes we made by the way. Some mistakes will be made along the way. That’s good because at least some decisions are being made along the way. And we’ll find the mistakes and we’ll fix them." (Steve Jobs, WWDC 1997)  R.I.P  :_-(

Um Método para Desenvolver Software Incerto

Figura 2: O poster do Desenvolvimento Ágil adaptado para o Software Incerto

O Desenvolvimento Ágil é sem dúvida um grande avanço para a humanidade. Mas mesmo com as metodologias e ferramentas de desenvolvimento Ágeis ainda existe muito desperdício, muito backlog, muita repetição de documentação e muito planejamento no processo de desenvolvimento de um software.

O Desenvolvimento Ágil inicia seu processo com a construção do Product Backlog. Já o Método Incerto inicia o seu processo de desenvolvimento com a identificação dos Minimum Viable Products da aplicação.

Para se identificar um MVP, é necessário ter muito conhecimento sobre os usuários (e clientes) da aplicação, caso contrário, o software nunca será viável (Leia também: Definindo o seu MVP). É muito comum Product Owners terem difículdade para minimizar e priorizar requisitos. Eles normalmente querem que tudo seja feito e com urgência. Não raramente um Product Backlog tem vários itens com a prioridade máxima. Mesmo que eles ainda pensem que tudo pode ser feito, a inicialização do desenvolvimento pode ser facilitada identificando-se qual será a primeira funcionalidade a ser entregue de imediato, ou seja, basta colocar as prioridades máximas em uma ordem e selecionar somente a primeira. O objetivo é que a equipe de desenvolvimento tenha um ponto por onde começar. A partir daí, as próximas prioridades deverão ser definidas de acordo com os resultados das entrevistas com os usuários finais (ver em breve: User Driven Development, post em construção).

Na Figura 2 acima encontra-se um resumo das adaptações sugeridas para o processo de desenvolvimento Ágil. São elas:

• Distribuir um MVP para cada time de desenvolvimento. (One MVP)

• Entrevistar constantemente os usuários finais e medir o grau de utilização de cada funcionalidade que está sendo adicionada no ambiente de produção. (Acceptance) 

• Substituir as inúmeras reuniões de estimativas e planejamento por uma rápida priorização de tarefas baseada em dados empíricos extraídos das medições do ambiente de produção. (Mini Iteration Plan)

• Engajar diretamente a equipe de desenvolvimento com os usuários finais para que os próprios desenvolvedores possam criar as soluções mais adequadas para o software que está sendo construído. (Improvements Meeting)

• Criar tarefas dinamicamente baseando-se nos dados de uso do software. (User Driven Development - UDD, post em construção)

Figura 3: O Manifesto Ágil  revisado para Software Incerto.

Abordagens não sistêmicas são muito úteis​​, como low fidelity prototypes ou qualquer outra prática de UX (User eXperience). Mas tenha em mente que entrevistar um usuário final pessoalmente, em frente ao software em funcionamento, tem valor inestimável para um desenvolvedor. A atmosfera psicológica que é formada em um momento como este, fornece uma percepção única com tanta informação preciosa para o desenvolvedor que nenhum documento e possívelmente nenhum intermediário podem descrever.

Figura 4:  Novo modelo para o Quadro de Tarefas (ou ainda, Quadro de Melhorias).

One MVP 

Entendo que praticamente qualquer funcionalidade tem dependências externas. É difícil isolá-las e desenvolvê-las de forma independente. Mas se a equipe de desenvolvimento puder simular (mock-up) as dependências externas e focar em cada MVP separadamente, as perspectivas se tornam muito mais claras, e facilmente surgem diferentes possibilidades de implementação para esse MVP. O vantagens são enormes. O que normalmente acontece é que várias dessas dependências nem precisarão mais ser implementadas, porque o planejamento começa a sofrer drásticas alterações depois que se começa a dialogar com os usuários finais.

"É preciso entender profundamente a essência de um produto para podermos nos livrar das partes não essênciais." (Jonathan Ive, Designer chefe da Apple)

Cada equipe de desenvolvimento deve focar-se em seu próprio MVP e começar a trabalhar com as tarefas determinadas para a primeira funcionalidade priorizada. Um Task Board pode ser utilizado, Improvements Meeting, Retrospectivas, etc, mas o mais importante é entregar algo o mais rápido possível no ambiente de produção, para que os usuários finais possam manipular o software pessoalmente e o loop Build, Measure, Learn possa girar o mais eficiente possível.

Depois que os usuários já estiverem satisfeitos com o atual MVP, é a hora de começar o próximo. A interação com os usuários neste momento já estará bem mais fluente. Será mais fácil identificar o que eles querem a seguir. E comumente eles não se importam muito que o software seja super flexível e adaptável, ás vezes nem mesmo que tenha alguns errinhos minoritários. Normalmente o que eles preferem é um software que tenha personalidade, algo que eles possam dizer "Que legal!".

O conceito dos Mini (& Lean) Apps

Depois que instalei o app do meu banco no meu celular, eu simplesmente não voltei mais a utilizar a página web para acessar minha conta bancária. Mesmo se o computador está na minha frente, eu ainda prefiro pegar o celular. O app do meu banco no meu celular é muito mais prático, conciso e objetivo.

Porque então não seguir os mesmos princípios de um mobile app nos sites para web? Essa é a idéia dos Web Apps (ver também http://en.wikipedia.org/wiki/Web_app).

O website do meu banco hoje é um verdadeiro elefante branco. Possui milhares de informações e funcionalidades, todas entrelaçadas na navegação. Eu posso praticamente fazer quase tudo pelo site que eu poderia fazer na agência bancária. Pelo lado da disponibilidade, isso é uma vantagem enorme. Mas pelo lado da objetividade, o excesso de oportunidades atrapalha.

Observação: Sou cliente de vários bancos diferentes e o website de todos eles possuem essas mesmas características.

Defendo aqui neste post que aplicativos corporativos transformem-se em vários Mini Apps, bastante práticos e objetivos, que desempenham tarefas bem determinadas com simplicidade. O usuário configuraria e utilizaria no seu browser ou no seu desktop, somente suas tarefas mais corriqueiras, quando precisasse delas, se vir a precisar. Tudo configurado de acordo com os seus interesses, assim como são os smart phones.

Vamos a outros exemplos:

Que tal o Microsoft Word sendo um "marketplace" com várias opções de mini aplicativos? Quando você quiser somente criar, abrir, editar, salvar ou imprimir um documento de texto, você utiliza o app principal (simples e prático como um notepad). Mas se você quiser inserir Cliparts, Wordarts, Gráficos, Referências Cruzadas, Símbolos, etc, essas funções estariam em um mini aplicativo a parte, com uma navegação bem mais específica e direcionada, muito mais fácil de usar e o mais importante, disponível somente no caso de você precisar.

E que tal a Intranet da sua empresa como se fosse a tela do seu celular? O app de RH separado do app dos eventos corporativos que é separado da página de contatos dos funcionários. Cada um com a sua navegação própria, sua interface simplificada e suas peculiaridades. Você não precisaria mais navegar por uma porção de links até chegar no seu contra-cheque.

A idéia é que cada Mini App seja um produto à parte dentro de um grande aplicativo. Um produto independente e autônomo. Você digitaria a URL do seu banco no browser e veria na sua home page somente os apps que você escolheu para utilizar. Se você tem cartão de crédito mas não tem investimentos com esse banco, então você visualizaria o app para acessar o seu cartão de forma prática e simplificada. Toda a parte de investimentos desse banco não ficaria visível para você a todo o momento, te confundindo.



Desenvolvendo Mini Apps

Desenvolver aplicativos complexos como sendo um conjunto de Mini Apps é uma enorme facilidade para os usuários. Mas a grande vantagem mesmo está no custo de desenvolvimento.

Com os Mini Apps, a equipe de desenvolvimento pode focar muito mais precisamente nos vários Minimum Viable Products que a aplicação possui, e se eles forem desenvolvidos independentemente um dos outros, com bastante autonomia e seguindo os conceitos de Lean Code, o custo de manutenção desse software pode cair consideravelmente.


Os Mini Apps de LiveSource

Quando comecei a desenvolver o LiveSource eu fui simplesmente adicionando todas as novas funcionalidade ao código fonte sem me preocupar muito com a quantidade de classes e arquivos fontes que estavam sendo criados. Numa questão de pouquíssimos meses, o código de LiveSource tornou-se altamente complexo e de caríssima manutenibilidade. Isso sem falar na interface com o usuário, que a cada nova funcionalidade, a navegação ficava mais confusa e prejudicada.

Foi quando surgiu a idéia de separar o produto LiveSource em vários mini produtos, e desenvolver o que estamos chamando aqui de Mini Apps.

O LiveSource original passou então a ser dividido em vários Minimum Viable Products, como por exemplo, um Mini App separado somente para tratar do Product Backlog de um projeto (que passou a chamar-se EasyBacklog), um outro Mini App para gerar e exibir um task board dinâmico (chamado de Live Task Board), um outro para lidar com a geração automática da documentação do código fonte, outro para tratar das métricas do software, e por aí vai.

Figura 1: Os Mini Apps de LiveSource

Observe no canto inferior esquerdo da figura acima os links para acessar os vários mini aplicativos fornecidos pelo site de LiveSource. Cada um possui o seu "mundo" à parte, com interface e código fonte independentes.

. . .

A independência dos Mini Apps de uma grande aplicação deve ser total. A interface com o usuário, a configuração, o código fonte, todos separados um dos outros e, principalmente, autônomos.

A autonomia dos Mini Apps traz automaticamente uma enorme visibilidade para as características individuais do mini produto que ele representa, características essas que muitas vezes ficam desapercebidas quando a aplicação é somente visualizada como um todo, numa grande sopa de funcionalidades.

O Código Magro (The Lean Code)

Seguindo a onda das idéias Lean eu gostaria de criar mais uma tendência aqui nesse blog:

O Código Magro (ou Lean).

Em poucas palavras, Código Magro (ou Enxuto se preferir) é um projeto de software pequeno, independente e extremamente organizado, que pode ser facilmente mantido e sua intenção facilmente compreendida por qualquer participante do processo de desenvolvimento do software, inclusive por não programadores.

A idéia é que mesmo um grande e complexo aplicativo passe a ser composto por vários projetos de software independentes, pequenos, organizados, fáceis de compreender e de manter.

Manutenção é comprovadamente um dos custos mais altos do desenvolvimento de um software. "Dois terços do custo do tempo de vida de um sistema de software envolve manutenções." (Ver Manutenção de Software). É muito mais rápido (e barato) identificar um problema ou uma funcionalidade que precisa ser mantida em um código magro, reduzindo consideravelmente o custo de manutenção de um software.

Quantas funcionalidades o seu código fonte está implementando no momento? A resposta dessa pergunta é uma boa indicação se seu projeto de software é magro ou não.

Um código magro implementa uma quantidade mínima de funcionalidades ao mesmo tempo. Se seu código fonte virou um spaghetti, ou seja, é muito extenso e se tornou tão complexo a ponto de você nem conseguir identificar as funcionalidades que ele implementa, então esse caso realmente necessita de uma refatoração Lean.

É muito importante também que um código magro seja viável. Código magro viável é aquele que possui usuários e clientes comprovadamente satisfeitos. (Veja a definição de Product-Market Fit).

Bons acompanhantes para essa leitura seriam: The Clean Code (ou o blog do Uncle Bob) e The Lean Startup de Eric Ries.

O Código Magro na Prática

Após muito pesquisar sobre visibilidade de código, entendi que para desenvolver um código magro são necessários os seguintes tópicos abaixo:

• Linguagem Ubíqua,
• Minimum Viable Products isolados,
• Uma ferramenta para visualizar a intenção de seu código fonte.

As vantagens da utilização da linguagem ubíqua dentro do código fonte são inúmeras. Esse tópico por si só é extremamente relevante, e por isso possui um post a parte já escrito anteriormente: 

Linguagem Ubíqua para dentro do código-fonte

Este post vai descrever com detalhes os aspectos importantes da Linguagem Ubígua no desenvolvimento de um código magro.

O próximo item é sobre os MVPs. Se seu aplicativo possui uma quantidade incontável de funcionalidades, simplesmente implementá-las todas em uma mesma massa de código fonte não ajudará em nada na compreensão e na manutenibilidade desse código. Por isso a definição a seguir: 


Um código magro deve conter somente um Minimum Viable Product. 

Quando os requisitos de seu software começarem a se multiplicar, volte-se sempre para a intenção de seu aplicativo. Mantenha o foco em seu MVP. Após entrevistar os seus clientes e consultar o seu mercado, se  novas funcionalidades comprovarem-se como de fato úteis para seus usuários (veja o post Definindo o seu Mininum Viable Product), então divida essas novas funcionalidades em diferentes MVPs e crie projetos de software independentes para elas, com códigos fonte isolados. Se necessário, utilize APIs e interfaces de comunicação entre seus MVPs, mas não simplesmente os desenvolva em uma mesma única massa de código.


LiveSource e O Código Magro

Ferramentas de trabalho são muito importantes para auxiliar o processo de desenvolvimento de um software. Não é à toa que uma equipe de desenvolvimento sempre utiliza inúmeras delas. Porém, as ferramentas de desenvolvimento atuais mais utilizadas pelos programadores, as chamadas IDEs (como por exemplo Eclipse, VisualStudio, IntelliJ, etc), são extremamente técnicas e infelizmente não são ideais para visualizar a intenção de seu código fonte ou para serem utilizadas pelos não programadores que também fazem parte da equipe de desenvolvimento de um software (como por exemplo stakeholders, product owners, especialistas de negócio, gerentes de projeto, testers e até mesmo usuários finais ou clientes).

É por esse motivo que desenvolveu-se o LiveSource, para que a intenção do código fonte possa ser filtrada,  visualizada e compreendida, e para que não programadores possam participar e contribuir mais ativamente no processo de desenvolvimento do software. Saiba mais sobre as vantagens de LiveSource aqui.

Com LiveSource o código fonte não mais estará escondido atrás de complexas camadas técnicas, mas sim, estará disponível online, traduzido e facilmente compreensível pelos programadores e não programadores da equipe de desenvolvimento. Se a intenção do negócio não estiver claramente refletida no código fonte, é desta maneira que LiveSource vai colaborar com a equipe de desenvolvimento: expondo o problema abertamente.

"Eu vejo valor em manter meu código fonte um pouco mais organizado e mais fácil de ver do que navegar através de código.", comentário de um early adopter de LiveSource.

Quando uma pessoa (programador ou não) visualiza o código fonte através da ferramenta LiveSource é facilmente detectável se este código fonte está suficientemente organizado ou não. É possível visualizar se a documentação desse código, quando existente, é relevante para o domínio de negócios ou se somente está adicionando detalhes técnicos (muitas vezes inúteis) para os programadores da equipe de desenvolvimento.

Possuir a intenção do domínio de negócios totalmente atrelada ao código fonte é uma característica chave do código magro. O nome de cada arquivo, de cada diretório, de cada classe, de cada pacote, de cada função e de cada variável deve refletir diretamente a intenção de sua existência para o domínio de negócios. Um não programador que leia o nome de um arquivo ou de uma função por exemplo, deve compreender facilmente o seu significado. E então, a documentação desse código deve adicionar as informações de negócio que justificam e explicam a sua necessidade.

Repito aqui a indicação da leitura do post sobre Linguagem Ubíqua para dentro do código fonte.

Quando todos os participantes do processo de desenvolvimento, incluindo product owners, gerentes de projeto, clientes, usuários, etc, podem participar ativamente da construção do artefato mais importante de um software, ou seja, do seu código fonte, o dinamismo da comunicação e a precisão dos resultados refletem diretamente na qualidade final do produto gerado, reduzindo drasticamente o custo de sua manutenção.

Após a definição do seu Minimum Viable Product

Os próximos passos após a definição do seu Minimum Viable Product (veja o post anterior desse blog) é justamente contruir e validar esse MVP.


Que funcionalidades precisam estar disponíveis para que seus Early Adopters comecem a utilizar seu produto?
Abaixo encontram-se as Histórias de Usuário para o MVP de LiveSource:


MVP 1: LiveSource é um Toolkit para web que carrega o código fonte de seu software e gera uma versão de fácil leitura desse código, compreensível por todos os integrantes da equipe de desenvolvimento inclusive pelos não-programadores.

• "Como um usuário, eu gostaria de visualizar a lista dos meus projetos de software."
• "Como um usuário, eu gostaria de visualizar a lista de todos os arquivos fontes de cada um dos meus projetos."
• "Como um usuário, eu gostaria de uma visualização de fácil compreensão para cada um dos arquivos do código fonte de cada projeto."

LiveSource é um projeto bastante extenso e complexo, mas como vocês podem observar só existem três Histórias de Usuário no meu MVP. É assim que um projeto Lean deve ser: começar pequeno, eliminar o desperdício, entregar rapidamente, etc...

Junto com a lista de Histórias de Usuário, é importante ter também um rascunho de como seria a interface com o usuário de seu produto. Pode ser algo bem simples, como um desenho em um pedaço de papel, ou a foto de um rabisco num quadro de trabalho. Chamamos isso de Low-Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

Neste ponto do processo de desenvolvimento, já estou utilizando algumas das técnicas do Desenvolvimento Ágil. Podemos agora começar a planejar uma Sprint, definir um Product Backlog, estimar e priorizar as Histórias de Usuário, etc.

Para simplificar ao máximo, para essa primeira entrega do MVP vamos descartar as páginas de login e até mesmo a necessidade de um banco de dados. Vamos carregar todo o código fonte a partir de um repositório de arquivos remoto, como Git ou Subversion.

Para o exemplo de LiveSource, vamos considerar as três histórias acima como prioridade e vamos inserí-las na primeira Sprint do produto. E então vamos descrever todas as tarefas necessárias para implementar essas histórias.

Tarefas para a Interface com o Usuário:

• Listar todos os projetos disponíveis.
• Quando o usuário clica em um projeto da lista, o sistema exibe uma lista com todo o arquivos do código fonte armazenado no repositório desse projeto.
• Quando o usuário clica em um arquivo na lista do código fonte, o sistema exibe uma versão de fácil leitura para esse código fonte.

Tarefas do lado do Servidor:

• Criar uma conexão com o servidor remoto de arquivos dos projetos.
• Carregar a lista de todos os arquivos fonte do projeto armazenados no repositório remoto.
• Carregar o conteúdo do arquivo fonte quando selecionado.
• Extrair todos os comentários e a documentação do conteúdo de um código fonte.

Eu poderia adicionar algumas Spikes a essa lista, como por exemplo uma tarefa para estudar as APIs para conectar com o repositório de arquivos dos projetos, ou uma outra tarefa para explorar como extrair a documentação e os comentários de um código fonte. Cada uma dessas tarefas podem ser complexas e se estender por dias de trabalho. Só não vou adicioná-las a minha lista neste momento porque eu já tive esses tópicos explorados enquanto eu estava desenvolvendo o protótipo do meu produto.

O próximo passo é distribuir as tarefas pela equipe de desenvolvimento. Deixe que cada programador escolha quais tarefas quer implementar e quando cada um pode se comprometer em implementá-las.

Enquanto estiver implementando seu MVP, tente construí-lo o mais independente possível. Quando novas funcionalidades surgirem, tente não simplesmente adicioná-las ao seu MVP já existente, mas sim, tente criar um novo MVP, também independente, de uma maneira que se possa conectar ou desconectar funções sem afetar o sistema como um todo.

Enquanto estiver implementando seu MVP você já deve permanecer em contato com seus ealy adopters, carregar dados reais e testar a usabilidade do sistema. O quanto antes você começar a receber feedback melhor. A idéia é que você já termine a implementação com seus early adopters utilizando o sistema.

A principal mensagem desse post é: Não inicie um novo MVP enquanto os seus early adopters ainda não estiverem utilizando os MVPs que você já desenvolveu. Há muito o que se ajustar depois que se começa a receber feedback dos clientes, e esses ajustes na maioria dos casos são muito mais importantes do que novas funções a serem desenvolvidas.

O melhor momento para se começar a adicionar novas funções ao sistema é quando já se estabeleceu a marca de 40% dos usuários declarando que ficarão "Muito Desapontados" se eles não mais puderem utilizar o seu produto. Essa técnica é chamada de Product/Market Fit.

Se você não está atingindo o seu Product/Market Fit, o que se tem a fazer é reiniciar todo o processo de desenvolvimento de clientes novamente. Retorne ao protótipo e ouça mais os seus early adopters. Que razões eles alegam para utilizar ou não o seu produto. Ajuste o seu MVP até que você atinja o seu Product/Market Fit.

Não é nada fácil atingir esse ponto. Exige-se muita determinação, e normalmente necessita-se de várias iterações para estar pronto para um crescimento em escala. O processo descrito aqui é um bom caminho inicial para o sucesso no final.

Definindo o seu "Minimum Viable Product"

Uma das principais metas do desenvolvimento de um software deve ser:

"O que é necessário fazer para se adquirir clientes." 

Todo software possui clientes. Não importa se é um projeto interno da sua empresa, se é uma simples aplicação para dispositivos móveis, se é uma complexa API, ou qualquer outra coisa.

Se você já começou o desenvolvimento do software e ainda não sabe quem são os clientes e quais são os principais problemas desses clientes, recomendo começar essa identificação o mais rápido possível. Uma das grandes causas do fracasso no desenvolvimento de um software é não ter ninguém que queira utilizá-lo.

Um outro bom exercício é considerar você mesmo como o cliente número Zero de seu projeto. Mesmo no caso de você não ser um cliente direto, ajudará muito se você tentar estabelecer como o produto que você está desenvolvendo lhe trará algum retorno.

A título de exemplo, esses são os clientes do meu projeto LiveSource:
        "Desenvolvedores de Software (incluindo programadores, gerentes de desenvolvimento, dono do produto e até possivelmente você que está lendo esse artigo)"

São várias as soluções que eu posso oferecer ao meu cliente, mas eu não vou simplesmente assumir que eu já saiba em quais eles estão mais interessados. Após várias entrevistas e apresentações de protótipo, percebi que "Melhorias de Comunicação" é o assunto que provoca mais reações nos meus clientes.

Você pode ajudar o projeto LiveSource respondendo a nossa pesquisa online:
                        http://www.surveymonkey.com/s/63GQJYS

Conquistar o primeiro cliente é um processo bastante iterativo. Você começa normalmente conversando com as pessoas e rascunhando um protótipo, depois você volta e entrevista seus prováveis clientes. Então você faz ajustes no protótipo e repete todo o processo novamente.

Em alguns projetos esse processo pode ser bastante rápido, demorando apenas alguns dias para você já ter um protótipo simples e eficiente, que provoque um feedback positivo nos seus clientes.

Já em outros projetos, esse processo pode demorar muito mais tempo, dependendo da capacidade que você tem de ouvir os seus clientes, do quanto das dificuldades de seus clientes você é capaz de entender e compartilhar e da habilidade que você possui para simplificar soluções.

No caso do LiveSource, eu tenho que admitir que minha capacidade para simplificar soluções está deixando a desejar. Eu comecei tentando oferecer uma série de soluções ao mesmo tempo e  não conseguia conter tantas idéias novas que me vinham à cabeça a cada semana. Não deixe que isso aconteça com você...

Enquanto você refina seu protótipo, já comece a procurar por seus Early Adopters. Tente encontrar o quanto antes as pessoas que, mesmo por caridade, usariam o seu produto. O ideal é que usar seu produto mesmo em fase de desenvolvimento também seja uma vantagem para estas pessoas. Se você não consegue ninguém para testar seu produto, pense o quão mais difícil será conseguir clientes reais. Repita o processo de entrevistar clientes e refinar o protótipo até encontrar seus primeiros Early Adopters (Esse post do Seth's Blog pode lhe ajudar a entender).

Na maioria das vezes, para adquirir usuários você precisa que seu produto não somente funcione mas que também tenha personalidade. Saiba mais aqui neste post sobre Minimum Viable Personality.

Os Early Adopters de LiveSource são desenvolvedores amigos meus que já confirmaram que ajudarão a testar meu produto. Mas não se pode esquecer: amigos e familiares são ajuda somente para se iniciar um projeto. Clientes reais são aqueles que de fato trazem receita para a empresa.

Antes de adicionar uma série de funcionalidades ao seu protótipo, você precisar definir como os seus clientes usarão o seu produto no futuro, como será o seu ambiente de produção.

Para projetos de software grandes, definir e construir o ambiente de produção pode custar um grande esforço. Porém, postergar essa solução é um erro. Defina como os seus clientes acessarão o seu produto e construa uma Launch page no seu ambiente de produção. Com uma página de lançamento você já pode testar o seu mercado, gerar uma lista de contatos, validar sua idéia e principalmente confirmar se as pessoas se cadastrariam para utilizar o seu produto ou não.

O ambiente de produção do LiveSource custou inacreditavelmente meses para ser construído. Após um bom tempo gasto com testes e integrações entre as clouds existentes no mercado eu finalmente possuo um bom e flexível ambiente de produção, que conseguirá suportar um produto complexo como LiveSource e que utiliza ambas as clouds Amazon EC2 e Google App Engine.

O importante é que se comece a validar o mercado o quanto antes, já no início do desenvolvimento, ou senão ao mesmo tempo em que se está construindo o protótipo ou a infra-estrutura para o seu produto.

No caso do LiveSource por exemplo, você já pode se cadastrar acessando o endereço:
                               http://golivesource.com

Eu poderia começar a adicionar uma porção de funcionalidades a esse link, mas para ser Lean eu preciso descobrir qual tem mais valor para os meus clientes. E então simplificar essa funcionalidade ao máximo, começar a receber os feedbacks dos meus early adopters e validar meus pressupostos. Ou não.

Não importa o quão grande e complexo o seu produto seja, descreva em uma única frase a funcionalidade que tem o maior valor para os seus clientes. Esse é um bom começo para se definir o seu Minimum Viable Product.

Para exemplificar, no caso do LiveSource, "Melhoria de Comunicação" é o tema que tem maior valor para os meus clientes. Veja abaixo a definição do meu Minimum Viable Product:

• LiveSource é um Toolkit para web que carrega o código fonte de seu software e gera uma versão de fácil leitura desse código, compreensível por todos os integrantes da equipe de desenvolvimento inclusive pelos não-programadores.

Eu sei que LiveSource vai muito além da definição acima, mas sem nenhuma sombra de dúvidas, hoje eu entendo que focar nessa única funcionalidade, fazê-la funcionar com perfeição e validar os meus pressupostos com a realidade do mercado, é o que vai me ajudar a adquirir clientes reais da forma mais rápida e eficiente possível.

Resumindo, antes de começar a desenvolver o seu software:

      - "Desassuma" seus pressupostos (Unassumer.com)

      - Entreviste seus clientes e o mercado (SurveyMonkey.com)
      - Identifique seu MVP

      - Disponibilize uma página de lançamento (LaunchRock.com)

      - Monte seu ambiente de produção

      - Prototipe rapidamente
      - Meça os resultados
      - Adquira e Satisfaça seus Early Adopters

Adicionar mais funcionalidades ao seu MVP sem que os usuários finais já estejam utilizando satisfatoriamente as funcionalidades existentes pode ser um total desperdício de tempo e dinheiro. Na grande maioria das vezes é de fato o que acontece.

Não acabou ainda!! :-)   Acompanhe a parte 2 deste post:

Após a definição do seu Minimum Viable Product

Ser Ágil não é fácil

Não é à toa que várias empresas e pessoas se dizem Ágeis, mas quando são questionadas se programam em pares, se desenvolvem orientados a testes, se trabalham 40 horas semanais, etc, grande parte das vezes a resposta ainda é "não necessariamente" ou "mais ou menos" ou  "não, mas a gente desenvolve em sprints". Pasmem...

Ser Ágil não é nada fácil.

Pelo menos nós Agilistas temos a consciência que simplesmente não ser Ágil é ainda mais difícil.

Mesmo com as várias metodologias ágeis adaptáveis, como Kanban por exemplo, ser Ágil significa uma mudança de comportamentos, de paradigmas e para muitas pessoas até mesmo de princípios e de personalidade (se é que isso seja possível). Uma das maiores dificuldades, que pelo menos eu pessoalmente tenho encontrado, é ter que desenvolver em conjunto com pessoas que se dizem ágil porque está na moda, mas nem sequer acreditam nos valores ágeis e se utilizam de qualquer artifício e argumentação para justificar o porque de não praticar a programação em pares, nem refatorar, não compartilhar seu código, não desenvolver testes unitários e principalmente, não focalizar na entrega de algo executável no final de uma iteração. Mais difícil ainda do que ser ágil é explicar para um pessoa que se acha ágil que ela não o está sendo.
  (Gostaria de citar aqui esse outro post que eu achei interessante: The emotional reaction to Agile adoption)

Mesmo para quem é de fato ágil, é extremamente comum saltar as práticas ágeis por indisciplina ou preguiça. Não tenho porque negar que isso já aconteceu comigo incontáveis vezes. Quando se está muito absorvido e pressionado com os problemas momentâneos e isolados é comum perder a noção das conseqüências futuras e globais da indisciplina. O problema aumenta consideravelmente quando a qualidade do trabalho não é visível pelos outros da equipe ou quando não se está programando em pares e não existe ninguém para inspecionar o seu trabalho a não ser você mesmo.

Em muitos casos, uma ferramenta que "force" e "garanta" o cumprimento das práticas ágeis pode ajudar muito uma equipe de desenvolvimento. Compreendo perfeitamente que a interação humana é o fator de maior relevância para a adoção ágil, e que nada a pode substituir. Mas acredito também que nem todas as pessoas possuem os valores ágeis por natureza, que mesmo os profissionais ágeis podem ser indisciplinados muitas vezes e que a simples confiança no empenho individual nem sempre é fator de sucesso. Uma ferramenta de auxílio para complementar as interações humanas (como comunicação, compartilhamento, respeito, confiança, ...) de uma equipe de desenvolvimento ágil quando esta está sendo incipiente pode ser uma solução muito eficiente.


As vantagens da ferramenta LiveSource

Assista nosso vídeo DEMO: http://www.screencast-o-matic.com/watch/cX6oVdTPZ

LiveSource é uma ferramenta Web que garante que o código fonte não estará mais escondido atrás de servidores de arquivos de complexo acesso, mas sim, sempre compartilhado para todos da equipe de desenvolvimento há um clique do seu browser e, mais ainda, que este código será compreensível pelos não-programadores. Pelo menos, se o código não estiver compreensível, a ferramenta LiveSource deixará bem exposto o problema, de uma forma que os programadores não terão como argumentar o contrário com seus jargões técnicos, também incompreensíveis. Tudo isso viabiliza a programação em pares inclusive entre programadores e não-programadores.

Figura 1. Visão dos Stakeholders e do Código Fonte
Extraído de um software para o Jogo da Velha
(Clique na imagem para vê-la ampliada)

Perceba na figura acima que todos os dados do quadro à esquerda foram extraídos diretamente do código fonte exibido a direita. O quadro à esquerda não passa de um filtro das informações de domínio relevantes a um Stakeholder que se encontram diretamente no código fonte. Se o programador utilizar a Linguagem Ubíqua dentro do código fonte como no exemplo acima, não haverá dúvida que qualquer não-programador poderá compreender o texto filtrado à esquerda. Para transformar esse filtro em uma História de Usuário ou em um requisito é uma questão de simples formatação de texto.

LiveSource estratifica o planejamento em tarefas o mais simples possível, em seu tamanho tão mínimo como o de uma única classe de desenvolvimento, para que a complexidade das histórias de usuário sejam entendidas e estimadas com mais rigor.

LiveSource publica a realidade verdadeira do projeto de software. O que não está 100% pronto no código fonte ficará evidenciado sem precisar passar por relatórios paralelos onde essa realidade pode ser facilmente mascarada pelos responsáveis.

Observe a lista de requisitos abaixo extraída diretamente do código fonte deste mesmo projeto exemplo, no caso uma aplicação simples para o Jogo da Velha.

Figura 2. Visualização do Escopo através da Lista de Requisitos (Clique na imagem para vê-la ampliada)

Figura 3. Visualização dos arquivos do Código Fonte (Clique na imagem para vê-la ampliada)

Como a lista de requisitos à esquerda é uma visão direta (e filtrada) dos arquivos do código-fonte da direita, não tem como um programador ou um gerente de projeto, ou qualquer outra pessoa da equipe de desenvolvimento, manipular esses dados para demonstrar uma maior produtividade além da verdadeira.

Comparando a Figura 2 com a Figura 3, veja também o quanto é mais fácil ler e compreender a estrutura e o significado do código fonte após os filtros de LiveSource.


Testes Unitários

LiveSource também evidencia com precisão a presença ou a ausência de testes unitários para uma determinada unidade de código.

Figura 4. Link entre um arquivo fonte e seu Teste Unitário
(Clique na imagem para vê-la ampliada)

Live Task Board

O Live Task Board é uma visão realista e dinâmica do status atual do software. É capaz de se atualizar automaticamente, porque seu conteúdo é extraído do que está sendo produzido diretamente no código fonte e não de um banco de dados de histórias que tem que ser atualizado em paralelo ou de histórias escritas em papel na parede que necessitam ser movidas fisicamente pela equipe diariamente.

Figura 5.   Live Task Board
(Clique na imagem para vê-la ampliada)

Entendo perfeitamente os efeitos maravilhosos da simplicidade de um task board na parede em frente à equipe de desenvolvimento, principalmente durante uma Stand up Meeting. Entendo a evolução que isso significa comparativamente aos modelos tradicionais de desenvolvimento, com seus cronogramas extremamente complexos e irreais. A idéia do LiveSource não é substituir os momentos de interação entre a equipe trazendo mais uma ferramenta para ser utilizada pelos desenvolvedores, mas sim melhorar ainda mais a comunicação deixando as tarefas manuais de atualização do quadro de tarefas para ser realizadas por um computador e proporcionando mais tempo para a equipe discutir os assuntos relacionados às tarefas em si.

Pode-se projetar o Live Task Board na parede e continuar adicionando os post-its à imagem projetada. No momento em que o programador for gerar o código fonte de uma tarefa específica, a informação dos post-its pode ser usada como documentação de código e assim a tarefa relacionada no papel volta automaticamente para o Live Task Board de forma eletrônica e bem mais permanente.


Visualizar o código de uma maneira filtrada e limpa, dá ao programador uma idéia imediata do que precisa ser melhorado. Causa um extremo desconforto visualizar tão claramente o próprio trabalho quando não está bem feito. É uma situação que só a real experiência com Live Source pode demonstrar sua extensão.

Agora imagine o impacto de um código confuso sendo visualizado por todos da equipe. Nenhum programador gostará de ser o responsável por esse código. E possivelmente não o será, pois a tendência do programador será priorizar a refatoração, diminuindo a sua complexidade consideravelmente.

É nesse sentido que LiveSource pode ser considerada uma ferramenta para aumentar a qualidade do seu software. Porque possibilita uma grande visibilidade ao que está sendo desenvolvido.

A idéia do LiveSource é que não tenha como disfarçar quando não se está sendo ágil. Nem para si mesmo.

Veja aqui vídeos demonstrativos de como acessar a ferramenta passo a passo.

Depois não se esqueça de enviar-nos seus comentários!

LiveSource - Brasil

View more presentations from Alline Watkins

 Nenhum Direito Reservado. Por favor copie-nos!