Flexibilidade no processo de desenvolvimento de software

Diante da consciência sobre a natureza iterativa da maioria dos projetos de software, e da necessidade de acomodar modificações durante o próprio processo de desenvolvimento, o presente item busca caracterizar e trazer a visão do gestor quanto à capacidade de seus processos para responder o ambiente evolutivo de software.

Para tanto, buscou-se caracterizar o processo na ótica do gerente de projetos a cerca da capacidade dos processos em responder às mudanças nos projetos, da capacidade de dar

continuidade nesses projetos diante da falta de informação necessária, bem como a facilidade de manutenção do produto e as relações de tempo na entrega de software funcionando.

Em relação à capacidade de adaptação a mudanças no projeto, o processo permite que estas alterações sejam realizadas em casos de urgência, uma vez que considera o levantamento de requisitos como uma etapa essencial. No entanto, como a empresa se trata de um banco, existem demandas de órgãos regulatórios, como o Banco Central.

No tocante a permissão de caminhos alternativos, o processo utilizado trata algumas etapas como essenciais, de forma que estas não podem ser negligenciadas, como, por exemplo, a documentação, levantamento de requisitos e prototipação do projeto. Dessa forma, existem sim etapas obrigatórias, que são utilizadas como mecanismo de controle de qualidade e entrega de software, visto que o processo adotado permite que as atividades sejam definidas pelos gestores do banco, como também, os mesmos homologuem e validem os softwares produzidos:

“...Apesar de existir metodologia tanto tradicional como ágil né, em algumas situações determinados projetos eles não seguem completamente o ciclo né, seguem algumas etapas que são essenciais, mais por questão de tempo, por questão de pressão de ordem legal, às vezes chega né, projetos aqui que tem apenas 3 meses para poderem serem concluídos, ai a gente acaba aplicando a metodologia, mas a gente não aplica ela por completo...”

Contudo, apesar de alguns passos do processo serem considerados obrigatórios, outros passos além dos apresentados como importantes são considerados opcionais. Sendo assim, os processos utilizados permitem que caminhos alternativos sejam criados para sua execução e, até mesmo que etapas do processo e algumas atividades sejam anuladas ou deixem de ser realizadas por inteiro:

“...então alguns passos desse processo na verdade eles são opcionais, nesse sentido, né projetos de maior magnitude com mais tempo pra ser executado, ai sim a gente segue sempre a risca, esse processo ai, então tem passos que são obrigatórios e tem passos que são opcionais, ai vai depender muito da características do projeto...” No que diz respeito à capacidade de iniciar projetos sem as informações completas, o entrevistado, apesar de tratar como obrigatória as etapas relacionadas à busca dessas informações, a exemplo, o próprio levantamento de requisitos e documentação, o mesmo, percebe que essa etapa pode ser realizada exigindo um nível mínimo de informação. Assim, o

processo adotado possibilita a continuidade dos projetos mesmo sem a informação completa necessária para sua execução até o final:

“...A tentativa de previsão sobre todo o projeto é considerada importante, porém, o processo permite que as atividades sejam executadas mesmo quando não existe a totalidade das informações necessárias para o desenvolvimento...pois o projeto tem que ser entregue né? Não tem outra forma, por isso desenvolvemos de uma forma que possa ser modificado posteriormente...”

Quanto às permissões de melhoria futura no software, é importante evidenciar que o entrevistado entende que o software é passível de mudança e que os processos são importantes na lida com essas mudanças.

O entrevistado relatou que existem sistemas desenvolvidos há muitos anos atrás, e que foram desenvolvidos com o intuito de resolver problemas pontuais, e por conseguinte, não existia uma preocupação com mudanças futuras no produto:

“... agora a gente tem sistemas aqui de 30 anos atrás né, então são sistemas bem antigos, e que naquela época lá, 30 anos atrás não se pensava em reutilização, em usabilidade nada disso, ou seja, se construía software pra atender, resolver algum um determinado problema da área de negocio, não tinha muitas preocupações né, então esses softwares eles continuam do mesmo jeito que eles foram construídos lá atrás, sem muita preocupação no sentido de expansão, tanto é que eles são mais inflexíveis né, ou seja, você não consegue crescer muito, você não consegue expandir muito esses sistemas, já que eles não foram construídos pra tal...”

