Lean Startup – Para iniciar uma empresa enxuta e ágil

“Startup é uma instituição humana projetada para entregar um novo produto ou serviço em condições de extrema incerteza” – Eric Ries

Introdução

Lean Startup é um termo registrado por Eric Ries e representa a síntese das metodologias de Desenvolvimento do Cliente, Desenvolvimento Ágil de Software e práticas Lean usadas no sistema de produção da Toyota.

O método Lean Startup não está relacionado com custos, mas sim com velocidade. Lean Startups desperdiçam menos dinheiro, porque usam uma abordagem disciplinada para testar novos produtos e idéias. Lean, quando usado no contexto de startup enxuta, refere-se a um processo ágil de construção de empresas e produtos que usam os princípios de manufatura enxuta aplicada à inovação. Esse processo envolve testes rápidos de validação de hipóteses, aprendizado sobre clientes e uma abordagem disciplinada para o desenvolvimento do produto.

A metodologia Lean Startup se aplica a todas as empresas que enfrentam a incerteza sobre o que os clientes querem. Isto é verdade independentemente da indústria ou até mesmo do tamanho da empresa: muitas grandes empresas dependem de sua capacidade de criar inovação disruptiva. Alguns gestores de tais empresas são intraempreendedores, podendo se beneficiar da velocidade e da disciplina de começar com um produto mínimo viável e aprender interagindo continuamente.

Não há nada errado em levantar capital de risco. Muitas Lean Startups são ambiciosas e capazes de usar bem grandes quantidades de capital. O que as diferencia é sua abordagem disciplinada para determinar o momento de gastar o dinheiro, ou seja, depois dos elementos fundamentais do modelo de negócio terem sido empiricamente validados. E este deve ser o foco: a validação dos pressupostos mais arriscados.

Lean Startups são movidas por uma visão convincente, e são rigorosas nos testes de cada elemento dessa visão com a realidade. Elas usam o Desenvolvimento do Cliente, testes e análise de riscos, como veículos de aprendizagem para fazer a sua visão ter sucesso. Elas não fazem cegamente o que os clientes lhes dizem, mas aprendem com eles. Ao longo do caminho, se necessário, elas mudam de direção (pivot) afastando os elementos delirantes da visão e duplicando esforços nos elementos que se mostram promissores.

Lean Startup

  • NÃO É sobre gastar ou levantar menos dinheiro, é sobre gastar / levantar o dinheiro de forma mais eficiente;
  • NÃO É só para Web Startups de tecnologia, e sim para qualquer empresa que trabalha com inovação ou com incertezas;
  • NÃO É sobre a substituição de visão com feedback e dados, é sobre como fazer acontecer quando você tem a visão certa.

Produto Mínimo Viável

Nesta metodologia, a primeira versão do produto deve ser um produto mínimo viável ou MVP, ou seja, o produto mínimo concebível que pode encontrar um conjunto de clientes que estão animados o suficiente para usarem e pagarem pela visão de longo prazo do produto ideal.

Ou seja, o primeiro objetivo em criar um produto de sucesso deve ser encontrar os usuários visionários ou evangelistas (early adopters) que querem e precisam do produto. Esses usuários serão capazes de ter a visão final do produto, por isso vão ignorar as falhas temporárias e acabarão ajudando a aprimorar o produto da Startup.

A idéia por trás do produto mínimo viável é que uma Startup pode eliminar o desperdício limitando a primeira versão de um produto para as funcionalidades absolutamente essenciais que validam a visão de longo prazo e as hipóteses fundamentais da Startup.

Ajuste do Produto ao Mercado

Uma vez que a Startup tem um produto para colocar nas mãos dos clientes (um MVP), seu o único foco será a confirmação das hipóteses sobre o mesmo, ou seja, transformar esse produto em algo que os clientes realmente querem, e que seja vendido de forma lucrativa. Quando isso acontece a Startup tem o que é conhecido como casamento do produto ao mercado ou PMF – (Product/Market fit).

Quando pequenas melhorias do produto em desenvolvimento não resolvem, a maneira mais eficiente para alcançar o ajuste do produto ao mercado é mudar um aspecto ou componente central do Modelo de Negócio de cada vez, como o produto, o mercado-alvo, ou o modelo de receitas. Cada uma dessas mudanças de direção é chamada de pivô (pivot).

