Desenvolver e implementar processos de trabalho para times de desenvolvimento de software não é tarefa trivial. É responsabilidade primária do CTO garantir que os processos mais ajustados sejam implementados e observados na organização.

A ideia de implementar uma “metodologia ágil” é extremamente tentadora. Entretanto, essas iniciativas falham com frequência porque se aplica a “mecânica” e se ignora os princípios.

Um universo de boas intenções

Muitos gestores, ao elaborar e tentar colocar em prática processos de desenvolvimento, buscam alternativas para que a operação ocorra da forma mais eficiente possível (sem desperdício de tempo ou de recursos), continuamente (sem interrupções, nem variabilidades), de forma veloz (quanto mais rápido, melhor) e, preferencialmente, minimizando conflitos entre as pessoas.

The chief merit of “good software development practices” is its technical efficiency, with a premium placed on precision, speed, continuity, discretion, and optimal returns on input. (Merlon)

Para isso, definem papéis e atividades independentes para:

1. Definir objetivos;
2. Especificar e/ou Planejar o que tem que ser feito;
3. Executar o trabalho.

Em termos práticos, estabelecem times com “analistas”, que são os únicos autorizados a falar com os “clientes” , e “traduzem” o que precisa ser feito, em especificações funcionais, para os “programadores” (executam o trabalho).

NOTA: Muitas vezes, antes dos analistas, há também consultores/gerentes de conta. Esse papel, “mais comercial do que técnico”, entende “os porquês” dos clientes.

São os analistas que entendem o que tem que ser feito e que planejam as atividades. Eles são profissionais mais “nobres e caros”. Geralmente, eles já foram programadores, mas, muitas vezes, esqueceram como escrever código.

NOTA: Os “analistas” são, geralmente, considerados pelos seus superiores como potenciais “líderes técnicos”. Não raramente, entretanto, são considerados como ultrapassados e supervalorizados pelos “programadores”.

Os “programadores” não perdem tempo entendendo o que o cliente quer, todos os dias, eles apenas “pegam a próxima história” (que é um jeito “ágil” de falar “especificação”) e começam a “transformar café em código”.

Choque de realidade

O problema é que o que muitos consideram ideal é, na verdade, conceitualmente, pura e simples burocracia.

The chief merit of bureaucracy “good software development practices” is its technical efficiency, with a premium placed on precision, speed, continuity, discretion, and optimal returns on input. (Merlon)

Definições explicitamente delimitadas para quem estabelece os objetivos, planeja e executa o trabalho caracterizam processos burocráticos que, embora funcionem bem para “trabalho braçal” ou repetitivo, não se ajustam para trabalhos complexos e intensivos em conhecimento, como é o desenvolvimento de software.

Ter analistas que “entendem” o que precisa ser feito e “orientam” os desenvolvedores apenas funciona, ainda que raramente, em times que fazem, sempre, mais do mais do mesmo. É herança do taylorismo, incompatível com trabalho do conhecimento.

Quando taylorismo se disfarça como agilidade

O espírito da agilidade não está em entregar mais features, e sim em entregar mais valor, em forma de software funcionando, em menos tempo.

Se há uma distinção clara entre quem define objetivos, analisa/planeja e executa o trabalho, há burocracia, não agilidade. Não importa se o “analista” ganha nome de Project Owner ou de arquiteto. Nem mesmo se há ou não um quadro kanban na parede (ou em versão virtual).

Recomendações para dias melhores

Se o trabalho em sua empresa não é repetitivo, não trate seu time como uma “linha de montagem”.

A ânsia de entregar mais rápido, eliminando desperdícios de tempo e de recursos, faz com que as entregas fiquem cada vez mais lentas e, frequentemente, com menor qualidade percebida. Todo mundo perde!

A busca pela precisão técnica, tentando fazer o certo da primeira vez, ignora o fato de que, muitas vezes, o cliente precisa “sentir” o software que foi desenvolvido, experimentando e avaliando, para ter uma ideia mais clara do que realmente precisa e deseja.

Tentar fazer com que o programador opere de forma contínua o afasta das discussões sobre as motivações para cada feature, impedindo que ele participe da construção da soluções. Programadores são profissionais valiosos demais para serem apenas “braços”, eles precisam ser “cabeças”.

Tentar manter um “ritmo constante” de trabalho para os programadores, empurrado e não puxado, os sobrecarrega e não deixa margem para a criatividade.

A maior parte do tempo consumido entre uma feature ser solicitada e entregue está em atividades que não tem relação com seu desenvolvimento. Não é raro que uma feature implementada em horas fique parada dias (e até semanas) esperando por homologação e deploy. Por isso, é importante considerar se vale tanto a pena gastar tanta energia na formulação de estimativas que, na prática, servem para pouco ou nada.

O maior custo em desenvolvimento de software é sempre o “custo de não ter” e ele é sentido pelo negócio. Formulemos processos com isto em mente e estaremos fazendo o certo!