jan 162014
 

Olá pessoal! No post anterior, falamos sobre o ALM, suas origens e como vem sendo utilizado como ferramenta de produtividade em ambientes ágeis de desenvolvimento de software. Seguindo nessa vertente, nosso tema de hoje propõe a junção dos dois modelos, fazendo com que os conceitos do Agile e do ALM tradicional se encontrem.

Vale reforçar um fator muito importante antes de esmiuçarmos melhor as características de um ALM: por si só, esse tipo de ferramenta já embute uma série de premissas que se acoplam perfeitamente aos princípios do Agile!

Mas como isso ocorre? Simples! Apeguemos-nos ao que é comum aos dois: tanto o Agile, como o ALM, pregam o uso da colaboração, integração contínua, comunicação e melhoria contínua dos seus processos como princípios básicos de funcionamento de ambos. Assim, quando adicionamos ao ALM tradicional um conjunto de valores e estratégias ágeis, fazemos com a ferramenta passe a ter foco na interação humana (“peopleware”), aumentando assim seu poder de comunicação.

Para que as ferramentas de produtividade se integrem ao contexto ágil, necessariamente, essas precisam apoiar outros processos de desenvolvimento, que não somente os ágeis. Portanto, um ALM Agile deve contemplar obrigatoriamente as seguintes quatro áreas de conhecimento comuns:

 

  • Colaboração: Todos os membros da equipe devem saber o que os outros estão fazendo. Dessa forma, as escolhas das atividades devem ser feitas de forma a facilitar o andamento do projeto, concentrando-se nas interações pessoais com foco no cliente; pois as baseadas em tarefas de desenvolvimento já são apoiadas pelas ferramentas.

 

  • Integração Contínua: As equipes devem estar conectadas e ter acesso às informações compartilhadas de forma integra durante todo o projeto. A integração da informação deve ocorrer em vários níveis, necessitando de uma infraestrutura que suporte a integração dos papéis, das equipes e dos fluxos de trabalho. É primordial a existência de repositórios de software comuns aos participantes do time durante todo o ciclo de vida do projeto.

 

  • Comunicação: A racionalização do ciclo de vida está fortemente baseado na implementação visual de todos os passos para a construção do software, simulando a troca de informações da equipe durante o ciclo de projeto. A comunicação da equipe deve ser vista de forma diferente durante um projeto de desenvolvimento e, uma ferramenta que atue nesse ambiente deve prever que o ciclo de vida inicia com a fase de preparação da ferramenta para a construção (setup). A seguir, é feita a aplicação das baselines e dos controles de origem, passando pela compilação, execução de testes técnicos e funcionais, testes de aceitação, deploy e implantação dos pacotes de software até a finalização do projeto.

 

  • Melhoria Contínua: Todo e qualquer processo pode ser melhorado a partir do momento em que esse é medido, já dizia Peter Drucker. Portanto, desde o levantamento, passando pela construção, até e entrega do software, é exigido que as fases do processo sejam quantificadas e medida que cada iteração é finalizada. Os testes de aceitação devem ser aplicados de forma integral e, junto com retrospectivas regulares, onde se discute o que correu de forma satisfatória durante a iteração e o que precisa ser melhorado, a transparência do processo permite que se possa melhorar continuamente.

 

Dessa maneira, por meio da implementação de modelos e estratégias ágeis, é possível embutir à ferramentas ALM novos conceitos, deixando com que ela se aproxime cada vez mais dos ambientes dos times. Um time de projeto Agile necessita de ferramentas leves, que possam ser utilizadas conforme a demanda de seus requisitos e que proporcione escalabilidade aos seus domínios de trabalho.

 

Em contrapartida, a maior parte das ferramentas de ALM é de fácil customização, permitindo, por exemplo, que os requisitos possam ser ajustados para uma visão de User Story. Além desse tipo de ajuste, é possível também customizar fluxos de trabalho e adequá-los ao uso das User Stories. É possível visualizar o tráfego dos requisitos pelas áreas do Kanban, além de acompanhar a geração do Burn Down de forma dinâmica, além de ser nativamente um concentrador de informações, fazendo com que os times acabem atuando de forma integrada continuamente.

 

Nos próximos posts faremos a apresentação de algumas ferramentas que se integram muito bem aos conceitos e características discutidos até o momento. Portanto, obrigado pela sua atenção e aguarde as cenas dos próximos capítulos…

 

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>