CMMI Brasil - Novo Grupo de Discussão!

Devido à decisão de fechar o grupo CMM-Brasil, feita pelo fundador, criei um novo grupo de nome CMMI-Brasil para continuar as discussões e os debates que ocorriam na antiga lista.

Ele possui o mesmo escopo do anterior, que é ser um grupo criado para troca de experiências entre profissionais que trabalham com modelos de maturidade e processos de desenvolvimento de software. O tema de interesse do grupo é ligado a modelos, padrões e processos que possuam aceitação internacional, como CMMI, MPS.BR, ITIL, SPICE, RUP, Metodologias Ágeis, SWEBOK, PRINCE2 e Guia PMBOK do PMI, séries ISO, etc. A participação é aberta a todos interessados ou envolvidos profissionalmente com exportação e modelos de melhoria de processos de software, bem como gerenciamento de projetos.

Aproveite e junte-se a nós para gerar e compartilhar conhecimentos sobre essa área tão vasta. Acesse a página do CMMI-Brasil e faça seu cadastro!

Planejamento ágil - reuniões para definição de releases e iterações

Na lista de discussões scrum-brasil surgiram algumas dúvidas relativas a aspectos do processo de planejamento de releases (versões) e sprints (ou iterações).

Dúvidas:

1 - Na reunião de planejamento de um release, se o time não se sentir confortável com suas estimativas em pontos, o time pode já quebrar as estórias em tarefas - e estimar essas tarefas em horas ?

2 - Na reunião de planejamento de sprints ou iterações, é necessário que todas as tarefas sejam atribuídas a algum membro já na ? Ou podemos apenas atribuir um conjunto inicial pequeno de tarefas e depois a medida que as tarefas forem sendo encerradas, o membro escolhe qualquer tarefa que ainda não tenha "dono"?

Minhas respostas (lembrando que essas dicas valem para os principais processos ágeis como Scrum, Extreme Programming, Crystal Clear e OpenUP):

1 - A estimativa em pontos é feita no Release Planning. Se no Release Planning eles não se sentem confortáveis para estimar uma estória ou item isso pode significar que: 1 - a estória é muito grande; 2 - Há muitas dúvidas e pontos nebulosos.

2 - As tarefas (tasks) não precisam ser TODAS distribuídas nessa reunião. Elas precisam ser estimadas, mas não alocadas a desenvolvedores específicos. Usualmente os desenvolvedores selecionam uma ou, no máximo, duas tarefas para iniciar a iteração. Essa alocação de tarefas continua ocorrendo, usualmente nos daily stand-up meetings (reuniões diárias em pé). Lembrando que são os desenvolvedores que se alocam nas tarefas. Eles não são alocados por alguém de nível gerencial.

As tarefas não devem ser distribuídas pela equipe durante a reunião de planejamento do sprint por um simples motivo: fazendo isso você está achando que identificou todas as tarefas da iteração e isso não será nunca realidade. Novas tarefas aparecem. Tarefas existentes precisam se dividir em duas ou mais, etc. O modelo comando e controle não ocorrerá porque os próprios desenvolvedores escolherão quais tarefas farão durante os daily stand-up meetings e APENAS após terem completado uma tarefa anterior.

Para corroborar ainda mais minha afirmação cito o excelente e crucial livro "Agile Estimating and Planning" (recomendo a todos que estejam usando Scrum, XP, OpenUP ou outro processo ágil que contenha Release Planning e Iteration Plannings que leiam o livro. Diria até que é leitura obrigatória!!!) do Mike Cohn:

Subtítulo "Tasks are not allocated during iteration planning" na página 147 capítulo 14: "Enquanto se planeja a iteração, tarefas não são alocadas a indivíduos específicos. No início da iteração, pode parecer óbvio quem irá trabalhar em uma tarefa específica. Porém, baseado no progresso de todo o time no conjunto das tarefas, o que é óbvio no início pode não ser o que acontece durante a iteração. Indivíduos não escolhem as tarefas em que vão trabalhar até que a iteração inicie e geralmente só escolhem uma ou duas tarefas relacionadas por vez. Novas tarefas não são iniciadas até que as previamente selecionadas sejam completadas. Não há nada a ganhar e muito a perder ao alocar indivíduos a tarefas específicas durante o planejamento da iteração."

