Modelo híbrido de gestão

O gerenciamento de projetos envolve um conjunto de atividades não triviais que possuem variações ágeis e nem tão ágeis assim. Dois arcabouços que se destacam para apoiar as atividades do gerenciamento são PMBOK e Scrum. Neste artigo não abordaremos como estes são diferentes, nem mesmo as diferenças entre eles. O foco será na união dos pontos fortes e como os processos podem coexistir tranquilamente e de uma maneira enxuta.

Este artigo é resultado de experiências anteriores em empresas de software as quais necessitavam ter controles mais tradicionais, até mesmo de forma a controlar os trabalhos e esforços despendidos, bem como ciclos rápidos de desenvolvimento gerando entregas de valor ao cliente utilizando-se o método Scrum. Durante a execução de todos os seus processos são geradas diversas informações relevantes aos clientes e partes interessadas através da aplicação de conceitos e artefatos tradicionais construídos tendo como base o PMBOK.

Um projeto antes de ser iniciado dentro da empresa, foi orçado e precificado, ou seja, houve uma análise prévia da equipe sobre o escopo onde foram estimados os esforços e, principalmente, estabelecidas as prioridades por entregável considerando-se o valor agregado a cada uma das entregas. Isso significa já existir um Product Backlog (lista de itens do produto) orçada e priorizada. As etapas seguintes, conforme estabelecido no Guia PMBOK como iniciação, planejamento, execução, monitoramento e controle e, o encerramento ocorrerão levando em conta este artefato – Product Backlog o qual foi extraído do contrato firmado entre as partes.

Sendo assim, o presente artigo descreverá os papéis, ferramentas utilizadas e artefatos gerados, processos e iterações durante todo o período de desenvolvimento do software contratado. Parte-se do pressuposto do conhecimento prévio da existência e do funcionamento básico do Guia PMBOK e da metodologia Scrum.

É necessário também contextualizar o projeto, cujo escopo está determinado no product backlog o qual contém diversas estórias. Não é relevante a ordenação das estórias as quais compõem o product backlog, mas sim, a prioridade ou o valor agregado gerado a cada estória produzida. Outra informação relevante é o esforço planejado para o desenvolvimento de cada estória. Sendo assim, o projeto contém várias estórias que serão agrupadas e produzidas em cada Sprint (a cada duas ou quatro semanas). Por exemplo: o projeto possui 10 estórias que foram priorizadas e organizadas em três Sprints. A primeira Sprint entregará cinco estórias, a segunda Sprint entregará três estórias e a terceira Sprint entregará dois estórias. A grosso modo, entendemos que o projeto terá duração de 12 semanas, considerando que cada Sprint possuirá quatro semanas de duração. Então, o plano do projeto constará exatamente esta informação.

Papéis e responsabilidades – Definindo quem faz o que

Todo e qualquer projeto de desenvolvimento de software depende, em sua maioria, de pessoas. Estabelecer os papéis e responsabilidades de cada um, em qualquer metodologia, é a principal atividade. Em um modelo híbrido de gestão existirão os papéis complementares e exclusivos para que não haja sobreposição de funções, otimizando e especializando determinadas atividades. Os papéis e suas responsabilidades estão descritos na Tabela 1.