Introdução

A metodologia do projeto em cascata é, em grande escala, firmada dentro de muitas organizações, tanto quanto a decisão de migrar para processos agile que frequentemente estão além do controle das equipes de desenvolvimento que implementam o código. Isso ocorre, especialmente, com projetos de grande porte que abarcam diversas organizações.

Apesar das diversas propostas de mudar um grande projeto atual para desenvolvimento agile, não foi obtido nenhum progresso nesse sentido, até que a equipe de desenvolvimento responsável por uma das aplicações críticas de projeto decidisse adotar a mudança e aplicar metodologias agile àquelas partes do projeto sobre as quais eles tem controle. O resultado dessa decisão ilustrou o valor e benefícios de desenvolvimento agile, de modo que a equipe de gerenciamento de projetos maiores pudesse apreciar e entender dentro do contexto do projeto total.

Esse artigo descreve como a equipe de desenvolvimento foi capaz de implementar com sucesso o desenvolvimento agile dentro de um projeto em cascata maior. Esse exemplo, inclusive os conceitos e técnicas implementados, os desafios enfrentados e os benefícios resultantes, poderiam auxiliar a descobrir uma maneira útil, com a qual se poderia introduzir conceitos e processos agile à sua organização.

Esse artigo considera um conhecimento prático geral com gerenciamento de projeto básico, e com conceitos e terminologia de desenvolvimento agile.

Voltar para parte superior

Plano de fundo do projeto

O aplicativo particular no centro desse estudo de caso é um aplicativo de contrato de vendas existente usado por uma equipe de vendas no mundo todo. O aplicativo tem sido produzido por muitos anos e, tipicamente, tem de três a quatro releases por ano, de pequeno e grande porte. A base de cliente de aplicativo é ampla e diversificada, com 3.000 usuários avançados mais milhares de usuários eventuais.

O projeto em andamento é gerenciado pelo CIO do departamento, com líderes de solução que representam os clientes. Os vários membros da equipe do projeto total - usuários, designers, arquitetos, desenvolvedores, testadores, operações de produção, etc. - são de diferentes organizações dentro da empresa.

O processo de desenvolvimento integrado para esse projeto em cascata incluiu as seguintes fases:

• Pré-conceito
• Conceito
• Plano
• Desenvolvimento
• Qualificação
• Lançamento.

Durante a fase de pré-conceito, a equipe de desenvolvimento fornece um rough order of magnitude (ROM) para conteúdo de release proposto e datas alvo (não comprometidas). Na fase de conceito, o cliente prioriza a lista de candidatos para o release, os requisitos de negócios e sistema são criados e revisados, e a equipe de desenvolvimento fornece nível de esforço (LOE) para business requirements (BRs) e system requirements (SRs). Na fase de plano, é estabelecida a lista de candidato de SR, e a equipe de desenvolvimento constrói dimensionamentos de baixo nível para esses requisitos.

Para esse projeto, um planejamento típico seria similar a:

• Fase de conceito: 2 meses
• Fase de plano: 2 meses
• Fase de desenvolvimento: 6 semanas
• Fase de qualificação: 6 semanas

As listas candidato de customer wants and needs (CWN), BRs, SRs, e, ocasionalmente, solicitações de mudança, são constantemente atualizadas e repriorizadas através dessas fases, mesmo na fase de desenvolvimento de seis semanas.

Em termos de tecnologias usadas no aplicativo, este foi construído em uma plataforma de Arquitetura Orientada a Serviços (SOA), usando as capacidades de alta disponibilidade de IBM® WebSphere® Process Server VB6.0.2.4, IBM WebSphere Portal V6.1 e IBM DB2® 9.1.6. O aplicativo alavancou serviços da Web para integrar com outros aplicativos internos da empresa. Além disso, a tecnologia WebSphere Process Server foi usada para gerenciar regras de negócios e processar fluxos de trabalho. A coordenação com a programação de requisitos e de release dos outros aplicativos internos contribuiu para a complexidade do planejamento e da programação de releases para a aplicação do projeto.

Voltar para parte superior

Por que agile em uma cascata?

Uma quantidade de tempo significativa de cada release típico desse aplicativo (quatro meses de um ciclo de sete meses) foi investida nas fases de conceito e plano. Mesmo depois, os requisitos ainda foram alterados. A equipe de desenvolvimento decidiu buscar uma abordagem agile, pois ela justificou as mudanças nas prioridades e necessidades de negócio, assim como a refatoração de desenvolvimento à medida que o projeto evoluía. Essa abordagem permitiria que a equipe de desenvolvimento eliminasse tempo significativo das fases de conceito e plano, adicionasse mais tempo à fase de desenvolvimento, e focasse na entrega de mais função e qualidade superior.

