Por Hélia Scremin de Souza Germano Nogueira

Se você nos acompanha há algum tempo, já deve estar bem cansado de ouvir o prof. Marcelo Nogueira falando sobre a crise do software e sobre filosofia ágil.

Nesta semana, a CTA traz um texto baseado em uma entrevista com ele para esclarecer por que o movimento ágil não é nem nunca foi sinônimo de bagunça, de desordem e muito menos de caos. Infelizmente para quem quer trabalhar com seriedade, agilidade tem sido tudo isso na prática em muitos lugares. Temos ouvido de muitos profissionais de vários níveis – nossos alunos e amigos – que a documentação ficou de fora. Métricas, modelagem e planejamento então, são coisas abominadas em muitos projetos “ágeis” por aí.

Não sabemos quanto a você, mas para nós, isso é de arrepiar os cabelos. A gente fica aqui pensando se as pessoas não leram o manifesto ágil, ou se interpretaram errado. Ou o pior, que a gente não quer acreditar: será que tem gente mal-intencionada se aproveitando dos softwares cheios de bugs gerados em meio ao desenvolvimento caótico?

Breve histórico

O termo crise do software começou a ser usado nos anos 1960. Nada novo, não é mesmo? Nessa época, informática era mato. Tinha que abrir clareira com facão para criar soluções para tudo. Brincadeiras à parte, era muito diferente do que conhecemos hoje. Como era uma área nova que buscava automatizar as informações, usava-se o conhecimento disponível: ciência matemática. Guarde essa informação!

Nos anos 1980, Roger S. Pressman, autor pioneiro em engenharia de software, reafirmou os desafios da área. Os produtos de software eram entregues com defeitos, fora do prazo, sem atender às necessidades do cliente. Nada parecido com o que acontece hoje (contêm ironia). E a discussão sobre os desafios e insucessos em programação ficou ainda mais forte em 1995, com o lançamento do Chaos Report.

Em meio a esse tumulto de fim de século, a solução era tornar os processos de trabalho engessados, com mil regras, documentação nos mínimos detalhes, muito foco em resultados, hierarquias e projetos pouco humanizados.

Equilibrando pratos

Para tentar melhorar as coisas, em 2001, surge o Manifesto Ágil, um texto curto e de fácil entendimento. O manifesto trazia premissas de desenvolvimento de software para tentar diminuir os problemas tão conhecidos desses profissionais. Mas isso você já deve saber. (Se não sabe, leia o texto original aqui)

O que pouca gente entendeu é que o manifesto e as práticas ágeis surgiram com intuito de equilibrar o jeito que as pessoas gerenciavam o trabalho com sistemas de informática. A percepção que o manifesto ágil traz é a de que não dava para deixar tudo no amadorismo. A agilidade quer acabar com o pensamento de que programar é algum tipo de trabalho artístico, artesanal. Ao mesmo tempo, o agile, no termo em inglês, traz o senso de colaboração, flexibilidade, entrega contínua e humanização do processo de programar.

Em todas as sentenças do manifesto, lemos “mais que”: 

E no final do texto, os autores ainda enfatizaram que veem valor nos dois lados. Mas fizeram questão de destacar que os primeiros itens são os que eles mais querem ver à frente do trabalho.

Alguém falou que não precisava documentar? Não! Que podia inventar um preço para o projeto, chutar quantos profissionais estariam na equipe? Também não. Então por que raios ainda tem gente fazendo software de qualquer jeito, sem respeitar normas, modelos, metodologias?

O segredo está no equilíbrio

Em uma conversa madrugada adentro, o prof. Marcelo Nogueira desmistificou algumas confusões que foram feitas na hora de interpretar o manifesto ágil. Eu traduzi em texto e imagens para não ter mais dúvidas do que dá para fazer software com muito profissionalismo sem deixar de ser ágil.

A ideia é aliar o melhor dos dois extremos para obter sucesso. Continue lendo para entender melhor.

Como aliar indivíduos e processos

O foco dos procedimentos ágeis deve estar nas pessoas e não na burocracia. Isso não quer dizer que você não precisa organizar seu trabalho. Muito pelo contrário, organizá-lo vai deixar o seu serviço ainda mais fácil a longo prazo. Isso também vai propiciar ambientes melhores para você focar no que importa: as partes envolvidas, ou stakeholders.

Algumas maneiras de deixar os processos mais leves e as pessoas em destaque:

1. Faça o trabalho ser divertido (para você e seu time). Use cores, jogos. Seja criativo. Você vai descobrir por que é tão importante gerir o projeto com equilíbrio
2. Adote técnicas que você gosta para modelar e projetar (ex. design thinking, design sprint, BPMN, UML) em vez de pular essa etapa
3. Use o que está à sua disposição. Nem sempre você precisa criar do zero. Já existem, componentes, serviços, micro serviços para reuso, suficientes para executar qualquer tipo de trabalho.
4. Pare de disfarçar seu cascágil. No desenvolvimento de software, a clareza dos métodos define o sucesso da implementação. Os métodos ágeis são suficientemente claros para solucionar as questões que surgem durante as sprints. Se você fica aguardando o trabalho de outras pessoas para poder executar o seu, isso não é ágil, é cascata.

Como entregar software sempre e com boa documentação

A entrega de software deve ser frequente e funcional. Não adianta entregar algo com bug e achar que está tudo bem e depois fazer o time sofrer para consertar. A crise do software existe porque ainda tem gente demais achando “normal” entregar programas defeituosos. Qual o efeito dos erros a longo prazo? Quantos danos podem ser causados em cadeia por software que não atende às necessidades? Trabalho a mais, demissões, retrabalho, vidas dentro do squad e atingidas pelo negócio do cliente, direta e indiretamente. Tenho certeza de que você não quer essa encrenca para você.

Portanto, para fazer um software continuamente bem-feito:

1. Não use o ágil como desculpa para fazer algo meia boca. Lide com a construção de software como a sua obra de engenharia perfeita.
2. Documentação não é relatório do que foi construído. É o seu plano do que deve ser implementado. Você não precisa engessar os incrementos por causa de um ou outro documento. Se você fez um plano e o documentou corretamente antes de iniciar a codificação e implementação, terá tudo à mão para ser ágil.
3. Adapte a documentação. Por exemplo, o RUP adaptou-se ao AUP (RUP ágil). Atividades antes prescritivas foram substituídas por histórias com modelagem, somente.
4. Eleja os artefatos suficientes para tornar o seu processo transparente. Outra pessoa deve saber de onde continuar ao pegar o seu projeto / código.

Como colaborar com o cliente e ter boas negociações

A profissional que negocia os termos do contrato normalmente não é a mesma que desenvolve. Porém, ela deve estar extremamente alinhada com o time de desenvolvimento. Do contrário, a equipe estará em maus lençóis e terá um péssimo clima para trabalhar. Dessa forma, em conjunto, todos devem pensar no melhor para o cliente desde o princípio:

1. Abra mão de entregar com bug para depois consertar e poder cobrar pela manutenção do que foi mal planejado / executado.
2. Escopo, custo, tempo e qualidade. Tenha em mente as necessidades do projeto.
3. Calibre suas métricas de acordo com as necessidades do cliente. Não abaixe a régua.

Como entender que o plano requer adaptações

O planejamento é o começo de qualquer grande projeto. Sem essa etapa, certamente haverá problemas no caminho. Porém, cabeças abertas trabalhando em conjunto poderão tomar as melhores decisões a fim de fazer todo o necessário para ajustar o que surgir durante a execução do plano. Parece utópico? Tente isso:

1. Não seja teimoso. Aceite mudanças, pois elas acontecem o tempo todo onde você menos espera. Abra mão do controle e desfrute do seu próprio trabalho. Afinal, você o escolheu. Abra mão do estresse curtindo a jornada, por mais maluca que ela pareça.
2. Você pode dar qualquer nome para as partes do projeto, mas todas têm que estar lá. Adaptabilidade não quer dizer que você não terá um plano inicial, mas que terá flexibilidade para mudar uma coisa aqui e outra ali, se necessário.

E agora, o que eu faço?

Falamos apenas das sentenças iniciais do manifesto. Porém, com uma leitura atenta, fica fácil compreender que elas resumem os doze princípios que vêm na sequência. Se você tem dúvidas, leia tudo mais algumas vezes até o ágil real dominar a sua mente e a sua prática diária.

A agilidade nunca se propôs a acabar com a seriedade e complexidade desse trabalho. A base da nossa expertise é a engenharia: processos, estimativas e métricas. É um trabalho intelectual baseado em muito raciocínio matemático, como dissemos lá no início do texto. As práticas ágeis servem para ajudar o profissional a estimar tempo, custo, qualidade, esforço e outras variáveis a partir da análise dos seus próprios dados históricos.

Portanto, honre o seu trabalho com o melhor dos seus esforços. Use a agilidade a seu favor com excelência. E lembre-se: norma é aquilo que se deve fazer. Método é o caminho. Metodologia é o estudo de como fazer. Estude sempre, renove-se. E conte conosco para iluminar o seu caminho profissional.

O seu próximo nível

Tudo o que falamos aqui é a linha mestra da nossa pós-graduação em Engenharia de Software, em parceria com a Universidade Paulista (Unip) que está com matrículas abertas somente até o próximo dia 8.

Se você quer fazer parte da solução e ser um Engenheiro de Software ágil de verdade, agende agora a sua entrevista clicando aqui. Você pode começar a mudar o rumo da sua carreira ainda este ano.