Uma empresa tem casamento de produto com o mercado, quando encontra um produto que os clientes realmente desejam. Quando uma empresa de Internet casa o produto com o mercado, muitas vezes começa a ter um crescimento exponencial de vendas.  As empresas que não conseguem ajustar seus produtos ao mercado, independentemente de como comercializem seus produtos, terão de lutar muito para encontrar o sucesso.

O processo Lean Startup

Conforme a figura abaixo, a partir das idéias você constrói um produto mínimo viável (código), mede os resultados, coleta dados e aprende algumas lições. E continua a executar este laço de aprendizagem, o mais rápido possível, fazendo ajustes até atingir o casamento do produto com mercado ou mudar algum item do modelo de negócios fazendo o pivô e começando tudo de novo. O objetivo é conseguir um modelo de negócio de valor, ou seja, que deixe o cliente feliz e gere lucro.

Concluindo

A idéia de Lean Startup é fazer tudo da forma mais simples possível, usando o mínimo de recursos e o máximo de velocidade para economizar dinheiro e diminuir riscos. Esta empresa enxuta começa com um produto mínimo viável e através de um processo iterativo de aprendizagem e validação qualitativa busca o ajuste do produto ao mercado para só então crescer em escala e estrutura.

Sobre mim: aqui, Contato: aqui.

Se gostou, por favor, compartilhe! Abraço, @neigrando

Veja também:

Referências:

Master Class sobre Modelos de Negócios e Inovação

Participei no final de novembro do evento Rio Business Innovation 2011, organizado pelo Cláudio D´Ipolitto e com o apoio de outros amigos do grupo que denominamos BMGen Brasil. O grupo se reuniu presencialmente em 20 de junho de 2011 na ESPM em São Paulo. Nosso principal objetivo é disseminar as técnicas de geração/design de modelos de negocio em nosso país, tanto para apoiar e incentivar o empreendedorismo, quanto à inovação nos negócios.

Nossa primeira meta foi trazer o Alexander Osterwalder ao Brasil para nos privilegiar com uma aula presencial especial (“Master Class”), o que aconteceu no dia 28 de novembro no Rio de Janeiro. O Alex é o autor do livro Business Model Generation (www.businessmodelgeneration.com) e do quadro que facilita desenhar o modelo de negócio de uma empresa em apenas uma folha de papel (canvas BMGen). O livro foi escrito com base em estudos acadêmicos e experiências práticas dele e de Yves Pigneur e contou com co-criação de um grupo de 470 participantes de 45 países, conforme já expliquei no artigo: A importância da Modelagem de Negócios.

Dia 28/11 – Master Class com o Alexander Osterwalder

Neste dia o Cláudio faz a abertura do evento enfatizando a importância do uso do BMGen para:

  • Pensar através de modelos
  • Criar modelos colaborativos
  • Sair da “caixa”
  • Falar uma linguagem comum em negócios

Em seguida João Batista Lanari Bó, Diretor do Depto de Tecnologias Inovadoras, MDIC, fez uma apresentação sobre a importância de Medir a Inovação com o título: Inovar é Preciso? E Andrea Bedeschi, Relações Institucionais da Rio Negócios (www.rio-negocios.com) nos mostrou o Panorama ”Rio Negócios”.

Depois disso, o Cláudio nos apresentou o Alex, dizendo que o “Método é o Caminho” e nos questionou:

– Para onde vamos? – Para que usar o canvas BMGen?

O Alex nos contou sobre algumas empresas inovadoras de sucesso e diz que elas:

  • deram mais forças a seus produtos através de modelos de negócio;
  • inventaram novos modelos de negócio;
  • assumiram alguns riscos e fizeram experimentos.

Para nos mostrar alguns problemas de comunicação e entendimento comum sobre negócios, ele perguntou à platéia: “O que é um modelo de negócios?” e recebeu diversas respostas, entre elas cito:
– “O plano que uma empresa usa para gerar receitas”.
– “O modo particular pelo qual uma organização empresarial garante que gerará renda, que inclui a escolha de ofertas de infra-estrutura, estratégias, estruturas organizacionais,práticas comerciais, processos e políticas operacionais.”

Então além de recebermos uma definição que o Alex usa em seu livro: “Um Modelo de Negócio descreve os fundamentos de como uma organização Cria, Entrega e Captura valor.”, ele nos perguntou novamente “O que fazer quando palavras não funcionam (blah, blah, blah, …)?” que responde em seguida nos falando que o modelo de negócios é uma linguagem para entendimento comum e que com o quadro (canvas BMGen) podemos ter uma visão sistêmica do negócio e melhorar o entendimento do negócio por todos os interessados. O quadro tem um design visual que incentiva atitudes criativas e colaborativas.

É muito raro aos homens de negócio pensarem de forma holística, usando algo como o canvas BMGen que mostra todas as partes juntas e facilita enxergar as relações entre elas.  Vide figura abaixo:

No quadro acima, pode-se escrever o modelo de negócios de várias formas. Recomenda-se iniciar pelo Segmento de Clientes ou pela Proposição de Valor e ir acrescentando os demais blocos. Esta forma de escrita, centrada no cliente, também pode ser usada na leitura da lógica do modelo, conforme vemos pelo seguinte texto: “A Proposição de valor é oferecida aos Segmentos de Clientes, através de Canais de comunicação, venda e distribuição e do Relacionamento com os clientes, gerando as Receitas que a empresa necessita. Este valor para o cliente é gerado através de Atividades chave, que empregam Recursos chave que estão a cargo da empresa e de suas Parcerias chave, que geram os Custos do negócio”.

Para exemplificar ele nos forneceu exemplos da Nespresso e da Apple, empresas que nos deixam as frases:

  • Nespresso: “O modelo de negócios pode ser a diferença entre o sucesso e a falha para o mesmo produto”.
  • Apple: “Nós estamos mudando de portfólios de produtos para portfólios de modelos de negócio”.

Orientou os presentes a compartilhar a visão do todo usando o Canvas BMGen. Disse que desenhar esta visão em equipe faz toda a diferença.

A orientação para os apresentadores de modelo de negócios pronto é que utilizem um Post-It por vez, para representá-lo no quadro, assim as pessoas podem seguir a explicação e ter tempo para pensar sobre o item e entender a explicação sobre a relação entre eles.

Outro ponto importante que destacou é que o Marketing e os Processos não fazem parte do desenho do modelo, mas sim da fase de implementação do mesmo. Cultura e estrutura hierarquia também só serão envolvidos na implementação.

Alguns críticos ao modelo apresentado por ele, dizem que o modelo não contém elementos como a concorrência, mas Alex nos explica que tais itens fazem parte do ambiente externo ao modelo onde o negócio está inserido, e que devem ser utilizados ao se pensar na estratégia. Com relação ao ambiente externo devem ser considerados não só as Forças da Industria (5 forças de Porter) que inclui a concorrência, mas também sobre as Forças do Mercado, Principais Tendências (tecnológicas, regulatórias, sociais e culturais e socioeconômicas) e Forças Macroeconômicas que incluem a infraestrutura da economia.

“Não congele com uma idéia.” – Jim Glymph, do livro “Managing as Designing”

“Prototipagem é a conversa que você tem com as suas idéias.” – Tom Wujec

Antes de partir para um exercício prático com modelos de negócio, o Alex nos mostrou a importância o uso do pensamento imaginativo e intuitivo ao trabalhar o design em busca ao desconhecido, e não apenas raciocínio lógico. Recentemente postei sobre isso em um artigo sobre Design Thinking. Ele também nos fez exercitar prototipação com um exercício chamado de desafio do marshmallow (Marshmallow Challenge). Neste experimento a tarefa é simples: em 18 minutos, diversas equipes formadas com 4 a 5 pessoas cada, devem construir a mais alta estrutura livre, em pé, a partir de 20 palitos de espaguete cru, um metro de fita adesiva, um metro de barbante e um marshmallow. Este experimento é muito interessante porque permite, aos membros da equipe não somente improvisar, mas exercitar alternativas, direções e possibilidades radicalmente diferentes (múltiplos modelos) que dão uma ideia do que pode ser feito em modelos de negócio. Na hora de inovar ou repensar o modelo de negócio, não se deve apaixonar-se pela primeira ideia.

Gostei também de escutar um pouco mais sobre inovação e sobre o livro “How Stella Saved The Farm” que você pode espiar em HowStellaSavedTheFarm.com. Trata-se de uma parábola de como se faz a inovação acontecer, escrito por: Vijay Govindarajan, e Chris Trimble – autores de outro livro “The Other Side of Innovation”.

Outros pontos abordados:

  • Pensar sobre o modelo de negócios e fazer perguntas do tipo “E SE”;
  • Não só reduzir custos, mas mudar a estrutura dos mesmos, por exemplo, pensar em substituir custos fixos por variáveis.
  • Pensar sobre a possibilidade de substituir venda do produto, por locação do mesmo, reduzindo assim o investimento inicial do cliente e conseguindo receita recorrente.
  • Considerar o Mercado de Dois Lados, como o do caso de um jornal que tem o lado leitor e o anunciante e o problema (galinha e ovo – quem nasceu primeiro). Isto ocorre também em negócios gateway como a gestão de os que fazem entregas a partir pedidos via Web ou Smarthphone (lado lojista e lado usuário); Ferramentas de busca x anúncios pagos; iPhone & Apple Store; etc.
  • O modelo Oceano Vermelho (Red Ocean) como o das console de jogos da Sony brigando com o Microsof Xbox, cujos jogos são complexos, exigem altos investimentos em pesquisa e desenvolvimento, produto com alta velocidade de processamento, alta resolução gráfica e direcionados a jogadores experientes. Enquanto um modelo diferente de negócios, como o que aconteceu com o Nintendo Wii, que foi pioneiro no uso de movimentos do corpo, é fácil de usar, tem menos necessidade de altos recursos gráficos e de processamento e foi feito para uso por pessoas comuns. Tal diferenciação ocorreu por que a empresa não tinha como competir, e assim precisou inovar.
  • A idéia de Eliminar, Reduzir, Aumentar ou Criar novos elementos durante o vendaval de ideias ao pensar o modelo de negócios.

Vimos que se temos dois segmentos de clientes distintos, geralmente teremos duas proposições de valor distintas correspondentes e que nestes casos devemos utilizar Post-It de cores diferentes para representá-los no quadro.

Para exercitar modelos de negócio, as equipes receberam a tarefa de trabalhar o produto “PEE BOO”: um saco-toalete de uso simples; auto-sanitário; que vira fertilizante, direcionado a pessoas muito pobres.

O negócio deveria ser lucrativo e escalável. E ao considerar o modelo, ele deve se possível:

  • ter Receitas Recorrentes;
  • ter um Custo de Mudança de fornecedor considerável por parte do cliente;
  • ter uma estrutura de preços do tipo Mudança de regras de Jogo, como o que fez o Skype junto às operadoras de telecomunicações concorrentes;
  • ter algum tipo de Proteção contra a Concorrência, como fez a Apple como o iPod/iTunes;
  • conseguir com que Outros Façam o seu Trabalho, como o caso do Facebook;
  • e até mesmo Receber antes de Gastar, como no caso da Dell que vende e recebe antes de entregar a encomenda.

Depois de tudo isso ainda fomos lembrados de que o desenho de um novo modelo de negócios é composto de uma série de hipóteses e que é muito importante testá-las em campo, junto ao potencial cliente antes de implementar o modelo, e uma forma de fazer isso, por exemplo, no mundo Web é criar páginas de lançamento alternativas (teste A/B). Meu artigo: O Modelo de Desenvolvimento do Cliente explica como testar o modelo junto ao cliente em paralelo com o desenvolvimento do produto usando Metodologias Ágeis.

Por favor, fique a vontade para contribuir com um comentário e compartilhar este artigo com seus amigos.

Meu endereço no Twitter é: @neigrando ou clique aqui para entrar em contato.

Se quiser ir mais fundo, o primeiro vídeo deste artigo contém uma palestra do Alex (em inglês) que apresenta alguns conceitos e exemplos que comentei: Stanford Talk & The Bay Area.

Faça o download da apresentação do Alex no Rio aqui.

Links relacionados:

Livros relacionados:

  • Business Model Generation, por Alex Osterwalder & Yves Pigneur
  • The Four Steps to the Epiphany, por Steve Blank
  • Design Thinking (do original Change by Design), por Tim Brown
  • Empreendedorismo Inovador – Como Criar Startups de Tecnologia no Brasil, 25 autores, Editora Évora
  • How Stella Saved The Farm, por Vijay Govindarajan, e Chris Trimble
  • The Other Side of Innovation, por Vijay Govindarajan, e Chris Trimble

Metodologias Ágeis no Desenvolvimento de Projetos de Software

Este é um artigo técnico, sobre os conceitos usados nas metodologias ágeis e está voltado para gestores de tecnologia da informação, gerentes de projetos de software, arquitetos de software, desenvolvedores, testers e demais interessados no assunto.
Entre os diversos títulos veja, em especial, o quadro comparativo geral entre a abordagem tradicional e a ágil, e o quadro que informa quanto é ideal usar cada uma delas.

“Desenvolvimento ágil é o método de engenharia usado para desenvolver produtos (hardware, software ou serviços) de forma iterativa e incremental com flexibilidade para reagir ao feedback dos clientes. Ele reconhece que as necessidades do cliente e que a especificação do produto final não pode ser totalmente definida a priori. Agile é a antítese do Desenvolvimento Cachoeira.”

Na última empresa que participei como sócio-gestor, nossa estratégia e gestão tinham como objetivo a busca pela excelência e a qualidade total com inovação e melhoria contínua. Concentramos esforços para atender, e até mesmo superar, as expectativas dos clientes, sócio-investidores e colaboradores, onde procurávamos sempre:

  • Utilizar o que havia de melhor em tecnologia da informação para satisfação de nossos clientes, seja no atendimento, seja no fornecimento de produtos e serviços.
  • Manter com os clientes, associados, colaboradores e fornecedores uma relação de alto nível profissional e ético, baseado na integridade, transparência e confiança.
  • Criar um ambiente alegre, saudável e propicio para a realização pessoal e profissional de nossos colaboradores.
  • Contribuir com a sociedade onde atuamos para manter sustentabilidade a longo prazo.

Nos últimos anos em nossa área de sistemas, nossas equipes trabalhavam em: análise de requisitos de negócio; arquitetura de software; design de interfaces visuais com navegabilidade via protótipos; desenvolvimento de código que incluíam testes unitários; testes completos; entrega e suporte técnico ao pessoal de infra-estrutura na implantação; e suporte técnico durante o período de manutenção.

Com certeza não é fácil encontrar a efetividade, ou seja, a eficiência de fazer bem as tarefas utilizando da melhor maneira possível os recursos, somada com a eficácia que busca atingir um excelente resultado.  Entregar no prazo, com qualidade e com todas as funcionalidades do escopo do projeto sempre foi o nosso objetivo, e, além disso, precisávamos encontrar formas de manter as equipes motivadas e os clientes satisfeitos.  Foi assim que resolvemos providenciar uma metodologia própria no desenvolvimento de projetos de software, que aproveitasse o melhor daquilo que havíamos estudado e praticado ao longo do tempo.

Tomamos então por base os princípios das metodologias ágeis, considerando características do SCRUM, FDD (Feature-Driven Development) , XP (eXtreme Programming) e MSF Ágile que é uma versão leve do Microsoft Solution Framework for CMMI (Capability Maturity Model Integration). Também consideramos algumas práticas do padrão PMBoK (Project Management Body of Knowledge) do PMI (Program Management Institute) na gestão dos projetos, e alguns diagramas UML (Unified Modeling Language) para ajudar na interação e coerência entre os requisitos, a modelagem e o sistema.

O desenvolvimento é iterativo, o que permite uma compreensão crescente do problema através de refinamentos sucessivos que nos aproxima da solução. Esta aproximação permite maior flexibilidade para acomodar novos requisitos ou mudanças táticas nos objetivos do negócio além de identificar riscos antecipadamente.

Esta metodologia nos permitiu:

  • Promover a integração constante entre os interessados (stakeholders) e a equipe da empresa, cliente e parceiros – para que as expectativas e necessidades fossem atendidas;
  • Assegurar a mesma visão do projeto e o acompanhamento de seu desenvolvimento por parte de todos os membros da equipe;
  • Contribuir para o posicionamento da empresa no mercado, com mais um diferencial competitivo.

Seguem abaixo três definições que serão úteis no entendimento dos textos apresentados neste documento:

Projeto – É um empreendimento temporário com início e término bem definidos, conduzido por pessoas para atender objetivos dentro de parâmetros de Prazo, Escopo/Qualidade e Custo.

