Feeds:
Posts
Comentários

Archive for junho \12\+00:00 2011

O guia PMBOK não vai te ensinar como ter sucesso nos projetos ou ser um bom gerente de projetos. Ele fornece diretrizes para o gerenciamento de projetos individuais. Olha o que diz o próprio Guia PMBOK:

“O Guia PMBOK identifica esse subconjunto do conjunto de conhecimentos em gerenciamento amplamente reconhecido como boa prática. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo e que existe um consenso em relação ao seu valor e sua utilidade. “Boa prática” significa que existe um consenso geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances do sucesso em uma ampla gama de projetos. Uma boa prática não significa que o conhecimento descrito deva ser sempre aplicado uniformemente em todos os casos; a organização e/ou a equipe de gerenciamento do projeto é responsável por determinar o que é apropriado para um projeto específico”.

E este é o desafio. Você não vai encontrar um livro ou algum “guia” dizendo exatamente passo a passo como você deve lidar com sua equipe, com seus projetos, clientes… A empresa deve identificar as melhores práticas e criar seu próprio “método de desenvolvimento de software”. E isso se constrói com aprendizado constante, revisões constantes, talvez muitos erros no começo, ou até uma consultoria no início, não sei… Mas é necessário começar!

Primeiro o PMBOK não é um guia específico de gerenciamento de projetos de SOFTWARE, e sabemos que projeto de software é bem diferente que demais tipos de projetos. Se você tratar projeto de software como um projeto de construção civil, por exemplo, em minha opinião… Pode se dar mal. As coisas não acontecem da mesma forma. Uma planta de apartamento de dois quartos, dificilmente mudará durante o “desenvolvimento do projeto”. Ninguém é doido de chegar e dizer: “Oi! Mudei de ideia, agora quero três quartos”, mas em software isso acontece… hehehe Tudo acontece, tudo é possível, rsrs. Então é “um pouco” diferente.

Mas vou falar um pouco do PMBOK neste post porque projetos de software também possuem escopo, tempo, pessoas envolvidas, qualidade, riscos, etc. e é interessante entender e saber de cada uma dessas questões para depois descobrimos a melhor forma de lidar com todas elas.

Ciclo de vida do projeto

Todo projeto possui começo, meio e fim. O PMBOK mapeia o ciclo de vida do projeto da seguinte forma:

  • Início do projeto;
  • Organização e preparação;
  • Execução do trabalho e projeto e;
  • Encerramento do projeto.

O ciclo de um projeto de software se encaixa nestas etapas? Vejo que sim, mas se você tentar partir para o desenvolvimento seguindo este modelo SEQUENCIALMENTE poderá ter problemas. É o que chamam de modelo “CASCATA”. Vejam na figura:

Parece que não vem dando muito certo. É o que já mencionei em posts anteriores: Identificar TODOS os requisitos no início do projeto pode gerar muita dor de cabeça… Porque eles VÃO MUDAR, certamente vão mudar. Codificar tudo, do começo ao fim para depois mostrar para o cliente, também pode ser um grande problema. Qualquer mudança que ele te solicitar poderá causar grandes impactos e custar caro. Enfim… E qual a solução? Existe o modelo INCREMENTAL. Resume em passar por todas essas fases, várias vezes! Parece ter mais sentido né? Desenvolver “pequenos pacotes de requisitos”. (As Sprints do Scrum são justamente isso).

(Mulheres precisam falar de vários assuntos ao mesmo tempo o.O) … Voltando a falar sobre o PMBOK….

Segundo o PMBOK, os processos de gerenciamento de projetos são agrupados em cinco categorias, conhecidas como grupos de processos de gerenciamento de projetos (ou grupo de processos): Obs.: Os grupos de processos não são as fases do projeto.

Grupo de processos de iniciação: São os processos realizados para definir um novo projeto ou uma nova fase de um projeto existente. Incluem as atividades:

  • Identificação das partes interessadas;
  • Aprovação do termo de abertura;
  • Declaração inicial do escopo do projeto;
  • Documentação dos requisitos de alto nível;
  • Duração do projeto;
  • Previsão de recursos.

Grupo de processos de planejamento: Os processos realizados para definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ação necessário para alcançar os objetivos para os quais o projeto foi criado. Algumas das atividades são:

  • Coleta de requisitos;
  • Definição do escopo;
  • Divisão do projeto em componentes menores;
  • Identificação das atividades, recursos e duração;
  • Cronograma;
  • Estimativa de custos;
  • Identificação de riscos;
  • Etc.

Grupo de processo de execução: Processos realizados para executar o trabalho definido no plano de gerenciamento do projeto. Atividades:

  • Podem surgir mudanças nas durações previstas para as atividades, disponibilidade dos recursos;
  • Mudanças solicitadas (que geram mudanças nos documentos, cronograma, etc);
  • Auditoria dos requisitos, para garantir a qualidade;
  • Obtenção da equipe necessária para o projeto;
  • Gerenciamento da equipe do projeto (Acompanhar desempenho, fornecer feedback, etc);
  • Distribuir informações para as partes interessadas;
  • Gerenciar as expectativas das partes interessadas;
  • Etc.

Grupo de processos de monitoramento e controle: Processos necessários para acompanhar, revisar e regular o processo e desempenho do projeto, identificar e iniciar as mudanças necessárias. Atividades:

  • Monitorar e controlar o trabalho do projeto (status, medição de progresso, previsões, etc);
  • Avaliar as solicitações de mudanças, aprovação e gerenciamento das entregas;
  • Formalizar a aceitação das entregas terminadas do projeto;
  • Monitorar o andamento do escopo;
  • Atualização do cronograma;
  • Atualização do orçamento;
  • Controlar a qualidade;
  • Distribuir informações sobre o desempenho do projeto e andamento das atividades.

Grupo de processos de encerramento: Processos executados para finalizar todas as atividades, visando contemplar formalmente o projeto contratado.

Bom, é disso que o PMBOK trata. Existe um capítulo focado em cada uma dessas áreas e atividades. Mas o PMBOK é apenas um conjunto de práticas de gerenciamento de projetos, e não uma metodologia…

Read Full Post »

Vou falar um pouquinho sobre documentação de software, que muitas empresas fazem “demais” e muitas empresas não fazem nada… E como todo extremo… Não é bom.

Documentar demais é ruim pelo tempo que se gasta criando o documento, alterando, revisando e dando manutenção. Esse assunto manutenção é engraçado. Se você documentar um software, por mais completo e detalhado que esteja o documento, se este não acompanhar a evolução do sistema… Para que servirá? E outra, para quem servirá? E não documentar nada, dependendo da situação também pode ser um problema…

Sempre tive dúvidas quanto a documentação, mas no final de tudo, sempre me respondi a mesma coisa: “Documente o que for necessário”. E partindo deste princípio, cada empresa ou até mesmo cada projeto poderá gerar documentações diferentes, em momentos e para pessoas diferentes.

Por exemplo, quando algum desenvolvimento ou processo for muito complexo, vale a pena documentar. Use desenhos e fluxos simples para explicar o que deseja. Pontue os principais detalhes e informações em “tópicos” (uma ideia). Pode ajudar no debate sobre a ideia ou nas futuras manutenções.

Outro momento legal de documentar, mas aí vejo que é uma documentação mais “temporária”, são os esboços iniciais do projeto. Ideias, fluxos e “rabiscos” (feitos normalmente no quadro branco da sala de reunião) que terão uma seqüencia de debate. Mas não perca tempo, tire uma foto! (celular) Simples assim.

Algo que já senti muita dificuldade foi de “entender o processo”. Entendendo o processo, o código fica fácil. Um fluxo mesmo que macro do processo cairia bem. Ajuda também no momento que este processo precisar ser revisado e alterado. As mudanças sofrerão menos riscos.

E, por fim, outra “documentação” que eu acho que deveria ser uma documentação ESSENCIAL para todo projeto é algo parecido com WIKI. Já pensou que legal? Primeiro, se você alimentar esta Wiki com explicações referentes a cada mensagem de erro que o sistema possa mostrar para o usuário, já conseguirá explicar boa parte do seu sistema! Outra coisa que, cada dúvida que se torne frequente entre os usuários, pode ser postada ali, com uma explicação do processo, desenhos… Seria o primeiro nível de suporte ao usuário, e muitas vezes o suficiente! O grande “problema” é: Alguém precisa alimentar! Mas… Melhor que um documento sem valor, que fica amarelando na gaveta e “não serve pra ninguém”.

Ah, vai uma dica de “documentação ágil”: NÃO CRIE DOCUMENTAÇÃO COMO ÚNICA FORMA DE COMUNICAÇÃO. Prefira a face-a-face.

Read Full Post »

Porque é difícil dizer quando um projeto de software vai acabar? Essa é uma pergunta que se repete estranhamente, porque quem pergunta sabe que terá uma resposta furada e quem responde, sabe que quem perguntou não vai acreditar. Então… Porque perguntam sempre a mesma coisa?

Quando você termina isso? Quando se tratam de tarefas pontuais (e não muito grandes), não é muito difícil, até porque seria como estimar o peso de uma estória; mas e quando se tratar de um projeto? Me sentiria estranha se precisasse desprender grandes esforços para planejar tarefa por tarefa para enfim, entregar o “cronograma tão solicitado”. Bonito é, mas pode não ser eficiente. Então, é hora de pensar diferente!

Por um lado eu gosto de “datas”. Mas acho que “data” não é a melhor palavra… O que preciso é da ideia da complexidade do que foi solicitado e uma meta para alcançar. Ter uma entrega planejada motiva a equipe, evita que percam o foco e é possível analisar o andamento das atividades. Realmente é importante.

Mas venhamos e convenhamos, um projeto inteiro, do início ao fim, dentro de um cronograma? Atenção! Este projeto poderá sofrer alguns efeitos colaterais: Cliente insatisfeito, escopo com colesterol alto (muito gordo), risco de mudanças e “cronograma” atrasado. Não é o que buscamos.

Se metas são importantes, mas não é saudável travar o projeto e chutar datas, o que podemos fazer? SCRUM!

  1. Descobrir a velocidade da equipe (se não conhece, levará algumas Sprints até calibrar suas estimativas), estimar as estórias para saber quantas podem ser entregues no final de cada Sprint;
  2. Priorizar as estórias juntamente com o PO (“Solicitante”, digamos assim);
  3. Planejar as estórias da próxima Sprint (conforme o máximo de estórias que o time suporta para aquele período);
  4. Acompanhar as atividades da equipe através de reuniões diárias;
  5. Entregar valor no final de cada Sprint;
  6. Acompanhar as atividades do projeto através do gráfico BurnDown.
  7. […]

Tem-se muito mais que um cronograma totalmente “justificado”, alterado e em vermelho, através de metas, datas e planejamento de cada Sprint do Projeto.

Podemos ter informações (confiáveis) sobre:

  • Impedimentos do projeto;
  • Reais estimativas;
  • O que foi realizado até o momento;
  • Qual será a próxima entrega de valor;
  • COMO o projeto está ficando (na prática mesmo);
  • Status de cada Sprint;
  • […]

É possível entregar frequentemente aos que precisam dessas datas, Status Report detalhados e completos,…E impressionar pela transparência, informações confiáveis e VALOR sendo gerado sem grandes esperas.

Read Full Post »