Agile

O problema não é da arquitetura

Estive recentemente palestrando na XP Conf BR, iniciativa muito legal dos meus amigos gaúchos para falar um pouco sobre “agilidade de raiz”. Essa agilidade de quem realmente faz o código, de quem escreve código e quer fazer bem feito. Falamos muito sobre as práticas da programação extrema e algumas outras coisas correlatas. É legal que, de uns tempos para cá, eu ando muito reflexivo e questionando quase tudo e todos. Talvez seja só um mal (ou bem) da idade mas o fato é que toda situação que me deparo tem me puxado um pensamento e esses eu tenho compartilhado por aqui. Foi muito bom rever meus amigos falando de Pair Programming, de Histórias de Usuário, de metáforas, entre outros assuntos legais. Assuntos teóricos, outros com casos reais de implantação, enfim, tudo ótimo. Mas a reflexão que isso me puxou é a seguinte: o problema realmente está na arquitetura?

Eu por vezes me vi tentado a pensar que sim, que como desenvolvedor eu via meus pares criando códigos de maneira quase irresponsável. Sim, irresponsável, afinal, a responsabilidade pelo código que escreviam era do gestor, do dono da empresa, ou ainda da criatura maligna do cliente que realmente não sabe o que quer, ou ainda não sabe pedir direito. Quando a gente vai num evento como esse, cheio de desenvolvedores, ávidos por escrever código de qualidade eu me questiono aonde estamos errando pois a realidade é bem distante da utopia que falamos nas palestras.

Nas palestras a gente fala de como deveria ser. De como nos fariam felizes que nossos ambientes de desenvolvimento fossem. De como seria legal que os valores ágeis, aqueles do manifesto, fossem seguidos como um código de conduta. É assim que baseio a minha vida e me parece plausível fazê-lo quando estou trabalhando. Pensar em pessoas e interações, software que funciona, colaboração com cliente e adaptação serem mais importantes que processos, documentos, contratos e planos parece fazer bastante lógica na cabeça de todo mundo que eu converso. Mas aonde estamos errando? Por que temos tanta dificuldade de convencer gestores sobre isso? Uma ideia que vem martelando na minha cabeça há tempos é que nós não entendemos o manifesto. Não entendemos a profundidade da mudança de pensamento exigida para fazer aquilo ali ser real. Vejo usualmente os desenvolvedores traduzindo “indivíduos” como “minha equipe”. É fácil se esquecer que em todos os níveis da nossa organização existem indivíduos, pessoas, seres humanos, de nossa espécie, e que esses são afetados se fizermos um trabalho mal feito.

De novo, não acho que o problema seja de arquitetura, tenho plena fé que meus amigos desenvolvedores são extremamente hábeis técnicamente para resolver os problemas que surgem e se não forem são capazes de evoluir a ponto de superar os obstáculos. Eventos como o XP Conf me mostram isso. O problema é que nós não nos importamos com as pessoas. Nem mesmo aquelas dentro da nossa organização, quem dirá aqueles que vão usar o nosso código para solucionar problemas em suas vidas.

Como classificar a agilidade?

Certa vez um programador de uma equipe que eu estava treinando me perguntou “O que é ser ágil?”. Eu fiquei surpreso que depois de tanto tempo pensando dessa forma eu ainda não sabia como descrever a minha maneira de pensar em poucas palavras. Aqueles segundos correram bem longos na minha cabeça quando finalmente me veio a resposta que eu costumo dar em eventos e palestras. É buscar a excelência no seu campo de domínio, o desenvolvimento de software. Mas isso acendeu uma luz em minha cabeça que precisava de atenção. Foi então que percebi que esse ponto precisava ser melhor trabalhado.