Devido às janelas de implementação restritas e à disponibilidade de usuários para participar do teste de aceitação, as datas de implementação foram limitadas e normalmente decididas já na fase de conceito. O planejamento e replanejamento extenso resultaram em uma fase de desenvolvimento mais curta que, por sua vez, fez com que a fase de desenvolvimento se tornasse consistentemente frenética e, sem dúvida, atrasada. Mudanças frequentes para liberar prioridades durante a fase de desenvolvimento não foram úteis.

Uma meta importante para a equipe de desenvolvimento foi adotar melhores processos de desenvolvimento para controlar o caos proveniente tanto das influências externas (requisitos tardios, requisitos de mudança, etc) como seus próprios procedimentos precários (processos de desenvolvimento inadequados, baixa qualidade de código, etc). A adoção de uma abordagem agile seria um meio direcionado de mudar sua cultura de desenvolvimento e controlar seus processos.

Além disso, a equipe de desenvolvimento tinha consciência dos outros benefícios da abordagem agile: melhor qualidade, implementação mais rápida, e maior satisfação do cliente. Eles também consideraram que, se pudessem avançar nos processos agile, ganhariam ímpeto em convencer o projeto maior a mudar para uma metodologia agile total. Suas lições aprendidas resultantes ajudariam a trabalhar quaisquer dificuldades em suas ferramentas e processos e acelerar a possível mudança para processos agile.

Voltar para parte superior

Em que proporção a metodologia agile foi realmente implementada?

Quando se deu início ao projeto, a equipe de desenvolvimento tentou adotar alguns (embora não todos) dos conceitos da estrutura Scrum, um processo agile baseado na teoria de controle de processo empírico que consiste na transparência, inspeção, e adaptação. A equipe implementou reuniões stand-up diárias e gráficos burndown, porém optou por não adotar componentes para permitir a inspeção, como por exemplo planejamento do sprint, revisão do sprint, e reuniões de retrospectiva.

À medida que o projeto avançava até a fase de qualificação em cascata - na qual a equipe de desenvolvimento precisou lidar com uma corrente constante de defeitos de teste - o processo scrum da equipe foi finalizado. Eles teriam de adotá-lo novamente quando o próximo release iniciasse sua fase de desenvolvimento. Esta falha da tentativa do Scrum inicial foi, finalmente, uma consequência por não terem sido adotados os processos de inspeção; essa lição aprendida auxiliou a equipe em seus esforços de Scrum seguintes.

Na fase de desenvolvimento de um release mais recente, a equipe de desenvolvimento decidiu começar do zero e introduzir o processo agile completo com base nos conceitos e marcas de qualidade do Scrum. A equipe estabeleceu um compromisso com o planejamento do sprint, a revisão do sprint e as reuniões de retrospectiva. Mais importante, eles se comprometeram com a inspeção de processo e auto-governança.

• Funções

  Para adotar totalmente o modo Scrum de se fazer as coisas, a equipe precisou identificar quem na equipe do scrum assumiria as três funções exigidas de Proprietário de Produto, ScrumMaster, e Equipe. Inicialmente, o gerente de projeto de desenvolvimento recebeu a função de Proprietário de Produto primário. A Equipe consistia nos membros da equipe de desenvolvimento existente. Foi escolhido um ScrumMaster, que estabeleceu um calendário de sprint com ciclos de três a quatro semanas, com datas de início e término que não se alinhavam, necessariamente, com os marcos de processo em cascata; a equipe aprendeu que reuniões do sprint agendadas próximas a marcos em cascata resultaram na mudança do foco da equipe para um desses eventos, porém não ambos, causando um resultado desfavorável para aquele que foi negligenciado.

• Lista não-processada

  Para a reunião de planejamento do sprint, a equipe de desenvolvimento iniciou com a lista não-processada do produto de candidatos identificados pelo cliente (nas fases de conceito e plano) para releases posteriores do aplicativo. O Proprietário de Produto escolheu um subconjunto desses itens, os quais constituíam a possível lista não-processada do produto a ser considerado para o sprint. Durante a reunião de planejamento do sprint, a equipe de desenvolvimento comprometeu-se com os itens da lista não-processada do produto que pudessem ser finalizados durante o sprint e, a partir daí, construir a lista não-processada do sprint, que consistia em tarefas, estimativas de tarefa, e atribuições que a equipe, de fato, trabalharia durante o sprint.

