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!

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

"We understand each other"  (James Shore)

http://jamesshore.com/Agile-Book/ubiquitous_language.html

• Seu código-fonte é um verdadeiro caos, impossível de compreender até mesmo pelo programador que o escreveu?

• Se algum dos programadores da sua equipe abandonar o trabalho hoje, os demais serão capazes de continuar o serviço tranqüilamente?

Live Source é um Web Toolkit que auxilia na criação de uma linguagem ubíqua e estende as vantagens que o código-fonte pode proporcionar ao seu processo de desenvolvimento.
 
A idéia é provar que a linguagem ubíqua pode ser utilizada até nos níveis mais técnicos do software incluindo o próprio código-fonte, sem nenhum efeito prejudicial ao processo de desenvolvimento. 

Observe os exemplos abaixo e envie-nos seus comentários a respeito das opções que estamos demonstrando.

Uma Story ANTES e DEPOIS da Linguagem Ubíqua A utilização da linguagem ubíqua deve começar nos mais altos níveis de interação do projeto, como emails, documentos de planejamento, User Stories, etc. Para o programador aplicar a linguagem ubíqua no código-fonte com facilidade, os termos já devem estar no seu sub-consciente, sendo utilizados com freqüência pelo resto da equipe. Observe as duas histórias de usuário abaixo e verifique que a simples aplicação dos termos de domínio nos artefatos do projeto não afeta em nada a mensagem a ser transmitida. (Exemplos extraídos de um software para jogar o Jogo da Velha) ANTES     Mover      Quando o usuário clica no grid,      o sistema exibe 0 ou X dependendo de qual é o usuário atual.   DEPOIS    Movimento do Jogador Quando o jogador clica no tabuleiro, o jogo exibe o símbolo 0 ou X dependendo de qual é o         jogador atual. Uma classe ANTES e DEPOIS da Linguagem Ubíqua A partir de histórias já escritas com a linguagem do domínio fica mais imediato para o programador identificar os jargões ténicos que devem ser evitados durante a programação. Perceba o quanto a análise é facilitada quando o programador aplica a linguagem ubíqua diretamente no código-fonte. A quantidade de suposições a respeito de sua lógica e suas intenções é bastante minimizada para aqueles que forem manter ou estender esse código, diminuindo consideravelmente a possibilidade de futuros erros. (Exemplos extraídos de um software para jogar o Jogo da Velha) ANTES     /**  * Exibe a string O ou X na celula do jogo. */ public class  MostraCellGrid{ public static void  exibeUsuario(Grid grid, Cell cell) {           if (!Inicializacao.flag   && Inicializacao.statusJogo.getSequencia() == null   && isVazio(grid, cell)) {  Inicializacao.flag = true;  String mk= exibeString(Inicializacao.statusJogo        .getUsuarioCorrente().getStringUsuario());  grid.setHTML(cell.getRowIndex(), cell.getCellIndex(), mk);  Inicializacao.statusJogo.getStatus()[cell.getRowIndex()][cell .getCellIndex()] = Inicializacao.statusJogo .getUsuarioCorrente(); GameEnd.verificaFim(Inicializacao.statusJogo, cell.getRowIndex(), cell.getCellIndex());        } (...) } DEPOIS    /**  * Efetiva o movimento do jogador na grade do jogo.   */ public class MovimentoDoJogador { /** * Quando o jogador clica numa celula na grade do tabuleiro o jogo desenha * um 0 ou X dependendo de qual e o jogador atual. */        public static void mover (GradeDoJogo gradeDoJogo, Cell celulaSelecionada) { if (!VariaveisGlobais.flagDeAguardoDoMovimento && VariaveisGlobais.statusCorrenteDoJogo.getSequenciaGanhadora() == null && eCelulaVazia(gradeDoJogo, celulaSelecionada)) { VariaveisGlobais.flagDeAguardoDoMovimento = true; String simbolo = exibeSimboloDoJogador( VariaveisGlobais.statusCorrenteDoJogo .getJogadorCorrente().getSimboloDoJogador()); gradeDoJogo.setHTML(celulaSelecionada.getRowIndex(), celulaSelecionada.getCellIndex(), simbolo); VariaveisGlobais.statusCorrenteDoJogo.getMovimentosNoJogo() [celulaSelecionada.getRowIndex()] [celulaSelecionada.getCellIndex()] = VariaveisGlobais.statusCorrenteDoJogo.getJogadorCorrente(); ChamadaParaOJulgamentoDoMovimento.verificaSeGanhou( VariaveisGlobais.statusCorrenteDoJogo, celulaSelecionada.getRowIndex(), celulaSelecionada.getCellIndex()); } } (...) } E então, qual das duas opções abaixo um Stakeholder melhor entenderia?  Os conteúdos das duas caixas abaixo foram extraídos diretamente das classes acima. Pequenas mudanças na terminologia de um código podem causar grande impacto em sua compreensão geral. O que pretendemos demonstrar aqui é que, assim que programadores passam a utilizar a Linguagem Ubíqua dentro de seus códigos-fonte, uma série de possibilidades, como busca e filtragens de informação, passa a ser viável e útil para aqueles que não necessariamente entendem os termos e as abreviações técnicas utilizadas nos produtos de sua empresa. (Exemplos extraídos de um software para jogar o Jogo da Velha) ANTES    Mostra Cell Grid    Exibe a string O ou X na celula do jogo.                                               Exibe Usuario          Is Vazio DEPOIS    Movimento do Jogador     Efetiva o movimento do jogador na grade do jogo. Mover       Quando o jogador clica numa celula na grade do tabuleiro          o jogo desenha um 0 ou X dependendo de qual e o       jogador atual. E Celula Vazia        Um jogador podera selecionar somente as celulas que         ainda nao foram selecionadas. Utilizar a Linguagem Ubíqua dentro do código-fonte pode parecer simples, mas não é nem um pouco. Na verdade implica em uma grande quebra de paradigma para os programadores que estão acostumados a utilizar normalmente seus termos técnicos pra lá e pra cá, como exemplos "EntityBeans", "AssyncronousCalls", "DTO's", etc, etc, etc. Substituir esses termos, que muitas vezes nem mesmo um outro programador entende facilmente, por termos que são mais auto-explicativos na visão de um Product Owner ou um Stakeholder, demanda tempo e muita refatoração por parte dos programadores. Não será de um dia para o outro que o código-fonte se transformará em ubíquo. Um progresso gradativo e contínuo deve ser o esperado. E por falar em termo auto-explicativo, a nomenclatura ideal para ser utilizada em um código é aquela que, quando se está explicando o software para alguém, não é exigido que se diga nem mais uma palavra além da própria nomenclatura. Por exemplo, uma variável deve ser chamada "Conexao" ou "ConexaoComOBancoDeDados" ? Uma função deve ser chamada "VerificaNulo" ou "VerificaSeEmailEVazio" ? Adoraríamos saber sua opinião. Envie-nos suas respostas sobre essas questões que estamos levantando. A equipe do Live Source agradece!!

Ubiquitous Language - Portugues

View more presentations from Alline Watkins

 Nenhum Direito Reservado. Por favor copie-nos!