Resenha do livro Head First Software Development da O'Reilly

O livro Head First Software Development, da O'Reilly, segue o mesmo padrão de conteúdo da série Head First: uso de imagens, análise de exemplos reais e simulados para ajudar no entendimento dos tópicos considerados, utilização de exercícios como: palavras cruzadas, preenchimento de lacunas, sessões de perguntas e respostas. Tudo com o intuito de reforçar conceitos estudados em um capítulo.

O livro possui uma meta ousada: Ensinar melhores práticas, técnicas e princípios para um ótimo processo de desenvolvimento de software e mostrar como é o ciclo de vida do desenvolvimento de software.

Os autores optaram claramente por demonstrar neste livro uma abordagem ágil para o desenvolvimento de software. O grande diferencial do livro é seu aspecto lúdico e divertido, o que facilita a leitura.

A seguir o conteúdo de cada capítulo:

1. Great Software Development
2. Gathering Requirements
3. Project Planning
4. User Stories and Tasks
5. Good-enough Design
6. Version Control
7. Testing and Continuous Integration
8. Test-Driven Development
9. Ending an Iteration
10. The Next Iteration
11. Bugs
12. The Real World
Appendix A. Leftovers
Section A.1. #1. UML class diagrams
Section A.2. #2. Sequence diagrams
Section A.3. #3. User stories and use cases
Section A.4. #4. System tests vs. unit tests
Section A.5. #5. Refactoring
Appendix B. techniques and principles
Section B.1. Development Techniques
Section B.2. Development Principles

É interessante notar que também existe um bom tratamento sobre as ferramentas básicas para a montagem de um bom ambiente colaborativo de desenvolvimento nos capítulos 6 e 7. No capítulo 5 encontramos uma breve exploração de conceitos relacionados a design (projeto) e refactoring de software.

Eu, particularmente, já conhecia todas as técnicas mostradas por eles e que são tratadas em diversos outros livros sobre processos ágeis. Recomendo fortemente para pessoas que querem conhecer mais sobre desenvolvimento ágil (e ainda possuem muitas dúvidas) e também para profissionais experientes que desejam ler um livro com uma abordagem mais interessante e diferenciada.

O livro também é muito recomendável para uso em disciplinas de Engenharia de Software, Processos de Desenvolvimento de Software e em treinamentos de métodos ágeis. Seus fortes aspectos didáticos auxiliam no entendimento de todos os tópicos abordados, seus relacionamentos e sua importância para o desenvolvimento de softwares.

Integração entre RUP e PMBOK: Como conciliar?

Pergunta endereçada por email para mim (o colega deu a permissão de publicá-la):

Sou professor e estou orientando 5 TCC's - Trabalho de Conclusão de Curso, todos voltados para Governança de TI. Um deles tem como tema Gestão de Projeto de Desenvolvimento de Software, em Processo Incremental (RUP), utilizando PMBOK. Este trabalho pesquisa uma solução para a dificuldade de compatibilização desses frameworks, uma vez que os mesmos são os mais utilizados para desenvolvimento e gestão do projeto.

Para ficar mais claro, transcrevo alguns trechos do trabalho .Na contextualização falamos :" ..Embora freqüentemente utilizadas em projetos de desenvolvimento de software, essas duas metodologias apresentam uma grande dificuldade para serem utilizadas em conjunto. Enquanto o RUP utiliza um modelo que busca a construção de um software através de sucessivas iterações (modelo espiral incremental), ou seja, a seqüência de desenvolvimento vai se repetindo em ciclos sucessivos, o PMBOK parte do princípio que as atividades ocorrerão de forma seqüencial e sem repetições..."

