Artigos Engenharia de Software Modelo híbrido de gestão

Por que eu devo ler este artigo:Gerenciar projetos de desenvolvimento de software não é uma tarefa simples, pois o uso de guias como o PMBOK leva muitas empresas a adotarem métodos muito rígidos e trabalhosos enquanto o mercado busca por agilidade. Por outro lado, os métodos ágeis como o Scrum resolvem a questão da agilidade e entrega de valor agregado e tornam mais clara a visibilidade e previsibilidade da entrega do produto do projeto, porém com certas perdas não tratadas por metodologias ágeis como controle de custo, riscos, contratações, aquisições, entre outros. Desta forma, o melhor caminho é a união dos pontos fortes de cada uma, respeitando aquilo que é de mais valioso em um projeto – a entrega do escopo. Este artigo é útil por mostrar como é possível trabalhar com abordagens ágeis e tradicionais em conjunto no gerenciamento de projetos. Essa abordagem híbrida traz benefícios e permite aos gestores definir um modelo de gestão ágil, documentalmente estruturado, eficiente, eficaz e bem aceito em modelos de maturidade como o MPS.BR e o CMMI.

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.

Tabela 1. Papéis e Responsabilidades.

Papel Sigla Descrição e Responsabilidade
Gerente de Projetos GP É a pessoa de contato e responsável geral pelo projeto, ou seja, aquele que garantirá o bom andamento do projeto tanto pela ótica do cliente como internamente, acompanhando e controlando o andamento do projeto, auxiliando nas dificuldades, monitorando e corrigindo possíveis desvios, mantendo as comunicações entre as partes, controlando os riscos, escopo, custo, prazo, entre outros.
Product Owner PO Gerenciar o Product Backlog garantindo que o que será produzido pela equipe está de acordo com as expectativas do cliente. Em outras palavras, o PO é o detentor das regras de negócio de cada item do product backlog, o representante dos desejos do cliente no que se refere ao produto a ser produzido e entregue. O PO também é responsável por manter a visibilidade a todos do product backlog.
Scrum Master SM Disseminador da adoção da metodologia Scrum junto à equipe, auxiliando na organização dos membros da equipe, permitindo que evoluam em sua auto-organização e aumentem sua produtividade. Também é o responsável por remover quaisquer impedimentos os quais interrompam ou possam vir a interromper o bom andamento do desenvolvimento das atividades durante a Sprint.
Equipe EQ

Equipe são as pessoas que trabalham no projeto e na Sprint. Na metodologia Scrum utiliza-se o termo auto organizada e multidisciplinar. Isso não quer dizer que todos os membros da equipe fazem todas as atividades, pois isso não seria nada produtivo. Ao dizer auto organizada e multidisciplinar deve-se entender:

  • Auto organizada: todos os membros da equipe sabem o que precisa ser feito e quem deverá fazer o que e no momento adequado, afim de garantir a entrega do objetivo;
  • Multidisciplinar: Não restringe o papel principal de cada membro da equipe. Por exemplo: um arquiteto de software poderá ser o administrador do banco de dados; um Desenvolvedor poderá fazer uma documentação necessária; um analista de testes também pode ser o analista de requisitos, etc.

O principal ponto a ser observado é a equipe ser composta por membros experientes e suficientes para a construção do software conforme o estabelecido.

O tamanho da equipe também poderá variar conforme a necessidade, porém é fortemente recomendado que os membros da equipe possuam forte conhecimento da metodologia Scrum para viabilizar o trabalho em conjunto com os demais. Em outras palavras, caso seja preciso aumentar a equipe, os novos integrantes devem possuir os conhecimentos da metodologia e da dinâmica de trabalho, bem como estarem confortáveis com os valores e a cultura da organização, caso contrário, a performance poderá não ser a esperada.
Quer ler esse conteúdo completo? Tenha acesso completo