Entretanto, o gerente entrevistado ressaltou que os projetos atuais já são pensados considerando a necessidade futura de adicionar e/ou substituir novas partes no software. Dessa forma, as alterações nestes sistemas acontecem com menos custos e em menor prazo:

“...os novos projetos os novos sistemas que são desenvolvidos todos eles são sempre pensando no futuro, ou seja, na escalabilidade de você consegui crescer né, o, as aplicações, como crescer o sistema de forma mais fácil, e ate reutilizar algumas coisas que já foram desenvolvidas...”

Em relação aos prazos diante das mudanças no projeto, o entrevistado ressaltou que hoje 70% dos projetos dentro da organização são executados fora do prazo. Contudo, o entrevistado entende que os atrasos não estão relacionados aos processos e sim com outros aspectos:

“...Gostaria de deixar claro, que o atraso, isso também é função de muitas mudanças de escopo, muita mudança de requisito, mudança de mercado, mudança de prioridade né, então vários outros aspectos também provocam o não cumprimento dos prazos dos projetos não é só a questão da ausência de uma estimativa mais assertiva...”

Dessa forma, mesmo com existência de modelos de processos tradicional e ágil, existem determinadas situações no que se refere às mudanças no escopo do projeto, inserção de novas partes ou surgimento de novos projetos trazem para a execução um grau de criticidade com relação à entrega de produtos de software funcionando.

Quadro 10 - Síntese do caso alfa

Categorias de análise Elementos de Análise Características do processo Alfa Modelos de processos

de desenvolvimento de

software

Tipos de sistemas desenvolvidos Sistemas de crédito, administrativo e sistemas de serviços bancários. Escopo do projeto Médio e grande porte: mais de 30 dias; Pequeno porte: menos de 30 dias. Tipo de processo(s) utilizado(s)

no desenvolvimento Projetos de médio e grande porte: Tradicional (RUP); Projetos de pequeno porte: Ágil (Scrum).

Flexibilidade com relação ao cliente

Nível de participação do cliente

no processo de desenvolvimento Intermediário visto que não consegue a participação em todos os casos. Aspectos positivos e negativos

da participação do cliente no processo

Positivo: Essencial a fim de dividir responsabilidades e antecipar a problemas no desenvolvimento de software.

Negativo: Não sabe o que realmente necessita; Não compreende a importância do seguir o processo para o sucesso do projeto.

Atendimento de demandas de

mercado Atende, mas com dificuldades com relação prazo e definição de escopo de projeto, que são constantes. Ocasionando retrabalho e falta de alinhamento com a evolução tecnológica.

Flexibilidade no grupo de trabalho

Flexibilidade funcional Os funcionários tem seus papeis e atividades bem definidos, contudo, em casos críticos de urgência _{pode haver o desvio função temporário.} Capacidades gerenciais dos

funcionários A equipe não tem liberdade de gerenciar suas prioridades e atividades.

Autonomia das decisões Centralizadas no gerente de projetos.

Comunicação interna Todos estão cientes das atividades que estão sendo executados, por meio de treinamentos workshops e _reuniões. Reação da equipe diante de

mudanças O grupo de trabalho não reage bem a mudança, sendo assim, buscam formas de se antecipar as mudanças.

Flexibilidade no processo de desenvolvimento de

software

Capacidade de adaptação a

mudanças O processo permite adaptações somente em casos de urgência, considerando algumas etapas do processo como essenciais e obrigatórias. Permissão de caminhos

alternativos Existe a possibilidade de que caminhos alternativos sejam criados em meio a execução e que etapas não obrigatórias deixem de ser seguidas. Capacidade de iniciar projetos

sem as informações completas Exige um nível mínimo de informação, com relação a previsibilidade de todo escopo do projeto. Permissão de melhoria futura no

software

Existem sistemas antigos que não permitem isenções e melhorias, contudo, os projetos atuais são pensados considerando a necessidade de adicionar e/ou substituir novas partes no software. Os prazos diante de mudanças

no projeto

Existe uma grande dificuldade na estimativa de prazo, nesse sentido, grande parte dos projetos são entregues fora do prazo.