Blog CMMI & MPS.BR

Pergunta: Vemos um monte de discussões sobre desenvolvimento Ágil e por vezes fanáticos se envolvem e acrescentam um monte de neblina a essas discussões, tornando o assunto mais nebuloso ainda.

O “Manifesto Ágil” explica um pouco mas não existe uma definição clara que possa ser usada para esta tag, ou seja, continua um mito para a maioria de nós. Eu, por exemplo, acredito que Agile é uma palavra qualitativa que não deve ser usada para definir uma metodologia.

Resposta: Não á espaço suficiente para escrever algo que dê um pouco de sentido sobre o assunto, há muita coisa, mas vamos tentar passar um pouco.

“Agile” é um termo genérico que se refere a um conjunto disperso de métodos que incluem SCRUM, XP, Feature Driven Development e outros modelos iterativos e incrementais. Você esta correto quando fala que “nao é uma metodologia em si”.

Você frequentemente ouve descrições muito soltas como “confiança”, “iterativo”, “sem documentação” (essa é a mais comum), etc. Estes são os termos mais comuns para se “falar” sobre Agile, todavia como podemos perceber, são bastante nebulosas. Para ser mais preciso:

1- Métodos Agile são iterativos, onde o ciclo de vida completo do projeto (planejamento, requisitos, design, testes, código) acontece em ciclos de tempo de menor duração, tipicamente 30 dias ou menos. Essas atividades são geralmente não lineares, mas empíricas, e nem sempre ocorrem em uma sequencia específica.

2- Métodos Agile são incrementais, onde um pequeno conjunto de requisitos é desenvolvido, seguido pelo refinamento ou outro conjunto de requisitos. Os métodos Agile são contra o “Big Bang” e defendem o desenvolvimento de pedaços menores de cada vez (Dividir para conquistar).

Veja o post completo →

Em quase todo projeto de sistema, usa-se muito tempo em atividades de prototipação e situações como: “Coloca mais esse campo” ou “muda essa informação pra cá ou prá lá”.

As atividades relacionadas a protótipos normalmente iniciam-se após saber o que deverá ser feito (pelo menos deveria ser assim), ou seja, ter os requisitos aprovados. O processo ocorre mais ou menos assim:

• Aprova-se os requisitos
• Os requisitos documentados e enviados ao designer
• Este por sua vez monta os protótipos, wireframes ou mockups
• Leva-se os mesmos ao cliente para ver se é isso mesmo que ele quer
• E… aqui começa os problemas… essas idas e vindas vão longe. E o pior é que leva-se tempo porque o analista vai até o cliente, o cliente mostra o que quer mudar, o analista volta para a empresa e passa ao designer, após os ajustes, o analista volta e apresenta ao cliente as alterações… e… o ciclo pode se reiniciar com mais ajustes.

Bom… não é preciso dizer que isto leva tempo e conseqüentemente dinheiro.

Então… o que podemos fazer para agilizar esse processo?

Vamos imaginar um cenário hipotético onde o analista pudesse ir até o cliente e sair de lá com os protótipos já aprovados. Veja o post completo →

Sejamos sinceros! Fazer registros de reuniões e distribuí-los entre os participantes é uma tarefa nada empolgante. Para muitos é mera formalidade e não possui utilidade alguma. Não são em todas reuniões que faço registros como sugerido no Efetividade, em algumas apenas anoto as pendência e já saio me dedicando a elas, entretanto tem sido cada maior o número de reuniões que venho registrando. Principalmente porque encontrei uma forma bastante ágil de fazê-lo e que para mim tem sido muito útil.

Nas reuniões que conduzo, gosto muito de utilizar o quadro para fazer anotações das idéias e pontos importantes que surgem durante a reunião. É uma forma de garantir que não sejam esquecidos e também permite que todos presentes acompanhem visualmente a evolução da reunião. O que traz uma série de vantagens:

• Quando registro alguma idéia no quadro, os participantes validam na hora se minha percepção é fiel a idéia apresentada;
• No quadro é possível fazer desenhos, setas e rabiscos em diferentes cores, o que além de trazer uma melhor organização, dá uma certa dinâmica a reunião;
• Este dias ouvi uma piada em que Moisés alertava a Deus que se os 10 mandamentos fossem representados com diagramas e não leis textuais, talvez a humanidade tivesse os compreendido. Certas coisas são difícieis de transmitir em um texto, rabiscos e desenhos no quadro são muito representativos e podem transmitir algumas coisas com mais facilidade.