• Revisões

  Ao final de cada sprint, a equipe de desenvolvimento realizou uma reunião de revisão do sprint. A finalidade dessa reunião era demonstrar às partes interessadas o que tinha sido finalizado no sprint, e fornecer uma oportunidade adequada para os acionistas comentarem e fazerem perguntas, possivelmente, resultando em uma lista de mudanças desejadas. Tais mudanças e qualquer funcionalidade ausente ou incorreta foram adicionadas à lista não-processada do produto para o próximo sprint.

• Retrospectiva

  Ao final de cada sprint, a equipe de desenvolvimento também realizou uma reunião de retrospectiva de sprint para revisar o que correu bem durante o sprint e o que poderia ser melhorado. Com base nesse feedback, eles alteraram seus processos conforme apropriado e adicionaram itens de ação não funcionais à lista não-processada do produto.

• Planejamento

  O planejamento típico era realizar a revisão do sprint e reuniões de retrospectiva de sprint no mesmo dia em que sprint terminou, seguidas pela reunião de planejamento do sprint para o próximo sprint no dia seguinte. Essas reuniões eram conduzidas dentro das diretrizes de tempo fechado do Scrum.

• Participantes

  Representantes de clientes (líderes de solução) compareceram às reuniões de planejamento e de revisão do sprint. Inicialmente, os interesses dos clientes eram representados pelo gerente de projeto de desenvolvimento, mas em sprints posteriores, a equipe de desenvolvimento pôde incluir os líderes solucionadores e obter contribuição e feedback de cliente direto através desses participantes fundamentais. Essa abordagem foi proposital; a equipe queria compreender os processos e metodologia bem antes de expandir o círculo de participantes para incluir os líderes de solução.

• Relatos de usuário

  A equipe de desenvolvimento também incorporou relatos de usuário em seu planejamento. Embora os representantes de cliente (líderes de solução) devam ser responsáveis por criar relatos de usuário, a equipe de desenvolvimento fez isso no lugar deles, com base em requisitos existentes, pois o projeto maior não era ainda comprometido com os processos agile. A equipe, então, incumbiu os líderes de solução de validarem os relatos de usuário, colaborou para refiná-los e obter maior entendimento dos requisitos. Essa prática melhorou consideravelmente o entendimento e a precisão dos requisitos, da mesma maneira como reduziu o retrabalho após o fato.

• Garantia de qualidade

  Embora a equipe de desenvolvimento tenha usado por muito tempo a integração contínua, ela, recentemente, incorporou o teste automatizado nos processos de desenvolvimento. Os itens de trabalho não foram considerados completos até que um teste automatizado fosse disponibilizado e incorporado à ferramenta de teste. As compilações diárias e o teste automatizado garantiram que a base de código não estava quebrada, pois o código foi verificado. Isso resultou em um código de maior qualidade e menos defeitos encontrados na fase de qualificação. Itens codificados não foram considerados completos até que a funcionalidade pudesse ser demonstrada em um servidor ativo. Itens não codificados, como por exemplo, novos processos ou documentação, foram publicados no wiki interno da equipe de desenvolvimento e distribuídos à equipe para revisão antes de serem apresentados como concluídos em uma reunião de revisão do sprint.

Voltar para parte superior

Outros elementos agile

Devido ao fato de a equipe de desenvolvimento ter operado dentro de um processo em cascata rígido, ela não pôde adotar todos os aspectos de desenvolvimento agile. A equipe ainda passou repetidamente por um ciclo de requisitos de refinação de CWNs a BRs e SRs, priorização, ROM, LOE, e dimensionamentos de baixo nível, adição de novos requisitos, e circulação.

A equipe de desenvolvimento pôde realizar algumas melhorias no ciclo de requisitos; por exemplo, mudar para listas priorizadas avaliadas pelos representantes dos clientes, e dimensionar relatos de usuários em diferentes pontos no ciclo de requisitos para construir listas de escopo de candidatos para que o cliente as revise. A equipe alavancou os processos de Scrum para tratar dessa atividade e gerou os produtos de trabalho necessários para o ciclo de requisitos, reduzindo, por fim, os temidos requisitos em massa e sem qualidade durante a fase de desenvolvimento.

