MS Project 4 AGILE: Configurar o Backlog do Produto
No artigo anterior explicámos as alterações que devem ser feitas de forma a adaptar o MS Project ao método de trabalho por interações (ver aqui). Essencialmente explicámos o que é preciso fazer para trabalhar com um único calendário de projeto uma vez que, o trabalho em equipa, essencial ao sucesso dos projetos AGILE
Neste novo artigo vamos explicar como se pode alterar a tabela Gantt do MS Project de forma a guardar a informação de que necessitamos para gerir e controlar um projeto SCRUM.
Continue a ler para aprender como pode configurar o MS Project de forma a usar a tabela Gantt para criar o Log de Produto de um projeto ágil.
Os projetos geridos de acordo com os princípios do AGILE são geridos com base num mecanismo de planeamento adaptativo centrado no Backlog do Produto e na Priorização das Funcionalidades a criar.
Para usarmos o MS Project na gestão ágil de projetos temos de criar, na Tabela Gantt do MS Project, um conjunto de campos adicionais que nos permitam guardar a informação que necessitamos para simular o planeamento e o controlo de execução feito com base no Backlog do Produto.
Num projeto gerido segundo os princípios do AGILE em vez de nos preocuparmos em definir, e controlar, as atividades que são necessárias para criar um determinado produto ou serviço, preocupamo-nos em definir e priorizar a ordem de criação das funcionalidades que o nosso produto ou serviços deve dispor.
O Backlog do Produto é uma lista de funcionalidades ordenada por ordem de prioridade, e o processo de criação do produto decorre com base em ciclos de trabalho sucessivos que no método SCRUM se chamam Sprints. Cada Sprint inicia-se com um processo de planeamento em que, a equipa, em conjunto com o representante do cliente, decide, com base nas prioridades atribuídas a cada uma das funcionalidades, quais aquelas que irão ser criadas nesse Sprint. A um grupo de dois ou mais Sprints nos quais se estejam a criar funcionalidades que são interdependentes dá-se o nome de Versão.
Assim, se usarmos o MS Project para gerir projetos SCRUM, o que vai estar descrito na Tabela Gantt são as funcionalidades a desenvolver. Para podermos transformar a Tabela Gantt que o MS Project oferece por defeito, num Backlog de Produto adequado à gestão ágil de projetos, temos de adicionar-lhe um conjunto de campos do utilizador que nos permitirão guardar informação sobre se uma determinada linha da Tabela Gantt representa ou não uma funcionalidade (Funcionalidade=Sim/Não), qual a Versão e qual a Interação (Sprint), a que cada uma das funcionalidades pertence, e qual a Prioridade que cada funcionalidade tem.
Outro conceito que é fundamental para controlar os projetos SCRUM é o conceito de Velocidade. A velocidade mede a capacidade de trabalho da equipa SCRUM e aplica-se aos Sprints do projeto. Por exemplo, se tivermos uma equipa de 5 pessoas a trabalhar a tempo integral, 7 horas por dia, e se tivermos Sprints de 10 dias uteis, então o numero de horas de trabalho que temos disponível no inicio de cada Sprint é [numero dias x horas diárias x numero pessoas] = 10 * 7 * 5 = 350 horas de trabalho. Se o Sprint tem 350 horas uteis de trabalho e 10 dias de duração, então a velocidade média do Sprint será 350 / 10 = 35 horas.
Durante o planeamento do Sprint a equipa vai decidir que funcionalidades irá executar nesse Sprint.
O SCRUM aconselha que se separe a estimativa de esforço relativo (medida em pontos da história) e a estimativa de esforço efetivo, também conhecida por duração, (medida em horas de trabalho efetivo).
A primeira (esforço relativo) é uma estimativa que vai sendo atualizada à medida que as funcionalidades do backlog do produto vão sendo detalhadas. É semelhante às estimativas de alto nível efetuadas na gestão de projetos tradicional, e permite ter uma ideia da complexidade relativa das várias funcionalidades do projeto.
A segunda estimativa (duração) é feita quando uma funcionalidade está completamente detalhada. É uma estimativa feita pela equipa de projeto e por consenso (No próximo artigo falaremos um pouco mais do processo para realizar esta estimativa e que, no SCRUM, é habitualmente chamado de Poker de Planeamento). Tem por finalidade saber com precisão o numero de horas que cada funcionalidade custa a implementar e é a base para o planeamento dos Sprints do projeto (as interações) e do calculo da velocidade da equipa de projeto.
Para usarmos o MS Project na gestão ágil de projetos temos de criar, na Tabela Gantt do MS Project, um conjunto de campos adicionais que nos permitam guardar a informação que necessitamos para simular o planeamento e o controlo de execução feito com base no Backlog do Produto.
Num projeto gerido segundo os princípios do AGILE em vez de nos preocuparmos em definir, e controlar, as atividades que são necessárias para criar um determinado produto ou serviço, preocupamo-nos em definir e priorizar a ordem de criação das funcionalidades que o nosso produto ou serviços deve dispor.
O Backlog do Produto é uma lista de funcionalidades ordenada por ordem de prioridade, e o processo de criação do produto decorre com base em ciclos de trabalho sucessivos que no método SCRUM se chamam Sprints. Cada Sprint inicia-se com um processo de planeamento em que, a equipa, em conjunto com o representante do cliente, decide, com base nas prioridades atribuídas a cada uma das funcionalidades, quais aquelas que irão ser criadas nesse Sprint. A um grupo de dois ou mais Sprints nos quais se estejam a criar funcionalidades que são interdependentes dá-se o nome de Versão.
Assim, se usarmos o MS Project para gerir projetos SCRUM, o que vai estar descrito na Tabela Gantt são as funcionalidades a desenvolver. Para podermos transformar a Tabela Gantt que o MS Project oferece por defeito, num Backlog de Produto adequado à gestão ágil de projetos, temos de adicionar-lhe um conjunto de campos do utilizador que nos permitirão guardar informação sobre se uma determinada linha da Tabela Gantt representa ou não uma funcionalidade (Funcionalidade=Sim/Não), qual a Versão e qual a Interação (Sprint), a que cada uma das funcionalidades pertence, e qual a Prioridade que cada funcionalidade tem.
Outro conceito que é fundamental para controlar os projetos SCRUM é o conceito de Velocidade. A velocidade mede a capacidade de trabalho da equipa SCRUM e aplica-se aos Sprints do projeto. Por exemplo, se tivermos uma equipa de 5 pessoas a trabalhar a tempo integral, 7 horas por dia, e se tivermos Sprints de 10 dias uteis, então o numero de horas de trabalho que temos disponível no inicio de cada Sprint é [numero dias x horas diárias x numero pessoas] = 10 * 7 * 5 = 350 horas de trabalho. Se o Sprint tem 350 horas uteis de trabalho e 10 dias de duração, então a velocidade média do Sprint será 350 / 10 = 35 horas.
Durante o planeamento do Sprint a equipa vai decidir que funcionalidades irá executar nesse Sprint.
O SCRUM aconselha que se separe a estimativa de esforço relativo (medida em pontos da história) e a estimativa de esforço efetivo, também conhecida por duração, (medida em horas de trabalho efetivo).
A primeira (esforço relativo) é uma estimativa que vai sendo atualizada à medida que as funcionalidades do backlog do produto vão sendo detalhadas. É semelhante às estimativas de alto nível efetuadas na gestão de projetos tradicional, e permite ter uma ideia da complexidade relativa das várias funcionalidades do projeto.
A segunda estimativa (duração) é feita quando uma funcionalidade está completamente detalhada. É uma estimativa feita pela equipa de projeto e por consenso (No próximo artigo falaremos um pouco mais do processo para realizar esta estimativa e que, no SCRUM, é habitualmente chamado de Poker de Planeamento). Tem por finalidade saber com precisão o numero de horas que cada funcionalidade custa a implementar e é a base para o planeamento dos Sprints do projeto (as interações) e do calculo da velocidade da equipa de projeto.
Microsoft Project Para Agile: Configuração do BackLog do Produto
Quando abrimos um ficheiro de MS Project o mais comum é que este abra por defeito a Tabela Gantt do projeto. Essa tabela é composta por um conjunto muito grande de campos, dos quais só visualizamos uma pequena parte, mas o MS Project permite-nos ainda criar campos adicionais para guardar informação que não esteja contemplada nos campos pré-definidos. É isso que vamos fazer, para guardar a informação a que nos referimos anteriormente (Funcionalidade, Numero de Versão e de Interação, Pontos e Prioridade da Funcionalidade).
Siga as instruções abaixo para criar os campos adicionais de que necessita para transformar a Tabela Gantt numa tabela que sirva para guardar o Backlog do nosso projeto AGILE.
1. Abra o MS Project
Siga as instruções abaixo para criar os campos adicionais de que necessita para transformar a Tabela Gantt numa tabela que sirva para guardar o Backlog do nosso projeto AGILE.
1. Abra o MS Project
2. Abra o ficheiro de projeto que usou no artigo anterior (ver aqui). No nosso caso vamos abrir o ficheiro MSP4AG_Art2 que guardámos no disco C:\ do nosso computador.
3. O primeiro campo adicional que iremos criar é o campo para guardar informação sobre se uma determinada linha do BackLog de Produto representa ou não uma Funcionalidade do produto ou serviço que estamos a criar.
3. O primeiro campo adicional que iremos criar é o campo para guardar informação sobre se uma determinada linha do BackLog de Produto representa ou não uma Funcionalidade do produto ou serviço que estamos a criar.
- Aceda ao menu Project | Custom Fields
- Na caixa de diálogo “Custom Fields verificamos se está selecionada a opção “Task” e o campo Text1
- Abra a combo-box "Type" e escolha o tipo de campo “Flag”
- De seguida carregue no botão “Rename” e renomeio o nome do campo de Flag1 para "Funcionalidade"
1 5. Como foi referido anteriormente cada funcionalidade tem uma estimativa de esforço a qual é representada em pontos (quantos mais pontos forem atribuídos a uma determinada funcionalidade, mais complexa será a sua implementação). Para guardar a informação sobre a pontuação de cada uma das funcionalidades vamos criar um outro campo adicional, igualmente de formato numérico, ao qual daremos o nome “Func Pontos”. Finalmente, para guardar a informação sobre a duração de cada uma das funcionalidades, vamos criar mais um campo adicional de formato numérico, ao qual daremos o nome de "Duracao_Horas".
6. Nos projetos ágeis o representante do cliente decide sobre a prioridade atribuída a cada uma das funcionalidades. Existem muitas formas de definir essas prioridades, iremos falar disso em artigos específicos que publicaremos ao longo dos próximos meses, mas a decisão sobre que prioridade deve ser atribuída a determinada funcionalidade deve ter como base o valor que, do ponto de vista do representante do cliente, a funcionalidade tem para o negócio. Em cada Sprint do projeto são criadas as funcionalidades a que o cliente atribui maior prioridade. Para guardar a prioridade de cada uma das funcionalidades do projeto temos de criar um campo adicional de formato Texto.
6. Nos projetos ágeis o representante do cliente decide sobre a prioridade atribuída a cada uma das funcionalidades. Existem muitas formas de definir essas prioridades, iremos falar disso em artigos específicos que publicaremos ao longo dos próximos meses, mas a decisão sobre que prioridade deve ser atribuída a determinada funcionalidade deve ter como base o valor que, do ponto de vista do representante do cliente, a funcionalidade tem para o negócio. Em cada Sprint do projeto são criadas as funcionalidades a que o cliente atribui maior prioridade. Para guardar a prioridade de cada uma das funcionalidades do projeto temos de criar um campo adicional de formato Texto.
- Aceda ao menu Project | Custom Fields
- Carregue no botão “Rename” e renomeie o campo "Text1" atribuindo-lhe o nome “Prioridade”
- Na secção “Custom attributes” carregue no botão “Lookup”. Na primeira linha da caixa de diálogo “Lookup Table for Funcionalidade” escreva “Alta” e na respetiva descrição escreva “Alta Prioridade”. Repita essa ação escrevendo nas linhas subsequentes “Média”, “Média Prioridade” e “Baixa”, “Baixa Prioridade”
- Carregue no botão “Close” para fechar a caixa de diálogo “Lookup Table for Funcionalidade”
- Carregue no botão “Ok” para fechar a caixa de diálogo “Custom Fields”
7. Guarde o ficheiro em que esteve a trabalhar, ele será usado como ponto de partida para o próximo artigo.
8. Aceda ao menu File | Save As
9. Escolha a localização e o nome do ficheiro a guardar. No nosso caso escolhemos o nome MSP4AG_Art3 e guardámos o ficheiro no disco C:\ do nosso computador.
10. Clique no botão “Save” Abandone o MS Project.
Por agora é tudo,
Bons projetos
Grp2ALL
Se pretender seguir esta série de artigos desde o inicio, tem aqui a lista cronológica dos artigos já publicados:
1.MS Project Configuração para AGILE (SCRUM)
1.MS Project Configuração para AGILE (SCRUM)
