Posts Tagged ‘ mudanças ’

Entendendo a Gerência de Configuração 21 June 2010 as 9:04 pm de Washington Souza

Uma coisa é certa em todos os projetos: “as coisas mudam”. Os requisitos podem mudar, o usuário pode melhorar seu entendimento sobre um determinado requisito e solicitar mudanças. O ambiente pode mudar, novas leis podem fazer com que o sistema mude e até mesmo a troca do usuário pode fazer com que as coisas mudem. Com tantas mudanças, se nada for feito o sistema pode naufragar. Para isto, tanto o CMMI quanto o MPS.Br possuem uma área de processo para endereçar este assunto, a Gerência de Configuração.

A gerência de configuração (GC) é um conjunto de atividades que permite as mudanças no projeto de forma controlada, mantendo a estabilidade no decorrer do mesmo.

A gerência de configuração é extremamente importante em um projeto, é por isso que diversos modelos de qualidade e maturidade como ISO, CMMI, MPS.Br e SPICE dão tanto valor à esta disciplina.

O CMMI define que GC deve:

  • Identificar os produtos que serão mantidos sob controle de configuração
    Normalmente são mantidos os principais produtos de um projeto como documentos de proposta, planejamento, cronograma, especificações, código e outros.
    .
  • Definir um sistema de gestão de configuração
    Um sistema de gestão vai desde o processo até a definição de uma ferramenta de configuração, uma boa ferramenta de gestão pode economizar muito trabalho no processo de gerenciamento de configuração, o Sharepoint é bom no gerenciamento de configuração de documentos, mas não atende bem a parte de código. O código por sua vez é muito bem controlado no SVN e este por sua vez não se da muito bem com documentos, mas existem mais de 50 ferramentas com este propósito.
    .
  • Manter seus baselines
    O baseline é uma versão de um produto ou conjunto de produtos. Se toda a parte de requisitos do módulo de gestão já esta aprovada, pode-se gerar um baseline destes produtos e caso seja necessária alguma alteração, muda-se a versão do baseline (após passar por todo o processo).
    .
  • Acompanhar e controlar as solicitações de mudanças
    Este é o principal motivo da existência da gerência de configuração. Mudanças vem de toda parte, desde o usuário até a sua equipe, e estas mudanças devem passar por um processo de viabilidade, análise de impacto e aprovação formal. Todas as mudanças devem ser documentadas e de fácil acesso.
    .
  • Registrar todas as alterações realizadas nos produtos
    Uma vez realizada uma alteração em um produto, esta deve ser documentada e colocada novamente em baseline (após aprovação). Uma boa prática é descrever a alteração sempre que um produto for movimentado.
    .
  • Leia o post completo →

+ Tutorial mini projeto parte 3 – Mudanças de escopo e impacto Por Washington Souza 14 January 2010 as 10:49 pm Nenhum comentário

Continuado a série de mini tutoriais de projeto, no ultimo post realizamos o dimensionamento do projeto e chegamos ao custo de R$ 8.400,00 em 210 horas.

Agora vamos compreender o impacto das mudanças.

Nota: Neste momento, você praticamente finalizou o projeto e esta validando-o com seu amigo.

Nosso projeto é uma pequena tela de cadastro de contatos e ao entrega-la ao seu cliente (seu amigo). Ele gosta tanto que mostra ao seu chefe, que também gosta muito do sistema e tem a idéia de implementar em toda empresa.

Você comenta que teria que fazer várias mudanças mas ele comenta que quer “do jeito que esta” não precisa mudar nada – Ele gostaria apenas que selecionasse a filial (ele tem 10 filiais) antes de ver os contatos. Esta solicitação vem junto com a frase “É fácil… é só uma tabelinha”.

Seguindo a mesma linha de dimensionamento que usamos, vamos então colocar:

+ Um arquivo interno
+ Uma entrada externa

O arquivo interno equivale à 10PFs e a entrada equivale à 4PFs, totalizando assim 14 pontos por função. Aplicando novamente a mesma produtividade utilizada anteriormente teremos 98 horas. Então podemos dizer que “a tabelinha” vai demandar mais 98h de trabalho em um projeto de 210h. Em outras palavras, seu amigo que já pagou R$ 8.400,00 pelo sistema terá que pagar mais R$ 3.920,00 por essa mudança.
Veja o post completo →

+ Entendendo o gerenciamento de mudanças Por Washington Souza 14 April 2009 as 3:37 pm 9 comentários

Pesquisas apontam que pelo menos metade dos fracassos em projetos de TI vem da falta de gerenciamento de escopo.

Simplificando, o escopo do projeto, nada mais é do que o que foi combinado fazer.

Vamos à uma analogia: Preciso trocar os pneus do meu carro. Faço um levantamento dos produtos e serviços necessários e verifico que precisarei de:
- Quatro pneus [Produto]
- Troca dos mesmos [Serviço]
- Alinhamento [Serviço]
- Balanceamento [Serviço]

Bom, este é o escopo deste meu projeto “Trocar Pneu” e devo fazer uma gestão efetiva deste escopo, para não gastar mais que o previsto.

Vou na loja, faço o pedido e aguardo. Após meia hora o vendedor (que obviamente quer vender) me fala que seria bom eu trocar os amortecedores também porque estão ruins. Vamos parar um pouco neste ponto.

Trocar os amortecedores tem custo e o vendedor vai cobrar com certeza. Esta troca esta fora do meu escopo inicial e devo decidir se mudarei o escopo ou não.

Reparem que quem decide sou eu, só que esta decisão traz impacto (aumento do custo). Será que vai adiantar alguma coisa se eu chegar ao vendedor e “espernear” falando que isto estava “sub-entendido” na troca e por isso não vou pagar? Com certeza não. Eu ficaria muito feliz se ele fizesse isto de graça, mas isto não vai acontecer pois tem custo pra ele.

Voltando, decido por não trocar pois esta fora do meu escopo inicial e isto ultrapassará o valor que eu tinha previsto.

Se coloquem agora no lugar do vendedor (que é o nosso!) e simulem a mesma situação. Vocês dariam os amortecedores ao cliente?

É isto que não se pode fazer (dar algo não combinado), temos sim é que cumprir o escopo previsto em nossos projetos e sempre posicionar o cliente de possíveis necessidades de mudanças.
Mas lembrando, o escopo não muda, a não ser que alguém permita.
O Gerente do projeto deve sempre ser firme e demonstrar os impactos (esforço, custo, prazo, etc) e nunca permitir o aumento sem que o cliente concorde com os impactos (formalmente). Comunicação é primordial.

Você deve tratar os custos (estimativas em geral) dos projetos como se este dinheiro fosse sair do seu próprio bolso.

Em tempo: Alguns pontos ajudam muito a “definir o escopo” como:
- Uma proposta comercial bem elaborada;
- Deixar claro o que será feito e o que será entregue (tudo);
- Deixar claro o que não será feito;
- Deixar claro suas responsabilidades e as do seu cliente;
- Estimar com uma técnica segura sempre que possível – recomendo APF (melhora significativamente a acertividade);
- Fazer um bom planejamento e gerenciar de verdade o projeto;

Fazendo isto sempre em seus projetos, além de reduzir considerávelmente suas dores de cabeça com o projeto você também estará atendendo boa parte da parte de engenharia do CMMI

Veja o post completo →


Monetizado com WP-HOTWords.