Finalidade
  • Engajar recursos humanos no projeto
  • Mapear os recursos disponíveis nos conjuntos de habilidades necessários ao projeto.
  • Agrupar os recursos disponíveis em equipes relativamente independentes, mas colaborativas.
Função:  Coordenador de Projeto  
Freqüência: Conforme necessário, normalmente pelo menos uma vez por fase e repetido conforme necessário.
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Workflow:   

Formar a Equipe do Projeto Para o início da página

O Coordenador de Projeto terá determinado as necessidades da equipe para a iteração em Atividade: Definir Organização do Projeto e Formação da Equipe e procurará a função de Recursos Humanos da organização para oferecer uma equipe com o domínio, as habilidades e os perfis de experiência necessários. A maioria das organizações não tem o requinte de manter um pool grande de equipe para projetos. Além disso, os inícios de projeto nem sempre coincidem com o término de projetos anteriores. Geralmente, com exceção do pessoal já envolvido no projeto desde o início, muitas pessoas precisarão ser contratadas. Isso pode ser um processo demorado. Portanto, o Gerente de Projeto prudente sempre estará olhando adiante e iniciando a seleção da equipe para iterações futuras e também para a atual. Talvez seja possível compensar a escassez fazendo hora extra ou recorrendo à contratação de pessoal, em vez de formar uma equipe permanente. Essas duas soluções oferecem desvantagens e qualquer escassez sistemática e persistente nos níveis de equipe representará um sério risco para a programação.

Mapear as Habilidades do Pessoal para as Funções Para o início da página

Um papel define o comportamento e as responsabilidades de uma pessoa ou de um conjunto de pessoas que estão trabalhando juntas no negócio. O comportamento de cada papel é definido como um conjunto de atividades. As responsabilidades de cada papel são geralmente definidas com base em determinados artefatos, como os documentos, por exemplo. Como exemplos de papéis, podemos citar o designer, o arquiteto de software e o revisor. Por meio do conjunto de atividades associado, a função também define implicitamente uma competência.

Observe que os papéis não são pessoas; eles descrevem como as pessoas devem se comportar no negócio e quais são suas responsabilidades.

O projeto normalmente tem a sua disposição uma série de recursos, individuais que têm as competências específicas. Por exemplo, Joe, Marie, Paul e Sylvia são pessoas com competências que, embora diferentes, se sobrepõem. Usando os papéis definidos no processo, mapeie os recursos disponíveis no projeto para os papéis que eles podem desempenhar.

O diagrama mostrafunções de sobreposição para Paul, Mary, Joe, Sylvia e Stephan.

A associação da pessoa ao papel é dinâmica no decorrer do tempo, orientada pela fase do ciclo de vida do projeto e pelo trabalho a ser executado.

  • Uma pessoa pode desempenhar funções diferentes no mesmo dia: Por exemplo, Sylvia pode ser uma revisora pela manhã e uma Designer de Caso de Uso à tarde.
  • Uma pessoa pode desempenhar várias funções simultâneamente: Por exemplo, Jane pode ser o Arquiteto de Software e a Designer de uma determinada classe, além de Proprietária do Pacote do pacote que contém essa classe.
  • Várias pessoas podem exercer a mesma função para executar uma determinada atividade juntas, agindo como uma equipe: Por exemplo, Paul e Mary podem ser Designers de Caso de Uso do mesmo caso de uso.

Tente alocar as responsabilidades para que haja pouca entrega de artefatos de um recurso para outro: faça com que a mesma pessoa ou equipe projete e implemente um subsistema para que não tenham que reaprender o trabalho já feito por outras pessoas.

Quando a mesma equipe projeta e implementa, a transição do design para a implementação é suave. Além disso, isso forma melhores designers: aprendendo o que funciona e o que não funciona, eles terão uma melhor percepção do que é um bom design e utilizarão isso em trabalhos futuros. Como um escultor, o bom designer deve compreender o meio de expressão, que, no caso do software, é o ambiente de implementação.

Formar Equipes Para o início dapágina

A forma da organização do projeto e os níveis de equipe necessários para a iteração foram decididos pelo Coordenador de Projeto em Atividade: Definir Organização do Projeto e Formação da Equipe. Sabendo a disponibilidade real dos recursos, ela permanecerá ajustada a essa estrutura e atribuirá a equipe a ela. O Coordenador de Projeto deve reexaminar qualquer equipe que tenha mais de sete pessoas, a fim de verificar se existe uma maneira arquiteturalmente sensata de dividi-la; digamos que isso seja feito juntamente com as linhas de subsistema.

As equipes devem ser compostas por, no mínimo, duas pessoas e, no máximo, sete pessoas. Equipes com mais de sete pessoas geralmente são divididas em subequipes; portanto, é melhor fazer isso para facilitar a vida de todos.

Ao atribuir o pessoal às equipes, o Gerente de Projeto deve estar atento à experiência geral e ao nível de familiaridade da equipe, e deve tentar formar equipes misturando o 'sangue novo' com o pessoal que já vem trabalhando no projeto há algum tempo. No início de um projeto, o Gerente de Projeto deverá contar com a combinação pessoal experiente/pessoal novato.

Treinar Equipe do Projeto Para o início da página

Em vários casos, um inventário de competências dos recursos disponíveis no projeto revelará brechas na atribuição dos membros da equipe aos papéis (partindo do pressuposto de que o curso normal de recrutamento de outros membros ou contratação de recursos externos já foi tentado). Nesse caso, as habilidades precisarão ser desenvolvidas. O treinamento e a orientação apropriados devem ser fornecidos a essas pessoas, com antecedência, mas bem próximo do momento em que elas precisarão revelar suas habilidades. O treinamento que não é colocado imediatamente em prática logo se perde. Geralmente, a combinação do treinamento formal seguido por um workshop ministrado pelo mentor para iniciar uma atividade é particularmente eficaz, uma vez que as novas habilidades entram logo em ação.



Rational Unified Process   2003.06.15