sexta-feira, novembro 23, 2007

Gestão de Projetos - Ferramentas livres e gratuitas para o gerenciamento de projetos

Segue uma lista com várias indicações interessantes de ferramentas livres e/ou gratuitas para a gestão de projetos. Algumas dessas ferramentas trabalham no estilo do Microsoft Project, isto é, são feitas para o desktop. Já outras são baseadas na web e centralizam a informação nos servidores web e de banco de dados da empresa.

Muitas dessas ferramentas podem substituir tranquilamente o Project. Outras possuem menos recursos, porém buscam atender a um nicho de pequenos projetos.

Uma importante dica: Não duplique informações. Se você utilizar uma ferramenta baseada na Web, elimine a ferramenta desktop do seu trabalho.

Você também precisa analisar e pensar se e como fará a integração entre a ferramenta de gestão de projetos e uma ferramenta de gestão de incidências. Algumas das ferramentas de gestão de projetos possuem plugins e integrações com ferramentas de gestão de incidências. Algumas ferramentas de gestão de incidências possuem funcionalidades que geram gráficos de Gantt, entre outros. Às vezes, com um uso coerente das funcionalidades disponíveis, é possível substituir a ferramenta de gestão de projetos apenas pela ferramenta de gestão de incidências.

Deixe um comentário, caso queira saber mais sobre alguma ferramenta ou conhecer minha opinião sobre elas. Aproveite também para falar o que achou sobre uma dessas ferramentas, caso já a tenha utilizado. Se há alguma outra ferramenta que não foi citada por mim, deixe sua dica aqui para termos uma relação bem atualizada de opções!!!


Leia sobre o ProjectKoach e Mingle.

Descubra também o Buildix (é mais do que apenas uma ferramenta para gerenciar projetos. É todo um ambiente para automação de desenvolvimento de software).

Veja o que é a ferramenta ScrumWorks, VersionOne e Rally.

Veja também as seguintes ferramentas livres e/ou gratuitas:

GanttProject

Achievo

Open Workbench

Faces

TaskJuggler

OpenProj

DotProject

Note também que algumas das ferramentas citadas disponibilizam funcionalidades para o ciclo de vida completo de um projeto de desenvolvimento de software e, o melhor, integrando com facilidade de uso esses aspectos. Além da gestão de projetos há também: gestão de requisitos, gestão de testes, gestão de incidências, integração com controle de versões. Alguns exemplos dessa categoria: Mingle, Buildix, VersionOne e Rally.

As ferramentas focadas em gestão de projetos e que são instaladas no desktop são: GanttProject, Open Workbench, Faces, TaskJuggler, OpenProj.

As ferramentas com foco no gerenciamento de projetos, porém instaladas em um servidor web e acessadas via browser são: Achievo, DotProject.

Resposta à pergunta do Edigar sobre o grau de importância das ferramentas de gestão no sucesso de um projeto de desenvolvimento de software: Hoje acredito que a ferramenta mais importante para o controle e a gestão de um projeto de software é a ferramenta de gestão de incidências. Se você fizer o controle corretamente e tiver bons fluxos definidos, a base de dados da gestão de incidências se tornará o coração dos seus sistemas e de sua empresa como um todo.

As maiores empresas desenvolvedoras de software no mercado mundial usam como recurso central as ferramentas de gestão de incidências para controlar, monitorar e organizar seus projeto de software. Hoje, na minha opinião, esse é um recurso fundamental para disciplinar, organizar e fazer a governança de sistemas de Tecnologia da Informação.

Já um ferramenta focada em gestão de projetos, que gera gantts, PERTs entre outros vira uma ferramenta acessória. Na minha opinião, ela só será útil se for integrada ao sistema de gestão de incidências e apenas como mais uma forma de monitorar o projeto, além da própria ferramenta de gestão de incidências em si (esta sim o coração e a máquina central do desenvolvimento de sistemas) e outros tipos de visualização úteis como o Release Burdown e o Sprint (Iteration) Burndown do Scrum e do OpenUP.

