O tema ferramentas de software é sempre empolgante, sejam elas visuais, completos suites  ou “free” software,  é comum buscar uma ferramenta melhor para atender a processos que já fazemos, e queremos deixar de fazer. Em geral é assim que é encarada a automação. Mas hoje eu quero conversar sobre ferramentas inteligentes. Quer dizer, quais características poderíamos querer que as ferramentas tivessem para as considerarmos mais inteligentes?

Quando implantamos um RTC (IBM Rational Team Concert) esperamos que ele organize todo o trabalho de equipe, ajudando em planejamento, designação de tarefas, controle de demandas e fontes, etc, etc! É uma enorme variedade de parâmetros e amarrações que definimos para estruturar o armazenamento e o transporte de informações. O modelo de uso da ferramenta vai nos dizer como proceder na sua operação. Isso tudo junto, e funcionando, nos dá uma enorme quantidade de informações. Mas será que aproveitamos tudo isso?

Uma primeira abordagem é tratar os dados e mostrar as informações através de modelos de datawarehouse e datamarts. É o que faz o IBM Rational Insight, criando dashboards e relatórios de dados. (Vejam a referência do Innovate 2013). Essas são informações estruturadas que foram previstas para serem extraídas (nem todas, é verdade). Mas certamente há informações que, em princípio, não foram inicialmente planejadas para captura e não estão em nenhum atributo previamente modelado. São informações escondidas na massa de dados coletada, informações que só existirão se descobrirmos um padrão. Para fazer uso desse tipo de informações podemos utilizar técnicas de aprendizagem de máquina e procesamento de linguagem natural (NLP), somente elas podem ultrapassar a previsão inicial da estrutura de dados do modelo de uso.

Aplicar técnicas de aprendizagem de máquina podem nos ajudar a descobrir padrões de solicitação de mudanças, por exemplo. As solicitações de mudança são armazenadas no RTC e sempre possuem textos associados, descrição, títulos, comentários, categorias, etc. Os atributos que categorizam as solicitações podem ser considerados a parte estruturada da informação, sendo que e a parte desestruturada da informação está escondida, a espera de ser extraída através de algum algoritmo que processe as palavras contidas nas demandas. 

Por exemplo, se devido a algum padrão emergente, pudermos agrupar as demandas por similaridade, poderíamos detectar a recorrência de certos temas que indicassem necessidade de melhoria no produto. Isto permitiria orientar estratégias de melhoria de qualidade. Na manutenção de software vale a regra dos 80/20, é sabido que 20% dos módulos de um sistema apresentam 80% dos problemas. Mas nem sempre temos dados diretos para esse tipo de investigação. Nessa situação uma clusterização que detecte a baixa qualidade é muito útil. Note que esses temas emergentes não foram previamente idealizados, mas podem ser descobertos por clusterização com um algoritmo de aprendizado de máquina.

Outro exemplo. A similaridade do grupo de demandas pode implicar em similaridade de soluções. Isto implica na possibilidade de reuso da solução, como indicou o colega Quintela e, portanto em economia, talvez com uma melhor alocação de recursos. (Veja a referência DeveloperWorks, onde se utiliza para isso um algoritmo bem conhecido, o K-Means).

Um importante sub-produto de um estudo desse tipo é a montagem de um histórico de medições de esforço para padrões de similaridade no conjunto solicitações-soluções. Uma base de solicitações com um histórico de custo (esforço ou duração), já é um item valioso para a governança do desenvolvimento. Através de alguma manipulação de aprendizagem de máquina pode-se melhorar nossa capacidade de estimativa de custo e trabalho. E isto nos leva à questão das estimativas no assunto requisitos, área de atuação do IBM Rational Requirement Composer, o RRC.

Mas antes de falar em estimativas vamos ver um problema ainda na fronteira entre o RRC e o RTC. Suponha que você tenha 500 tarefas associadas a uma dezena de demandas, que por sua vez estão associadas a uma centena de User Stories. Qual a esperança de otimizar o replanejamento disso quando aparecer novas demandas? Não precisa replanejar? Mas o replanejamento é a essencia do Scrum, sem replanejamento o processo não cumpre a promessa de entregar valor mais cedo ao negócio. Então precisamos replanejar... o que significa repriorizar, ler uma enorme quantidade de texto e comparar User Stories entre si.

 Quem já passou pela experiência de repriorizar um montão de requisitos, sabe que o mais árduo é ler e reler, não é aplicar uma escala de prioridades, essa é a parte relativamente fácil. O replanejamento seria facilitado se tivéssemos os requisitos clusterizados. O aparecimento de padrões emergentes permitiriam isolar Épicos de User Stories, verificar temas repetitivos e assuntos mal definidos. O trabalho do Product Owner poderia ser enormemente facilitado e com ele o de toda a equipe.

O caminho mais comum é aumentar a hierarquia estruturada, mas há um limite prático para a estruturação. Quanto mais “organizamos” nosso conteúdo em árvores (ou pirâmides) mais aparece a necessidade de informações cruzadas. No limite, um enorme emaranhado de rastreabilidade poderia aparecer como resposta à tentativa de continuar a estruturação de informações cruzadas. Por outro lado, se trabalharmos a informação desestruturada, sob demanda, construímos menos coisas e possivelmente atuaremos com mais rapidez na direção do objetivo. Não estamos sugerindo abandonar a estruturação, apenas fazê-la conviver com uma saudável desestruturação...

