BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Uma coleção de recursos de Agile, por Sutherland, Schwaber, Starr, Lacey e Anderson

Uma coleção de recursos de Agile, por Sutherland, Schwaber, Starr, Lacey e Anderson

Favoritos

A Microsoft juntou uma coleção de conteúdos sobre princípios, práticas e diretrizes para o desenvolvimento ágil. São artigos resumidos que apresentam a essência de várias metodologias ágeis, de líderes como Jeff Sutherland, Ken Schwaber, David Starr, Mitch Lacey e David J. Anderson. Os conteúdos foram organizados em três categorias: Princípios Ágeis, Práticas Ágeis, e Lean/CMMI.

A seguir são apresentados os links e breves descrições dos principais documentos disponibilizados.

1. Princípios Ágeis

Princípios e Valores Ágeis

Jeff Sutherland explora os quatro valores apresentados pelo Manifesto Ágil:

  • Indivíduos e suas interações
  • Entrega de software em funcionamento
  • Colaboração com os clientes
  • Responder às mudanças

Sutherland diferencia ainda entre o Agile em si, e as metodologias e práticas ágeis, detalhando o significado e as características complementares do Scrum e do XP.

Retrospectiva dos dez anos do Agile: Como melhorar nos próximos dez

Neste artigo, Sutherland relembra a retrospectiva de dez anos de Agile em Snowbird, no estado norte-americano de Utah, em 2011, na qual os signatários do Manifesto ressaltaram quatro fatores fundamentais para o sucesso nos próximos dez anos:

  • Exigir excelência técnica;
  • Promover mudanças individuais e lidere mudanças organizacionais;
  • Organizar o conhecimento e melhorar a educação;
  • Maximizar a criação de valor durante todo o processo.

Após listar vários impedimentos no caminho para o sucesso, Sutherland conclui:

É essencial que as equipes ágeis melhorem suas práticas, pois o maior problema enfrentado pela comunidade ágil é a insuficiência na excelência técnica. Entregar o que foi definido no backlog do produto demanda gerentes de produto profissionais, que entendam as necessidades do usuário; e equipes com entusiamo em entregar com excelência. Conseguir que o backlog do produto seja desenvolvido em um sprint requer priorização, integração contínua do trabalho em andamento e intolerância a defeitos. Exigir excelência técnica é a maior prioridade para os próximos dez anos.

Pronto e Não-Pronto

Utilizando tanto casos de estudo reais quanto fictícios, Ken Schwaber e David Starr discutem o conceito do "pronto" percebido e o do "pronto" real, explicando como diferenciá-los e como podem influenciar o sucesso de um projeto. Schwaber e Starr falam sobre transparência, dívida técnica, planos de release e sobre duas técnicas para a melhoria da produtividade: o "Scrum de Scrums" e a Integração Contínua.


2. Práticas Ágeis

Preparando e gerenciando o backlog do produto

Neste artigo, Mitch Lacey discute a importância do backlog e práticas para sua criação e manutenção, e fala de tópicos como histórias de usuários, estimativas, priorização e grooming, concluindo:

Um bom backlog do produto ajuda a garantir que o software tenha as funcionalidades mais importantes, de acordo com o que foi identificado nas conversas com clientes e stakeholders, e definidas nas histórias de usuário. Para criar e manter um bom backlog, é necessário que exista um envolvimento ativo tanto do grupo de clientes/stakeholders quanto da equipe, ao menos uma vez por sprint.

Criar um bom backlog não garante um bom sistema, mas a falta de um backlog irá garantir, certamente, um sistema que não atende as demandas dos clientes. Em outras palavras, não manter o backlog atualizado [ou não tê-lo] quase sempre resultará no fracasso do projeto.

O trabalho do product owner é de tempo integral e o backlog do produto é de sua responsabilidade. Mantenha um backlog de produto em bom estado e os clientes agradecerão.

Priorização

Lacey continua o artigo Construindo e Gerenciando o Backlog do produto, apresentando três métodos para a priorização do backlog:

Lacey vê o backlog como "algo vivo" que precisa de atenção e repriorização constante para atingir o sucesso.

Estimativas

Lacey também explica porque é tão difícil fazer boas estimativas e fala sobre Pontos de histórias como unidades de medida, e propõe duas técnicas para fazer estimativas: Planning Poker e Estimativa de Parede. Lacey conclui:

Estimar é difícil porque existe muita incerteza no começo do projeto. Clientes e gerentes de projetos ágeis procuram maximizar o ganho antecipado de valor, através do aprendizado adquirido nas conversas com clientes e stakeholder, da construção efetiva de software funcional e da assimação dos feedbacks que recebem sobre o software entregue, afim de atingir um estado aceitável para o lançamento do produto. Mas mesmo projetos ágeis devem fornecer alguma estimativa de quando um conjunto de funcionalidades estará pronto.

Planejamento de Sprint

Lacey termina sua série "Práticas Ágeis" dando conselhos sobre o Planejamento de Sprint. O autor fala sobre Previsão versus Comprometimento, Planejamento e como atingí-lo, e mais alguns problemas/soluções comuns. Lacey acredita que o Planejamento do Sprint "não precisa ser um desafio. Geralmente é divertido e um período para que toda a equipe Scrum se integre melhor trabalhando junta".


Desenvolvimento Lean de Software

David J. Anderson apresenta o Lean e sua relação com práticas ágeis, junto com os valores, princípios e práticas Lean. De acordo com Anderson, os valores Lean são:

  • Aceitar a condição humana;
  • Aceitar que a complexidade e a incerteza são naturais em trabalhos intelectuais;
  • Buscar melhorar os resultados econômicos;
  • Não abrir mão dos resultados sociológicos;
  • Procurar, abraçar e questionar ideias de uma grande variedade de disciplinas;
  • Comunidade com base em valores melhora a velocidade e profundidade das mudanças positivas.

Os princípios do processo Lean de desenvolvimento são:

  • Seguir um pensamento sistêmico e uma abordagem pautada no design de projeto
  • Resultados emergentes podem ser influenciados pela criação de um contexto de de um sistema adaptativo complexo
  • Respeitar as pessoas (como partes de um sistema)
  • Utilizar o Método Científico (para impulsionar melhorias)
  • Estimular a liderança
  • Gerar visibilidade (no trabalho, fluxo de trabalho e na operação do sistema)
  • Reduzir o tempo do fluxo
  • Reduzir desperdícios para melhorar a eficiência

Anderson diz que o desenvolvimento Lean de software "não determina práticas", mas a comunidade tem adotado uma série delas, incluindo: Diagramas de Fluxo Cumulativo, Controles visuais, Sistemas Kanban virtuais, Lotes de tamanho pequeno / Fluxo de Partes Únicas, Automação, Eventos Kaizen, Reuniões diárias em pé, Retrospectivas e Revisões de Operações. Anderson conclui:

Não há, na verdade, um processo específico de desenvolvimento Lean de Software. Um processo pode ser chamado de Lean se for alinhado com os valores e princípios do desenvolvimento Lean de Software, que não prescreve nenhuma prática, mas algumas atividades tornaram-se comuns.

As empresas que empregam o desenvolvimento Lean de Software também podem ser chamadas de Lean se apresentarem apenas pequenas quantidades de desperdício e continuarem buscando otimizar a entrega de valor por meio do gerenciamento efetivo de risco. A busca pela perfeição no Lean é sempre uma jornada sem fim. As empresas verdadeiramente Lean estão sempre procurando melhorar ainda mais.

O desenvolvimento Lean de Software ainda é um campo emergente e deve continuar evoluindo na próxima década.

Princípios e Valores CMMI

Concluindo a série de recursos ágeis, este artigo de David J. Anderson afirma que gerentes, engenheiros de processo e stakeholders podem obter ideias valiosas sobre uma organização usando o Capability Maturity Model Integration (CMMI). Explica ainda o que é maturidade organizacional, o modelo CMMI, como uma organização pode progredir pelos vários níveis de maturidade e como a maturidade CMMI é medida.


Conheça mais sobre os conteúdos ágeis organizados pela Microsoft na biblioteca do MSDN

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT