Quando trabalhar com os processos ágeis ou fabris no desenvolvimento de um software?

 

Nos últimos meses, venho recebendo severas críticas sobre a idéia fábrica de software. Vários interlocutores afirmam que o conceito de fábrica de software não existe e que a solução dos problemas da engenharia passa ou passará pelos processos ágeis de desenvolvimento de software.

Todos nós sabemos que os processos ágeis são caracterizados dentro da engenharia de software como processos evolucionários.  O feedback é um atributo extremamente importante dentro desta caracterização. Esta categoria de processo utiliza algumas práticas que podem ser aplicadas com extrema facilidade em qualquer projeto de software, inclusive nos fabris, este post destaca algumas delas:

Programa em pares.

Duas pessoas implementado um componente de código ou uma ordem de serviço. Veja os benefícios desta técnica em https://engenhariasoftware.wordpress.com/2008/03/25/a-programacao-em-par-ou-pair-programming-pode-melhorar-a-capacidade-produtiva-de-uma-empresa-de-desenvolvimento-de-software/   

Desenvolvimento guiado por testes.

Os casos e os dados de testes são projetados e, posteriormente, o componente de código é implementado.

Refactoring.                                                                                                                   

Constante reorganização do código fonte de um projeto de software.

Integração contínua.

Ao desenvolver uma funcionalidade integre-a ao projeto, faça novamente todos os testes.

Já algumas práticas, a meu ver, são difíceis de implementar, principalmente em um grande projeto de software, este post destaca:

Cliente sempre presente. 

Imagine que você possua uma empresa de produção de software sediada na cidade de São Paulo. Com certeza você não irá rejeitar um bom contrato com uma empresa sediada em Ji-Paraná – RO. Correto?  Questiono: Como você implementará esta prática? Você irá deslocar a equipe para Ji-Paraná? O Cliente ficará em São Paulo durante todo o projeto? Conheço vários agilistas que trabalham em empresas que instituiram uma equipe própria de produção de software (neste caso o cliente está ao seu lado na própria empresa) ou que estabelecem contratos em escopo estritamente regional para um pequeno projeto. Nestes casos, acredito que existe uma  boa chance desta prática ser implementada.

Estabeleça contratos de escopo variável.

Imagine que você é o CIO de uma grande empresa. Esta empresa necessita adquirir uma determinada solução ligada a TI. Esta solução passa pela implementação de um grande projeto de software. Este CIO diz para a CEO que  investimento no projeto em questão será de x mil dólares nos dois primeiros meses, e o que o custo total do projeto é uma grande incógnita. Tudo vai depender do que a empresa irá necessitar. Desculpe-me, mas infelizmente, o mercado não está e nunca estará preparado para estabelecer este tipo de contrato. Software é caracterizado como um produto e todos querem saber o quanto pagarão por ele.

Utilize somente os cartões para documentar requisitos.

A utilização de cartões de estórias no levantamento de requisitos pode ser eficaz, porém não supre todas as necessidades arquitetônicas de um projeto de software. Em vários projetos, o modelo funcional e o modelo de dados devem possuir certa estabilidade para que possamos estabelecer o custo e prazo de produção. Vários projetos de software são negociados sob a métrica de pontos por função. Para entrar neste tipo de negociação, você deve materializar os modelos citados. Para isto é necessário desenvolver casos de uso, diagramas de fluxo de dados, entre outros.

É importante salientar que no estabelecimento de um grande contrato de produção de software é necessário possuir métricas refinadas e um alto-conhecimento de sua capacidade produtiva. Neste momento entra o conceito de fábrica de software. Ao materializar o escopo do projeto, um conjunto de funcionalidades é definido, este conjunto é dividido em ordens de serviço, estas ordens são codificadas e testadas, por fim, as funcionalidades são implantadas (a aplicação do velho modelo incremental). Existe um controle de produção de todas as atividades, principalmente àquelas relacionadas à codificação e testes. Uma base de componentes é amplamente utilizada na produção do produto em questão. Ao controlar a produtividade você estará estabelecendo uma base de conhecimento de projetos que poderá ser utilizada em estimativas futuras. Se existir alguma dúvida sobre a aplicabilidade do conceito de fábrica de software, sugiro a leitura deste post/ e deste  artigo/ .    