Para ilustrar, ainda que pobremente, o resultado de uma busca de contexto sobre um escopo desestruturado, considere um simples “concordanciador”. Este é uma função de processamento de linguagem natural, que simplesmente lista as referências a uma palavra ou tema, incluindo o seu contexto. Tradicionalmente apresenta o resultado de uma forma especial:

    ..... que alteraria o status do     cliente preferencial      para aprovado, enquanto......

   ...calculando o bonus para o     cliente preferencial.    Esse bonus deve ser.............

   ........... do sistema1 e incluir     cliente preferencial      no cadastro de clientes.........

   ........12N489 0 Task: Bonus    cliente preferencial:     implementar opção de..........

   ............. se foi alterado para     cliente preferencial.    Quando ultrapassar o valor...

Mesmo que o uso desse recurso seja manual, já percebemos as possibilidades com a clusterização contextualizada. Observe que não respeitamos as fronteiras entre as ferramentas. Há inúmeras possibilidades de aproveitar uma informação de contexto como essa. A mais simples seria instrumentalizar o Product Owner com uma verificação de contexto.

Agora falando de estimativas. Uma das necessidades do desenvolvimento é alguma forma de estimar o esforço envolvido numa unidade de escopo. Mesmo os processos que adotam apenas a perspectiva da priorização, também estimam em algum momento. Veja, por exemplo, a necessidade de identificar um Lead Time médio para planejamento (novamente a referência Innovate 2013).

Como o assunto é delicado (se fosse fácil em 50 anos de desenvolvimento de software a solução definitiva já teria aparecido), procuramos alternativas paliativas. A estimativa feita com a escala de de fibonacci, que se usa frequêntemente junto com o Scrum, é uma das formas mais simples. Essa forma de estimar produz uma avaliação relativa, uma User Story é pontuada relativamente às outras, do mesmo sistema.

Esse procedimento de estimativa poderia ser facilmente melhorado se houvesse um filtro automático para pré-clusterizar o conjunto, antes da aplicação do trabalho manual. Isto se tornaria viável se identificarmos elementos de similaridade nos textos das User Stories. Algoritmos de aprendizagem de máquina são capazes, portanto, de facilitar nossa vida também na estimativa e, talvez, até gerar avaliações aproximadas do trabalho, dependendo da profundidade de coleta dos dados estruturados e não estruturados.

Um assunto que está se desenvolvendo a passos largos é a “análise de sentimento”, uma aplicação de aprendizado de máquina para identificar e classificar conteúdos de sentimentos, emoções e opiniões, presentes nas unidades de texto. No que isto poderia ser útil para introduzir inteligência nas ferramentas?

Suponha que o levantamento de requisitos para o seu novo sistema corporativo esteja em curso. A necessidade de priorizar características e módulos é encarada racionalmente, mas é uma tarefa grande e desgastante. Fica pior quando há conflito entre stakeholders do projeto. Porque não analisar a questão da priorização com uma abordagem massiva de clusterização dos documentos e do volume de correspondência trocado?

Textos, que pela abordagem racional seriam descartados, através de uma abordagem de processamento de linguagem natural poderiam fornecer informações complementares ou subsidiárias. Expressões como “alta qualidade”, “fazer economia”, “racionalização de recursos”, significam alguma coisa, apesar de que, numa respecificação técnica de requisitos, teriam pouco valor definitório. Na análise de sentimentos, porém, essas expressões podem nos ajudar a pontuar prioridades, inicialmente criando um resumo, e, com um pouco mais de trabalho, uma lista de prioridades ordenadas.

O assunto fica ainda mais interessante se ampliarmos esse cenário para a web. Nesse caso, se o seu produto de software for destinado para o público externo, é ainda mais relevante garimpar opiniões de sentimento em blogs, tweeters, avaliadores especializados, etc. Boa parte das características de seu produto podem ser confirmadas, ou despriorizadas, com informações coletadas dessa forma. Por exemplo, num feedback sobre aspectos do produto podemos desencavar requisitos de facilidade de uso, movimento de tela, tipos de botões, quantidade de memória, etc. Mesmo que alguns aspectos estejam sendo vistos negativamente, isso não importa.

Enfim, ferramentas inteligentes devem abranger essa nova tendencia que são os algoritmos de Big Data e capacidade de aprendizagem de máquina, só assim poderemos fugir da tarefa interminável de modelagem das estruturas de categorização. Os dados estruturados não desaparecerão, mas há muito o que se descobrir na parte desestruturada da vida...

 Referências

Innovate 2013 – Improving Predictability and Efficiency with Kanban Metrics using Rational Insight. Luiz Augusto de Souza, Paulo Cezar Lacerda Neto e Marc J. Nehme.

DeveloperWorks - Benefits of applying clustering algorithms to finding change request patterns. Luis Carlos Quintela.

Moacyr  Mello é IBM Certified IT Specialist,  tem 28 anos de experiência em tecnologia de informação e atua nas áreas de processos e requisitos na IBM Rational desde 1999. É Engenheiro Eletricista pela Escola Politécnica da USP, com especialização em gestão de projetos pela FGV.