Posts com o tag ‘Lean Software Development’

Investimento em Opções

Domingo, 26 de outubro de 2008 por Daniel Cukier

O mercado financeiro e de commodities desenvolveu há muito tempo um mecanismo, chamado de opções. Ele basicamente serve para permitir que decisões sejam postergadas. Uma opção é o direito, não uma obrigação, de fazer algo no futuro. Como um certificado de garantia: se as coisas forem bem, como esperado, pode-se exercer a opção (equivalente a ficar com o produto). Senão, pode-se ignorar a opção (devolvendo o produto) e tudo que se perde é o custo inicial de ter a opção.

Uma incerteza pode levar para duas direções: nos dias de hoje sabe-se muito bem como uma ação na bolsa de valores pode subir ou descer muitas vezes. Também nesse mercado existe uma forma de vender opções que garantam um preço mínimo de venda da ação (no caso de queda) ou comprar opções para um preço máximo de compra (no caso de uma alta).

Tube bem que é um pouco confuso essa coisa de misturar venda com compra, compra com venda, uma barbaridade, mas no fundo a idéia é gastar pouco agora para poder ganhar muito no futuro se a coisa der certo e, caso dê errado, como o gasto foi pequeno, perder pouco. O principal é que com isso podemos tomar as grandes decisões na hora certa, que é justamente quando a incerteza diminui.

A Microsoft fez isso com software, em 1988, quando apresentou na Comdex o DOS, uma versão do Windows, o OS/2 para IBM, uma versão do UNIX e as primeiras versões do Word e do Excel. Nessa época não se sabia qual plataforma iria prevalecer e Gates tinha a estratégia: cobrir todas as possibilidades. Ele jogou o jogo das opções e esperou o mercado emergir.

Processos de desenvolvimento de software podem ser vistos como uma forma de criar opções, permitindo que as decisões sejam adiadas para o momento em que o cliente sabe claramente o que quer. Não se pode confundir com falta de planejamento, mas com uma forma de deixar as coisas sempre prontas para se adaptarem e mudarem conforme a necessidade do cliente. A idéia é evitar tomar decisões erradas antecipadamente e ao mesmo tempo poder mudar rapidamente de rumo caso seja necessário.

Vale lembrar que pensar em opções tem seu custo: opções não garantem sucesso. Mas elas são uma excelente ferramenta em tempos de incertezas e devem ser usadas para tomar decisões olhando-se fatos, baseando-se em aprendizado e não em especulações.

Fonte: Lean Software Development - An Agile Toolkit

A natureza de desenvolver software

Sábado, 18 de outubro de 2008 por Daniel Cukier

A geração de bom software não é um processo de produção; é um processo de desenvolvimento. Desenvolver é diferente de produzir. Desenvolver é como criar uma receita, enquanto que produzir é seguir os passos de uma receita pronta. São atividades diferentes. Desenvolver uma receita é um processo de aprendizado, de tentativa e erro. Quando um grande chefe cria um prato, ele não o cria de primeira. O prato primordial é resultado de um refinamento, de várias tentativas e variações sobre um tema, na busca do resultado perfeito.

Desenvolvimento
Projetar a receita
Produção
Produzir o prato
  • Qualidade é estar de acordo com o uso
  • Variações são boas
  • Iterações geram valor
  • Qualidade é estar de acordo com os requisitos
  • Variações são ruim
  • Iterações geram desperdício (re-trabalho)

Na Disneylândia, existem centenas de atores cujo único trabalho é fazer com que cada visitante tenha momentos maravilhosos. Os requisitos do que é um “momento maravilhoso” muda de visitante para visitante e o trabalho do ator é descobrir o que o visitante vê como experiência de qualidade e se certificar de que ele tenha essa experiência.

A visão de qualidade de serviço (e hoje software é serviço) leva em conta que cada cliente tem uma idéia diferente do que significa uma experiência de qualidade.

A diferença entre prover um serviço e produzir um produto é que, em serviços, atender a necessidade do cliente requer variações, enquanto que em linhas de produção variações são vistas como inimigas.

Problemas de software possuem várias soluções, em vários níveis, feitas por todos os membros do time. Não só os arquitetos estão envolvidos, mas todos os desenvolvedores. Escrever código envolve um entendimento profundo do problema, reconhecer padrões, experimentar várias abordagens, testar os resultados. Para isso, o melhor processo é aquele que consiste em ciclos curtos de aprendizado.

Fonte: Mary and Tom Poppendieck, Lean Software Development - An Agile Toolkit

Agile2008 Conference

Quinta-feira, 21 de agosto de 2008 por Elson Barbosa

No início de agosto a Locaweb esteve presente no maior evento de Metodologias Ágeis do planeta: o Agile2008, em Toronto, Canadá. Os números impressionaram: por volta de 2000 participantes do mundo inteiro se dividiram em quase 500 sessões sobre os mais diversos assuntos, desde Scrum, XP e Lean até Cultura Ágil, Liderança Ágil, Planejamento Ágil, Valores, Métricas, Ferramentas, Qualidade, UX etc. As credenciais dos palestrantes também impressionaram: Mary Poppendieck (autora de Implementing Lean Software Development), Mike Cohn (autor de Agile Estimating and Planning), Alan Shalloway (autor de Design Patterns Explained: A New Perspective on Object-Oriented Design), Scott Ambler (autor de Refactoring Databases: Evolutionary Database Design), Henrik Kniberg (autor de Scrum and XP from the Trenches), entre dezenas de outros.

Como participante, a maior dificuldade foi escolher a melhor sessão a assistir. Em média havia 40 sessões simultâneas, sendo no mínimo umas 10 imperdíveis. A seguir alguns breves comentários sobre as sessões a que assisti:

  • Expanding Agile Horizons: The Five Dimensions of Systems
    Mary Poppendieck
    Poppendieck começou questionando se Ágil pode ser somente mais uma “plank road” - uma excelente solução temporária que não sobrevive a longo prazo. Mas concluiu que até o momento não há indícios que as Metodologias Ágeis sejam temporárias - pelo contrário. Em seguida explicou as cinco dimensões que todo sistema deve ter - Propósito, Estrutura, Integridade, Tempo de Vida e Resultados.
  • Introduction to Lean Software Development
    Alan Shalloway
    Shalloway descreveu as semelhanças entre o Desenvolvimento de Produto Lean e o Desenvolvimento de Software Ágil. Descreveu o Pensamento Lean, seus princípios - Valor, Fluxo de Valor, Fluxo, Puxar, Perfeição - e suas práticas - Otimizar o Todo, Eliminar Desperdícios, Construir Qualidade, Entregar Rápido.
  • Agile Estimating and Planning
    Mike Cohn
    Cohn apresentou um resumo do livro Agile Estimating and Planning, uma das bíblias da Metodologia Ágil. Todos os conceitos básicos - Backlog de Produtos, Estimativas, Pontos de História, Planejamento de Sprints, Planning Poker, Velocidades, Releases etc - foram apresentados, além de algumas boas dicas para quem já aplica a metodologia.
  • Embrace Uncertainty, Why In Agile Development Knowing What You Want May Be An Impediment to Getting It
    Jeff Patton
    Nessa palestra Patton mostrou como o conceito de Iteração Ágil pode ser mal interpretado ao ignorarmos incertezas. Ele demonstrou como desenvolver histórias pensando em Metas de Qualidade Iterativa - primeiro focar em Necessidade, depois Flexibilidade, depois Segurança, e por fim Luxo e Performance. Em outras palavras, se o release contiver 10 features, é melhor desenvolver o mínimo de cada uma das 10 em poucas iterações e depois melhorá-las do que desenvolver as 10 completas uma de cada vez. “Não existe iteração se você fizer uma única vez”.
  • Value Stream Mapping - Extending Our View to the Enterprise
    Alan Shalloway
    Shalloway demonstrou como criar um Mapa de Fluxo de Valor - identificar as ações, identificar os tempos totais e de valor de cada ação, identificar retrabalhos, calcular a eficiência atual -, para enfim identificar o que fazer para melhorar cada ponto do processo e assim melhorar sua eficiência.
  • Prioritizing Your Product Backlog
    Mike Cohn
    Cohn mostrou como priorizar histórias de produtos utilizando pesquisas de usuários aliado a diferentes técnicas de análise: Kano Analysis, Theme Screening, Theme Scoring, Relative Weighting etc.
  • Defining the Role of Agile Manager - Theory and Practice
    Michael Spayd, Lyssa Adkins
    Spayd e Adkins mostraram os diferentes tipos de Liderança Ágil - Gerenciamento de Times, de Recursos, de Performance, de Resultados, de Portfolio, de Parceiros Internos, de Fornecedores -, explicaram seus papéis e responsabilidades, e sugeriram um “health check” para identificar sucessos e pontos de melhoria.
  • Future Directions for Agile
    David Anderson
    Anderson questionou o quanto o próprio conceito de Agilidade se adapta e evolui com o tempo, e apresentou algumas novas tendências como Behaviour-Driven Development, Kanban Development e Real Option Theory.
  • From High-Performing to Hyper-Performing Agile Teams
    Gabrielle Benefield, Jeff Sutherland, Rob Mee, Jason Titus
    Nesse debate os participantes relataram experiências de Ágil na PatientKeeper, Pivotal e Yahoo Mail, contando como melhoraram a performance de seus times e a qualidade de seus produtos.
  • The Aikido of Agile Project Metrics
    Alan Goerner
    Goerner mostrou técnicas simples e eficientes para criar métricas em projetos ágeis, demonstrando indicadores de qualidade e prazo através da análise de velocidades de times e de quantidade de valor entregue.
  • Energize Your Strategy Through Agility and Innovation
    Jochen Krebs
    Krebs comentou a importância da inovação através de métodos ágeis, buscando definir metas (maximização de valor, alinhamento estratégico) e evitando riscos (muitos projetos em paralelo, projetos errados em andamento, falta de visão).
  • Starting a Kanban System for Software Engineering with Value Stream Maps and Theory of Constraints
    Corey Ladas
    Ladas deu dicas de como aplicar Lean em desenvolvimento de software, utilizando Kanban (cartões ou post-its), limitando trabalho em andamento e implementando um sistema puxado de atividades.
  • 10 Ways to Screw Up with Scrum and XP
    Henrik Kniberg
    Kniberg apresentou as 10 “melhores” maneiras de estragar Scrum e XP: Acreditar no hype, não ter uma definição de “pronto”, não analisar velocidade, não ter retrospectivas, não ter comprometimento do time, ter débitos técnicos, não ter teamwork, não ter um product owner efetivo, mergophobia, não ter um backlog claro.

Conclusão

A oportunidade de assistir a sessões dos experts nesses conceitos foi excelente. A cada palestra assistida surgiam novas idéias de aplicação aqui na Locaweb. O ponto contra foi a enorme quantidade de palestras simultâneas, o que obrigou cada participante a abrir mão de centenas de sessões em favor de algumas poucas. Mas no geral vale a pena, e muito. O ganho que teremos na empresa com a aplicação das diversas idéias discutidas ali certamente será enorme.

Por exemplo, implantamos o Método Ágil de Remoção de Impedimentos com sucesso absoluto! :)