Compreender a natureza dos requisitos pode estimular a adoção de metodologias ágeis

Na semana passada (quinta e sexta-feira), tive a oportunidade de conhecer a bela cidade de La Plata, na Argentina, graças ao convite que recebi do Centro Superior para el Procesamiento de la Información (CeSPI) da Universidade Nacional de La Plata (UNLP) para realizar uma edição "in company" do curso Requisitos de Software: Princípios e Práticas para Equipes Ágeis.

Foram dois dias muito agradáveis de teoria e prática garantidos por uma equipe bem participativa formada por 30 profissionais pertencentes ao CeSPI e ao Laboratório de Investigación en Nuevas Tecnologías Informáticas (LINTI). A turma era formada basicamente por gerentes de projeto, analistas de negócio e de sistemas, desenvolvedores e testadores, sendo que somente 20% dos participantes demonstrou conhecimento prévio dos princípios e práticas ágeis (um dos grupos está iniciando a adoção de Scrum).

Antes de continuar com o post, vou aproveitar a oportunidade para registrar meus cordiais agradecimentos a todo o pessoal da UNLP que esteve envolvido na realização do curso, em especial Alejandra, Christian e Juan, pois não economizaram cordialidade e atenção durante o período em que lá estive. ¡Muchas gracias por todo!

Pois bem, nesta última edição, tive a oportunidade de comprovar uma idéia que vinha se formando em minha mente nos últimos eventos - a de que o despertar do interesse pelas metodologias ágeis pode ser feito mediante o correto ensino da verdadeira origem dos requisitos de software: a mente humana!

"Me pareció muy inovador pensar los temas
desde el ser humano y no desde la tecnología."

Dalila, CESPI/UNLP

Todos sabem que os requisitos de negócio, de processo, de sistema e de projeto iniciam nas necessidades e desejos da mente humana. Porém, o que a maioria não sabe é como explorar esse fato com modelos objetivos de percepção, informação, decisão e atitude, gerando resultados ainda mais positivos em seus ambientes de negócio. As metodologias ágeis seguem um manifesto que fortalece os indivíduos e suas interações mais que processos e ferramentas, motivo pelo qual todo e qualquer profissional que atue na promoção ou implantação dessas metodologias deve entender alguns princípios básicos da natureza humana a fim de fortalecer a adoção dessa nova cultura e a percepção das verdadeiras necessidades dos projetos de software.

Minhas duas últimas turmas de requisitos de software realizadas na Argentina (Buenos Aires, com 39 alunos, e La Plata, com 30) eram formadas, em sua maioria (> 75%), por pessoas que desconheciam os princípios e práticas das Metodologias Ágeis, mesmo com o título do curso remetendo o foco para o treinamento de "equipes ágeis". Diante desse resultado, o que pude observar é que aqueles que adotam as práticas ágeis no seu dia-a-dia recorrem ao curso para conhecer novas técnicas, questionar dúvidas e aprimorar suas competências, enquanto que aqueles que desconhecem as metodologias recorrem ao curso para saber como nossas equipes ágeis tratam dos diversos aspectos da Engenharia de Requisitos, procurando respostas para a necessidade de simplificação de seus atuais ambientes de trabalho.

"El instructor mostró una versión distinta en muchos aspectos
muy interesante para ser aplicada en el trabajo diário."

Alejandra, CESPI/UNLP

A estratégia que adotei para ensinar requisitos de software à equipes ágeis, e que está provocando mudanças até mesmo na mente daqueles que adotam outras metodologias, pode ser resumida nos seguintes pontos:

1. Apresentar estatísticas que evidenciem que o principal problema no processo de desenvolvimento de software ainda está relacionado com a forma como são tratados os diversos aspectos dos requisitos de software;
   
2. Apresentar o modelo tradicional da Engenharia de Requisitos (captação, análise, especificação, validação e gerência) e questionar como e quando essas atividades são realizadas durante a história do projeto;
3. Apresentar modelos de percepção e tomadas de decisão da mente humana e demonstrar como tudo o que percebemos da realidade depende da forma como as informações chegam e são armazendas em nossa mente (já discuti que o "Mapa Não é o Território" num post anterior);
4. Apresentar conceitos e práticas que comprovam que a comunicação escrita pode ser utilizada de forma eficaz quando se tem consciência de que ela é um mapa que orienta a navegação durante nossa jornada (requisitos, por exemplo) e não o objetivo da jornada em si (o software, por exemplo);
5. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos quando sua essência está relacionada a necessidades básicas de segurança e reconhecimento do ser humano (pirâmide de Maslow) e não a melhoria do processo de negócio em si;
6. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos devido a crenças e valores limitantes que sustentam incapacidades e comportamentos indevidos do ser humano;
7. Demonstrar que, em ambientes empresariais, todo e qualquer projeto faz parte da realização de uma estratégia de transformação de um processo organizacional, e que um produto de software deve sustentar essa transformação, motivo pelo qual os profissionais que atuam com requisitos devem conhecer os elementos do processo de negócio;
8. Demonstrar como a transformação do processo de negócio pode ser descrita de forma sintetizada, utilizando um modelo de raciocínio baseado na resolução de problemas (Project Story);
9. Demonstrar como as atividades do processo de negócio (Temas) podem ser alvo de análise na decomposição do problema, simplificando o cálculo do retorno de investimento em projetos de software;
10. Demonstrar como o entendimento dos cinco princípios do pensamento enxuto (Valor, Fluxo de Valor, Fluxo Contínuo, Produção Puxada e Perfeição) pode mudar completamente a forma como desenvolvemos e gerenciamos os requisitos de software e justificar a utilização das User Stories;
11. Apresentar as User Stories como um modelo de informações que permite o registro dos requisitos de software de forma aderente ao pensamento enxuto, garantindo a criação de mapas simplificados que nos conduzem ao verdadeiro destino de forma objetiva e segura (planejamento quantitativo e validação objetiva do trabalho realizado);
12. Demosntrar como esse modelo de informações pode ser utilizado de forma efetiva em atividades de planejamento e controle de projetos de software;
13. Demonstrar como podemos nos beneficiar da mudança de percepção sobre as atividades de gerenciamento de requisitos, passando a atuar no controle de estoques e na eliminação do trabalho inacabado em todas as fases de desenvolvimento de produto.
    

Ou seja, adotei uma estratégia top-down que inicia na mente humana, passa pela compreensão dos elementos do processo de negócio, avalia as necessidades de transformação dos resultados organizacionais, ressalta a importância da criação de anticorpos em nosso organismo para atuarem contra requisitos descabidos, e simplifica a compreensão do que deve ser documentado e mantido em nossos estoques de requisitos. O resultado tem sido o reconhecimento de que a cultura ágil tem fundamentos fortes e deve ser adotada por qualquer organização que almeje níveis superiores de qualidade e produtividade em suas equipes de software.

Para aqueles que gostam de metáforas, gostaria de fazer uma analogia entre os requisitos de software e a filosofia zen-budista (originada aproximadamente em 500 d.C., 1.000 anos depois da morte de Buda), que enfatiza permanentemente que "as palavras são um meio e não o fim em si (a iluminação)", motivo pelo qual muitos mestres preferem a prática na compreensão da verdade (aprender fazendo) e criticam os debates filosóficos na transmissão dos ensinamentos. Leia a história abaixo (clique para ampliar a figura) e descubra porque os requisitos nada mais são que o dedo que aponta para a lua!