08 Sep 2014
Eu olhei para os dados disponíveis e achei que não tinha muito o que fazer com eles. Normalmente a gente tem uma pergunta, vai a campo buscar dados e obtêm uma resposta, mas quando uma consultora do Ministério da Educação para inclusão de alunos portadores de deficiência na escola regular me pediu ajuda para extrair informações úteis dos dados disponibilizados pelo Ministério, eu fiquei encucado. Parecia não ter jeito de transformar aqueles dados em algo útil.
Trabalhando como analista em projetos de software ágil, estou acostumado a me perguntar "o que eu quero tirar disso" quando algo dá errado ou quando estou começando algo do zero. Dessa vez os dois aconteceram, é um domínio que eu não tenho conhecimento e os dados pareciam ter chegado antes da hora.
Ora, dados por si só valem muito pouco. Em tempos de Big Data, a oferta é tão grande que não importa a demanda, o valor de dados brutos nunca foi tão baixo. O movimento de Agile Analytics tem abordado o problema virando ele de ponta cabeça e só os buscando quando sabemos a pergunta que queremos responder. Datensparsamkeit ao invés de simplesmente coletar tudo ao estilo NSA. Neste caso os dados nem eram tão Big assim.
O que deveria sair desta análise é um plano de ação para aumentar a inclusão em municípios selecionados na Região Sul do Brasil. Com base nisso, o passo seguinte, pareceu ser tentar ver o retrato hoje. A taxa de inclusão varia muito entre municípios e o tamanho dos municípios também varia. De forma que 10 alunos em escola especial (o que significa que eles não estão incluídos na escola normal) em Porto Alegre (aprox. 1,4 milhões de hab.) seria um resultado muito bom, ao passo que o mesmo número em Cacequí (aprox. 14 mil hab.) seria consideravelmente pior. Experimentando um pouco com os dados, acabei dividindo eles nos quadrantes abaixo:
A coluna da esquerda representa municípios com baixo volume de alunos na escola especial e a da direita, alto. De forma análoga, a linha de baixo tem os municípios com baixa incidência de alunos na escola especial, e a de cima, alta. Isso significa que no quadrante inferior esquerdo temos os municípios mais avançados no processo de inclusão e no superior direito os que ainda demandam mais esforço. Cada um desses quadrantes é um tipo de problema, e podemos imaginar que as soluções para eles sejam parecidas entre sí, por exemplo:
- O quadrante laranja, são municípios onde o número absoluto de alunos em escola especial é baixo, mas a percentagem de inclusão também é baixa. Esse é a maior quantidade de municípios, portanto é aonde vale a pena uma solução "empacotada" (treinamento, programa de longo prazo, etc);
- O quadrante vermelho são os casos mais extremos, numero absoluto alto e pouca inclusão. Devemos imaginar que esses darão mais trabalho, talvez valha a pena ter um funcionário dedicado em cada um deles;
- O quadrante verde, são os que tem baixo numero absoluto de alunos em escola especial e inclusão alta. Esses municípios estão quase lá. Só precisam motivação e apoio para chegarem a 100% de inclusão e liberarem os recursos das classes especiais;
- Por fim o quadrante lilás só tem dois municípios. Provavelmente podem ser trabalhados individualmente, não vale a pena planejar nada para eles.
Com isso, ao invés de abordar 111 problemas diferentes (1 para cada município analisado), agora o trabalho pode ser focado em 30 casos distintos (os 29 municípios vermelhos e todos no grupo laranja) e algumas iniciativas relativamente simples para os outros dois quadrantes. Certamente apenas isso não garantiria a solução imediata, mas permite o acompanhamento do progresso de cada um dos grupos, bem como a movimentação dos municípios entre eles.
Esse modelo foi adotado para o plano de ação dos municípios analisados e apresentado como referência para as outros grupos de municípios da Região Sul. Foi interessante ver que essas ferramentas comuns em atividades de concepção de software podem ser usadas também para servir as políticas públicas. Agora é esperar o final do ano para acompanhar os resultados!
19 Aug 2014
Meio sem notar, escrevi recentemente ou aqui no blog ou no site de Insights da ThoughtWorks três artigos que acabaram se complementando e de certa forma resumindo a minha visão atual de análise de sistemas/negócios em projetos ágeis.
É apenas o pensamento atual - pode e deve mudar com o tempo - e é imperfeito e não aplicável a todos os casos, mas representa um bom conjunto de axiomas que tenho tentado aplicar nos projetos que me envolvo (que normalmente tem sido tiros curtos de menos de 6 semanas) e que tem dado bons resultados. São fortemente influenciados pelas ideias de Lean Startup e Continuous Delivery e com elementos de pensamento sistêmico e umas ideias do Chris Argyris.
Onde o modelo gerativo de estórias é apresentado em contraposição ao modelo "indutivo" que simplesmente descreve uma funcionalidade já pensada. Quando falamos em épicos, no mundo da Agilidade, muitas vezes relacionamos a uma lista de funcionalidades já existentes e épicos sendo um nível mais alto de granularidade. Essa abordagem exige um conhecimento "a priori" de todo escopo, o que gera ansiedade ("e se eu não pensei em tudo...") e necessariamente exige um esforço inicial de análise. O modelo gerativo busca inverter essa relação, começando com um objetivo geral e gerando as unidades de trabalho a medida do necessário.
O modelo gerativo faz com que a primeira coisa a fazer seja determinada praticamente automaticamente. É muito difícil validar hipóteses sem ter código funcionando em produção. E ser capaz de colocar código em produção também é uma hipótese que deve ser validada, assim fazer isso imediatamente é o melhor jeito de começar. E essa é uma atividade que exige pouquíssima análise dado que os objetivos gerais estão definidos. Isso permite que o desenvolvimento inicie imediatamente, e a análise identifique a próxima coisa mais importante em paralelo.
Gerar o trabalho a partir a validação das hipóteses, e começar imediatamente tentando colocar código em produção, são um bom começo, mas para que o desenvolvimento flua a partir disso de forma rápida os incrementos tem que ser pequenos. Isso por que queremos maximizar a influência que o feedback obtido tem sobre as próximas decisões de desenvolvimento. Estórias pequenas permitem que isso ocorra mais frequentemente, multiplicando o efeito "gerativo" das mesmas.
Aplicar estes princípios permite ver resultados rapidamente em seus projetos, mas isso só vai funcionar se a equipe estiver comprometida a manter o processo simples e prestar atenção no feedback recebido a medida que as estórias forem chegando em produção e sendo testadas. Fazendo isso, você vai ter o software certo antes do que imagina!
02 Jul 2014
Recentemente recebi um convite para publicar a minha dissertação de mestrado "Cultura Organizacional e Adoção de Práticas Ágeis" de uma certa "Novas Edições Acadêmicas". Devo admitir - para a minha vergonha - que me deixei levar pelo meu ego e me empolguei com a ideia, mesmo sabendo que meu trabalho não era exatamente um marco do assunto no mundo acadêmico.
Graças aos meus antigos professores, me motivei a pesquisar um pouco mais sobre essa generosa oferta antes de responder. O que acontece é que essa "Novas Edições Acadêmicas" é a representação no Brasil da OmniScriptum GmbH & Co. KG, uma editora alemã. Pelo que eu entendi pesquisando sobre esta empresa, na Alemanha, para um aluno completar um mestrado, ele tem que ter o seu trabalho publicado, assim se criou um nicho para empresas como a OmniScriptum, que não cobram para publicar trabalhos (mas também não pagam os autores). O modelo de negócio consiste em conseguir direitos sobre estes trabalhos acadêmicos e vende livros que são gerados sob demanda.
Aparentemente eles resolveram expandir este modelo para outros países e fazem buscas semi automáticas por artigos com palavras chave interessantes e abordam os autores. O problema é que no Brasil, não existe esta obrigatoriedade de publicar e eu estaria cedendo meus direitos de autor (e tornando o resultado do meu trabalho acadêmico mais "fechado" sem ganhar nada em troca.
Ao menos isso me motivou a fazer algo que já devia ter feito a tempo: compartilhar o texto final da minha dissertação. Ele na verdade já está disponível no Lume da UFRGS como Creative Commons, mas resolvi publicar uma segunda vez aqui para não deixar dúvidas.
Sobre o trabalho
O trabalho tinha por objetivo identificar dimensões culturais interessantes, gerar uma lista de práticas (observáveis) que melhor representassem os princípios (não observáveis) e medir a adoção das práticas. Apesar de não ter me dado conta na época que escrevi, creio que estava buscando mapear a aderência dos valores expressos (práticas) em relação aos pressupostos básicos (cultura).
Entre as descobertas mais interessantes, destaco algumas:
- Standups, TDD, integração contínua, refatoração e programação em pares não apresentaram correlação com nenhum traço cultural observado. Na minha experiência, essas são as primeiras práticas adotadas por times que buscam se tornar ágeis. Parece coerente, uma vez que devem funcionar em qualquer ambiente, e por tanto são boas para começar a mudar a cultura;
- Os traços culturais mais relacionados com agilidade são "proatividade", "pragmatismo", "valorização da comunicação" (em detrimento da privacidade), assumir melhores intenções ("o ser humano é basicamente bom") e coletividade. Esses são traços frequentemente relacionados a equipes ágeis e um ambiente que "pede perdão e não permissão";
- Também foi medida a satisfação dos clientes com métodos ágeis, e a correlação disso com a participação ativa do cliente (uma das práticas ágeis elencadas) foi muito alta, ou seja, clientes que se envolvem são satisfeitos e clientes que não se envolvem não são satisfeitos. Devemos lembrar que correlação não é causa, e que a satisfação pode ser um viés pró-escolha (as pessoas gostam de ágil por que estão envolvidas nas decisões, não por que é objetivamente melhor), mas isso parece indicar que o envolvimento do cliente é importante para a sua satisfação;
Não sei se isso é tão importante para o resto do mundo quanto foi para mim, mas certamente me ajudou a entender melhor quando e por que ágil "funciona". Se quiser saber um pouco mais, pode baixar o trabalho aqui.