Por fim, acredito que ambas a teorias processuais são aplicáveis, a escolha vai depender da característica do projeto. Como diz minha filha de três anos: “ado ado ado… cada um no seu quadrado”.

Em tempo, é importante salientar que as práticas citadas, neste post, não surgiram com a institucionalização dos processos ágeis, final da década de 1990 e início da década 2000. Afirmo que muitas delas vinham sendo implementadas a vários anos (nos próximos posts apresento a vocês a origem de cada uma).

José Augusto Fabri

3 Responses to “Quando trabalhar com os processos ágeis ou fabris no desenvolvimento de um software?”

  1. Oi, José,

    Uma coisa importante sobre processos ágeis é que eles não são definidos por suas práticas e sim pelos objetivos descritos no manifesto ágil. Implementar práticas comumente utilizadas em processos ágeis em qualquer outro tipo de processo pode (e eu acredito que vá) dar benefícios mas não é a mesma coisa.

    Sobre o cliente presente, atualmente trabalho numa empresa especializada em processos ágeis e com escritórios em diversos continentes. É extremamente comum termos projetos onde o cliente está em Londres e o software sendo desenvolvido na Índia e existem diversas técnicas para isso, a mais simples utilizando Client Proxies. Os beneícios não são tão grandes mas ainda ajudam a atingir os objetivos (lembrando o parárafo anterior).

    Sobre contratos de escopo variável, creio que o mercado não seja tão drástico como afirma. Até mesmo o PMBoK possui contrato de T&M como prática “clássica” e esta é uma das modalidades que proporcionam escopo variável. É bem utilizado dentro nossos clientes.

    Quanto à parte sobre histórias, note que histórias são diferentes de cartões (cartões são uma técnica aplicada junto com histórias) e que os cartões não especificam os requisitos, são apenas um mnemônico destes. No restante da sua argumentação sobre este ponto eu fiquei em dúvida se você está defendendo um modelo em fases, típicos de projetos waterfall.

    []s

  2. Eliana Feo Says:

    Desde o início da formação do conhecimento em gestão, é a indústria automobilística que comanda as inovações. Dela surgiram as idéias da racionalização do trabalho, da rotação de cargos, da avaliação 360 graus, a qualidade total, a reengenharia, a engenharia simultânea e muitas outras. Como cada uma dessas idéias surgiu da necessidade de resolver um problema específico desse setor, a adaptação em outras situações merece uma cuidadosa avaliação.
    A organização de fábricas de software, por exemplo, pode gerar a especialização que tira o significado do trabalho e gera sofrimento ao funcionário? A metodologia Scrum, de acordo com um palestrante, “obriga” o comprometimento do cliente com o projeto, isso não compromete a gestão da qualidade?
    Há consenso entre os autores de Gestão de empresas que cliente não deve ser obrigado a nada e que ao funcionário se deve garantir uma visão holística.

  3. José Augusto Fabri Says:

    Calçado, desculpe-me a demora para responder seu comentário.

    Antes, gostaria de lembrar que sou um freqüentador assíduo de seu blog. Alguns de seus textos são extremamente interessantes. Gostaria de parabenizá-lo.

    Primeiramente, gostaria de salientar que sou contra qualquer tipo de radicalismo na nossa área. Este foi o principal motivo que me levou a publicar o POST. Acredito que exista espaço para todos. Saliento que a aplicação das metodologias ágeis, antes de mais nada, está ligada a natureza das organizações. As empresas devem possuir pré-disposição para isto. Assim que sobrar um tempinho vou escrever um post sobre este assunto. A meu ver o manifesto ágil caminha e paralelo a este fato.

    A questão da variação de escopo de contrato é um paradigma e paradigmas não são quebrados facilmente. Mesmo esta modalidade de contrato estando no PMBoK, minha visão continua sendo bastante pessimista. Contrato de escopo varíavel requer maturidade de ambas empresas (empresa do cliente e empresa produtora de software). Isto não é trivial.

    Defendo um modelo de processo incremental, o projeto de software é particionado, as atividades do processo são percorridas para cada partição, possibilitando assim várias interações entre equipe de produção e cliente.

    Acredito que o termo Client Proxies é muito mais adequado que o cliente “sempre” presente defendidos pelos radicais ágeis.

    Bem basicamente é isto que tenho a dizer…

    Abraços

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: