Na maioria das vezes, as consultorias SOA adotam processo convencionais para a entrega de resultados aos seus clientes. Neste processo, todos os artefatos que serão gerados ao longo do projeto, sejam definições tais como: guias, padrões, ferramentas, práticas e templates, ou conteúdo de um projeto piloto como: contratos de serviços, especificações de integração e arquitetura do projeto, são todos definidos no início do projeto de consultoria.
Além do fato de, nos processos convencionais, todos os artefatos serem entregues somente no final do projeto, normalmente, os guias gerados são extensos demais, ocasionando outro grande problema que é a dificuldade na absorção do conteúdo gerado.
Somando-se os dois problemas, temos um processo longo que demora no mínimo seis meses para começar a entregar resultados e, quando esses são entregues, são de difícil compreensão e acabam não agregando tanto quanto poderiam agregar.
Para tentar minimizar este problema, a adoção de práticas de metodologias ágeis, tais como o Scrum, tem sido uma alternativa na agregação de resultados para o cliente. Um grande diferencial deste tipo de metodologia é a definição de espaços menores de tempo (Sprints), que variam entre duas a quatro semanas, onde são definidas quais atividades/entregáveis devem ser realizados e, ao término deste período, os resultados são apresentados, revisados e um novo Sprint é planejado e tudo começa outra vez.
O Scrum define alguns papéis: Product Owner, Scrum Master e Time Scrum. Geralmente um projeto de consultoria SOA conta com apenas um consultor e a equipe envolvida do cliente. O consultor exerce papel de Scrum Master e Time Scrum, pois é o principal gerador de conteúdos além se preocupar com as atividades do backlog que estão com problemas (blocks). O ponto focal do cliente atua como Time Scrum pois, além de revisar os artefatos gerados, algumas atividades, principalmente durante o piloto, são endereçadas a ele, e também tem o papel de Product Owner, afinal, é ele quem prioriza o backlog. Os ritos – Sprint Planning, Spring Review e Daily Meeting – e ferramentas – ProductBacklog, SprintBacklog – são utilizados para contemplar a metodologia.
Esta abordagem, considerada uma abordagem leve, tem se mostrado muito eficiente, pois o cliente não precisa ficar esperando o término do projeto para ver os resultados. Os guias criados, como são revisados no final de cada Sprint, tendem a ser menores e mais focados no objetivo real do guia. Além disso, um dos pontos mais importantes, todos os guias e definições são validados em um projeto real, um piloto que garante que todas as definições serão aplicadas e validadas de acordo com a necessidade real da corporação.
O Scrum, na maioria das vezes, é recomendado para projetos complexos onde as mudanças devem ser gerenciadas e priorizadas constantemente. Pode até ser que esta não seja uma característica dos projetos de consultoria SOA, no entanto, em meu último projeto de consultoria, adotamos um processo de gestão ágil que trouxe grandes ganhos, pois nosso Backlog de execução se moldou de acordo com as demandas imediatas e, às vezes, inesperadas de governança SOA do cliente. Graças à utilização de Sprints curtos (duas semanas) e da flexibilização do Backlog, conseguimos atender todas as demandas do cliente.
Rec6
Del.icio.us
BlogBlogs
Technorati
LinkTo