Quando o projeto mudar totalmente para processos agile, a expectativa é de que os relatos de usuários sejam construídos no início do ciclo; a prioridade será limitada a um ou dois ciclos, e será gasto mais tempo na fase de desenvolvimento. Esse estado de adoção do agile oferece suporte à revisão de recursos implementados com o cliente e a atualização da funcionalidade com base em seu feedback, em vez de retrabalhar os diversos níveis de requisitos múltiplas vezes no papel.

Em vez de confiar completamente no conjunto de ferramentas de lista não-processada do sprint e no gráfico burndown para atribuir e acompanhar o trabalho, a equipe de desenvolvimento usou um plano de Projeto® Microsoft para programar tarefas durante a fase de desenvolvimento. Houve algumas razões para isso. Em primeiro lugar, isso demonstrou ao cliente que recursos distribuídos ao projeto foram totalmente usados para entregar o máximo de conteúdo possível. Em segundo lugar, o Projeto Microsoft foi a forma de comunicar status do modo esperado e mais reconhecível em um projeto em cascata. Contudo, fazendo referência ao burndown, além de um plano de projeto em atualizações de status, a equipe de desenvolvimento estava em vias de expor e executar a transição das outras equipes para métodos de acompanhamento do agile.

Voltar para parte superior

Lidando com os desafios

Claro que trabalhar com dois estilos (e culturas) inerentemente diferentes de gerenciamento de projeto apresentou uma variedade de desafios à equipe de desenvolvimento:

• Idioma

  Um desafio fundamental ao executar a transição de um processo em cascata para um processo agile é construir uma conexão entre as terminologias. Para esse projeto, o gerente de projeto de desenvolvimento realizou um excelente trabalho ao fazer essa tradução, tanto em termos de "falar em cascata" com o cliente quanto em levar em conta a lacuna entre ferramentas e status no contexto agile aos seus correspondentes no mundo em cascata. Com a existência dessa "ponte", a equipe de desenvolvimento teve mais liberdade para adotar seus próprios processos e realizar as fases incrementais aqui descritas.

• Planejamento

  O modo de operação padrão da equipe de desenvolvimento esteve constantemente em um ciclo sprint - estando ou não especificamente trabalhando em um candidato do release. Portanto, os sprints abrangeram o trabalho de dimensionamento, atividade de suporte à produção, e trabalho de qualificação. Por causa disso, a equipe tentou não ter o início e término dos sprints no development cutover milestone (DCUT). Do mesmo modo, foi útil não finalizar o sprint na data de DCUT; o tempo despendido nesse ponto para os dois dias de reuniões obrigatórios não permitiu que o release de destino fosse incorporado à fase de qualificação. Tipicamente, o sprint encerrou-se na semana seguinte.

• Suporte

  Inicialmente, a equipe de desenvolvimento mediu forças com a obrigatoriedade de lidar com suporte de produção dentro dos sprints. Alguns desenvolvedores dedicaram-se a lidar com Suporte Nível 3, porém a maior parte dos defeitos de produção que ocorreram precisava ser tratada por membros da equipe de desenvolvimento. Embora todo esse trabalho não possa ser totalmente planejado, um nível geral de trabalho relacionado a suporte pode ser antecipado. Esse trabalho foi tratado em duas partes: análise e resolução. A regra fundamental que ajudou a equipe a avançar com a integração de suporte de produção ao modelo Scrum definia a prioridade de qualquer defeito de produção ao maior valor possível; desse modo, a análise inicial superou todo o resto em um plano ou lista de tarefa de desenvolvedor.

  No lado da análise, quando foi criado um defeito de produção, o bilhete foi adicionado ao sprint atual e designado com base na gravidade. A análise da origem do problema foi realizada para determinar o esforço envolvido em fornecer uma solução, e essa análise resultou na identificação da causa do problema (ou, se não era óbvio, no que foi necessário para identificar a causa), um dimensionamento estimado para implementar a correção e criar um teste de unidade, e a dificuldade de implementar a correção. Feito isso, o bilhete foi retirado do sprint atual e os Proprietários de Produto determinaram a prioridade em relação a outros itens na lista não-processada do produto. A análise da origem do problema foi definida para ser realizada dentro de requisitos de Acordo de Nível de Serviço existentes.

  Os Proprietários de Produto atribuíram, então, o problema a uma lista não-processada de sprint (que poderia ser o sprint atual, ou a lista não-processada do produto para um sprint futuro), que permitiu que a correção fosse entregue dentro de um release, um fix pack, ou através de um hot fix.

  A equipe de desenvolvimento estimou dez defeitos por semana durante as duas semanas após a implementação de um release, e três defeitos por semana, de outro modo, com quatro horas de análise.