Marcadores:

quarta-feira, novembro 07, 2007

Agilidade e Governança: Um falso dilema

Existe uma percepção de que não é possível ter governança de TI ao usar um processo de desenvolvimento de software ágil. Em um próximo artigo resumirei minhas idéias sobre o assunto e mostrarei como isso é uma falácia. Agora pretendo apresentar links de artigos de um mestre. Assim aquilo que eu já sabia se torna ainda mais embasado :-) .

Leia com atenção os seguintes artigos de Scott Ambler (lembrando que ele é um dos evangelistas da IBM Rational e, portanto, está guiando a Visão de produtos e processos da IBM):

Governança no desenvolvimento ágil de software

Melhores práticas para governança de equipes ágeis

Melhores práticas para a governança enxuta de desenvolvimento: Parte 1

Melhores práticas para a governança enxuta de desenvolvimento: Parte 2

Melhores práticas para a governança enxuta de desenvolvimento: Parte 3

Ágil com preço fechado

As terríveis consequências do uso de projetos de preço fixo em TI

Marcadores:

segunda-feira, novembro 05, 2007

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.

Marcadores: ,

Esforço de testes em projetos de software e proporção entre desenvolvedores e testadores

Pergunta das listas de discussão: qual a proporção entre o número de analistas de testes da equipe de qualidade para o número de desenvolvedores da equipe de desenvolvimento?

Minha resposta:

Isso varia bastante. Em empresas que vendem software como fim, como a Microsoft e a Oracle, autores detectaram uma maior concentração em testes na proporção de 1 testador para cada desenvolvedor.

A Netscape tinha 1 testador para cada 2,4 desenvolvedores. Segundo o livro do Cusumano isso dificultava o trabalho de testes na Netscape, porém eles tinham os usuários beta e early users que ajudavam nesse esforço.

Na literatura se encontram variações no esforço de testes que vão de 20% até 70% do projeto. A verdade é que lá fora o processo de testes é bem mais valorizado e tende a ter um bom numero de pessoas na equipe. Aqui isso está crescendo paulatinamente.

Os dados da Microsoft e da Netscape estão basicamente em dois livros do Cusumano: "Os Segredos da Microsoft" e "Competing on Internet Time". Coloquei esses dados em um artigo meu chamado "O Processo de desenvolvimento da Netscape e Microsoft e sua influência na vantagem competitiva". Vide especialmente as seções 2.7 e 2.8

Minha resposta em relação à postura contra a divisão do trabalho/especialização em desenvolvimento de software e testes:

Um testador precisa ter um paradigma completamente diferente de um desenvolvedor. O testador está lá para destruir o software, encontrar defeitos. Já o desenvolvedor está lá pra construir. É essa a base do processo de testes e é por isso que costuma-se ter desenvolvedores que não sabem testar muito bem o que eles mesmo criam.

Alguns papéis podem ser feitos por todos, com treinamento. Porém outros são arriscados.

É importante ter especialistas generalistas. O ideal é que o testador, se preciso, possa ajudar eventualmente com programação e requisitos e o desenvolvedor ajudar nos testes. Mas de qualquer modo é importante ter pessoas especializadas em pelo menos uma disciplina e visão de todas as outras. Esse é o modo como grandes empresas desenvolvedoras de software trabalham. Elas tem o programador e o testador. Mas isso não impede do programador ajudar nos testes e do testador ajudar a revisar o código de um programador.

Recomendo a leitura do artigo do Scott Ambler sobre os "Especialistas generalistas". São raras as pessoas que conseguem se especializar em mais de um papel ao mesmo tempo. E é bom ter especialistas, contanto que eles minimamente conheçam as outras disciplinas para ajudar os especialistas destas outras.

Marcadores:


Veja as Estatísticas