Entretanto, quando da elaboração do orçamento de um projeto, dois dos requisitos indispensáveis são : Custo e Prazo . Ora, como determinar custo e prazo antecipadamente se a priori não sei quantas iterações terei que fazer no processo de desenvolvimento ? Como compatibilizar o gerenciamento de um projeto com PMBOK se o processo é RUP ?

Minha resposta:

Em relação à contextualização tenho uma crítica: o PMBOK não diz que obrigatoriamente o projeto será feito de forma sequencial. Ele define a importância e o formato do "rolling-wave planning" e da "progressive elaboration" que nada mais é que um ciclo iterativo e incremental. Apesar de falar pouco sobre isso o "rolling-wave planning" e a "progressive elaboration" constam da 3a. edição do PMBOK. Sobre a questão de custo e prazo posso adiantar que esse problema ocorre quando o cliente deseja um projeto de preço e prazo fechado. Há várias maneiras de resolver isso e tenho uma palestra que trata do assunto e que ministrei para o PMI-SP.

Outros dados mais detalhados podem ser encontrados nos livros do Craig Larman - Agile and Iterative Development, A Manager's Guide - e do Mike Cohn - Agile Estimating and Planning.

Posso resumir dizendo que não há nenhuma incompatibilidade entre RUP e PMBOK. Termos diferentes são usados para descrever conceitos similares nos dois. Mas nada no RUP contradiz o PMBOK e vice-versa. Portanto, se um Gerente de Projetos estiver usando a disciplina de gestão de projetos do RUP ele estará aderente também às práticas do PMBOK. Há duas áreas pouco tratadas no RUP e que podem ser alavancadas com o PMBOK: Gestão de Aquisições e Gestão de Custos. Para maiores detalhes dessa conclusão vide o artigo "A Mapping between PMBOK and RUP".

Portanto, use a disciplina de gestão de projetos do RUP. Ela é aderente ao PMBOK. E se tiver necessidade de alguma boa prática extra então avalie o que tem no PMBOK e customize a disciplina de Gestão de Projetos do RUP. Não caia na armadilha de substituir a getão de projetos do RUP, pois você correrá o risco de destruir o principal princípio do Rational Unified Process: Realizar desenvolvimento iterativo e incremental.

Esforco das Atividades de Gerência de Projetos para Desenvolvimento de Software

Minha resposta sobre o assunto, a partir de pergunta no grupo CMM-Brasil:

O esforço da gestão pode variar bastante e principalmente de acordo com a complexidade, a quantidade de riscos do projeto, o número de stakeholders, etc.

De acordo com uma tabela do COCOMO II, modificada por Bittner e Spence no livro "Managing Iterative Software Development Projects", para o RUP, temos que se gasta em média para a gestão:

14% do esforço da fase de iniciação

12% do esforço da fase de elaboração

10% do esforço da fase de construção

14% do esforço da fase de transição

Portanto, podemos dizer que a média de esforço em gestão é de 10 a 15% do total de esforço do projeto.

PodCast de José Papo sobre RUP e OpenUP

RUP pode ser ágil - Podcast e explicação abaixo produzidos por Vinícius Teles

RUP pode ser ágil, ao contrário do que muitos acreditam. Isso é que nos explica José Paulo Papo no Improvecast número 20. José Papo trabalha com implantação de processos e gerência de projetos. Além disso, é professor de Engenharia de Software, de Lógica de Programação e de RUP e OpenUP.

Um dos destaques desse podcast foi a evolução do RUP nos últimos anos, no sentido de adotar princípios alinhados com os do Manifesto Ágil. Outro assunto interessante é o surgimento do OpenUP. Conversamos também sobre os seguintes assuntos:

