Fábrica de Software Tradicional vs Ágil

Cada empresa possui necessidades específicas, sejam operacionais ou de negócio. Porém, desenvolver uma solução eficaz, dentro do tempo adequado, com um equipe especializada e tecnologia atualizada, requer um grande investimento para qualquer empresa.
Devido a isso, muitas empresas buscam fábricas de software para realizar parte ou todo o ciclo de desenvolvimento, pois além do conjunto de expertise a empresa pode reduzir, ou até mesmo eliminar, investimentos e gastos com infraestrutura, espaço físico, contratação de profissionais e toda a gestão de desenvolvimento de sistemas e de aplicações.

Escopo

As fábricas de software são classificadas de acordo com o seu escopo de atuação ou simplesmente pelo escopo do contrato com o cliente, conforme apresentado abaixo.

f1

Figura 3. Classificação de fábrica de software

  • Fábrica de Componentes: dedicada ao desenvolvimento de componentes de software, realiza a codificação e o teste unitário. Por possuir extensa expertise na construção de soluções e no desenvolvimento dos mais diversos tipos de componentes, a fábrica de componentes acumula não apenas experiência de desenvolvimento, mas também os próprios componentes de sistemas e aplicações. Assim, além da redução do tempo usado no desenvolvimento da solução em si, esta variedade de componentes e de expertise em diferentes mercados pode oferecer uma visão mais abrangente e, consequentemente, contribuir com o aproveitamento de soluções em diferentes situações de forma inovadora. Além disso, este tipo de fábrica de software pode fornecer componentes para outras fábricas de software.
  • Fábrica de Testes: dedicada a realização de teste integrados, de aceitação e outros tipos de teste, tais como teste de desempenho, teste de segurança, teste funcional, teste operacional etc.
  • Fábrica de Projetos Físicos: realiza a codificação, a especificação técnica, os testes unitários, os testes integrados e os testes de aceitação. É geralmente acionada quando o cliente possui uma área de TI que levanta as necessidades do negócio e as explicita em especificações funcionais, as quais são enviadas para a fábrica de software realizar o restante das etapas do ciclo de desenvolvimento de software.
  • Fábrica de Projetos de Software: abrangem todas as atividades desde a especificação funcional, mas o cliente ainda é o responsável por definir a arquitetura desejada, que geralmente deverá ser aderente a sua infraestrutura e seu ambiente de TI.
  • Fábrica de Projetos Ampliada: neste modelo a fábrica de software é responsável por todo ciclo de desenvolvimento de software.

Todos os tipos de fábrica de software, independente da sua classificação, possuem processos definidos que atendem às necessidades de desenvolvimento. No caso das fábricas de componentes, por exemplo, o processo central refere-se à codificação e teste unitário, e deve estar baseado na adoção de frameworks de mercado como o OpenUP, o RUP ou o eXtreme Programming, que são processos focados em engenharia de software.

Já para fábricas de projetos de software e fábricas de projetos ampliada o foco central está no gerenciamento do projeto e para tal deve-se utilizar métodos de gerenciamento de projetos como o Scrum, o Prince2 ou o PMBoK em conjunto com os processos de desenvolvimento de software.

Modelos de Fábrica de Software

Outra variável importante na definição do foco da fábrica de software é dirigida ao que o cliente percebe como valor. Se para o cliente o mais importante é ter certeza do escopo a ser implementado antes de enviar para a fábrica de software, ele deverá optar por uma fábrica de software que utiliza métodos tradicionais. Mas se o cliente não tem certeza sobre o escopo ou ainda está em definição, ele deverá optar por uma fábrica de software que utiliza métodos ágeis.

Para que essa diferenciação fique mais clara, basta comparar o Tradicional Triângulo de Ferro, que consiste de escopo, cronograma e custo com o Triângulo Ágil, que consiste de valor, qualidade e restrições

f2