Porém muitas das informações representadas no quadro são perdidas nas atas formais. Talvez sejam necessário 3 parágrafos para detalhar uma idéia rabisca às pressa em uma lousa…

Hoje, graças ao advento das câmeras digitais é possível tirar fotos e em poucos minutos anexá-las em um documento e repassar aos participantes. Mesmo com celulares já é possível tirar fotos boas que permitam a releitura do quadro construído durante a reunão. Acreditem, voltar os olhos para uma foto do esquema original, criado para organizar as idéias, pode resgatar muitas informações que uma ata textual talvez não conseguiria! Fazendo uso deste recurso otimizei bastante meus registros.

Atualmente registro os participantes, local, objetivo e tópicos os mais importantes. Faço isso de uma forma bem branda, pois anexo as foto na ata. Dessa forma não há necessidade de digitar todos detalhes, uma vez que durante a reunião os tópicos importantes vão para o quadro e a foto traz um resumo bastante significativo sobre cada um.

Exemplo: Cópia tirada uma aula

Veja o post completo →

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Veja o post completo →

Para este mês estaremos montando um conjunto de dicas de coisas que devem ser feitas em cada um dos níveis do CMMI. Por ser muita coisa, estamos dividindo em blocos de aproximadamente 50 dicas. Ao todo esperamos postar mais de 300 dicas. Comentem!

Dicas gerais

1. Obtenha o patrocínio da alta direção – Esta é uma das coisas mais importantes!
2. Estruture o EPG logo no início
3. Estruture o Grupo de PPQA logo no início
4. Coloque como analista de PPQA pessoas muito experientes – normalmente seniores
5. Experiência de gerencia pode formar um excelente analista de PPQA
6. Implemente uma boa ferramenta de gerenciamento de configuração
7. Crie políticas para as PA’s coerentes com os objetivos de negócio
8. Garanta recursos e fundos para as atividades
9. Estabeleça processos padrão de desenvolvimento
10. Defina a estrutura da fábrica
11. Defina ciclos de vida de projetos
12. Estruture um framework de processos
13. Crie critérios para customização dos processos de desenvolvimento de projeto
14. Defina responsabilidades e forneça autoridade aos envolvidos
15. Treine todo mundo
16. Obtenha aprovação formal dos produtos
17. Obtenha o envolvimento e comprometimento de todos na organização
18. Leia o modelo – leia mesmo, de verdade. Se não entendeu algo, leia de novo e procure informações até entender o valor – lembre-se que tudo no CMMI tem valor, se você não esta vendo o valor é porque ainda não entendeu a PA
19. Se sua empresa compra muito serviços e projetos, avalie a implementação do CMMI para serviços (CMMI SVC)

Dicas de CM – Gestão de configuração

20. Planeje quais produtos serão mantidos em controle de configuração
21. Planeje as datas que os produtos passarão por baseline
22. Em configuração crie um ambiente de trabalho e um de baseline
23. Garanta segurança e integridade em ambos os ambientes
24. Faça auditorias independentes no ambiente de configuração para garantir que o processo esta sendo seguido
25. Documente todas as alterações nos produtos em baseline

Dicas de MA – Medição e análise

26. Especifique mecanismos para medições
27. Defina métricas alinhadas com os objetivos de negócio
28. Defina objetivos para os projetos
29. Defina objetivos organizacionais
30. Estabeleça um bom mecanismo de coleta e armazenamento de medições
31. Analise periodicamente os resultados das medições
32. Divulgue os resultados de medições
Veja o post completo →

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 →

A Imagem abaixo demonstra muito do que acontece atualmente em grande parte das organizações.

Alguns dos principais pontos relacionados à requisitos são:

1. Os requisitos devem ser documentados
2. Os requisitos devem ser aprovados
3. Os trabalhos devem ser aprovador
4. Eles devem estar sob gerência de configuração
5. Os requisitos somente podem sofrer alterações mediante análise de impacto, aprovação e replanejamento

Um ponto chave para reduzir problemas com comunicação é a formalização da mesma. Assim consegue-se mais envolvimento e comprometimento entre os envolvidos.