Gestão de Projetos – Combinação de recursos humanos e materiais através de metodologias e técnicas para atender os objetivos de um projeto. Aplicação de conhecimentos, habilidades e técnicas para planejar atividades que visem a atingir os requisitos do projeto.

Metodologia – É um conjunto de técnicas e métodos; é a forma de ordenar e organizar diferentes tarefas; é um mapa de vôo; é o caminho mais inteligente a ser percorrido para alcançar o melhor resultado. É um guia de referência sobre o que deve ser considerado.

A idéia é adotar práticas que ajudaram outros projetos beneficiar o novo projeto.

O Dilema da Construção de Software

Analisando o cenário de projetos da área de Tecnologia da Informação, percebe-se que, mesmo com os esforços e investimentos realizados, as empresas têm falhado sistematicamente na entrega de seus projetos de desenvolvimento de sistemas. Pesquisas apontam diferentes causas para esse insucesso, entre elas, a falta de domínio de métodos e técnicas e/ou a adoção de práticas errôneas de gerenciamento de projetos. Em face dessa situação, verifica-se a existência de uma lacuna entre a necessidade dessas empresas e os resultados práticos de desempenho alcançados. Desse hiato, advém a urgência de se estruturar ou mesmo repensar a disciplina de gerenciamento de projetos clássico, adotado pelas organizações de desenvolvimento de sistemas.

O Agile Project Management ou Gerenciamento Ágil de Projetos – surge como uma solução promissora, com o intuito de melhorar os resultados de desempenho dos projetos de desenvolvimento de sistemas de Tecnologia de Informação.

O problema:

Projetos de software sempre foram marcados por fracassos:

  • Prazos e orçamentos não cumpridos;
  • Expectativas não satisfeitas;
  • Retorno muito menor que o esperado;
  • Impossível satisfazer ao mesmo tempo custo, prazo, escopo e qualidade.

A solução:

Utilizar uma metodologia apropriada para o desenvolvimento de software

  • investindo tempo e recursos em uma fase detalhada de planejamento e design;
  • garantindo o sucesso da execução com gerenciamento e processos bem definidos.

Metodologias tradicionais

Será esta a Solução? Utilizar metodologias tradicionais, como RUP, CMMI, modelos ISO e tantas outras?  Buscar a complexidade, ao invés da simplicidade?

“Uma grande solução para nossos problemas … ou um grande problema para nossas soluções?” Ou devemos ser mais ágeis, utilizando uma metodologia ágil?

Modelagem Ágil – Um apanhado geral por Scott W. Ambler

Modelagem Ágil é uma metodologia baseada na prática para modelagem efetiva de sistemas baseados em software.

A metodologia de Modelagem Ágil é uma coleção de práticas, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia.

Modelagem Ágil não é um processo prescritivo, ela não define procedimentos detalhados de como criar um dado tipo de modelo, ao invés ela provê conselhos de como ser efetivo como modelador. É “no tato”, e não “pau-na-máquina” – pense em Modelagem Ágil como uma arte, não como uma ciência.

A modelagem Ágil tem três objetivos:

  1. Definir e mostrar como colocar em prática uma coleção de valores, princípios e práticas pertinentes à modelagem efetiva e “peso-leve”.
  2. Explorar como aplicar técnicas de modelagem em projetos de software através de uma abordagem ágil tal como XP, FDD, DSDM ou SCRUM.
  3. Explorar como melhorar a modelagem sob processos prescritivos como o Processo Unificado da Rational (RUP) – atualmente da IBM.

O que são os Modelos Ágeis?

Um modelo ágil é um modelo bom o suficiente, que implica nas seguintes características:

  • Atende seu propósito;
  • É inteligível;
  • É suficientemente preciso;
  • É suficientemente consistente;
  • É suficientemente detalhado;
  • Provê um valor positivo;
  • É tão simples quanto possível.

O que é (e não é) Modelagem Ágil?

  • É uma atitude, não um processo prescritivo;
  • É um suplemento aos métodos existentes, ele não é uma metodologia completa;
  • É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto;
  • É efetivo e é sobre ser efetivo;
  • É uma coisa que funciona na prática, não é teoria acadêmica;
  • Não é uma bala de prata;
  • É para o desenvolvedor médio, mas não é um substituto de pessoas competentes;
  • Não é um ataque à documentação, pelo contrário, aconselha a criação de documentos de valor;
  • Não é um ataque às ferramentas CASE;
  • Não é para todos.

Os 12 Princípios da Agilidade

  1. Lembre que a mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor;
  2. Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente;
  3. Libere software freqüentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta;
  4. Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto;
  5. Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado;
  6. O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face;
  7. Software funcionando é a principal medida de progresso de um projeto de software;
  8. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica sempre;
  9. A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade;
  10. Simplicidade é essencial, devendo ser assumida em todos os aspectos do projeto;
  11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
  12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento.

Resumo dos Princípios Centrais da Modelagem Ágil

  • Mudanças são bem-vindas;
  • Capacitar o próximo esforço é seu objetivo secundário;
  • Mudanças incrementais;
  • Maximizar o investimento daqueles que suportam o sistema;
  • Modelar com um propósito;
  • Múltiplos modelos;
  • Trabalho de qualidade;
  • Feedback rápido;
  • Software é seu objetivo primário;
  • Viaje com pouca bagagem.

Resumo dos Princípios Suplementares da Modelagem Ágil

  • Conteúdo é mais importante que Representação (Forma);
  • Todos podem aprender com todos os outros;
  • Conheça seus modelos;
  • Conheça suas ferramentas;
  • Adaptação local;
  • Comunicação aberta e honesta (integridade e transparência);
  • Trabalhe com o instinto das pessoas.

Os Valores da Modelagem Ágil

A serem adotados no Desenvolvimento de Projetos de Software.

Comunicação – Modelos promovem a comunicação entre a equipe de desenvolvimento e os interessados do projeto tão bem quanto entre os desenvolvedores da equipe.

Coragem – Coragem é importante para a tomada de decisões e para permitir a mudança de direção descartando ou refazendo o trabalho quando algumas decisões anteriores foram inadequadas.

Humildade – Os melhores desenvolvedores são humildes o suficiente para reconhecer que não conhecem tudo e que estão sujeitos a falhas e que seus seguidores, líderes e outros interessados no projeto também têm suas áreas de especialidade, e de que testes do código/solução feitos por si e por outros são necessários e fundamentais para a qualidade do desenvolvimento/resultado.  Uma abordagem efetiva é assumir que todos os envolvidos no projeto têm igual valor e, portanto devem ser tratados com respeito. Devemos procurar tratar as opiniões e/ou idéias dos outros como se tivessem maior valor que as nossas. Será mais positivo e produtivo agir com proatividade procurando  criar sinergia e não reação e discórdia.

Simplicidade – É importante aos desenvolvedores entender que modelos são críticos para simplificar o software e os processos de desenvolvimento – é mais fácil explorar uma idéia e melhorá-la conforme seu entendimento aumenta, desenhando um diagrama ou dois ao invés de escrever/estudar dezenas e até mesmo centenas de linha de código.

Retorno (feedback) – É fácil obter feedback para agir quando comunicamos idéias através de diagramas universais, como os da UML.

Os Valores da Aliança Ágil

Adicionalmente aos valores listados acima, a metodologia Modelagem Ágil também adotou os valores da Aliança Ágil. Vide em http://www.agilealliance.org os valores definidos no seu manifesto:

  • Indivíduos e Interações mais que processos e ferramentas;
  • Software operante mais que documentações completas;
  • Colaboração do cliente mais que negociações contratuais;
  • Responder às mudanças mais que seguir um planejamento.

A coisa importante a se entender é que enquanto você deve valorizar os conceitos do lado direito, você deve valorizar ainda mais os itens do lado esquerdo. Uma boa forma de pensar sobre o manifesto é que ele define preferências, não alternativas.

Práticas Centrais da Modelagem Ágil

  • Participação ativa daqueles que suportam o projeto;
  • Aplique os artefatos certos;
  • Propriedade coletiva;
  • Considere a “Testabilidade”;
  • Crie vários modelos em paralelo;
  • Crie conteúdo simples;
  • Represente os modelos de forma simples;
  • Apresente os modelos publicamente;
  • Passe para os outros artefatos;
  • Modele em pequenos incrementos;
  • Modele com os outros;
  • Prove, demonstre com código;
  • Use as ferramentas mais simples.

