Arquivo de etiquetas: Gerenciamento de Projetos

Time Scrum


É composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.

Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

O Product Owner

Ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:

  •  Expressar claramente os itens do Backlog do Produto;
  • Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
  • Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
  • Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
  • Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

O Product Owner pode fazer o trabalho acima, ou delegar para a Equipe de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.

 O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.

 Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com a Equipe de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.

 Equipe de Desenvolvimento

 Consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos.

  •  As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as seguintes características:
  •  Eles são auto-organizadas. Ninguém (nem mesmo o Scrum Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
  • Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
  • O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.
  • Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e,
  • Equipes de Desenvolvimento não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios.

Tamanho da Equipe de Desenvolvimento

 O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho.

 Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, ao menos que eles também executem o trabalho do Backlog da Sprint.

 O Scrum Master

É responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum.

 O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.

 O Scrum Master trabalhando para o Product Owner. O Scrum Master serve o Product Owner de várias maneiras, incluindo:

  • Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
  • Claramente comunicar a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento;
  • Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
  • Compreender a longo-prazo o planejamento do Produto no ambiente empírico;
  • Compreender e praticar a agilidade; e,
  • Facilitar os eventos Scrum conforme exigidos ou necessários.

O Scrum Master trabalhando para a Equipe de Desenvolvimento . O Scrum Master serve a Equipe de Desenvolvimento de várias maneiras, incluindo:

  •  Treinar a Equipe de Desenvolvimento em auto-gerenciamento e interdisciplinaridade;
  • Ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de alto valor;
  • Remover impedimentos para o progresso da Equipe de Desenvolvimento
  • Facilitar os eventos Scrum conforme exigidos ou necessários; e,
  • Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

 O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo:

  •  Liderando e treinando a organização na adoção do Scrum;
  • Planejando implementações Scrum dentro da organização;
  • Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
  • Causando mudanças que aumentam a produtividade do Time Scrum; e,
  • Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações.

fonte : Preparação para certificação Scrum Master – http://www.scrum.org/scrumguides/

Leia também : Os doze princípios do software ágil

Tipos de Comportamento


Como qualquer projeto é desenvolvido por um time de profissionais, solucionar conflitos envolve identificar o comportamento de pessoas em grupo e saber como conduzi-los melhor de modo a obter harmonia, boa atitude e parceria, entre outros.

Abaixo alguns tipos clássicos de comportamentos.

Sabotador: pessoa que está sempre procurando descobrir um resvalo de sua parte, um pequeno erro cometido. Via de regra é focado em “problemas”.

Franco atirador: é aquele que atira em tudo o que vê e ouve. É destruidor por natureza, e muitas vezes, por prazer.

Contraditor: é aquela pessoa que sempre encontra algo para se opor a uma ideia, uma solução ou uma forma de encaminhar uma determinada ação. As suas frases, normalmente, começam com a palavra “não”.

Calado: é aquela pessoa que contribui se for solicitada. Só age mediante impulso externo. Geralmente, mantém-se alijada dos processos mais movimentados do projeto.

Ansioso: é aquele que está sempre irrequieto, nunca está satisfeito com o que está fazendo, com o que ganha, com os recursos que dispõe. É o insatisfeito negativo, nocivo ao desenvolvimento do projeto.

Dominador: sempre procura levar vantagem por ser maior, por falar mais forte e alto, por bater mais na mesa ou mesmo pela forma de falar e se portar frente aos outros membros da equipe do projeto.

Que sai pela tangente: aquele que nunca se compromete com nenhuma alternativa ou sugestão que deve ser dada ao projeto.

Acomodado: é aquele que acata tudo o que lhe for dito. É nocivo ao projeto pela excessiva passividade frente ao que deve ser decidido e feito.

Crítico: sempre apresenta um “senão” a tudo o que é apresentado. Procura dar o seu toque, mesmo quando não é convidado para tal.

Que busca atenção: pelas vestimentas, pelas idéias, pela forma de se sentar ou seu comportamento durante as reuniões.

Palhaço: que está sempre contando uma piada ou “causo” e, com isto, apesar de divertir as pessoas, por vezes, não ajuda a focalizar o assunto que está sendo tratado. Ele se transforma num grande dispersador de energia na equipe do projeto.

Ao encontrar com um destes tipos, será importante manter a seguinte postura:

1. Destaque a conduta que está sendo percebida, nunca a pessoa. Isto aumentará a confiança das pessoas em você como condutor do time.

2. Detalhe seus efeitos mais aparentes, pois a pessoa não quer, na maioria das vezes, ser identificada.

3. Sugira comportamentos alternativos: é a atitude que você deve adotar de modo a permitir que a pessoa se recomponha e possa vir a colaborar com o projeto.

Material de estudo : Gerenciamento de Projetos – Catho Executivo

leia também : Organização Funcional X Centrada em Processos

Lidar com os conflitos em Projetos


Existe muito amadorismo nas relações entre as pessoas envolvidas num projeto quando o assunto é “conflito”. Muitos agem pelo instinto. Não que ele não seja importante, porém, agir apenas instintivamente pode levá-lo a um desgaste muito grande durante o projeto.

 Existem inúmeras maneiras de se lidar com conflitos nos projetos. As mais comuns são:

 1- Negação ou retração – ocorre quando você, submetido a uma situação de conflito, prefere “negar” que ele existe. É um “fazer de conta que”.

 2- Supressão ou apaziguamento – é a técnica que é empregada para “acalmar os ânimos” dos envolvidos no conflito.

 3- Poder ou dominação – é o mecanismo empregado pelo uso de algum tipo de autoridade que se possua: hierárquica, técnica, persuasão, conhecimento de regras e leis, etc.

4- Acordo ou negociação – refere-se à criação de “moedas de troca” que possam ser utilizadas, trocadas por outras “moedas”, na busca por um determinado resultado ou posição.

5- Integração ou colaboração – é a forma de tratar conflitos que procurem fazer com que os envolvidos tenham clareza de posição, tanto do projeto como individual, e possam ajustar os seus encaminhamentos para um ponto que seja comum.

A negação ou retração é aplicada quando você não pode vencer. Desta forma, você “bate de retirada” desta situação. Outras vezes você precisa apenas ganhar mais tempo para analisar determinada demanda. Nesta situação a retração é uma das melhores técnicas a serem aplicadas. O conflito não é dado por encerrado, e enquanto isto você adquire mais informações e argumentos sobre o assunto em pauta. Outras vezes, utiliza-se esta técnica para preservar a sua neutralidade ou reputação – como gestor do projeto ou mesmo como especialista.

A supressão ou apaziguamento é uma técnica empregada no tratamento de conflitos em projetos quando se quer atingir um objetivo extremamente difícil e é preciso contar com o apoio de todos os envolvidos no projeto. Por vezes, é preciso manter a harmonia entre as pessoas e esta técnica é, então, a mais indicada. Por outro lado, quando você vê que vai perder mesmo, empregue esta técnica e mantenha um bom clima de relacionamento dentro do projeto.

O poder ou dominação é uma técnica que você aplica quando cresce o conflito e você sabe que tem razão. A força também é aplicada em situações de “ou ele ou eu”, “tudo ou nada”. Nestas circunstâncias você não pode titubear frente ao seu, então, “oponente”. Uma circunstância onde aplicamos esta técnica é quando estamos frente a uma situação de elevado risco. Ser decisivo, preciso e não deixar nenhuma margem para dúvidas, nestas circunstâncias, passa a ser fundamental para a continuidade do projeto.

O acordo ou negociação é aplicado quando as duas partes precisam vencer. Ambas preparam o que querem, identificam, também, “moedas de troca” para serem utilizadas durante as negociações, pois sabem que terão que “queimá-las” no processo de negociação. Em situações onde você não pode vencer, você abre a negociação com o intuito de permitir que a outra parte crie a condição de arrebatar argumentos que permitam a você vencer a negociação. Outras vezes, você não tem certeza que está com a razão. Aí você abre a negociação para, inclusive, angariar argumentos que dêem sustentação ao seu posicionamento.

A integração ou colaboração, que é a única maneira aonde o conflito realmente é eliminado, é empregada quando existem condições de envolvimento e motivação das pessoas frente ao projeto. Quando o objetivo do projeto é tido como sendo “seu” objetivo. Buscamos este tipo de solução para os conflitos para reduzir custos no projeto ou quando sabemos que as habilidades se complementam e que o sucesso virá apenas com a colaboração das partes. Outra circunstância na qual a busca da colaboração é requerida é quando há confiança na capacidade técnica do outro.

Apenas por meio da integração é que conseguimos, de fato, solucionar o conflito. As outras formas são, entretanto, muito úteis a um projeto, pois permitem dar sequencia às atividades planejadas, buscando o cumprimento dos prazos. É importante lembrar que o papel do gerente nem sempre é o de solucionar os conflitos. Ele o trata para que o projeto continue.

Material de estudo – Gerenciamento de Projetos – Catho Executivo

leia também : KPI Gerenciamento de Incidente