• Mudanças

  Periodicamente, problemas de produção resultaram em uma solicitação de mudança. As diretrizes da equipe de desenvolvimento estabeleceram que esses problemas devem ser priorizados pelo Proprietário de Produto para inclusão em um sprint. Se o Proprietário de Produto considerasse que uma solicitação de mudança fosse a prioridade mais alta para a equipe de desenvolvimento, o ScrumMaster e o Proprietário de Produto decidiriam se o sprint atual deveria ser ajustado ou (em um caso raro) interrompido para acomodá-lo.

• Desvios

  Um subconjunto da equipe de desenvolvimento foi uma equipe de infraestrutura que lidava com ferramentas de construção, administração do servidor (tanto teste como produção), administração de base de dados etc. Essa equipe tinha atribuições dentro do sprint, porém ela recebia periodicamente pedidos de trabalho de outras equipes no projeto. Isso violou o princípio de Scrum que relata que a equipe deve ter liberdade para realizar seu trabalho do sprint.

  Para mitigar esse problema, a equipe de desenvolvimento listou três táticas:

  • Ela identificou tarefas de infraestrutura que deveriam ser incluídas em cada sprint e as incluiu na lista não-processada de sprint (por exemplo, implementações alpha, suporte de implementação beta, backups online de produção etc).
  • Quaisquer tarefas de infraestrutura relacionadas a itens de lista não-processada de produto foram identificadas e incluídas na lista não-processada de sprint.
  • A Liderança da Equipe de Infraestrutura foi designada como o ponto focal para solicitações externas de qualificações de infraestrutura, trabalhada com o Proprietário de Produto para determinar a prioridade desses itens de trabalho, e incluída na lista não-processada de sprint conforme foi considerado necessário.

  Os membros da equipe de infraestrutura aprenderam a recusar as interrupções, adiando o processo acima para tais solicitações. Isso permitiu-lhes permanecer totalmente engajados no processo Scrum.

• Tamanho

  A equipe de desenvolvimento finalmente mudou para uma hierarquia de equipes de Scrum, devido ao seu tamanho, dividindo-se em quatro equipes:

  • Processo de Negócios/Serviços de Backend
  • Interface com o usuário
  • Gerenciamento do Ciclo de Vida
  • Infraestrutura.

  Essas equipes conduziram scrums diários entre si. Um scrum de scrums quinzenal foi realizado, no qual um representante de cada uma das equipes de Scrum participou e resumiu o status de sua equipe desde a última reunião, os planos da equipe antes da próxima reunião, a existência de quaisquer impedimentos, e quais obstáculos eles imporiam sobre outras equipes de Scrum.

Voltar para parte superior

Ferramentas utilizadas

A equipe de desenvolvimento utilizou um sistema de acompanhamento de erro/problema que forneceu um Wiki integrado com recursos convenientes de geração de relatório. O IBM Rational Team Concert™ fornece esta funcionalidade. A equipe criou bilhetes de acompanhamento para todos os itens de trabalho de desenvolvimento e gerou gráficos Burndown (entre outros relatórios) para os sprints. A equipe também foi capaz de ampliar a ferramenta e o Wiki para acomodar os requisitos da equipe. Por exemplo, a equipe criou uma ferramenta para relatos de usuários que foi incorporada ao Wiki.

A equipe de desenvolvimento utilizou com frequência um Wiki de desenvolvimento para documentar processos, fornecer acesso a relatórios de progresso, e criar a interface para o seu sistema de acompanhamento. Por causa da interface ao sistema de acompanhamento, o Wiki foi um mecanismo particularmente bom para documentação e colaboração.

