Relatório do Caos - Por quê os Projetos Falham?

O Relatório do Caos é criado, anualmente, pelo Standish Group, e tem como objetivo apresentar um estudo sobre o cenário de projetos de TI. Para o estudo, o relatório apresenta uma comparação entre projetos para contrução de pontes e projetos de sistemas. O motivo do relatório escolher tal comparação, deve-se ao fato de serem projetos com características opostas. Enquanto um projeto de contrução de ponte tem pouquíssimia possibilidade de mudança de escopo, projeto de sistemas tem muita necessidade de mudança, devido ao dinamismo de seu mercado.

Para o relatório, projetos de contrução de pontes são, mundialmente, vistos como projetos de sucesso. E, quando fracassam, as causas do fracasso são investigadas profundamente, o que impede, ou mitiga, a possibilidade de repetição. Nos casos de projetos de sistemas, em caso de fracasso, suas causas não são investigadas e tratadas de forma correta, o que direciona para sua repetição.

O relatório aponta números impressionantes sobre os valores desperdiçados, por grandes empresas, devido a projetos que são cancelados antes mesmo de serem concluídos. Apenas nos Estados Unidos, 31% dos projetos são cancelados em fase de construção, o que implica em mais de 81 bilhões de dólares em prejuízos. E quando o projeto é concluídos, apenas 16% são entregues no prazo e custo estimados e com cerca de apenas 42% dos requisitos originais.

Mas por quê isto acontece? Por que os projetos de TI possuem números tão assustadores? 

Acredito que a maior causa dos problemas esteja relacionado justamente com a comparação realizada pelo instituto para criação do relatório. Os projetos de TI nasceram com os conceitos da construção civil, como a fase de planejamento, a engenharia, arquitetura e contrução. Muitas metodologias de gestão colocam  projetos de TI no mesmo patamar de outros projetos. Porém o dinamismo do mundo corporativo, não permite tal inclusão.

Eu costumo fazer uma alusão entre projetos de TI e seriados de TV, que acredito serem muito mais parecidos. Requisitos de projeto são como personagens do seriado; crescem de importância ou são excluídos de acordo com o andamento do projeto, ou seriado. E a comunicação entre a equipe técnica com seu cliente, é parecida com o retorno dado pelo público, durante a temporada de um seriado.

Outro ponto que difere projetos de TI dos demais projetos, é o fato de sistemas serem menos visíveis e tangíveis durante seu desenvolvimento. Em uma casa, ou ponte, podemos ver o que é contruído a cada etapa, sentir e tocar. Projetos de TI, por vezes, impedem tal percepção.

Por isso precisamos fazer com que o cliente esteja próximo da equipe técnica durante toda a fase de desenvolvimento de sistemas. Apresentar cada item desenvolvido e receber feedbacks sobre o andamento do projeto. E, para isso, precisamos mudar conceitos e buscar, no mercado, metodologias que embasem projetos de TI como algo singular, seja ágil ou não. Porém, o mesmo relatório aponta que projetos de TI, embasados por metodologias ágeis, apresentam melhores resultados. 

Até o próximo post.

AMDD e TDD - Arquitetura, Modelagem e Desenvolvimento Ágil

Os princípios, mencionados no artigo Ciclo de Vida de Desenvolvimento de Sistemas Ágil, podem ser utilizados junto à outras metodologias, ou conceitos, para se criar um processo de desenvolvimento de sistemas. Um desses conceitos é a Modelagem de Desenvolvimento Dirigira (MDD em inglês). Esse conceito guia como agrupar os requisitos do projeto, como modelá-los e como arquitetar a solução para atender aos requisitos. Assim, ao ser utilizada sob o foco ágil nasce a Modelagem Ágil de Desenvolvimento de Sistemas (AMDD em inglês).

Esse conceito pode ser utilizado juntamente com diversas metodologias ágeis para completar o Ciclo de Vida do Desenvolvimento de Sistemas. Isto é, a metodologia escolhida suportará o planejamento do projeto bem como suas alterações, como criar o fluxo de comunicação e etc. E o AMDD proverá como realizar estas tarefas, do ponto de vista da equipe técnica. Isto é, como dividir o desenvolvimento em iterações, como criar e manter os documentos necessários para o projeto.

Agile Model Driven Development

A Figura acima - http://www.ambysoft.com/essays/agileLifecycle.html - apresenta as tarefas realizadas em cada iteração do projeto, a partir da iteração 0 – início do projeto. A caixa verde mostra as atividades da iteração 0. Nesta fase, os requerimentos iniciais são modelados assim como a arquitetura inicial do projeto, ambos em caráter de macro-visão.

O modelo, dos Requisitos Iniciais representa a lista de requerimentos que os clientes necessitam que o sistema possua ou execute. Esta lista é chamada de Product Backlog, e contém os requisitos, ordenados por prioridade – as prioridades representam quais requisitos retornam mais valor ao negócio –, e nortearão a equipe técnica a desenvolver e entregar os requisitos mais importantes primeiro, assim como a estimar a duração do projeto de maneira mais eficiente.

É importante ressaltar que esta lista pode ser alterada durante o projeto pelos clientes, com a inclusão, mudança ou retirada de algum requisito. Porém tais alterações são realizadas em momentos específicos, como veremos a seguir.

O modelo da Arquitetura Inicial representa a arquitetura que será utilizada pela solução em uma visão macro. Isto é, o modelo proverá qual tecnologia será utilizada, qual a linguagem de programação, banco de dados, se será Web ou Cliente-Servidor e etc. O detalhamento da arquitetura como componentes, seqüência ou classes serão modelado no início de casa iteração de Construção.

As caixas azuis representam as iterações de Construção, seguintes à iteração 0. Cada iteração de Construção possui a mesma estrutura. Isto é, cada uma das iterações começa, se desenvolve e termina através do mesmo processo.

Ao dividir o Product Backlog, criado na iteração 0, em sub-listas, uma nova lista será criada. Esta nova sub-lista chama-se Sprint Backlog.

O Sprint Backlog proverá ao time de desenvolvimento quais requisitos serão desenvolvidos durante a iteração atual. Ainda que o Sprint Backlog possa ser alterado pelos clientes, é primordial que este seja congelado, no início da iteração, de modo a estabilizar o trabalho da equipe técnica. Assim, se algum requisito, pertencente ao Sprint Backlog, necessitar de alterações, um novo requisito deve ser criado e priorizado para próxima iteração. Se esta alteração é realmente importante, os clientes devem escolher um outro requisito para ser substituído, ou projetado para uma próxima versão do produto.

A primeira atividade de cada umas das iterações de Construção é avaliar e validar o Sprint Backlog. Esta atividade está incluída na tarefa de Modelagem da Iteração. Esta atividade é muito importante, pois através dela é possível certificar que o prazo da iteração é viável e que seus requisitos são possíveis de serem desenvolvidos. Outro ponto é que este é o momento em que os clientes podem sugerir mudanças do escopo de maneira mais eficaz e com menos riscos para a qualidade do projeto.

Além disso, nesta atividade, o modelo da arquitetura é revisto e detalhado para incluir os itens necessários para o desenvolvimento da iteração atual.

A melhor maneira de se criar o Modelo de Tomada (Model Storming) é se reunir com a equipe técnica, por cerca de 30 minutos em média, e analisar todas as possibilidades de risco para o item e apontar a melhor estratégia de desenvolvimento. Esta tarefa é feita para cada item a ser desenvolvido na iteração atual.

A tarefa de Desenvolvimento Dirigido à Teste (TDD em inglês) adiciona a documentação e o desenvolvimento efetivo dos itens. TDD é um conceito que suporta estratégias de desenvolvimento de sistemas, onde o desenvolvedor primeiro constrói o teste que deve ser feito para validar o item desenvolvido e, em seguida, constrói o código fonte para atender os testes com sucesso.

De acordo com este conceito, o desenvolvedor cria o teste necessário para validar alguma funcionalidade e, em seguida, começa a desenvolver o fonte para implementar a funcionalidade. A idéia é criar o código fonte passo a passo – cerca de 10 linhas – sempre testando o código. A funcionalidade está criada com sucesso, quando os testes rodam com cucesso. A figura abaixo apresenta como o TDD funciona.

Test Driven Development

Se o TDD for bem implementado, os testes criados serão utilizados como a documentação técnica e o código certamente será bem executado. Entretanto, nem todas as funcionalidades do sistema deve ter um teste implementado. Somente códigos críticos ou complexos deveriam ter testes implementados. O desenvolvedor deve pensar se a funcionalidade é complexa o suficiente para requerer uma estratégia TDD.

Assim, no final de cada iteração, depois de todos os itens pertencentes ao Sprint Backlog serem desenvolvidos, o sistema estará pronto para ser entregue à equipe de Testadores para certificarem-se que o produto não possui problemas. Se tudo estiver bem, os clientes podem iniciar seus testes. Estes testes proverão um parecer se os requerimentos foram desenvolvidos como necessário e se eles estão satisfeitos com o sistema.

Se tudo estiver de acordo, o projeto segue paras as próximas iterações. Caso contrário, as mudanças necessárias são implementadas e testadas, conforme o ciclo de vida do projeto. 

Até o próximo post.