Figura 1. Triângulo de Ferro.
O Tradicional Triângulo de Ferro do gerenciamento de projeto possui o escopo como principal condutor devido à falsa suposição de que o escopo seria conhecido logo no início do projeto, enquanto o custo e o cronograma variavam – embora alguns gerentes tentem atrelar todas as dimensões.

f3

Figura 2. Triângulo Ágil.
No Triângulo Ágil as medidas são valor (para o cliente), qualidade (necessária para agregar valor contínuo ao cliente) e restrições (escopo, cronograma e custo). Restrições ainda são importantes parâmetros de projeto, mas não são as metas do projeto. O valor é a meta, e as restrições podem precisar ser ajustadas a medida em que o projeto avança. O cronograma pode ainda ser uma restrição fixada, mas daí o escopo pode ser ajustado para agregar o mais alto valor dentro das restrições do cronograma, focando nas funcionalidades mais importantes.

Documentação e Equipe de Desenvolvimento

O modelo de fábrica de software tradicional tem como premissa a preexistência de requisitos detalhados e completos, assumindo que todo o contexto pode ser definido pelo cliente no início e homologados por ele no final do desenvolvimento e que a principal forma de comunicação é a documentação. Ou seja, o processo “entra papel e sai código”, sem a garantia de que o desenvolvedor entendeu o que deve ser desenvolvido ou que o cliente vai receber no final do processo o produto que ele imaginava.

Isso gera um problema, que é considerar a documentação como único meio de comunicação entre a área de negócio e o desenvolvimento, e a imprecisão da linguagem escrita pode sempre gerar erros de interpretação. Por isso, métodos ágeis utilizam conversas frequentes entre desenvolvedores, clientes e usuários no lugar de longas especificações funcionais. Ou seja, ao invés de gastar o tempo do cliente para especificar, revisar e dar aceite em extensas documentações é melhor investir o tempo do cliente para conversar com ele sobre o escopo, onde a própria equipe da Fábrica de Software pode sugerir soluções mais eficientes e mais baratas para o cliente, com a reutilização de seus componentes e frameworks.

Contratos

A forma de contratação pode limitar e definir o formato da fábrica de software, onde fábricas de software tradicionais trabalham com contratos com preço fixo para um escopo fechado e as fábricas de software ágeis trabalham com contratos do tipo tempo e material, na qual define-se o período de tempo e a quantidade de horas de cada perfil do time de desenvolvimento e o cliente encaixa neste tempo o escopo possível de ser entregue.
Contrato de preço fixo.

É o formato preferido pelos clientes pois o risco é transferido para a Fábrica de Software. Nesse modelo ocorre a definição de um preço fixo total para um determinado produto ou serviço ou resultado a ser fornecido. Podendo ser utilizado para entrega de todo o escopo de um produto ou para entregas parciais que podem ser realizadas por Sprints, que possuem o escopo fechado.

Cada Sprint pode ser considerado um micro contrato independente em que a Fábrica de Software é responsável pela entrega de um incremento de produto operacional, que deve atender aos critérios de aceitação do cliente.
Porém, de acordo com o Scrum, as entregas podem não ser concretizadas devido a diversos fatores, chamados de impedimentos, o que pode inviabilizar este tipo de contrato. Outro fator que pode inviabilizar este tipo de contrato é o desejo do cliente mudar o escopo da Sprint em andamento, levando ao seu cancelamento, onde o desenvolvimento das funcionalidades pode estar em progresso e no momento do cancelamento a funcionalidade não estará em conformidade com os critérios de aceite do cliente e/ou inaptas para o uso, fazendo com que não seja considerada entregue. Para esses casos, podem ser negociadas exceções com pagamentos parciais de acordo com a etapa de desenvolvimento de cada funcionalidade, mas ainda assim poderão existir conflitos entre o Cliente e a Fábrica de Software devido a possíveis diferenças no entendimento sobre o progresso no desenvolvimento de cada funcionalidade.
Por esses motivos que este tipo de contrato se adapta melhor a fábricas de software tradicionais, as quais possuem o escopo fechado e tratam mudanças com requisições de mudança, as quais são submetidas para aprovação do cliente. O que geralmente aumenta os custos do projeto e podem inibir a adaptação e a inovação.

Para citar um exemplo, o Grupo Meta já desenvolveu projetos com este tipo de contrato e com métodos ágeis na Gerdau. Nesse cliente ocorreu a apresentação da visão geral das funcionalidades desejadas, as quais foram estimadas e após serem detalhadas e aprovadas pelo cliente foram enviadas para o desenvolvimento. Qualquer adição ou remoção que ocorreu no escopo houve a negociação dos valores e formalização por meio de requisições de mudança. É importante observar que neste exemplo o cliente já conhecia a maior parte do escopo, o que viabilizou este modelo de contrato. Já em outros clientes, que quiseram adotar este modelo de contrato sem ter conhecimento de escopo, foi necessário vender o serviço de Planejamento de Desenvolvimento de Sistemas, que tem como objetivo o levantamento dos requisitos e outras informações importantes para possibilitar a definição de estimativas de tempo e de custo, antes de avançar para o desenvolvimento.

Contratos por tempo e material

Permite a contratação de capacidade de desenvolvimento da Fábrica de Software, com definição do escopo que deverá ser entregue, mas sem a obrigação de realizar essa entrega ao final da Sprint, pois durante a Sprint podem surgir impedimentos que inviabilizem a entrega de todo o escopo.
Este modelo exige grande maturidade e acompanhamento da Fábrica de Software e do Cliente, já que a única maneira de monitorar o valor entregue pela Fábrica de Software é pela análise de indicadores de desempenho e reuniões de acompanhamento.

Este modelo é mais aderente ao formato de Fábrica de Software Ágil, pois permite que o Cliente mude e adapte o escopo durante o projeto, a medida que utiliza as funcionalidades entregues, sem restrição de escopo, mas com restrição de orçamento e de tempo. Mudando a restrição para orçamento e tempo e não mais para o escopo, força o cliente a focar no que realmente irá agregar valor ao negócio.

O Grupo Meta já desenvolveu projetos com este tipo de contrato com métodos ágeis na Auttar e no Grupo RBS. Esses clientes contrataram uma equipe fixa por um tempo específico. Durante os projetos, ocorriam reuniões de planejamento e de revisão do escopo da Sprint, reuniões diárias de acompanhamento e reuniões para verificar o que poderia ser melhorado no processo para as próximas Sprints. Projetos que geraram ótimos resultados para os clientes, onde o projeto do Grupo RBS deu origem a uma nova empresa, chamada Appus – www.appus.com.br – que possui clientes como Grupo Boticário, Gerdau, Itaú e o próprio Grupo RBS e o projeto da Auttar recebeu prêmios de Inovação do Grupo Santander, a qual ela faz parte e expandiu o seu mercado de atuação.

Considerando esse relacionamento cliente-fornecedor, com a equipe de desenvolvimento se comunicando constantemente com o cliente foi importante manter a mesma equipe durante a execução de todo o projeto. E este foi, e ainda é, um dos grandes desafios, pois geralmente as fábricas de software possuem equipes dinâmicas atuando em diversas demandas de diversos clientes ao mesmo tempo.

Conclusão

Fábrica de Software tradicional ou ágil são modelos que dependem basicamente de 4 fatores: metodologia, nível de participação do cliente, equipe do projeto e tipo do contrato. Se a metodologia prever entregas pequenas e constantes (1), com o cliente participando de todo o ciclo de desenvolvimento de software (2) em comunicação com a mesma equipe de desenvolvimento (3) e com um contrato que permita a mudança de escopo (4) é possível atuar com uma Fábrica de Software Ágil. Caso contrário teremos uma Fábrica de Software Tradicional.
Outros fatores, como ferramentas e técnicas de desenvolvimento e formato e tamanho das equipes também são fatores importantes, mas neste artigo foram comparadas apenas as principais diferenças entre os dois modelos de Fábrica de Software.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *