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!

O Fim de uma Era ... e o que podemos aprender com a GM

Pois é ... na última segunda-feira, dia 31 de maio de 2009, a primeira empresa verdadeiramente moderna da indústria automobilística, recriada em 1920 pelo gênio Alfred Sloan, e totalmente gerenciada por números até os dias de hoje, pediu concordata. Esse fato foi analisado pelo guru dos Sistemas de Produção Enxuta, James P. Womack (criador do termo Lean), na última newsletter (02/06/2009) publicada pelo Lean Enterprise Institute sob o título "The End of an Era". Para Womack, esse dia marca o fim de uma discussão que persistia há mais de 30 anos, desde o começo do declínio da GM na recessão de 79. Ele diz que "Finalmente, o David derrubou o Golias, exatamente quando o Golias estava começado a prestar atenção na mensagem da gestão enxuta".

Analise bem este cenário:

1. A GM possuia fábricas competitivas em termos de produtividade e qualidade;
2. A GM possuia um processo de desenvolvimento de produto competitivo;
3. A GM estava consolidando um sistema de produção global consistente, baseado nos princípios e práticas do Lean Manufacturing, mesmo depois de falhar por uns 15 anos na adoção do modelo com o apoio da própria Toyota (vide NUMMI);
4. O modelo de gestão enxuta estava sendo adotado em todos os processos da empresa, até mesmo nos processos administrativos e de negócio.

Por que então a GM quebrou desse jeito? Simples! Porque todo esse movimento de renovação da gestão organizacional começou tarde demais! Na concordata, a GM mostrou para todos que ela não era lucrativa nem que ela sabia fazer gestão. Como assim? Que absurdo falar que uma empresa do tamanho da GM não sabia gerenciar seu próprio negócio! Pois é, Womack fala que o problema não estava na gestão dos números, uma vez que toda a Alta Direção era proveniente da área de finanças. O problema estava na concepção equivocada sobre qual o papel da gerência diante da organização e da sociedade. Em termos mais simples, podemos ter uma idéia do que ele quer dizer fazendo as seguintes perguntas:

• Cadê o novo Sloan?
• Onde está aquele líder capaz de repensar a missão da empresa e sua forma de gestão a fim de torná-la mais uma vez relevante para os americanos?
• Mesmo que encontremos um líder, será que ele terá liberdade para tratar dos problemas e reconstruir a glória original da empresa com idéias inovadoras?
• Será que as crenças arraigadas daquela gestão fria e calculista, que empurrou a empresa para o precipício, não irá impor barreiras para um novo modelo de gestão organizacional?

Sloan reconstruiu a GM no começo do século XX vendendo o "sonho americano" do carro luxuoso, o sonho do Cadillac. Só que o atual sonho dos americanos, e da grande maioria da população mundial, é do carro ecológico, barato e de baixo consumo de combustível, preferencialmente feito à base de energia limpa. Que mercado resta então para a GM diante de um atraso tecnológico no desenvolvimento dessa categoria de automóveis? O que fazer diante da concorrência que já possui automóveis rodando nas estradas alimentados por hydrogênio e eletricidade? Quanto a isso, só o tempo dirá ...

Pensem agora na área de software ... será que os 30 anos de debates aos quais Womack se refere (entre modelos de gestão industrial) começaram para nós na publicação do Manifesto Ágil, em 2001, ou na publicação do Objectory por Ivar Jacobson, em 1988 (primeira versão do modelo que viria a se transformar no RUP, em 1998). Pois bem, já faz 20 anos desde a disseminação do modelo de Use Cases e muita gente ainda não sabe como isso funciona! Sem falar naquelas pessoas que não compreendem ou não querem compreender (conheço várias) o paradigma de orientação à objetos ... Em 30 anos, a indústria automobilística evoluiu tanto a tecnologia e os requisitos mínimos de desempenho, segurança e conforto que até mesmo um carro popular da atualidade pode superar diversos modelos de luxo da década de 70 (na relação custo x benefício). Nossa área evoluiu consideravelmente nos últimos 5 anos, mas ainda muitos de nossos representantes permanecem consumindo modelos e tecnologias defasadas, sem nem passar pela mente termos como Releases, Sprints, TDD, Refactoring, Continuous Integration, Retrospectives, etc.

O que podemos pensar de tudo isso se compararmos essa "nova era" da indústria automobilística ou da gestão industrial com a revolução do desenvolvimento de software promovida pelos Métodos Ágeis? Será que em 2031, 30 anos após a publicação do Manifesto Ágil, os modelos tradicionais de gestão que conhecemos ainda estarão presentes em nossas empresas? Ou a queda de alguns impérios (como diversas fábricas de software que atuam estritamente com base no modelo taylorista de gestão empresarial) fará com que uma nova visão da gestão criativa do desenvolvimento de software consolide nossa nova era?

O que sei é que também precisaremos de líderes! Precisaremos de "gerentes" criados dentro de ambientes baseados numa cultura enxuta! Baseados numa cultura de excelência focada no ensino, aprendizagem e auto-gestão. Se começarmos agora, talvez em 2020 possamos colher os primeiros frutos na nova geração ... nossos novos líderes de projetos de software!

Por fim, Womack deixa claro em sua carta que até mesmo a Toyota não escapa da crítica diante dos resultados negativos que apresentou nesta última crise financeira. Ela cresceu mais rápido do que sua capacidade de desenvolver novos gerentes competentes para manter a cultura Lean e desvirtuou sua estratégia de crescimento para se tornar a maior organização da indústria automobilística, perdendo o ideal de ser a melhor organização para a solução dos problemas de seus clientes. Essas ações foram contraditórias ao próprio pensamento Lean e repercutiram nos últimos resultados financeiros da empresa.

Que lições podemos aprender de tudo isso?

1. Não devemos deixar para amanhã o que podemos e devemos começar ainda hoje!
2. O que parece lindo por fora pode estar podre por dentro ...
3. Mesmo os mestres podem cometer erros em momentos difíceis ...
4. É difícil transmitir arte, filosofia e sabedoria para nossas futuras gerações ...
5. Adote um modelo vencedor para sua vida e não perca o foco na realização desse modelo!

Desejo muito sucesso para todos vocês!