O Valor Real da Maturidade do Processo Agile

Bob Aiello examina alguns dos fatores críticos de sucesso necessários para implementar práticas bem-sucedidas de agile de forma confiável na sua organização. Em seguida, mostra como implementar processos agile robustos e maduros.

Bob Aiello, Consultant and editor-in-chief, CM Best Practices Consulting

Bob Aiello é consultor, editor-chefe do website CM Crossroads para desenvolvedores e coautor de Configuration Management Best Practices: Practical Methods that Work in the Real World (Addison-Wesley Professional, 2010 (cmbestpractices.com). Tem mais de 25 anos de experiência como gerente técnico em muitas das principais empresas de serviços financeiros da cidade de Nova York, onde foi responsável pelo CM em toda a empresa, muitas vezes prestando suporte técnico para as ferramentas de gerenciamento de código fonte corporativo, conformidade com SOX/Cobit, engenharia de criação, integração contínua e implementação automatizada de aplicativos. Bob foi vice-presidente do grupo de trabalho IEEE 828 Standards (Planejamento de CM) e é membro do comitê de gerenciamento do IEEE Software and Systems Engineering Standards Committee (S2ESC). Tem mestrado em psicologia industrial pela Universidade de Nova York e é bacharel em ciência da computação e matemática pela Universidade Hofstra. É possível entrar em contato com ele por email ou no LinkedIn.



17/Set/2012

A implementação do desenvolvimento agile em organizações de grande porte pode ser uma tarefa muito complexa e desafiadora. As práticas agile que podem escalar e suprir as necessidades das tarefas corporativas, inclusive sistemas de missão crítica, envolvem muito mais do que uma reunião a cada manhã e sprints fixos de timebox. As organizações bem-sucedidas desejam que todos os projetos que envolvem processos agile tenham o mesmo nível de sucesso em termos de produtividade e qualidade. Este artigo examina alguns dos fatores de sucesso críticos que são necessários para implementar práticas bem-sucedidas de agile de forma confiável na sua organização. Também mostra como implementar processos agile robustos e maduros.

Ferramentas em foco

Por décadas, muitos especialistas da melhoria de processos contestaram a importância das ferramentas. O senso comum sempre ditou que o processo é mais importante que as ferramentas envolvidas. Isso parece intuitivo, pois os profissionais experientes de TI sempre viram equipes de alto desempenho que se saíam muito bem apesar das limitações dos seus conjuntos de ferramentas (muitas vezes legados). Posso dizer que muitas equipes tecnológicas talentosas conseguem fazer um bom trabalho apesar dos conjuntos de ferramentas limitados de software livre ou legados à sua disposição. A experiência mostra que as equipes podem ser bem-sucedidas apesar de seus conjuntos de ferramentas já existentes. Também é verdade que ter ferramentas excelentes não garante o sucesso. Há um ditado nos EUA que diz "um idiota com uma ferramenta continua sendo um idiota". Contudo, algum tempo atrás, passei por uma experiência que mudou o meu ponto de vista sobre a importância das ferramentas.

A minha mãe sofreu um ataque cardíaco que a impediu de ter uma vida independente no ano seguinte. Inicialmente, adaptamos a nossa sala de estar como um quarto privado de recuperação para ela e, em seguida, começamos a ampliar a nossa casa para que ela tivesse um apartamento privado com um banheiro acessível para deficientes. Pouco depois, havia uma escavadeira e outros equipamentos especializados no nosso quintal. Rapidamente, eu me lembrei de que artesãos qualificados precisam das ferramentas e dos processos qualificados para fazer o melhor trabalho possível. Ferramentas excelentes não são opcionais!


Processos agile maduro

A maioria dos especialistas em melhoria de processos se concentra na adoção de uma abordagem confiável e repetida que pode ser aplicada a projetos grandes e pequenos. Há várias equipes multifuncionais altamente bem-sucedidas que adotam práticas agile e dão resultados fantásticos. Muitos desses projetos são realizados com sucesso por equipes pequenas. Outros projetos precisam de uma quantidade muito maior de recursos para preencher seus requisitos funcionais e de entrada no mercado. Grandes sistemas bancários, dispositivos médicos e sistemas de engenharia de missão crítica frequentemente requerem equipes muito grandes para cumprir os prazos dentro de um período aceitável.

Escalável

As práticas agile funcionam. Infelizmente, embora muitas organizações relatem um sucesso excelente com o uso de métodos agile em projetos menores, essas mesmas empresas frequentemente enfrentam desafios ao tentar usar práticas agile em projetos grandes. Precisamos de práticas agile que funcionam em projetos pequenos e grandes.

O ajuste de escala do agile envolve pegar as práticas que foram bem-sucedidas na equipe pequena típica e usá-las com a mesma efetividade em projetos grandes. O uso de métodos agile em um contexto mais amplo requer o treinamento dos membros de forma consistente. Também precisa de ferramentas para ajudar a guiar a equipe no uso do processo agile. Embora a abordagem agile valorize mais as pessoas e interações do que os processos e ferramentas, o ajuste da escala depende de contar com processos com o dimensionamento correto e as ferramentas certas para obter sucesso.

Os processos em si requerem o suporte da automação do fluxo de trabalho para garantir que sejam repetidos e rastreáveis. Isso significa que é necessário implementar os processos corretos e as ferramentas certas para fazer o trabalho. Essas ferramentas também devem ajudar a suportar as pessoas e interações com colaboração, transparência e rastreabilidade. As organizações bem-sucedidas também enfatizam adequadamente o controle da TI.

Repetido

O gerenciamento de ciclo de vida do aplicativo (ALM) pode ajudar ao suportar todo o ciclo de vida de entrega de sistemas ou software ou SDLC (consulte as Melhores Práticas de Gerenciamento de Configuração, citadas em Recursos). As práticas maduras de agile são repetidas, previsíveis e podem ter a escala ajustada para suportar o tamanho da equipe conforme a necessidade. Os processos agile maduros também devem seguir os valores e princípios do agile. Isso é muito importante, porque é muito comum ouvir falar de projetos que supostamente seguiam a metodologia agile, mas uma observação mais atenta revelava que isso era apenas uma desculpa para codificar sem requisitos bem definidos. Gosto de chamar o grau de adesão de uma metodologia de desenvolvimento de pureza do processo agile.

Pureza do processo agile

Os processos agile devem seguir os valores propostos pelo Agile Manifesto (consulte Recursos para obter um link). Obviamente, isso significa que valorizamos:

  • Mais as pessoas e interações que os processos e ferramentas
  • Mais o software funcional que a documentação abrangente
  • Mais a colaboração com o cliente que a negociação de contratos
  • Mais a resposta às mudanças que a adesão a um plano

Como o Agile Manifesto especifica: "embora valorizemos os itens à direita, valorizamos mais os que estão à esquerda". Em termos de valores e prioridades, isso é totalmente verdadeiro. Dito isto, algumas empresas precisam de mais processos e outras, de menos processos — entretanto, a escolha das ferramentas corretas sempre é essencial para o sucesso. Contratos, documentação e planos detalhados também são um requisito absoluto. Não importa se você trabalha com financiamento de capital de risco ou uma nova empresa na Internet ou está procurando aprovar o seu orçamento para implementar um sistema de comércio em larga escala, muitas organizações simplesmente não aprovam o projeto se os chamados "itens à direita" (listados acima) não forem tratados de forma aceitável.

Embora eu já tenha feito muitos negócios na base do aperto de mão (e não me arrependa disso), os contratos certamente têm a sua razão de ser. Os processos agile maduros ajudam a enfatizar corretamente os itens à esquerda e, ao mesmo tempo, preencher os requisitos mínimos dos itens à direita. Essa abordagem abrangente e equilibrada é essencial para ajustar a escala dos processos agile — um requisito fundamental para muitas organizações, particularmente nos segmentos de mercado altamente regulamentados.


Controle da TI

Muitos colegas meus reclamam que o gerenciamento senior não tem contato com o trabalho quotidiano que está sendo realizado pelos funcionários comuns. De fato, às vezes, parece que o gerenciamento senior não entende totalmente o que é necessário para desenvolver sistemas tecnológicos complexos. A verdade é que os trabalhadores da tecnologia podem contribuir muito para o fornecimento de informações claras e úteis para os seus supervisores, a fim de ajudá-los a tomar decisões melhores e proporcionar uma liderança mais efetiva. O gerenciamento das informações que chegam ao gerenciamento senior ajuda a garantir a tomada de decisões informadas e fundamentadas em informações precisas.

Isso não significa que o gerenciamento senior tenha que tomar todas as decisões. Em um ambiente agile maduro, as equipes autogerenciadas também desempenham um papel vital na tomada de muitas decisões importantes — embora faça isso idealmente em um momento em que todas as informações essenciais estão disponíveis. Muitos entusiastas do agile-lean chamam isso de Último Momento Responsável para indicar o adiamento de uma decisão até que todos os fatos estejam disponíveis, para que a decisão se baseie nas informações mais atualizadas.

Cultura da transparência

A organização agile madura tem uma cultura de compartilhar informações essenciais. Se você já fez uma viagem grande com crianças pequenas, a pergunta "já chegamos?" pode estar gravada na sua memória. Da mesma forma, todas as partes interessadas no projeto querem entender se o projeto está avançando e, obviamente, com que velocidade.

Muitos profissionais do agile usam gráficos de burnup e burndown , que mostram o progresso até o momento (recursos concluídos, por exemplo) e o tempo restante planejado para concluir a iteração ou o release. A lista não processada de produtos é uma relação de requisitos, frequentemente na forma de épicos e histórias do usuário. (onde a história é uma descrição da funcionalidade desejada pelo usuário final). As conversas ajudam ao descrever os detalhes da história e devem ser registradas, juntamente com testes que indicam os pormenores que ajudam a determinar quando uma história está concluída (consulte Histórias do usuário aplicadas). Os épicos geralmente são uma descrição mais ampla que, de modo geral, pode ser dividida em duas histórias ou mais.

A taxa de progresso da conclusão dos épicos e das histórias geralmente é medida pela velocidade (consulte The Software Project Manager's Bridge to Agility). Os radiadores de informações altamente visíveis ajudam a comunicar informações essenciais em tempo real. Todas essas formas de comunicação ajudam a criar e possibilitar uma cultura de transparência que ajuda toda a organização a melhorar a produtividade e a qualidade.

As ferramentas devem ter a capacidade de suportar esse foco no compartilhamento de informações em tempo real. A comunicação eficiente é particularmente importante para o planejamento do projeto.


Planejamento do projeto

Um conceito equivocado em relação ao desenvolvimento agile é que ele não requer planejamento. O Agile Manifesto indica que a resposta às mudanças tem uma prioridade mais alta que a adesão a um plano. Mesmo assim, em um ambiente agile maduro, frequentemente há necessidade de planos detalhados e até mesmo abrangentes.

Portanto, o planejamento em um ambiente agile pode variar de um planejamento simples de release e iteração a planos detalhados e abrangentes que rivalizam com qualquer coisa produzida por um plano de ciclo de vida em cascata. Vi muitas organizações nas quais o planejamento era um requisito absoluto para o sucesso.

Às vezes os gerentes são forçados a tomar decisões antes que todas as informações estivessem disponíveis. Vi casos extremos em que as decisões se basearam em suposições falsas só porque as estimativas foram exigidas antes que todos os fatos fossem conhecidos. A abordagem agile incentiva a sinceridade no planejamento, permitindo a tomada de decisões no "último momento responsável". Essa espera até o último momento responsável é muito importante — especialmente quando novas tecnologias estão sendo usadas e há muitos faltos desconhecidos ou riscos que não são fáceis de controlar.

Também é necessário planejar as liberações para garantir a transparência em relação aos recursos que podem ser concluídos em um período de tempo especificado. O planejamento em um contexto agile é afetado particularmente pelo conceito de iterações fixas de timebox , nas quais cada sprint deve enquadrar-se em um período de tempo especifico — geralmente, quatro semanas.

Planejamento de release e iteração

O plano de release envolve determinar exatamente quais funções são necessárias para que um release especifico seja considerado concluído. O plano de iteração especifica os recursos que devem ser concluídos dentro do timebox fixo sprint. A conclusão de cada iteração pode ser útil sob o ponto de vista do desenvolvimento e dos testes, mas o release correspondente ao marco em si só deve ser enviado ao cliente quando a funcionalidade for concluída de forma madura e viável para o teste pelo usuário final. Nunca se deve enviar ao cliente uma liberação "meio pronta", com a funcionalidade tão incompleta que não pode ser testada de forma razoável.

Às vezes, o release criado em um sprint fixo de timebox pode ter apenas a funcionalidade suficiente para ser mostrada ao usuário como uma ferramenta para verificar os requisitos e ajudar a estabelecer claramente o que deve ser construído. Entretanto, também vi casos em que o cliente recebeu um código que não se encontrava em um marco funcional. Essa situação afetou muito a relação entre o cliente e o fornecedor, porque o cliente acreditou (e indicou) que recebeu um sistema incompleto e não funcional.

Em vez disso, os clientes devem receber liberações de marcos com uma linha de base que têm um número razoável de histórias concluídas a partir da lista não processada do produto. É precisamente nesse ponto que as melhores práticas de gerenciamento de configuração podem permitir que a equipe entregue liberações com linhas de base construídas de forma confiável, contanto que elas sejam produtivas.


Gerenciamento de configuração e práticas agile

O gerenciamento de configuração (CM) desempenha um papel interessante no contexto do agile. Em um contexto de agile maduro, a CM ajuda a gerenciar o código fonte de forma inteligente, incluindo o suporte para estabelecer a linha de base dos marcos, as construções independentes automatizadas e muitas variantes no código (correções de erros, por exemplo).

A engenharia de criação gera valor ao criar procedimentos repetidos que produzem arquivos binários executáveis (geralmente chamados de itens de configuração) de forma confiável e que podem ser identificados prontamente para assegurar que a versão correta tenha sido concluída, empacotada e implementada.

A engenharia de release cria um pacote confiável, o qual inclui um manifesto que lista o conteúdo da criação (também conhecido como lista de materiais ou BOM). Em muitos ambientes, o pacote de release é criado de forma a assegurar que ele seja à prova de adulteração e facilita o procedimento de implementação do aplicativo.

O mais importante é que esses procedimentos fornecem um mecanismo para auditar e se certificar de que os itens de configuração corretos tenham sido construídos, empacotados e implementados conforme a necessidade. Essas melhores práticas são muito mais fáceis de implementar com uma infraestrutura de criação robusta. Com a ajuda dessas técnicas, o CM desempenha um papel essencial na facilitação do desenvolvimento iterativo rápido. O planejamento do CM ajuda a especificar um roteiro claro de todas as atividades necessárias para manipular o gerenciamento do código fonte, juntamente com a criação, o release e a engenharia de implementação.

Idealmente, você usa um processo automatizado que pode rastrear os itens de configuração à medida que são criados e fazem check-in no repositório de código fonte e, em seguida, são criados automaticamente com testes de unidade (e até mesmo análise de código), com o resultado atual refletido em tempo real. Isso ajuda a manter os desenvolvedores focados no que eles fazem melhor, eliminando distrações, e fornece transparência para todas as partes interessadas, permitindo que o gerenciamento tome as melhores decisões com base nas informações mais atualizadas.

Esse nível de automação também facilita o desenvolvimento iterativo rápido.

Desenvolvimento iterativo rápido

O desenvolvimento agile requer muitas iterações. Isso cria uma situação que demonstra o valor das construções, do empacotamento e da implementação de aplicativos de forma automatizada. Muitas equipes utilizam a integração contínua (CI) para desenvolver o aplicativo, frequentemente várias vezes ao dia. Há épocas em que uma criação noturna é suficiente, mas o desenvolvimento iterativo rapidamente mostra a necessidade de um processo automatizado e repetido de criação, empacotamento e implementação que, em última análise, envia o release completa para um ambiente de teste, usando uma estrutura de implementação madura.

O desenvolvimento rápido iterativo enfatiza bastante todo o ciclo de vida de desenvolvimento do aplicativo. Também enfatiza adequadamente a qualidade do software, com suporte para testes de unidade automatizados e análise de código.

Essa visualização ampla ajuda a suportar todo o ciclo de vida de desenvolvimento de software e sistemas.

Ciclo de vida completo de desenvolvimento de software

O gerenciamento de ciclo de vida do aplicativo (ALM) é um empreendimento que engloba todo o ciclo de vida, e as ferramentas que suportam o ALM agile devem ajudar a guiar todo o ciclo de vida — desde o planejamento, coleta dos requisitos e design até a criação, empacotamento e implementação do aplicativo. Em um contexto agile maduro, todos sabem o que devem fazer diariamente.

Esse é outro caso no qual a ferramenta correta pode ajudar, criando uma estrutura automatizada para a manipulação abrangente dos itens de trabalho, incluindo tarefas e defeitos vinculados a artefatos relacionados — como épicos, histórias e casos de teste.

As tarefas e os defeitos também têm a sua própria estrutura de relacionamento.

A hierarquia das tarefas e defeitos

É muito comum que os itens de trabalho, como as tarefas e defeitos, tenham um relacionamento hierárquico. Em alguns casos, isso pode significar que uma tarefa tem uma subtarefa ou mais, que podem incluir tarefas ou defeitos relacionados que devem ser corrigidos. Os épicos podem ter filhos, que são histórias, e essas histórias podem ter tarefas e defeitos atribuídos a elas. A disposição dos itens de trabalho de forma hierárquica oferece um meio excelente de organizar o trabalho e mostrar os itens que foram concluídos e o trabalho que ainda precisa ser finalizado.

A capacidade de coexistir com processos que não são agile é outro aspecto de um projeto agile maduro.


Coexistência com processos não agile

O desenvolvimento de software agile maduro também precisa coexistir com processos não agile e dar suporte para o controle e a conformidade de TI.

Também é muito comum que as equipes empreguem métodos agile em um ambiente no qual eles precisam coexistir com metodologias de cascata. Na forma mais comum de fazer isso, a equipe trabalha diariamente no contexto agile, mas se reporta ao gerenciamento senior por meio de um ciclo de vida tradicional de desenvolvimento de software ou sistemas em cascata.

As ferramentas atuais precisam ser capazes de suportar modelos de desenvolvimento híbridos com processos de desenvolvimento de software agile e não agile. Da mesma forma que o agile e os outros métodos devem coexistir em harmonia, muitas vezes os métodos agile também precisam cumprir os regulamentos normativos indicados pelos padrões e estruturas do segmento de mercado.

Harmonia com os padrões e estruturas do segmento de mercado

Muitas organizações precisam cumprir os requisitos normativos do governo federal dos EUA, inclusive a Seção 404 da Lei Sarbanes-Oxley de 2002 ou a HIPAA CFR 21. Os padrões de mercado incluem a orientação de organizações como o IEEE, ISO ou ANSI e também estruturas como a respeitada ISACA Cobit ou o itSMF ITIL v3. Essas melhores práticas frequentemente exigem a separação de obrigações, que fica muito mais fácil com os procedimentos totalmente automatizados de criação, empacotamento e implementação de aplicativos.

A rastreabilidade dos itens de trabalho até os conjuntos de mudanças atômicos também é importante para identificar as mudanças precisas concluídas e vinculadas diretamente ao item de trabalho (solicitação de mudança) que autoriza a mudança. Os itens de trabalho geralmente são gerenciados em uma ferramenta de automação de fluxo de trabalho e progridem por estados predefinidos, como criação, revisão, aprovação, encerramento e verificação.

Os processos agile maduros mantêm todas as eficiências excelentes do desenvolvimento e, ao mesmo tempo, preenchem todos os requisitos normativos e do segmento de mercado, conforme o descrito no padrão especifico ou nas estruturas desenvolvidas e aceitas como a autoridade e a orientação relevantes. A melhoria dos processos é uma jornada, e os processos agile maduros também enfatizam a melhoria contínua da metodologia de desenvolvimento de aplicativos.


Retrospectivas e mudança

Um dos métodos mais importantes da melhoria de processos é a revisão regular das ações anteriores e a reflexão sobre como podemos melhorar. Retrospectivas fornecem o mecanismo correto para revisar os processos já existentes e discutir sobre o que deu certo e o que pode ser melhorado. Às vezes, essas retrospectivas podem ser realizadas em um local especifico; em outras ocasiões, as equipes estão distribuídas em um local ou mais e, portanto, precisam de ferramentas que suportem a colaboração e a comunicação.

Não importando se é possível se dar ao luxo de ter todas as pessoas na mesma sala para comer pizza e falar das perspectivas ou se tem que obter as opiniões de todos de forma menos tradicional, as retrospectivas podem ajudar a impulsionar todo o esforço de melhoria do processo. Elas fornecem uma estrutura para a reflexão sincera, comunicação constante e melhoria contínua.

Resumo

Os processos agile maduros devem ser repetidos e escaláveis para suprir as necessidades da organização. Apesar do grande sucesso, ainda há algumas coisas a serem feitas para permitir que os métodos agile sejam igualmente bem-sucedidos em todos os projetos de uma organização, inclusive os projetos maiores com membros da equipe geograficamente distribuídos que frequentemente trabalham em fusos horários diferentes e podem até falar idiomas diferentes.

O desenvolvimento de software agile maduro também precisa coexistir com processos de outro tipo e fornecer transparência, fornecendo informações claras e precisas que são essenciais para suportar o controle e a conformidade da TI. Agile funciona! O desenvolvimento agile maduro leva essas práticas a um nível mais alto, que gera muito valor e uma vantagem competitiva ainda maior.

Recursos

Aprender

  • Para obter mais informações relacionadas a este artigo:
    • Configuration Management Best Practices: Practical Methods that Work in the Real World, de Bob Aiello e Leslie Sachs (Addison-Wesley Professional, 2010).
    • Integração Contínua em Desenvolvimento Agile Como os métodos agile, a integração contínua e os testes aprimoram o design e desenvolvimento de sistemas complexos, de Martin R. Bakal, Jennifer Althouse e Paridhi Verma (developerWorks, 2012)
    • O Agile Manifesto.
    • The Software Project Manager's Bridge to Agility, de Michele Sliger e Stacia Broderick (Addison-Wesley Professional, 2008).
    • User Stories Applied: For Agile Software Development, de Mike Cohn (Addison-Wesley Professional, 2004).
  • Visite a seção área do software Rational no developerWorks para visualizar os recursos técnicos e as melhores práticas dos produtos da Rational Software Delivery Platform.
  • Assine a newsletter semanal por email do developerWorkse escolha os assuntos que irá seguir.
  • Fique atualizado com os eventos técnicos e webcasts do developerWorks com ênfase em uma série de produtos IBM e assuntos relacionados ao segmento de mercado de TI.
  • Participe de um briefing gratuito do developerWorks Live! para se atualizar rapidamente sobre produtos e ferramentas da IBM, bem como tendências do segmento de mercado de TI.
  • Acompanhe as demos sob demanda do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.

Obter produtos e tecnologias

  • Faça download de uma versão gratuita de avaliação do software Rational.
  • Avalie outros softwares IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a online, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar a Arquitetura Orientada a Serviços de forma eficiente.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que acessar o developerWorks, um perfil será criado para você. Informações do seu perfil (tais como: nome, país / região, e empresa) estarão disponíveis ao público, que poderá acompanhar qualquer conteúdo que você publicar. Seu perfil no developerWorks pode ser atualizado a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=834889
ArticleTitle=O Valor Real da Maturidade do Processo Agile
publish-date=09172012