the scrum experience

Após estarmos à um tempo considerável a usar Scrum aqui fica o status da experiência.

O primeiro contacto da equipa com o Scrum não foi muito pacífico (embora também não tenha sido nenhuma desgraça), pois apesar de ter transmitido que a presença de um quadro com as tarefas de um projecto não tinha como propósito ser um “big brother”, a verdade é que senti alguma resistência à mudança, pois o white board era encarado como uma ferramenta de controlo/subjugação. Constatei que o white board (inicialmente) em vez de se tornar um facilitador tinha-se tornado uma fonte de stress.

Mas na verdade, e tal como esperava, após a equipa habituar-se à presença do white board (uma questão de dias), bem como das daily scrums, o trabalho começou a fluir de uma forma muito interessante e sem dúvida que nos tornamos bastante mais eficientes.

Com as nossas daily scrums e com o white board conseguimos de forma rápida e simples aferir em que ponto do projecto estamos, que dificuldades estamos a sentir no desenrolar das actuais tarefas, o que está feito, o que está por fazer e o que está realmente feito (validado).

Inclusivamente tivemos um projecto em que o cliente quis fazer uma versão beta e como tínhamos todas as tarefas claramente identificadas foi muito simples definir que features seriam possíveis para uma versão beta e que features apenas estariam disponíveis para a versão final. E é neste tipo de situações em que o Scrum se torna uma mais valia e se destaca das demais metodologias de gestão de projectos.
Apenas deixamos de utilizar o white board quando entramos em fase de testes. Aí usamos uma ferramenta open-source, chamada redmine, para fazermos toda a gestão do fluxo de reporting de bugs (desde o momento em que o bug é reportado até à sua resolução e validação por parte do cliente).

Neste momento estou muito satisfeito com o Scrum e a equipa também já o perfilhou. Estamos todos (a equipa) satisfeitos com o Scrum. As “coisas” mudaram para melhor e somos hoje uma equipa mais eficiente.

Gostaria só de deixar um aviso à navegação: o Scrum não é uma silver bullet, ou seja, não é a solução para todos os males de uma equipa. É apenas uma excelente forma de gerir e desenvolver projectos. Li uma frase na internet que explica da melhor forma o que acabei de escrever: “A great team will have great success with or without Scrum. A shitty team will still produce shit with scrum. Just that the shitty scrum team will see it earlier than the shitty no-scrum team”.

Até para a semana.

Anúncios

gestão do âmbito

Antes de mais peço desculpa por não ter escrito a semana passada mas a verdade é que estive envolvido num processo de mudança de casa e como tal não tive acesso ao bem precioso que é a internet.

Agora sobre o tema desta semana, o âmbito é “algo” que é definido no início de um projecto. E ao contrário do que seria de esperar, o âmbito é tão instável que é normal ser alterado durante o ciclo de vida de um projecto.

E como se procede a essa alteração? Antes de mais através da formalização da comunicação alteração do âmbito por parte do sponsor ou stakeholder responsável. A partir deste ponto devemos avaliar junto do arquitecto/líder técnico ou junto da equipa que impactos esta alteração trás ao nosso planeamento:

  • É exequível?

  • Precisamos de mais tempo?

  • Precisamos de mais recursos?

  • O que foi desenvolvido até à data é posto em causa?

  • Toda a equipa tem disponibilidade para levar o projecto até ao fim? (Imaginemos que precisamos de mais tempo para o projecto e um recurso já está escalado para outro projecto no próximo mês)

  • Como minimizamos o impacto no nosso projecto?

  • O âmbito é negociável?

  • Podemos abdicar de alguma feature para cumprir com o novo âmbito?

São várias as questões que o gestor de projecto deve colocar. Deve não só procurar a resposta para todas como acima de tudo revelar muita calma, confiança e segurança à equipa de forma a evitar resistências à mudança. A equipa deve assumir o novo âmbito como um desafio e não como uma contrariedade.

Depois do plano de acção estar refeito, o gestor de projecto deve comunicar as alterações de âmbito (confirmação do que será desenvolvido durante o resto do projecto), do tempo e dos custos. E como faz isso? Através de um documento de “Change Request” onde irá formalizar todas as alterações de forma a assegurar o compromisso do sponsor ou stakeholder responsável pela mudança do âmbito.

O bottom line aqui é nunca fazer uma tempestade num copo de água por causa de uma alteração de âmbito. O âmbito deve ser o mais estável e preservado possível mas temos de ser realistas o suficiente para aceitar que um projecto em que o âmbito se torna desenquadrado da realidade de uma empresa é um projecto inútil e que irá gerar um produto obsoleto.

Sem dúvida que é frustrante a meio de um projecto ter de re-equacionar todas as variáveis e por vezes ponderar até que ponto o projecto faz sentido ou não… mas se tudo fosse fácil também não era preciso gestores de projectos.

Os imprevistos e problemas existem tanto na vida como num projectos. E enquanto formos gestores de projecto temos como missão assegurar que nenhum deles prejudica o nosso projecto. Isto leva-me a crer que é pena não termos na nossas vidas também um “gestor de projecto”.

Até para a semana.

gestão da mudança

Durante um projecto é praticamente inevitável a mudança.

E mudança de quê?

Das mais variadas coisas:
– dos requisitos;
– da equipa de projecto:
– da tecnologia;
– dos stakeholders;
– do sponsor;
– do tempo, custo e/ou qualidade
– do âmbito;
– entre outros;
– importância do projecto;
– entre outras.

A mudança é uma realidade num projecto. Quem é que nunca perdeu um recurso durante o decorrer de um projecto? Ou assistiu à mudança de um stakeholder? Ou assistiu a alterações do triângulo custo, tempo e qualidade?

A verdade é que a mudança está sempre a ocorrer, umas vezes com maior impacto do que outras. E infelizmente como as pessoas têm uma grande resistência à mudança, a tarefa de gerir essa mesma mudança não é propriamente fácil.

A mudança pode ter várias origens:
– a equipa de projecto;
– factores externos;
– sponsor;
– restantes stakeholders;
– gestor de projecto.

Qualquer pessoa ou circunstância ligada directa ou indirectamente ao projecto pode ser originadora de uma mudança.

O papel do gestor de projecto na gestão da mudança é fulcral. Cabe-lhe a ele manter sempre a calma, ser receptivo e acima de tudo encarar sempre de forma positiva e transmiti-lo a todos os stakeholders. Basicamente é o chamado “Always look on the bright side of life!”. O dever do gestor de projecto não é evitar a mudança, mas sim fazer com que tenha o menor impacto possível no projecto e que seja encarada de forma positiva por todos os stakeholders. Desta forma a mudança será um aspecto positivo do projecto e não um aspecto negativo. Tudo depende como esta (a mudança) é introduzida no projecto.

Se o gestor de projecto fizer um drama de uma mudança, a equipa de projecto não a irá aceitar bem, os stakeholders irão torcer o nariz e pode-se transformar uma bela relação num autêntico pesadelo.

E a partir deste momento, se as pessoas começam a ficar resistentes à mudança todo o resto do projecto sairá prejudicado e terão de se redobrar esforços na comunicação.

Já que estamos a falar de comunicação, poderemos abordar este tema no próximo post.

Até para a semana.

atrasos

Sem dúvida que o bicho papão de qualquer projecto é o  “atraso”.

E afinal o que são os “atrasos”?

Os atrasos são deslizes no tempo, ou seja, é o resultado da decisão dos stakeholders em abdicar do Tempo em favor da Qualidade e do Custo (de forma a cumprirem com determinadas expectativas).

Esta decisão é um clássico na gestão de projecto e por norma das mais erradas. Isto porque é mais vantajoso cumprir os tempos do projecto e refazer o âmbito (menos funcionalidades, menos relatórios, menos detalhe) mantendo a qualidade e o custo do que pura e simplesmente abdicar do tempo na expectativa de manter o âmbito intacto e que os novos tempos se cumpram sem mais percalços.

Tendo em conta que os “atrasos” acontecem sempre nos projectos, os stakeholders deveriam encarar este fenómeno de outra forma. Não pelo lado negativo mas sim como um acontecimento natural que exige uma reflexão sobre todo o projecto.

E a que se devem os “atrasos”?

Basicamente os atrasos devem-se a todos os stakeholders no geral:

– programadores (atrasarem-se nos desenvolvimentos);

– líder técnico (estimativas erradas);

– gestor de projecto (má orquestração de todas as partes envolvidas no projecto e/ou estimativas erradas);

– outras equipas (é sempre difícil coordenar um projecto em que envolva mais do que 1 equipa, onde cada uma tem o seu objectivo e o seu respectivo calendário);

– decisores (redefinição de requisitos a meio dos desenvolvimentos quer por alterações da realidade quer por omissão de requisitos durante a fase de análise ou até por alteração dos decisores em si);

– sponsor (alteração da prioridade/importância do projecto);

Resumindo, os “atrasos” podem acontecer por culpa de qualquer pessoa ligada ao projecto.

Mas não é só por causa das pessoas que um projecto pode atrasar. Existem outros fenómenos que originam atrasos:

– fenómenos externos à organização (situação actual da economia e decisões políticas);

– tecnologia (tecnologia desadequada ao projecto);

– indisponibilidade dos stakeholders (férias, despedimentos, gravidez);

ou seja, os atrasos podem ser motivados por imensos factores o que faz com que os atrasos em si sejam perfeitamente naturais dentro dos projectos. E sendo uma realidade intrínseca em qualquer projecto, a principal função do gestor de projecto é não só evitar os atrasos mas essencialmente fazer com que qualquer atraso prejudique o menos possível o projecto.

Para me explicar melhor vou dar um exemplo: Imaginem um capitão num barco em alto mar. Apesar de poder optar sempre pelas rotas mais favoráveis, a verdade é que eventualmente vai-se cruzar com uma tempestade. E aí sim é que se vê quem é bom capitão. Bom capitão é aquele que atravessa a tempestade e leva a sua tripulação para um porto seguro. E deve-se dar tanto ou mais valor a quem consegue atravessar uma tempestade do que a quem, por sorte ou mérito, a consegue evitar (a sorte não dura para sempre e nem todos os dias somos brilhantes).

Creio que o assunto “atrasos” está por agora encerrado.

Estamos agora a começar a entrar na gestão da mudança (em atravessar tempestades). Mas sobre esse tema iremos falar no próximo post.

Até para a semana.