Como e quando foi seu primeiro contato com abordagens ágeis de desenvolvimento de software?
O que mais chamou sua atenção nessas abordagens?
Que tipo de problemas você tinha antes de adotar tais abordagens?
Que tipo de uso prático você vem fazendo das metodologias ágeis atualmente? Você utiliza alguma ou algumas delas em seu trabalho?
Que práticas ágeis você mais utiliza atualmente?
Quais você considera mais fáceis?
Quais são as mais difíceis?
O que é o OpenUP?
Como você enquadra o OpenUP em relação às metodologias ágeis de desenvolvimento de software?
Na sua atuação como professor universitário, você ensina abordagens ágeis de desenvolvimento?
Pelo que você tem observado, as universidades estão começando a ensinar metodologias ágeis, ou ainda estão baseadas apenas nos modelos tradicionais de desenvolvimento de software?
Como você está vendo a evolução da adoção de métodos ágeis aqui no Brasil?
Quais são seus planos para o futuro, na área de desenvolvimento ágil?

Novas ferramentas livres para gestão ágil de projetos: Mingle e ProjectKoach

Duas novas ferramentas para gerenciamento ágil de projetos foram lançadas no mercado.

A ferramenta ProjectKoach é uma ferramenta leve e gratuita feita especialmente para gerenciar projetos usando o processo OpenUP 1.0. Com a ferramenta ProjectKoach você pode:

- planejar projetos
- gerenciar iterações
- Medir a velocidade da equipe
- Rastrear itens de trabalho a requisitos e outros itens
- Integração com o processo OpenUP e facilidades de editar o processo e alterar também a ferramenta automaticamente
- Guias de processo para analistas e desenvolvedores, que explicam em detalhes as tarefas alocadas.

A única funcionalidade que eu acho que ainda é necessária na ferramenta é a integração com ferramentas de controle de versões como Subversion, CVS, IBM Rational ClearCase, etc.

Vide abaixo uma figura da tela principal da ferramenta:


Faça o download do ProjectKoach e experimente a ferramenta! Você precisa apenas de um JDK do Java. Ela pode se tornar um excelente apoio ao seu projeto e, ainda melhor, sem custo!!!

A ferramenta Mingle foi desenvolvida pela famosa consultoria de projetos ágeis americana ThoughtWorks. Ela é gratuita para até 5 usuários. A partir do sexto usuário deve ser paga uma taxa de licenciamento conforme a tabela de preços.

A ferramenta Mingle está atualmente bem mais completa que o ProjectKoach, porém tem um custo após o sexto usuário. Ela inclusive possue integração com ferramentas de controle de versões e integração entre requisitos, casos de teste, defeitos e riscos.

Uma outra excelente funcionalidade é a capacidade de visualizar os requisitos e tarefas no Mingle como cartões na tela. Vide a imagem de exemplo abaixo:


Faça o download do Mingle e experimente a ferramenta! Você precisa ter o banco de dados MySQL 5 instalado.

Incrementos executáveis no RUP ( Rational Unified Process ) e validação de clientes

Pergunta surgida na lista RUP Brasil:

Na fase de construção do RUP ( Rational Unified Process ), cada iteração produz uma versão executável do sistema que adiciona funcionalidades ou melhora as funcionalidades disponibilizadas em uma iteração anterior? Ao fim da iteração, a versão executável do sistema é entregue ao cliente (para que ele possa fazer uso do sistema o mais rápido possível, bem como validar o produto e fornecer feedback sobre o sistema para iterações posteriores) ou o usuário só recebe o produto na fase de transição?Caso as duas abordagens sejam possíveis (entregar os incrementos já na fase de construção ou esperar pela fase de transição e entregar tudo), qual delas é a mais recomendável? E o que costuma ser feito na prática?

Minha resposta:

Cada iteração do RUP ( Rational Unified Process ) em princípio deve produzir algum software. Mesmo as iterações da fase de iniciação podem produzir protótipos de interface gráfica e/ou protótipos arquiteturais.

O software que é produzido a cada iteração pode ou não ser entregue. Se ele for entregue a cada iteração significa que você está adptando o RUP para um modelo chamado "Entrega Incremental". Vide um artigo de meu blog que mostra alguns possíveis Managing Iterative Software Development Projects de Bittner e Spence.

