Blog CMMI & MPS.BR

Pergunta: Boa noite, gosto muito do seu blog, ele tem me ajudado muito.
Na empresa onde trabalho praticamos Agile em quase todos os projetos. A equipe é bem empenhada e a maioria dos nossos projetos vai bem. De uns tempos pra cá começamos a pensar em “certificar” ou no CMMI ou no MPS.Br e o que ajudou muito foi que a diretoria solicitou um estudo neste sentido.

Achamos alguns artigos falando do uso do Agile com CMMI, e alguns destes dizem que o Agile cola bem no CMMI chegando bem até o nível 3. Vi no seu site também um gráfico que mostra isso.

Agora vem as nossas perguntas:

1. Seguimos o Agile muito bem, como o Agile é bem aderente ao CMMI, podemos tomar como verdade que teremos poucos ajustes para conseguir o CMMI nível 3.
2. Da para ir direto para uma avaliação nível 3?
3. Temos pouco ou muito trabalho pela frente?
4. Quais os próximos passos que devemos seguir?

Pergunta de Mariana Catalone – São Paulo

Resposta: Olá Mariana, tive que resumir um pouco sua pergunta, mas a essência esta ai.
No passado havia muita muita discussão em torno de Agile com CMMI. Os agilistas de plantão viam o CMMI como oposto de sua cultura, porém, isso vem mudando e hoje em dia há muitas empresas que adaptam seus “métodos” Agile ao modelo CMMI. O ponto de mudança foi o artigo CMMI or Agile: Why not embrace both! publicado pelo SEI em 2008.

Veja o post completo →

Agir corretamente hoje não é só uma questão de consciência. É um dos quesitos fundamentais para quem quer ter uma carreira longa e respeitada. Em escolhas aparentemente simples, muitas carreiras brilhantes podem ser jogadas fora. Atualmente, mais do que nunca, a atitude dos profissionais em relação às questões éticas pode ser a diferença entre o seu sucesso e o seu fracasso. Basta um deslize, uma escorregadela, e pronto. A imagem do profissional ganha no mercado a mancha vermelha da desconfiança.

Ser ético é uma característica fundamental. Cada vez mais as organizações estão adotando o hábito de checar o passado dos candidatos a alguma vaga. Quem tem a ficha limpa sempre terá as portas abertas nas melhores empresas do mercado. Mas afinal, como é esse profissional?

Ser ético nada mais é do que agir direito, proceder bem, sem prejudicar os outros. É ser altruísta, é estar tranqüilo com a consciência pessoal. É também agir de acordo com os valores morais de uma determinada sociedade.

“Ética é a teoria ou ciência do comportamento moral dos homens em sociedade”.
Adolfo Vasquez

Qualquer decisão ética tem por trás um conjunto de valores fundamentais. Entre eles: ser honesto em qualquer situação, ter coragem para assumir decisões, ser tolerante e flexível, ser íntegro, educado, fiel, humilde e prudente.

Empresas não são apenas entidades jurídicas, elas são formadas por pessoas e só existem por causa delas. Por trás de qualquer decisão, de qualquer erro ou imprudência, estão seres de carne e osso. E são eles que vão viver as glórias ou os fracassos da organização. Quanto mais uma organização se destaca no mercado, mais se deve preocupar com as relações éticas. Errar é humano, mas falhas éticas destroem carreiras e organizações.

Veja o post completo →

Semana passada um comentário no Twitter me chamou muita atenção. O comentário era o mesmo do título deste post: “Alguém sabe se alguma empresa usa de verdade o MPS.Br?”.

Vamos desconsiderar o equivoco em uma pergunda como esta e entender o que é o tal do MPS.Br. Como vocês já devem saber, o MPS.Br é um modelo de melhoria de processos de software muito similar ao CMMI, mas criado e mantido por brasileiros (Softex).

E assim como o CMMI, o MPS.Br nada mais é do que um conjunto de boas práticas de engenharia de software e gestão. Ele fala o que deve ser feito, mas não como fazer, até porque cada empresa tem sua realidade e pode implementar uma determinada prática de um jeito. O plano do projeto por exemplo pode ser um doc, pode ser sistematizado, pode ser dividido em vários documentos e sistemas, enfim, pode ser do jeito que a empresa achar melhor, ela deve apenas seguir as recomendações que o MPS.Br pede.

Estas recomendações são boas práticas de engenharia de software e gestão, e a empresa pode implementa-las ou não, todavia, para obter o certificado MPS.Br nível X, a empresa deve implementar todas as práticas do nível que deseja. E esta implementação deve ser aprovada por um avaliador MPS.Br.

Agora que já tiramos algumas dúvidas, vamos responder a pergunta… O que você acha?
Alguma empresa usa de verdade o MPS.Br?

A resposta é objetiva. Claro que sim, aliás não apenas as “empresas avaliadas”.

Veja o post completo →

Uma das áreas mais importantes em Gerenciamento de Projetos é a Gestão da Comunicação. E pelo fato de ser uma das mais importantes, também é uma das grandes “vilãs” para o sucesso do projeto.

Todos nós sabemos que um projeto é formado por uma equipe de pessoas, sendo assim vem um grande problema: Como lidar com as diferenças de personalidades dessas pessoas? Como motivar essa equipe? Como gerenciar os conflitos, os interesses? Como se comunicar!

Esses são alguns dos problemas que encontramos quando trabalhamos com pessoas.

Normalmente em projeto de grande porte, existe um plano de comunicação bem elaborado e também pode haver um membro da equipe responsável para gerenciar a comunicação de todo o projeto.

É fato que em projetos menores muitas vezes a comunicação não é exercitada de maneira eficiente e nem um plano de comunicação existe. Por exemplo, na fase de levantamento de requisitos se não tivermos uma boa comunicação com os stakeholders, certamente não conseguiremos absorver e anotar as suas expectativas. Por outro lado se não conseguirmos sanar as dúvidas de um membro da equipe ou até mesmo deixar claro as suas responsabilidades no projeto, ou seja, o que ele deve entregar e como entregar.

Certamente esses dois casos irão ajudar muito para o fracasso do projeto. Isso é fato!

Existem algumas dicas e técnicas que podem nos ajudar:

Para Stakeholders:

• Na fase de levantamento de requisitos, crie uma planilha RTM – Requirements Traceability Matrix, onde você irá listar as expectativas do seu stakeholder e a sua influência no projeto;
• Ouça e escute o que ele tem a dizer, não influencie o mesmo para seus objetivos;
• Esclareça as suas dúvidas em relação às necessidades do mesmo;
• Após identificar o interesse do stakeholder temos que procurar trazê-lo para o projeto para ajudar, ou ao menos, para não atrapalhar o projeto;
• Se você é o líder do projeto, após identificar todas as expectativas do stakeholder converse com o Gerente de Projetos da organização para debater tais itens, esclarecendo todas as dúvidas que surgirem;

Para Equipe:
Veja o post completo →

Como é de conhecimento comum, um dos elementos chave para o sucesso de um projeto é a elaboração de um bom WBS (work breakdown structure ou em portugues, EAP). Com um bom WBS podemos controlar de forma mais efetivas os itens da tripla restrição (tempo, escopo e custo), mas ai vem aquela velha pergunta, até onde devemos decompor a WBS?

Devemos decompor a WBS em pacotes de trabalho até um nível que seja fácil de se gerenciar, mas… até que nível? Existem várias técnicas, várias regras, alguns gerentes recomendam pacotes de uma semana, 40 horas, 80 horas, 8 horas e outros. Enfim, não há uma regra definida, isso vai depender muito do tamanho, criticidade ou tipo do projeto, enfim… como será se controle.

Eu particularmente gosto de usar pacotes pequenos na maioria das vezes, especialmente em projetos mais críticos.

Cada pacote de trabalho deve ter:

• Esforço
• Prazo
• Responsável
• Custo
• Métrica que indique qualidade

Essa é uma boa forma de limitar sua WBS. Uma outra dica é sempre que tiver um pacote de trabalho faça as seguintes perguntas:

• Tem um responsável?
• O esforço foi estimado (ou da pra estimar)?
• Tem custo (ou da pra estimá-lo)?

Se todas essas perguntas tiverem resposta você pode continuar a decompor, caso contrário você pode parar e retornar ao nível superior.

Além disso você deve verificar a periodicidade com que o controle do projeto será realizado pois se você vai controlar suas baselines de custo, tempo e escopo mensalmente, qual o sentido de decompor os pacotes até o nível de horas? Por isso você deve ter em mente que a WBS não tem tamanho pré-fixado, mas dependerá do porte do seu projeto.

A ultima dica é que o custo para se gerenciar um pacote óbviamente não deve ser maior que o mesmo (nem metade ou 20% – sugiro no máximo 10%), afinal, o WBS deve nos ajudar no gerenciamento e não criar mais burocracia.

Muita gente acredita que “Código de Ética e de Conduta Profissional” seja uma das disciplinas do PMBOK. Estão enganados, pois não é! As nove disciplinas contidas no PMBOK são: gerenciamento do escopo, de riscos, de custos, da comunicação, dos recursos humanos, do tempo, da qualidade, de aquisições e gerenciamento da integração.

Em um primeiro momento, o fato do tema “Código de Ética e de Conduta Profissional” estar fora do PMBOK poderia causar entranheza ou algum tipo de desconforto aos leitores mal avisados, pois permite uma equivocada e precipitada conclusão de que o PMI estaria atribuindo baixa prioridade para assunto tão importante.Indiscutivelmente, a ética permeia todas as atividades de um gerente de projetos, para qualquer tipo de projeto, em qualquer uma das nove disciplinas mencionadas.

Na realidade, a ética está presente (ou deveria estar) no dia a dia de todas as pessoas, no exercício de nossas atividades profissionais ou pessoais, na escola, no trabalho, no clube, no trânsito, nos negócios, no cinema, na rua, enfim, a ética deveria ser o oxigênio levado a cada célula do organismo humano, dando-lhe vitalidade, saúde moral e direcionando as ações de empresários, políticos e cidadãos.

Retomando o tema de gerenciamento de projetos, em todas as nove áreas do conhecimento (disciplinas), a ética está presente. Por exemplo, no gerenciamento da comunicação, cabe ao gerente do projeto: elaborar/acompanhar o Plano de Comunicação do Projeto e distribuir a informação para os interessados no projeto. No entanto, é inerente à sua atuação nesta disciplina que ele seja ético, dizendo a verdade e sem postura de “omissão por conveniência” diante de situação desfavorável do projeto ou de seus resultados. De forma análoga, é responsabilidade do gerente de projeto no gerenciamento do escopo realizar a gestão dos requisitos do projeto, garantindo a entrega com qualidade nos prazos pactuados. Entretanto, do ponto de vista ético, o gerente deve deixar explícito, claro e documentado “o que o projeto faz e o que o projeto não faz”, evitando situações intencionalmente dúbias ou omissas. Há impasses em que muitos profissionais visando postergar a situação-problema alegam que “depois o cavalo fala…”.

Veja o post completo →

Em 1986 foi publicado um paper comparando a construção de pontes com a construção de software, como premissa foi utilizado:

• Pontes normalmente são entregues no prazo, dentro do orçamento e “não caem”
• Softwares raramente são entregues no prazo ou dentro do orçamento. E normalmente eles tem bugs.

Uma das maiores razões para o sucesso na construção de pontes é o alto nível de detalhe “em momento de design”. O “design” é congelado e o contratante tem pouquíssima flexibilidade de mudanças. Todavia, no mundo de negócios atual, este “congelamento” pode não acomodar as mudanças de negócio necessárias pelas empresas. Portando, um modelo mais flexível deve ser aplicado.

Mas também há outro elemento primordial a ser analisado entre a construção de pontes e construção de software. A construção de pontes é feita a pelo menos 3.000 anos. Quando uma ponte caia, as causas da queda eram investigadas, documentadas e disseminadas para que ninguém cometesse o mesmo erro novamente. Isto raramente acontece no desenvolvimento de software, onde as falhas são muitas vezes tratadas como causas normais e rotineiras e em sua grande maioria, são ignoradas. Como resultado, continuamos a cometer os mesmos erros que tínhamos na década passada (muda a linguagem ou o dispositivo, mas o erro é o mesmo).

Neste sentido, o foco da pesquisa do The Standish Group foi identificar:

• As falhas dos projetos de software
• Os maiores fatores que influenciam na falha de projetos de software
• Os pontos chave que podem reduzir estas falhas

Os Estados Unidos gastam mais de 250 bilhões de dólares cada ano no desenvolvimento de aproximadamente 175.000 projetos de software. O custo médio de um projeto em uma grande empresa americana é de 2.3 milhões de dólares, para uma empresa média é de 1.4 milhões d dólares e 434 mil dólares para uma empresa pequena. E a grande maioria destes projetos falha. Os projetos de desenvolvimento de software estão no caos.

O estudo classificou os projetos em três tipos:

• Sucesso: Projeto dentro do prazo, dentro do orçamento e com boa parte do escopo
• Sucesso parcial: Projeto funcionando, mas entregue sem atender ou custo, ou esforço ou com o escopo parcial
• Fracassos: Projetos cancelados ou não utilizados

Sua última revisão (2009) mostrava que:

• 24% dos projetos fracassam
• 44% dos projetos são entregues com sucesso parcial
• E apenas 32% dos projetos obtêm sucesso.

Veja o post completo →

A busca pela atração de talentos tornou-se uma constante preocupação das empresas. No entanto, de tanto olharem para “fora” dos seus portões, há organizações que se esquecem de pensar em como reter os profissionais que formam suas equipes e fazem o diferencial para o seu negócio. Ao contrário do que muitos pensam, não é apenas um salário tentador que motiva o colaborador a vestir a camisa da companhia. Hoje, os profissionais estão mais seletivos e não querem ser considerados apenas números na folha de pagamento. Confira abaixo alguns fatores que listei, a partir de inúmeras conversas que já mantive com profissionais que atuam na área de Gestão de Pessoas.

1 – A empresa precisa ter ciência dos seus pontos fortes como também dos processos que precisam ser melhorados. Dessa forma, poderá atender tanto às suas necessidades quanto às expectativas dos colaboradores. Para isso, uma ótima ferramenta é a aplicação periódica da pesquisa de clima organizacional.

2 – Quem deixa de falar e de se expressar, nunca será entendido. Da mesma forma que ocorre com as pessoas, as organizações devem saber se comunicar tanto com o público externo quanto o interno. Uma boa política de comunicação interna faz com que a empresa ganhe credibilidade junto aos funcionários e esses, por sinal, darão preferência a escutar os canais de comunicação da empresa do que se deixarem levar por boatos.

3 – O processo de feedback, desde que conduzido corretamente, torna-se um recurso valioso para a Gestão de Pessoas. Isso porque através dele, o colaborador sabe o que a empresa espera dele e quais as competências que precisa desenvolver ou aperfeiçoar para ter um bom desempenho e até mesmo superar as expectativas desejadas.

4 – Não há talento que deseje manter-se parado e é por esse motivo que, cada vez mais as empresas investem no planejamento de carreira, uma vez que esse dá um norte, um direcionamento à ascensão do profissional.

5 – Trabalhar sentindo-se isolado é jogar um banho de água fria, melhor, geladíssima em qualquer um. Quem possui detém conhecimento precisa disseminá-lo e adquirir novas competências, sejam técnicas ou comportamentais. Isso requer trabalhar num local onde as pessoas valorizem o espírito de equipe.

6 – Tudo em excesso torna-se veneno. Isso também vale para o trabalho. Pessoas que se tornam workaholics – viciados no trabalho tendem a cair no grau de estresse perigoso. Não é à toa que as empresas investem em ações focadas na melhoria da qualidade de vida dos profissionais.

Veja o post completo →

Pergunta: Nós não temos nenhum processo definido para DAR. Queremos atingir o CMMI 3, mas para isso temos que começar do zero. O que fazemos para dar certo? Podemos ter uma política e um processo orientando no uso de DAR e integrar este processo ao desenvolvimento do produto? Que ferramentas podemos usar para facilitar o uso de DAR?

Resposta: DAR, ou mais especificamente a área de processo Análise de Decisão e Resolução, é uma área de processo do CMMI 3 e seu objetivo é nos ajudar a tomar decisões complexas durante períodos de estresse ou caos. É um processo estruturado, que utiliza orientações e critérios para a tomada de decisões que poderiam ser impulsionadas pela emoção, custo ou favores de fornecedores (como “presentes”, ingressos ou até mesmo dinheiro).

DAR é iniciado através das diretrizes que determinam quando usar DAR. Então, existem critérios e métodos definidos para ajuda-lo na tomada de decisões.

Como as outras áreas de processo do CMMI, é perfeitamente possível (e fácil) integra-lo em seus processos de desenvolvimento de software. Na verdade, a PA TS – Solução Técnica consegue obter benefícios de DAR logo nos primeiros estágios. Não apenas TI tem vantagens de DAR – ela pode ser utilizada em praticamente todo procesos de decisão crítico.

Você pode iniciar com simples planilhas com padrões de orientações e critérios, e a partir desta definição, pontuar e selecionar a maior. Com o tempo, mais maturidade será alcançada e seu processo evoluirá e no futuro você terá uma biblioteca de de Decisões para que você possa reutiliza-las em seus projetos.
Veja o post completo →

Apesar da percepção de que as melhores prática do CMMI e do Agile são opostas um com o outros, recentes pesquisas apontam justamente o oposto. O fato é que as organizações podem se beneficiar de ambos os modelos e melhorar significantemente o desempenho.

No final de 2008, o SEI publicou um artigo intitulado “Agile ou CMMI: Por que não abraçar os dois?. Este relatório foi escrito pela equipe do SEI e industria. Como sabemos, CMMI e Agile usam métodos diferentes para se realizar o mesmo trabalho, e como já era de se esperar, ambos tem suas comunidades e seguidores. Mike Konrad, um membro senior da equipe do SEI, concorda e afirma que a tendência natural é formar “novos feudos” ao redor de método diferentes (e normalmente novos). No entanto, de acordo com o relatório, esta ação não é saudável para a profissão de Engenharia de Software.

“Como ambas as comunidades continuavam a aumentar, parecia ser o momento certo para abordar esta questão”. Explica Konrad. “Além dodisso, foi uma excelente oportunidade para nós do SEI dissipar alguns mitos e ajustar nosso entendimento.”

O aumento na adoção de CMMI e Agile aconteceu através de diversos fatores. Por exemplo, a adoção do CMMI normalmente vem de uma necessidade de negócios (como aumento de qualidade e produtividade), ou seja, vem de cima pra baixo, enquanto no Agile as coisas acontecem de forma mais flat. Desta forma, era inevitável o cruzamento de ambos os modelos já que a aprovação vinha aumentando.

Veja o post completo →

O Carnegie Mellon Software Engineering Institute ou simplesmente SEI é (podemos dizer) um centro de pesquisa e desenvolvimento com sede no campus da universidade Carnegie Mellon em Pittsburgh nos Estados Unidos. O SEI também tem escritórios em Arlington, Virginia, e Frankfurt na Alemanha. A maior parte dos recursos recebidos do SEI vem do departamento de defesa dos Americano.

O SEI também tem uma relação estreita com a industria e meio acadêmico através de pesquisa e colaborações.
As três principais áreas de atuação que são:

• Práticas de gestão
• Práticas de engenharia de software
• Práticas de aquisição

História do SEI

Desde 1984, o SEI tem por objetivo servir como um provedor global em engenharia de software e melhoria de processos como um todo. Com o tempo o SEI se tornou a maior autoridade mundial em práticas de engenharia de software através de seu principal programa (CMMI) que permitem as organizações melhorar seus processos e com isso conseguir mais qualidade com um custo menor e com previsibilidade.

Nos últimos anos a importância do software nas organizações tem se tornado maior e mais crítica, desta forma não apenas os Sistemas de Defesa precisam de softwares mais precisos e com qualidade como também empresas de transporte, finanças, medicina, entretenimento, enfim, praticamente todas as áreas de negócio.

O SEI têm contribuído com este crescimento em várias áreas, incluindo:

• Melhoria de processos de software
• Segurança de rede
• Arquitetura de software
• Linhas de produto de software
• Aquisições
• Atendimento a serviços
• Qualidade
• Desenvolvimento pessoal
• Previsibilidade

Áreas de trabalho

O SEI define iniciativas específicas destinadas a resolver os problemas que impedem a maturidade e capacidade das organizações para adquirir, construir e desenvolver sistemas previsivelmente no prazo, dentro do custo esperado, atendendo os requisitos e sem vulnerabilidade.

Práticas de gestão

Veja o post completo →