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.

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

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.

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.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.