for Agile Software Development e MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile e um mix de posicoes equilibradas, pois defende um SDLC (Software Development Life Cycle) mais curto com iteracoes de no maximo 4 semanas, contudo preserva a importancia dos papeis definidos previamente e abomina a linha "todo mundo pode fazer tudo no projeto". Outro quesito de destaque nesta fusao sao os testes unitarios e a preocupacao com a cobertura de 100% do codigo fonte.Um tema muito forte dentro do MSF Agile e integracao. Metodologias ageis nescessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto. Para isso sao constituidos cenarios de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor. Estes cenarios fazem parte de uma determinada iteracao do plano de iteracoes. Esta iteracao agrupa os cenarios de desenvolvedores e os cenarios de testes (que sao efetuados em seguida ao desenvolvimento). Desta forma controla-se a integracao de um time com papeis diversos dentro do projeto (usuario, desenvolvedor e analista de testes).Para o MSF, um projeto precisa dos seguintes papeis (entende-se papeis como responsabilidades que devem ser assumidas por algum membro da equipe):Program ManagerProduct ManagerUser ExperienceTesterDeveloperArchitectRelease ManagerE arduo afirmar que foi o fundamentador do MSF, porem o grande patrocinador sempre foi a propria Microsoft. Para nao ficar em branco com nomes, Michael Cusomano, Steve McConnell destacam-se entre muitos outros como personagens da historia do MSF.SCRUMSCRUM e um metodo de gerenciamento de software que pode ser usado com XP ou MSF. E baseado na teoria do controle empirico de processos e seus fundamentos sao originados na industria de manufatura japonesa. Ciclo de vida empirico e um ciclo baseado na observacao dos fatos. Muitos gerentes de projetos nao gostam do metodo reativo sugerido pelo SCRUM e preferem trabalhar com um planejamento que na minha leitura e um trabalho especulativo, pois tenta prever uma sequencia de atividades lineares. Por mais que o cronograma tenha um valor que e o planejamento previo, ou seja, pensar antes de sair fazendo, perde muito em tentar prever atividades distantes cheias de dependencias predecessoras e nao facilita o controle das mudancas de requisitos. Segundo o SCRUM, o desenvolvimento deve ser trabalhado em 3 niveis: Sprint, Release e Product.O ponto central e que os requisitos sao convertidos em uma lista que contem valores do cliente chamada Product Backlog. Um sub-conjunto desta lista e criado e chamado de Release Backlog. Este sub-conjunto e particionado mais uma vez transformando-se em Sprint, uma especie de acordo de desenvolvimento de funcionalidades que apos aceito pela equipe nao deve ser mais alterado. Praticando SCRUM, o que mais chama a atencao e a simplicidade. Controlar projetos desta forma e participar de um jogo competitivo e saudavel em que todos se auto-avaliam todos os dias (daily stand-up meeting) tornando possivel resultados e tecnicas de melhoria continua.O gerente de projetos como conhecemos hoje, na proposta SCRUM, e chamado de SCRUM Master. Suas principais responsabilidades resumem-se em duas: Proporcionar a passagem tecnica e retirar todos os impedimentos. A equipe do projeto e dividida em apenas 3 papeis: o SCRUM Master (coach), o Product