A equipe de desenvolvimento construiu seus planos de projeto no Microsoft Project. O plano do projeto fez referência a um bilhete de acompanhamento para cada tarefa de baixo nível incluída no plano; isso foi uma evolução que teve início antes de passar para processos agile. Em vez de fazer referência a um CWN com suas horas associadas, foi criado um bilhete de acompanhamento para cada tarefa envolvida na entrega de um CWN em um release. Quando possível, as tarefas foram subdivididas e horas foram distribuídas entre dois ou mais desenvolvedores para aumentar a produtividade e reduzir a duração total de codificação. Cada tarefa subdividida recebeu seu próprio bilhete de acompanhamento e foi referida individualmente no plano de projeto (a intenção foi a de que cada bilhete/tarefa tivesse, no máximo, um proprietário). O plano de projeto também identificou a prioridade de tarefas entre desenvolvedores individuais e a prioridade geral de candidatos do release. Um campo de prioridade personalizado foi criado nos bilhetes de acompanhamento, atualizado de acordo com o plano de projeto, e imposto a cada desenvolvedor para que pudessem realizar suas tarefas.

Voltar para parte superior

Benefícios concretizados

Conforme esperado - e como anunciado - adotar processos agile resultou em melhor qualidade do código, implementação mais rápida, maior satisfação do cliente, e melhores processos de desenvolvimento. A equipe de desenvolvimento também conseguiu outros benefícios, incluindo alguns que não são geralmente considerados como benefícios do agile:

• Manuseio de grandes tarefas

  Um benefício importante de adotar o Scrum foi ter possibilitado à equipe de desenvolvimento incorporar itens de bilhete grande aos releases. Isto parece ser nada intuitivo; afinal de contas, de acordo com alguns, limitar sprints em um período de duas a quatro semanas elimina a capacidade de manipular grandes funcionalidades. Neste projeto, foi difícil incluir grandes recursos na lista priorizada de um release; o cliente preferia, com frequência, dez itens menores do que um item grande, mesmo se esse item grande fosse importante. O Scrum forçou a equipe de desenvolvimento a considerar esses grandes recursos de forma incremental, dividindo-os em análise ou pesquisa e, depois, implementação incremental. A equipe foi capaz de incluir a análise ou pesquisa em sprints não vinculados à fase de desenvolvimento, fornecendo a eles disciplina para concluir as tarefas imediatamente, e facilitando a implementação incremental nas prioridades de release.

  Esta abordagem também foi utilizada para itens não funcionais, tais como refatoração de código e teste de integração automatizada. Convencer o cliente de que esse trabalho era importante e desafiador, porém a equipe de desenvolvimento foi capaz de dividir o trabalho de refatoração em pequenas partes, construir um plano gradual para as mudanças, e então, adequar as mudanças incrementais em sprints e releases.

• Flexibilidade

  Relacionado a isso está o benefício de conseguir a capacidade e disciplina para desconstruir grandes tarefas; os sprints forçaram a equipe de desenvolvimento a pensar em termos de tarefas menores. Com tarefas menores, a equipe foi mais capaz de planejar o conteúdo do release, bem como realocar recursos caso essas tarefas fracassassem. Grandes tarefas tinham a tendência de exigir uma faixa maior de habilidades e experiência, porém quando divididas em tarefas menores, muitas delas poderiam ser atribuídas a desenvolvedores com habilidades mais estreitas, o que permitia maior flexibilidade na atribuição de recursos. Após diversos releases e múltiplas sessões de planejamento de sprint, este pensamento de "pequena tarefa" tinha se cristalizado em toda a equipe.

• Melhoria do processo

  O processo Scrum também contemplava uma estrutura para a melhoria incremental do processo que faltava anteriormente na equipe de desenvolvimento. As reuniões de retrospectiva de sprint forneceu feedback útil, e as mudanças do processo foram adicionadas ao próximo sprint. Em alguns casos, tais como suporte de produção e tarefas da equipe de infraestrutura, foi necessário diversos sprints para refinar os processos até o ponto do sucesso. A equipe comprometeu-se com o processo, trabalhou os problemas e construiu processos que trabalham bem para a equipe.

• Manipulação de mudanças

  A equipe de desenvolvimento ficou mais capacitada para tratar das mudanças, mesmo no meio do sprint. Durante um release, eles iniciaram a fase de desenvolvimento com uma clara compreensão das prioridades, então no meio de um sprint, o cliente apresentou uma nova prioridade número um. Normalmente esse fato poderia desmoralizar uma equipe, mas eles utilizaram os princípios do Scrum para discutir as opções (interrompendo o sprint e reiniciando versus realizar uma lista de prioridade incorreta). Visto que a equipe de desenvolvimento foi autorizada a tomar a decisão, eles foram capazes de mudar mecanismos e aceitar a nova prioridade com sucesso.