Eu costumava dividir os aspectos da agilidade em dois somente. Existem ferramentas muito ricas para a área de gestão. Gestão de projetos, de processos, de métricas, de fluxo de atividades. Não vou nominar para não ser injusto com nenhum, além do que nem é o meu objetivo aqui. Existem outras que são para o trabalho do desenvolvedor, que eu chamo de arquitetura. Ali temos especialmente as práticas do Extreme programming, a entrega contínua só para citar algumas. Resumindo, no meu entender haviam apenas duas grandes áreas, gestão e arquitetura. Isso atendia bem minhas necessidades e me ajudou a fracionar aquela resposta. Assim, se depois dessa divisão na minha cabeça alguém me perguntasse novamente sobre o que é agilidade eu diria que existem a agilidade para a gestão, que é a melhoria dos processos, reduzindo o tempo de feedback e aprendizado sobre o produto da empresa e existe também a agilidade para desenvolvimento que seriam o conjunto de práticas e ferramentas que usamos para nos permitir atender essa necessidade da gestão.

A parte legal é que sendo ágil, eu posso até criar uma definição que me atende hoje, mas se aprender uma melhor eu não preciso me apegar na minha ideia original. Posso usar a nova com seus devidos créditos, obviamente. Eu vi isso acontecer bem recente no Gathering do Rio de 2015. Participando da sessão de ScrumMaster 3.0 do Rodrigo de Toledo (o cara!) vi que ele, junto com seus amigos/sócios criou uma classificação de Agile em quatro grandes áreas. Isso é certo ou errado? Não sei, mas faz sentido em seu contexto e provalvemente tem funcionado para ele desde então e pode ser que também funcione para você. Basta que você experimente e valide a ideia em seu contexto.

O segredo da agilidade é o seu pensamento. Pensando de maneira ágil e evoluindo esse pensamento conseguiremos chegar à um novo patamar e quem sabe até a um novo pensamento que substitua o ágil. Domine o pensamento ágil a ponto de, um dia, poder criar o seu próprio modelo que atenda as necessidades, sem perder os valores iniciais.

Ainda somos ágeis?

Ou será que um dia já fomos? Eu tenho me pego com frequência pensando sobre isso. Sobre o que é ser ágil ou um agilista. Sobre os conflitos entre pessoas e grupos clamando ser mais ágeis que outros, determinando que tais e tais práticas são dignas de pertencer ao panteão da agilidade ou não. Isso me fez pensar se ainda estamos indo no caminho certo, se é que algum dia já estivemos.

Quem em conhece, sabe que eu sempre falo do manifesto. Não tem como eu não falar, especialmente quando é isso que resume também esse pensamento em ser ágil. Veja, talvez agilidade como um movimento, como algo organizado realmente tenha nascido ali. Mas o incomodo e diversas práticas que hoje chamamos de ágeis já existiam. O que aconteceu ali foi que rolou um grito de independência, um desabafo, aqueles programadores precisavam se manifestar (pegou a referência?) sobre as suas insatisfações, sobre o que lhes dava (ou daria) tesão de ir trabalhar. Ou seja nós, programadores, fizemos algo impressionante até então: afirmamos com todas as letras os valores que temos dentro de nós. E daquele dia em diante, nos sentimos mais ágeis.

Perceba que o manifesto é curto. Conciso e simples. Mas como ouvi esses dias, o demônio está nos detalhes. Simplicidade não é simplista. Tem muita coisa ali. Muita mesmo. Nem quero começar a debater os valores do manifesto, aquela balança que tem ali no meio. Quero chamar a sua atenção somente para o cabeçalho e pro rodapé, tão esquecidos e deixados de lado. O cabeçalho fala de que como somos nós quem realizamos o trabalho de desenvolver software, somos nós as pessoas mais indicadas para determinar melhorias e sugestões úteis nesse trabalho. Nossa, descobriu a pólvora, certo? Por incrível que pareça, sim. Sempre fomos uma categoria de profissionais otimistas, com um perfil de isolamento ou tribal, que não entendemos do negócio ou não nos preocupamos. Essa era a visão (que ainda persiste em diversos círculos) do profissional de desenvolvimento do software. Esse início foi necessário para determinar a nossa capacidade de enxergar além do nosso próprio trabalho, para mostrar como nos importamos com o resultado final e que queremos melhorar a maneira como fazemos as coisas. E então demonstramos nossos valores.

A parte legal sobre os valores é que a gente os colocou numa espécie de balança. Basicamente dissemos assim: entendemos que esses oito tópicos aqui são importantes, quem sabe até vitais para uma organização, mas desses oito, nós enxergamos mais valor nesses quatro aqui. E é por isso que o rodapé existe e não pode nunca ser ignorado. Sem o rodapé aquelas falácias tão famosas como que agilidade não planejamento, não tem documentação, é uma festa, só ganham mais força. É uma balança desiquilibrada de propósito, mas que os dois pratos têm seu peso. Temos documentos, mas só os que usamos. Temos planos, mas apenas para curto prazo, pois entendemos que mais que isso seria desperdício. Sem o rodapé isso se perde. Muito cuidado para não usar o manifesto incompleto.

O que eu quero falar com esse meu desabafo é que ser ágil é muito mais do que seguir um processo X ou Y. Os processos são muito úteis e nos ajudam a começar a melhorar as maneiras como fazemos as coisas, baseado nas dores de outros. Com o tempo, as suas dores virão e você tem que criar sua maneira de resolver. Afinal nós estamos descobrindo novas maneiras de fazer software todos os dias, fazendo-o nós mesmo e ajudando outros a fazê-lo. Evolua meu amigo e depois me conta como foi, pois esse é o espírito.

Dicas para escrita de histórias de usuário

No post anterior eu falei um pouco sobre a história das histórias de usuário, seu template e sua finalidade. Hoje falo um pouco sobre algumas dicas que juntei por aí sobre como escrever boas histórias.

Ao iniciar o seu backlog, escrevendo as suas primeiras histórias, comece com histórias que tenham alguma meta envolvida, algo que realmente entregue valor para o cliente. É muito interessante vermos como as coisas são nas universidades. No meu tempo (idoso mode: ON) quase que invariavelmente se ensinava a fazer um sistema de locadoras. Com poucas variações, a grande maioria das faculdades naqueles tempos faziam o mesmo. Nós, como inocentes aprendizes íamos ali, criando novos softwares começando, quase sempre, pelos cadastros, quando o que realmente entrega valor numa locadora é a função de locar. Cadastrar os clientes, as mídias, todo o resto é acessório para o ato de locar. Vejam o quanto isso é a inversão desse valor, o quanto estamos acostumados a entregar o que nos parece mais confortável do nosso ponto de vista. Para o cliente, o meu cliente como desenvolvedor, ter todos os dados daquele blue-ray é importante, mas o mais importante é a locação. Com isso, nasciam cadastros com campos sem necessidade, mesmo cadastros inteiros sem necessidade aparente. Começar pelas histórias que são importantes te dá a possibilidade de validar os acessórios.

Ao dividir as suas histórias, lembre-se que uma história é uma entrega de valor. Para que uma história atenda a isso, ela não pode ser algo que vai entregar somente uma camada do sistema. Histórias que alteram somente o visual, somente o banco, ou somente a regra de negócio devem ser observadas com muita atenção, buscando sempre a entrega de valor. Embora existam situações nas quais realmente uma mudança de design entregue valor por si só, muitas vezes já vi pessoas criando histórias somente para adicionar campos novos no banco de dados, sem uma explicação do porquê. Pense nas histórias como uma fatia de bolo e não como uma camada dele. Uma boa história de usuário vai entregar um pedaço de cada camada do bolo, tal qual uma fatia.

Outra dica muito importante é colocar os critérios de aceitação no cartão da história. Isso ajuda ao cliente a entender os limites da tarefa e ajuda o desenvolvedor a entender quando ele realmente a completou. Eles devem ser claros o bastante para que sejam entendidos pelos envolvidos. Os testes podem ser escritos em qualquer formato que os leitores concordem como sendo conveniente, cenários, tabelas-verdade, o que for interessante. O fundamental nesse momento é que os critérios nesse momento sejam testáveis, sejam validáveis de maneira simples. No fim das contas eles certificam que as história implementadas correspondem ao que o cliente necessita. Sempre que possível, automatize o processo de validação das histórias. Utilizando uma combinação de integração contínua e testes funcionais, algo como Jenkins e JUnit (para Java), os resultados podem ser realmente potencializados.

Embora todo o time, até mesmo o cliente possam escrever histórias e ajudar na formação do backlog, a responsabilidade por escrever as histórias, por gerenciar o backlog completo é o Product Owner, quando estamos falando de Scrum. Observe que o uso de Histórias de Usuário não é algo de uma única metodologia, mesmo quem costuma usá-las.

São trabalhadas e amadurecem à medida que a análise progride. Não se deve ter todo o backlog escrito no início do trabalho. Isso seria considerado um desperdício. Uma metodologia ágil, ao menos a maioria, prega que isso seria um desperdício, pois seria como tentar adivinhar tudo o que o software teria logo no início na coleta de requisitos. Ter um ou dois sprints ou ainda uma ou duas semanas bem detalhadas já é o suficiente para um bom andamento do ciclo de trabalho

Para finalizar, o que acontece com as histórias após terem sido feitas e validadas pelo cliente? Bom, caso você queira manter alguma rastreabilidade, para fins de nostalgia ou ajudar a se lembrar do que foi entregue pode manter uma cópia das histórias. Mas elas não foram pensadas para isso. Foram pensadas como uma ferramenta para execução do trabalho e não com fins de registro ou documentação. Assim, após a sua validação podem ser descartadas.

Bom, isso era um pouco do que eu tinha para falar sobre Histórias de Usuário/User Stories. Até o próximo post.

Referências:

A história de uma história

Dia desses escrevi aqui sobre as técnicas que mais usei para levantamento de requisitos. Naquela oportunidade citei que seria interessante um post mais específico para falar sobre o meu método preferido, as user stories, ou histórias de usuário.

A minha predileção por esse método se dá pela sua simplicidade. Estamos falando de papéis coloridos pregados em uma parede e em linguagem natural, aquela que falamos no nosso dia-à-dia. Muito embora o modelo seja simples, alguns cuidados devem ser tomados para seu bom uso e garantir a sua efetividade.

Segundo o meu amigo Heitor Roriz, histórias de usuários…

“…provêem uma apresentação fácil de compreender e de forma concisa sobre uma determinada informação. São geralmente numa linguagem informal e contém o mínimo de detalhes, deixando os demais dados aberto à interpretação. Elas devem ajudar a entender o que o software deve englobar.”

Isso significa que as US (user stories/histórias de usuário) funcionam como um “nivelador de linguagem”, trazendo para o mesmo nível de entendimento o cliente, o cara de negócios, que pode não entender nada de programação e o desenvolvedor, o cara que vai resolver aquele problema usando o conhecimento técnico. É muito interessante pois a US é um convite ao debate, à conversa. Ela é pequena e concisa de propósito, para que você tenha que discutir os detalhes com quem fez a solicitação e durante essa conversa novos tópicos possam surgir.

Um outro ponto importante é que elas devem ser acompanhadas por critérios de aceitação para ajudar a elucidar os comportamentos aonde as histórias pareçam ambíguas. Os critérios de aceitação seriam algo como os testes que indicam a quem for desenvolver quando a sua tarefa foi completada. Os critérios podem ser pequenos e simples, algo como uma regra de validação, ou mesmo mais complexos, dando origens a novas histórias.

Um modelo nos foi sugerido por Mike Cohn, dizendo que opcionalmente eu poderia ter a terceira cláusula (o porquê). Eu respeitosamente discordo, mas vamos falar disso mais adiante. O modelo proposto é o seguinte:

Como um [papel],
eu quero/desejo [objetivo/desejo]
então [benefício/razão]

Entendendo bem as partes, comecemos com o papel. Se você estudou um pouco de UML deve estar fazendo a relação na sua cabeça com o ator de um use case e está correto. Aqui estamos falando da pessoa que se beneficiará se essa história for desenvolvida. Isso é legal, pois como desenvolvedor você saberá com quem tirar suas dúvidas durante o desenvolvimento do produto. Nem sempre você terá funcionalidades que serão utilizadas somente por um único papel, ou mesmo por um papel tão simples que possa ser descrito de maneira sucinta. Nesses casos, o que é recomendado é o uso de personas, que nada mais é do que criar personagens com as características que um determinado perfil de usuário possui. Uma boa persona descreve algumas características básicas como:

  • Um nome, idade e um estilo de trabalho e vida definido
  • Um bordão para distingui-lo de outras personas
  • Atributos chave que afetam uso e expectativas do produto, serviço ou website
  • Tarefas frequentemente realizadas
  • Ferramentas e recursos utilizados
  • Pontos de atenção relevantes ao projeto

Usualmente não se criam mais do que 8 personas por projeto, dada a sua complexidade. É possível fazer algumas atualizações durante o projeto, mas isso é bem incomum. Enfim, não comece o seu projeto criando um punhado de personas, deixe que isso emerja da necessidade. Conforme você for escrevendo suas histórias, vai surgir em algum momento algum papel que precise de um pouco mais de atenção e talvez seja o momento de reunir o seu time e escrever seus personas. Ou sua equipe pode realmente se sentir mais confortável em saber quem vai usar o sistema desde o primeiro momento.

Por hoje é só, no próximo post, falarei algumas dicas de escrita para iniciar o seu backlog.

Spice girl manifesto

Eu sou um cara casado. De casamento já se vão oito ótimos anos de vida juntos. Mas nos conhecemos antes disso, mais ou menos uns cinco anos antes. Somando tudo posso dizer que temos uma excelente convivência, uma vida compartilhada por assim dizer a pelo menos treze anos. Ainda assim, não posso dizer que a conheço completamente. Não sei de todos os seus anseios ou vontades, de todos os seus desejos e existem muitos momentos em que ela diz uma coisa querendo dizer outra. Embora isso possa parecer um lamento, é só um fato, que eu aceitei e levo a nossa relação tendo isso em mente. Mas é bem interessante de se pensar que pessoas que dormem e acordam juntos, que compartilham suas vidas de maneira tão intensa não sejam capazes de compreender as vontades um do outro por completo, não é mesmo?

Se mesmo com toda essa intimidade eu aceito o fato do desconhecido, porque você exige do seu cliente algo diferente quando vai iniciar um projeto? Sério, o paralelo não é tão distante. Vocês mal se conhecem, são pessoas em última instância, não empresas. E são desejos/necessidades de pessoas que precisam ser traduzidos em requisitos de software. O mal entendimento desses desejos e vontade pode sim decretar o sucesso ou o fracasso de um projeto. Assim como em casa eu uso várias técnicas para entender o que minha esposa espera de mim, aplico o mesmo pensamento no trabalho.

Outro problema, é a distância entre o desenvolvedor e o cliente. A começar pelo idioma. Enquanto o desenvolvedor entende profundamente o que acontece dentro do software é bem incomum ver esse mesmo profissional entendendo o que acontece no lado do negócio. Mais incomum ainda é ver o contrário, pessoas de negócio que entendem como o software funciona. Assim, esses profissionais falam idiomas diferentes e sua compreensão fica defasada por conta disso.

Só para fins de curiosidade, o título desse post veio de um treinamento de Kanban, ministrado pelo próprio David Anderson, no qual ele disse que mais do que o manifesto ágil, precisávamos agora de um manifesto spice girl. Vendo o espanto dos alunos, ele explicou: So tell me what you want, what you really really want… enfim, entender o problema, a necessidade, é metade da solução.

A seguir eu alguns métodos que usei em algum da minha vida. Não os estou julgando (ainda)…

Questionários
Uma técnica bem antiga, no qual o analista redige questionários e os entrega aos usuários chave do sistema. Muito útil com equipes mais tímidas ou para captar o máximo de respostas de todos os membros da equipe.

Entrevistas
Quanto os questionários se mostram muito frios, uma investigação mais profunda se faz necessária. Marcar entrevistas com os usuários, isolados ou em grupo, pode ajudar a esclarecer diversos pontos que outros métodos deixaram em aberto.

Observação
Nada mais simples do que, ao se automatizar algum processo, observá-lo e ver como o mesmo ocorre, sem depender da narração de outra pessoa. Nós temos o hábito de suprimir etapas, acreditando que são óbvias, ou que estão subentendidas no que já foi dito. Para evitar assunções, veja por você mesmo.

Análise de documentos
Verificar como as informações são registradas atualmente nos permite mapear muito de como o sistema deve ser e inferir quais mecanismos e processos o sistema deve ter para que possa atender àquela necessidade. Reconheço que usei muito dessa técnica no passado.

Essas quatro técnicas foram das que mais usei quando o assunto era automatizar/informatizar um processo que já existia, ou fora dos computadores ou mesmo dentro, em planilhas ou sistemas isolados, integrando tudo. Poderia usar a palavra “simples” para descrever esses sistemas, afinal, buscavam “somente” transformar o processo atual em algo mais dinâmico e seguro. Muito embora ainda exista demanda para esse tipo de sistema, a maior parte dos trabalhos que chegam até mim na última década está bem longe disso. As pessoas chegam com novidades, apps, webapps, enfim, soluções para coisas que não existem no mundo real. Esse novo tipo de aplicação exige uma nova abordagem. Mais do que buscar entender como um processo funciona, agora precisamos validar como o processo foi imaginado para entender se tudo é como se pensou. Assim, seguem os que uso nesse tipo de situação:

Brainstorming
O bom e velho “toró de parpite”. Aqui buscam-se todas as ideias possíveis e mais tarde nós a validaremos e pensaremos em qual rumo tomar. A proposta é muito simples: gerar o maior número de insights sobre o problema que o nosso aplicativo quer resolver.

Prototipação
Existem diversos tipos de protótipos. Desde usando ferramentas, frameworks até mesmo o bom e velho papel e caneta. Sério, isso já me salvou em algumas situações. O nível de realidade que se vai usar aqui depende somente do nível de abstração que seu cliente e você conseguem suportar. Enquanto existem pessoas que conseguem entender alguns rabiscos no papel e imaginar como a partir daquilo surgirá um aplicativo, muitos outros têm dificuldade e precisam de um detalhamento mais próximo do resultado final. Cabe ir avaliando isso ao longo do levantamento de requisitos.

Use cases
Como eu já ouvi gente batendo forte em use cases eu sou obrigado a citá-los aqui. Sim, eles são bons e são necessários. Eu acho bobo voltar àquele debate sobre a documentação, mas só para mencionar, sim, existem documentos que são necessários e precisam ser atualizados, mesmo na visão do mais fundamentalista dos agilistas. A parte boba disso é acreditar que isso (ou o oposto) se aplica a todo e qualquer documento. Tendo isso como posto, já tive processos complexos que precisaram não só de um use case, mas também de um diagrama de sequência para ficar claro para todo mundo. Depois que a tarefa foi cumprida o documento foi desprezado, mas para a sua execução esses documentos foram de vital importância.

e finalmente User Stories!
Como eu gosto muito desse modelo, eu vou deixar aqui só um gostinho, deixo para um outro post falar mais sobre o assunto. O que eu preciso dizer de imediato é que é uma das formas mais simples de coleta de requisitos, trabalhando com uma língua que desenvolvedor e cliente conseguem entender, dividindo o trabalho em unidades que agreguem valor ao produto/projeto, definindo critérios claros de validação para que todos os envolvidos saibam sem sombra de dúvida que o trabalho foi concluído.

Conclusão
Sem o menor preconceito, já usei todas as técnicas acima, umas mais ou menos, sempre buscando entender o que meu cliente precisava. Um bom desenvolvedor vai ter sempre uma boa caixa de ferramentas preparada para usar a certa no momento mais propício. Entender o problema é metade da solução.

Tem-gente-que-nao-sabe-pedir