Planejamento das Iterações e Fases do RUP e do OpenUP/Basic

Coloco aqui minha resposta à uma pergunta surgida no grupo RUP Brasil. A pergunta é: Como se faz o planejamento das iterações no RUP (e no OpenUP e OpenUP/Basic) para se ter uma idéia do projeto todo? É realizado um levantamento de requisitos, desenhados todos os casos de uso, e a medida que as iterações vão sendo concluídas eu defino quais casos de uso serão implementados?

Faço um planejamento inicial a longo prazo distribuindo os casos de uso nas iterações e no curto prazo revejo esse planejamento, no sentido de verificar se o que planejei eu cumpri e então definir o que fazer na próxima iteração?

O tamanho de uma iteração, tempo e duração seria de duas semanas? Se eu tiver uma rotina batch por exemplo, um MRP, uma rotina de fechamento que leve mais de uma iteração. Como quebrar isso?

Resposta de José Papo (eu mesmo :-) !!!):

Não se levantam todos os requisitos para depois começar a planejar o projeto. A maior parte dos requisitos (não todos pois o restante será levantado na fase de Construção) estarão definidos (cerca de 80% de acordo com o RUP) no final da última iteração da fase de Elaboração. A fase de Iniciação irá gerar um escopo e estimativa macro e também um plano de projeto macro. Somente no final da fase de Elaboração(com 80% dos requisitos levantados e uma arquitetura executável criada) haverá uma estimativa mais confiável (com 25% de variação). Recomendo minhas aulas sobre planejamento de projetos iterativos que disponibilizei em meu site Erudio.

Vide especialmente as aulas 4 e 5 da disciplina de RUP e Processos Iterativos.

Segundo o RUP uma iteração pode ter de 2 a 6 semanas, de acordo com a necessidade do projeto. Menos ou mais que isso acaba se tornando um pouco difícil. Você não necssariamente precisa fazer todo um caso de uso dentro de uma iteração. Conforme explico nas minhas aulas de RUP e Processos Iterativos um work item de uma iteração pode ser apenas um fluxo, um cenário ou parte de um fluxo de um caso de uso. Você pode implementar uma fatia "magra" de um cenário numa iteração e completá-lo numa iteração posterior.

Gerenciamento de Projetos no OpenUP e OpenUP/Basic

O planejamento de projetos do OpenUP é fortemente baseado em Scrum.

A gestão de projetos no OpenUP/Basic funciona da seguinte forma:


O Gerente de Projetos trabalha com os stakeholders para criar um plano de projeto macro, baseado na Visão do Projeto. Esse plano descreve os tamanhos e objetivos das quatro fases e das iterações de cada fase: Iniciação, Elaboração, Construção e Transição.

No começo de cada iteração o Gerente de Projetos trabalha com os stakeholders para priorizar requisitos, requisições de mudança e defeitos da Lista de Itens de Trabalho para alocá-los na iteração subseqüente.

O Gerente de Projetos desenvolve junto com a equipe de desenvolvimento um Plano de iteração detalhado com base nos objetivos e prioridades definidos. Os membros trabalham nos itens de trabalho, fornecendo continuamente ao gerente de projetos estimativas refinadas para as tarefas necessárias e o status de cada uma delas.

No final de cada iteração deve ser gerado um produto de software funcionando que possa ser demonstrado aos stakeholders. No final de cada iteração o Build deve incluir os resultados de testes e as conclusões e avaliações devem ser capturadas num documento de Avaliação da Iteração.

O time demonstra o progresso contínuo ao reportar o número de itens de trabalho fechados por meio de um gráfico de Burndown do Projeto. É possível usar um Burdown de iteração para mostrar progresso dentro de cada iteração.

Riscos são gerenciados continuamente através de um trabalho pró-ativo de análise da Lista de Riscos.

Segundo o exemplo de plano de iteração e o exemplo de work items list que se encontra no OpenUP/Basic pode-se colocar a criação de artefatos como atividades. Eles podem ser sub-tarefas de uma atividade ou uma atividade e work item por si só.

Apresentação sobre gerenciamento de riscos em projetos de software

Publiquei uma palestra que ministrei em simpósio na Universidade de Guarulhos, a convite do professor Nilson Salvetti.

A palestra trata sobre a gestão de riscos em projetos de software.

Seus objetivos:
- Compreender a importância do gerenciamento dos riscos em
projetos de software
- Identificar os principais elementos do processo de gestão de riscos
- Avaliar os principais riscos em projetos de software e como
minimizá-los ou eliminá-los completamente

Seus conteúdos:
- Conceitos básicos sobre riscos e seu gerenciamento
- Necessidade de controlar os riscos na gestão de um projeto
- Elementos do processo de gestão de riscos (Envolvidos, Atividades, Artefatos)
- Principais riscos de projetos de software e estratégias de
mitigação

O material se encontra na seção de downloads do site Erudio.

O Processo de desenvolvimento de produtos da Netscape e Microsoft e sua influência na vantagem competitiva

Escrevi um artigo em conjunto com o meu grande amigo de mestrado e de docência na São Judas, Paulo Marcelo Lessa Moreira (diretor da Unitech), para o mestrado do IPT (Instituto de Pesquisas Tecnólogicas). O artigo trata sobre o processo de desenvolvimento de produtos da Netscape e Microsoft e sua influência na vantagem competitiva.

O artigo completo se encontra na seção de downloads de Engenharia de Software do site Erudio.

Segue o breve resumo:

O processo de criação e inovação de produtos é crítico para a continuidade do sucesso, prosperidade e sobrevivência das organizações empresariais. Em particular, as empresas que atuam no ramo de produtos e serviços de software se encontram em um mercado altamente competitivo, onde a inovação e o lançamento de novos produtos e novas versões de produtos são cruciais para a sua sobrevivência. Sob essa ótica, analisamos como o processo de desenvolvimento de produtos da Netscape e da Microsoft se torna um fator decisivo em suas estratégias competitivas. Buscamos analisar quais são as práticas adotadas por essas empresas como fatores de sucesso para manter um processo de desenvolvimento de software que possibilite a sustentação de suas vantagens competitivas frente aos concorrentes.

PALAVRAS-CHAVE

Estratégia competitiva, Vantagem Competitiva, Processo de desenvolvimento de produtos, Netscape, Microsoft, Inovação, Desenvolvimento de Software.

Referências Bibliográficas

BLOOMBERG. Japan Stocks Fall, Led by Sony on Game Delay Report; Banks Drop. Disponível em:
http://www.bloomberg.com/apps/news?pid=10000101&sid=aq8JOorKByJA . New York, 2006.

CHRISTENSEN, Clayton. O Dilema da Inovação. São Paulo: Makron Books, 2001.

COOPER, Robert. Winning at New Products: Accelerating the Process from Idea to Launch. 3rd Edition. New York: Basic Books, 2001.

CUSUMANO, M.; SELBY, R. Os Segredos da Microsoft. São Paulo: Editora Ática, 1996.

CUSUMANO, M.; YOFFIE, D. Competing on Internet Time. New York: The Free Press, 1998.

CUSUMANO, Michael. The Business of Software. New York: The Free Press, 2004.

DESCHAMPS, J.; NAYAK, P. R. Product Juggernauts: How Companies Mobilize to Generate a Stream of Market Winners. Boston: Harvard Business School Press, 1995.

FOWLER, M.; FOEMMEL, M. Continuous Integration. Disponível em:
http://www.martinfowler.com/articles/continuousIntegration.html . Martin Fowler,
2005. Acesso em: 06 de março de 2005.

LEFFINGWELL, D.; MUIRHEAD, D. Tactical Management of Agile Development: Achieving Competitive Advantage. Disponível em:
http://knowledgestorm.inc.com/inc/search/viewabstract/76279/
Colorado: Rally SDC, 2004.

McCONNELL, Steve. Rapid Development: Taming Wild Software Schedules. Redmond: Microsoft Press, 1996.

McGRATH, Michael. Product Strategy for High-Technology Companies, 2nd Edition. New York: McGraw-Hill, 2001.

PORTER, Michael. Estratégia Competitiva. 6a. Edição. Rio de Janeiro: Editora Campus, 1986.

PORTER, Michael. Vantagem Competitiva. 5a. Edição. Rio de Janeiro: Editora Campus, 1989.

REINERTSEN, Donald. Managing the Design Factory: A Product Developer’s Toolkit. New York: Free Press, 1997.

SMITH, P. G.; REINERTSEN, D. G. Developing Products in Half the Time. 2nd Edition. New York: John Wiley & Sons, 1998.

WIKIPEDIA. Browser Wars. Disponível em:
http://en.wikipedia.org/wiki/Browser_wars . Wikipedia, 2006.

Proposta de um Roteiro para a Redução do Tempo de Desenvolvimento de Projetos de Software

A pedidos do meu grande amigo e colega professor André Luiz Dias Ribeiro estou publicando mais um de seus artigos, que propõe um Roteiro para a Redução do Tempo de Desenvolvimento de Projetos de Software.

Resumo:

A realização de um projeto de software dentro do prazo planejado é um dos desafios da engenharia de software moderna. A agilidade e rapidez com que os produtos do mercado evoluem tornam o fator de atendimento do prazo como um diferencial entre as empresas de desenvolvimento de sistemas. A proposta do roteiro é organizar as técnicas e práticas de engenharia de software que auxiliem no planejamento, na definição da arquitetura e na aplicação da engenharia simultânea com o objetivo de obter-se ganhos reais no tempo de desenvolvimento do software e no aumento da produtividade que permitam a realização do projeto dentro do prazo estabelecido.

O artigo se encontra na seção de downloads do site Erudio.

Gerenciamento de Projetos Tradicional x Gerenciamento de Projetos Ágil: Uma Análise Comparativa

A pedidos do meu grande amigo e colega professor André Luiz Dias Ribeiro estou publicando seu artigo que compara o gerenciamento de projetos tradicional com o gerenciamento de projetos ágil.

Além da bibliografia sugerida por ele, no final do artigo, recomendo os seguintes livros que já li e são essenciais para entender a gestão ágil de projetos:

- Effective Project Management: Traditional, Adaptive, Extreme, Third Edition de Wysocki e McGary

- Radical Project Management de Rob Thommsett

- Agile Project Management : Creating Innovative Products de Jim Highsmith

- Managing Agile Projects de Sanjiv Augustine

- Agile Project Management with SCRUM de Ken Schwaber

- Agile Project Management: How to Succeed in the Face of Changing Project Requirements de Gary Chin


Sem mais delongas, segue o resumo do artigo de André Luiz Dias Ribeiro. O dowload pode ser feito na seção de downloads de Engenharia de Software do site Erudio.



Resumo

O ambiente de desenvolvimento de software passa por um processo de mudanças. Os projetos de software tornam-se cada vez mais complexos, sujeitos a constantes alterações e com prazos cada vez mais restritos para atender as demandas de mercado.
Neste cenário, os métodos de gerenciamento de projetos tradicional e de gerenciamento ágil são analisados criticamente numa busca do que é mais eficaz na gestão de desenvolvimento de software.
O objetivo deste artigo é apresentar os conceitos principais de cada método e realizar uma análise comparativa entre eles, gerando subsídios que permitam a análise de qual método é mais apropriado de acordo com as características de cada projeto.

Abstract
The software development environment is changing. The projects are getting more complex, with constants changes and reduced time-to-market.
In this scene, the traditional and agile project management have been critically analyzed to search for an effective software development management.
This paper presents the methods main concepts and a comparative analysis between them that help choosing the best method for managing the project in hand.

Palavras-chave: Gerenciamento de Projetos, Métodos Ágeis, XPM, Engenharia de Software.