• Ambiente de trabalho

  A adoção de processos de Scrum teve um impacto significativo na moral da equipe, disciplina da equipe, e interação da equipe. Visto que a equipe de desenvolvimento foi autorizada a melhorar seus próprios processos, eles se comprometeram fortemente aos processos e colocaram energia e entusiasmo em tudo. A criatividade foi aplicada às melhorias do processo, e esta criatividade foi transferida aos esforços de desenvolvimento da equipe. Além disso, os processos atualizados melhoraram muito o ciclo de desenvolvimento, reduziram o pânico no marco DCTU, e reduziram a quantidade e a gravidade de defeitos encontrados tanto na fase de qualificação quanto na fase de produção. O processo de liberação se tornou um esforço mais constante e bem planejado, e menos uma etapa de caos, como a equipe havia experimentado antes. As horas de trabalho foram mais previsíveis, mesmo quando a equipe atingia as datas dos marcos, o que aumentava a moral e reduzia a tensão entre os desenvolvedores e as outras equipes que trabalham no projeto.

Voltar para parte superior

Conclusão

Com o valor e benefícios de desenvolvimento agile esclarecidos - e com resultados impressionantes - o projeto total pretende mudar para processos agile, usando Scrum com o próximo release do aplicativo; um workshop de agile inicial para esse release acabou de ser realizado. A equipe de desenvolvimento poderá facilmente reter seus processos de desenvolvimento, fazendo pequenos ajustes para acomodar os processos agile maiores.

Como parte do planejamento de desenvolvimento e acompanhamento, a equipe de desenvolvimento possui uma extensa lista não-processada de candidatos (CWNs e defeitos) que não fizeram o corte. Esses serão armazenados na ferramenta de acompanhamento de problemas da equipe e serão incorporados aos novos processos agile para serem observados em um release futuro.

Uma grande chance para a equipe de desenvolvimento será o desenvolvimento de relatos de usuário pelos Proprietários de Produto. Esse esforço teve início com o workshop agile inicial, usando Rational Team Concert como a ferramenta de escolha. Visto que os processos de relato de usuário fornecem requisitos de maior qualidade, os Proprietários de Produto comprometeram-se a isso e sua condução melhorará os processos em grande escala.

Outra mudança significativa mudará as equipes de Scrum da estrutura de silo atual (com base em áreas funcionais em desenvolvimento) para uma estrutura que inclui representantes envolvidos no projeto. Anteriormente, visto que Scrum limitava-se à equipe de desenvolvimento, a divisão funcional foi natural. Durante o início, as estruturas de equipe foram discutidas e mapeadas para o próximo release. A equipe de desenvolvimento adotou medidas para mudar para uma estrutura de equipe mista para o release atual, e ela analisará e revisará o processo enquanto o faz, aplicando as lições aprendidas ao próximo release.

A equipe de desenvolvimento planeja tornar-se uma oficina de desenvolvimento orientada a teste, e adotou medidas para essa finalidade com a equipe de teste (que está em uma organização separada). A equipe de desenvolvimento trabalhará com a equipe de teste, lhe trará para seus sprints, ensinará os conceitos Scrum, e trabalhará em conjunto rumo ao objetivo da adoção agile pelo projeto, independentemente do cronograma.

Por fim, planejamentos futuros incluem pregar os princípios de Scrum e agile às equipes parceiras pelo projeto total. A experiência da equipe de desenvolvimento coloca-os em uma posição privilegiada para treinar outros, não só porque ela tem o conhecimento de agile e ou porque aprendeu as lições, mas também porque seus membros têm mais conhecimento com os trabalhos do aplicativo e viveram a experiência cultural de usar desenvolvimento agile na organização.

Recursos

• Guia Scrum da Scrum Alliance
  
  
• Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004
  
  
• Agile and Iterative Development: A Manager's Guide, Craig Larman, Addison-Wesley, 2003
  
  
• An Introduction to Agile, Kevin Aguanno, Multi-Media Publications, 2005
  
  
• Educação: Obtendo sucesso com Agile
  
  
• IBM developerWorks WebSphere
  
  
• IBM WebSphere Developer Technical Journal
  
  

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Plano de fundo do projeto
• Por que agile em uma cascata?
• Em que proporção a metodologia agile foi realmente implementada?
• Outros elementos agile
• Lidando com os desafios
• Ferramentas utilizadas
• Benefícios concretizados
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais