Agenda Ágil de outubro

por em Eventos,Metodologias Ágeis Nenhum comentário

O mês de outubro está repleto de ótimos eventos ágeis. Vai ser difícil conciliar a agenda para conseguir acompanhar tudo que acontecerá no próximo mês. Aí vão as dicas:

Dia 11 de Outubro: Encontro Ágil, organizado pela Agilcoop. O evento é gratuito e terá uma trilha básica para os iniciantes e uma trilha avançada para aqueles que já conhecem métodos ágeis e querem se aprofundar nos conceitos. Presenças confirmadas de Fábio Kon, Dairton Bassi e Vinicius Teles entre outros.

Dias 15 e 16 de Outubro: Rails Summit Latin America, organizado pela Locaweb. O foco do evento é a linguagem Ruby On Rails, mas sabemos que a comunidade Rails está fortemente ligada à comunidade ágil. Presenças de Chad Fowler, Fábio Akita, Danilo Sato, Fábio Kung.

Dias 23 e 24 de Outubro: Falando em Agile, organizado pela Caelum. O evento terá participações importantes de colaboradores da Thoughtworks, uma das primeiras empresas de consultoria a adotar métodos ágeis. Presenças de David Anderson, Alexandre Magno, Adail Retamal e Edmílson Miyasaki e muito mais.

Pin It

Agile2008 Conference

por em Metodologias Ágeis (1) comentário

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! :)

Pin It

Mudanças de Sprint

por em Metodologias Ágeis Nenhum comentário

Algumas semanas atrás apresentamos um webcast sobre metodologias ágeis, com enfoque em Scrum. Observei que um dos assuntos que mais geraram dúvidas é em relação a mudanças durante os sprints. Acredito que vale um post específico sobre esse assunto.

Antes de mais nada, vale lembrar que o Scrum é totalmente flexível para mudanças fora do sprint (ou seja, o backlog de histórias pode ser atualizado a qualquer hora), mas durante o período do sprint, as histórias que entram em um sprint não devem ser alteradas. Contudo, sabemos que exceções acontecem, desde atrasos ou adiantamentos que requerem uma mudança de planejamento, até histórias que têm de ser re-priorizadas ou retiradas do sprint. Na prática, o ideal é a equipe e o PO analisarem cada caso para tomarem a decisão correta. Se existe algo urgente a ser feito, pode valer mais a pena a equipe desenvolver essa história e deixar de entregar outra do que seguir o plano inicial e deixar a história urgente para o sprint seguinte. Cada caso é um caso.

Vamos ver alguns exemplos. Abaixo seguem algumas situações que requerem mudanças durante o sprint, devido a atrasos, adiantamentos ou impedimentos. As situações são baseadas em um sprint imaginário de duas semanas, com um fim-de-semana no meio do sprint, tendo ao todo 100 horas. As análises serão feitas baseadas nos gráficos de burndown e burnup.

Sprint Atrasado

Situação A: A equipe está trabalhando no sprint, mas algo não está indo bem e faz com que a equipe atrase as atividades. O burndown mostra que no fim-de-semana faltavam por volta de 80 horas, ao invés das 50 previstas.

Burndown

Existem duas explicações possíveis:

BurnupExplicação A1: A equipe não está trabalhando no sprint. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 20 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo – Estão recebendo tarefas fora do sprint? São urgentes? O que tem que ser feito para que a equipe volte a produzir?

BurnupExplicação A2: A equipe subestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, novas horas surgem (ex: uma atividade tinha 8 horas; equipe trabalha 4 horas e diz que ainda faltam mais 8 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo – Falta de planejamento? Falta de entendimento das histórias no dia do planejamento? Falta de experiência na linguagem ou ferramenta utilizada?

O que deve ser feito:
- As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que algumas histórias não poderão ser entregues nesse sprint, e o PO deve decidir quais podem ser retiradas. Com isso acontecendo, vemos no burndown a situação se normalizando, e no burnup a queda de horas a serem entregues.

Burndown Burnup

O que não deve ser feito:
- Exigir que a equipe trabalhe mais horas sem cortar escopo: Isso oferece riscos à qualidade final do código.
- A equipe decidir quais histórias não entregar: Quem deve tomar essa decisão é sempre o PO.
- A equipe “deixar a bomba estourar” sem avisar o PO.

Sprint Adiantado

Situação B: A equipe está trabalhando no sprint, mas está indo mais rápido que o previsto e deverá terminar o sprint antes do esperado. O burndown mostra que no fim-de-semana faltavam por volta de 30 horas, ao invés das 50 previstas.

Burndown

Existem duas explicações possíveis:

BurnupExplicação B1: A equipe está trabalhando mais do que o previsto. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 70 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo – Estão codificando sem seguir padrões, sem testes e sem qualidade? Estão fazendo pouco pareamento?

BurnupExplicação B2: A equipe superestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, outras horas são eliminadas (ex: uma atividade tinha 8 horas; equipe trabalha 2 horas e diz que faltam somente mais 2 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo – Falta de planejamento? Falta de entendimento das histórias no dia do planejamento?

O que deve ser feito:
- As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que o sprint está adiantado, e pedir mais histórias pra completar o sprint. Com isso, vemos no burndown a situação se normalizando, e no burnup o aumento de horas a serem entregues.

Burndown Burnup

O que não deve ser feito:
- Terminar o sprint alguns dias antes: Em algumas situações pode ser aceitável, mas isso acaba quebrando a cadência da equipe, além de criar possíveis problemas de agendamento de salas, atualização de agendas etc.
- A equipe esconder a situação para trabalhar menos: Isso pode ser visto facilmente nos gráficos, e pode gerar desconfiança entre as partes envolvidas.

Mudança de Prioridade

Situação C: A equipe está trabalhando no sprint, mas um problema urgente surge e deve ser resolvido ainda durante o mesmo sprint.

O que deve ser feito:
- Conversar, sempre. A situação é tão urgente que não pode esperar 15 dias? A metodologia defende a idéia de que o sprint deve ser cancelado, já que o seu escopo está sendo alterado. Contudo, pode valer uma adaptação da metodologia: Fazendo uma renegociação, com a história urgente entrando no sprint, ao mesmo tempo em que outras histórias ainda não iniciadas saem, pode ser mais ágil do que propriamente cancelar o sprint e fazer um novo planejamento.
- Tratar a atividade como impedimento, e discutí-la na revisão de sprint: Esse problema poderia ter sido previsto e/ou evitado? Pode acontecer novamente no futuro?

O que não deve ser feito:
- PO insistir na história urgente sem negociar: “É rápido e vocês resolvem fácil…”
- Tratar a situação fora do sprint: Toda atividade realizada fora do sprint não aparece como resultado da equipe, e é importante saber se essa situação é frequente ou somente uma exceção.

Revisão de Sprint: Melhoria Contínua

Por fim, vale lembrar uma das práticas mais importantes das Metodologias Ágeis: Melhoria Contínua. Todas as situações acima devem ser discutidas na reunião de revisão de sprint, e decisões devem ser tomadas para que esses problemas não ocorram mais.

Revisão

Pin It

Webcast – Metodologias Ágeis e Scrum

por em Metodologias Ágeis (3) comentários

Repassando o post publicado no blog oficial da Locaweb:

Na próxima Sexta-feira, 13 de Junho às 15h, faremos uma transmissão ao vivo sobre a utilização de Metodologias Ágeis e Scrum no desenvolvimento de Software.

A duração prevista é de 60 minutos e a participação é gratuita.
Para participar clique aqui, preencha o cadastro e faça a sua inscrição.

Se você já se cadastrou, clique na aba “Já sou cadastrado“, digite o seu e-mail e inscreva-se no evento.

As vagas são limitadas!

O evento será apresentado por Elson Barbosa, Gerente de Projetos, que destacará os principais benefícios destas metodologias nas equipes de desenvolvimento.

Obs: o webcast é um projeto piloto da Locaweb e podem ocorrer instabilidades durante a sua apresentação.

Como sempre, sugestões são MUITO bem-vindas!

Pin It