Práticas Suplementares da Modelagem Ágil

  • Aplique normas de modelagem;
  • Aplique padrões gentilmente;
  • Descarte os modelos temporários;
  • Formalize os modelos de contrato;
  • Modele para comunicar;
  • Modele para entender;
  • Reutilize recursos existentes;
  • Atualize somente quando doer.

Comparativo Geral da Abordagem Tradicional com a Ágil

Abordagem Tradicional  Abordagem Ágil
Preditivo: detalhar o que ainda não é bem conhecido Adaptativo: conhecer problema e resolver o crítico primeiro
Rígido: seguir especificação predefinida, a qualquer custo Flexível: adaptar-se a requisitos atuais, que podem mudar
Burocrático: controlar sempre, para alcançar objetivo planejado Simplista: fazer algo simples de imediato e alterar se necessário
Orientado a processos: segui-los possibilita garantir a qualidade Orientado a pessoas: motivadas comprometidas e produtivas
Documentação gera confiança Comunicação gera confiança
Sucesso = entregar o planejado Sucesso = entregar o desejado
Gerência = “comando-e-controle” voltado para trabalho em massa, ênfase: papel do gerente, com planejamento e disciplina fortes Gerência = liderança/orientação
trabalhadores do conhecimento, ênfase: criatividade, flexibilidade e atenção às pessoas
Desenvolvedor hábil (variedade) Desenvolvedor ágil (colaborador)
Cliente pouco envolvido Cliente comprometido (autonomia)
Requisitos conhecidos, estáveis Requisitos emergentes, mutáveis
Retrabalho/reestruturação caro Retrabalho/reestruturação barata
Planejamento direciona os resultados (incentiva controlar) Resultados direcionam o planejamento (incentiva mudar)
Conjunto de processos, com metodologia definida Conjunto de valores, com atitudes e princípios definidos
Premia a garantia da qualidade Premia o valor rápido obtido
Foco: grandes projetos ou os com restrições de confiabilidade, planej. estratégico / priorização (exigem mais formalismo) Foco: projetos de natureza exploratória e inovadores, com equipes pequenas/médias
(exigem maior adaptação)
Objetivo: controlar, em busca de alcançar o objetivo planejado (tempo, orçamento, escopo) Objetivo: simplificar o processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos

Quando usar qual metodologia

Metodologias Preditivas Metodologias Ágeis
Projetos altamente críticos Projetos pouco críticos
Equipe iniciante Equipe experiente
Projeto com poucas mudanças Projeto com mudanças constantes
Equipes maiores (>= 20 pessoas) Pequena equipe (< 20 pessoas)
Equipe distribuída Equipe co-localizada
Cultura de controle Cultura de adaptação

Pontos positivos e negativos das abordagens

  • Partem de pressupostos diferentes!
  • Podem coexistir e conviver bem em um mesmo ambiente, pois as “boas práticas” são compatíveis e podem funcionar bem, mesmo sem contemplar integralmente um modelo ou norma.
  • Importante: considerar, criteriosamente, o ambiente correto.
  • É necessário buscar o ponto de equilíbrio, avaliando os riscos.

O ciclo de vida ágil é semelhante aos outros

  • Definir o que o cliente quer e iniciar o projeto;
  • Planejar o projeto, calculando esforço;
  • Executar o plano, construindo a solução;
  • Monitorar resultados e entregar ao cliente;
  • Ciclos mais rápidos, executados várias vezes.

O planejamento aperfeiçoa a agilidade. A agilidade dá eficiência ao planejamento.

Manifesto Ágil – par de alternativas se reforçam

  • Processos e ferramentas podem melhor capacitar os indivíduos e interações;
  • Documentação ajuda as pessoas a entenderem um software complexo;
  • Negociação de contrato pode ser parte integrante da colaboração do cliente;
  • Seguir um plano pode ser o melhor modo para responder a mudança, quando esta for previsível.

Observação: Pessoas comprometidas e suas proposições de valor são fundamentais!

Por favor, fique a vontade de contribuir com um comentário e compartilhar este artigo com seus amigos.

Meu endereço no Twitter é: @neigrando –  www.twitter.com/neigrando

Links relacionados com o assunto: