Como implantar um processo de desenvolvimento onde não há processo de desenvolvimento
O artigo imediatamente anterior trata sobre implantar uma cultura de testes onde não há cultura de testes. Todavia considera-se, lá, que haja algum processo de desenvolvimento já estabelecido, coisa que pode levar o leitor a questionar: mas e se nem processo temos?.
Você também pode ler este artigo lá no MyNotes, onde foi originalmente publicado:
Processo
A teoria do software
Um processo de desenvolvimento de software começa justamente na parte mais importante de todas, que é o desenvolvimento das teorias.
Você pode ler mais a respeito nesse artigo interessantíssimo do Peter Naur: Programming as Theory Building.
O contexto deste, evidentemente, precisa de um pouco de atualização e ouso dizer que planejo escrever um artigo tentando trazer uma luz mais atual à coisa toda, embora ainda baseado na ideia central que o autor sugere, que é a seguinte: escrever software é muito mais do que editar texto e a vida ou morte de um software se dá de acordo com a vida e morte da teoria por trás da construção do texto.
Naur argumenta que o que torna os desenvolvedores capazes de manipular o texto de um programa de maneira a adequá-lo a novas necessidades não é um conjunto de regras escritas, a qualidade do texto (código) em si ou mesmo a documentação, mas sim a familiaridade destes desenvolvedores com a teoria por trás do software, do entendimento do “mundo” em torno do mesmo e o conjunto de coisas que são tão específicas em sua linha de raciocínio que tentar “documentá-las” seria mais ou menos como tentar documentar qual é o gosto de um vinho: por melhor que seja a descrição, ainda ficará extremamente aquém da realidade em si.
E a consequência prática disso é justamente o contrário do que uma mente mais afobada pode estar concluindo, que talvez fosse o caso de desistirmos de documentar: a primeira pergunta que eu, particularmente, faria para uma equipe precisando de ajuda no estabelecimento de um processo de desenvolvimento de software seria: “onde está o conhecimento de vocês?”, porque o fato de que é impossível transferir todo o conhecimento que está na cabeça dos desenvolvedores (ou seja, a teoria do software em si) para o “papel” indica justamente que precisamos facilitar ao máximo a passagem deste conhecimento e, para isso, devemos fazer uso das ferramentas mais adequadas.
Pense comigo: a empresa conseguiu contratar vinte novos desenvolvedores da noite para o dia. Isso deveria ser bom, certo? Mas a maioria das equipes de desenvolvimento consideraria isso um pesadelo. Por quê? Porque o processo de passagem da teoria é completamente desorganizado e depende quase sempre exclusivamente da transmissão oral, ou seja, do ensino direto. E havendo tantos detalhes a serem repassados, é frustrante ocupar tempo demais com aqueles que são os mais triviais.
Estes devem estar no papel. Quanto menos pudermos depender da experiência de transmissão direta, experimental, e quanto mais as trivialidades e a ideia geral da coisa puder ser transmitida de maneira “automatizada” (que se resume em “senta aí e lê isso”), melhor.
Onde está vosso conhecimento?
Minha recomendação? Que a equipe mantenha uma wiki. Nela deve ser documentado o mundo em que o software habita: as necessidades do negócio, as peculiaridades dos clientes, a forma usual de definição de prazos e, especialmente, os motivos pelos quais as decisões foram tomadas durante o desenvolvimento do software de maneira que hoje a equipe tenha este software e não nenhum de todos os outros possíveis e imagináveis.
A equipe precisa se esforçar para manter o máximo da teoria do software no papel. 100% é impossível, mas quanto maior for a taxa conseguida, mais fácil será o treinamento de novos membros e, especialmente, menos frustrante para todos.
Você já conhece a WiKey? Ela foi criada justamente para isso.
Ferramentas
Se me pergunto se há equipes de desenvolvimento que não usam um SCM/CVS acabo sempre respondendo-me que, sim, há…
Confesso que tenho aprendido coisas muito interessantes estudando diversos outros SCMs como Fossil, Bazar e até mesmo DARCS, mas minha recomendação para equipes que atuam na indústria ainda é que usem git, que tornou-se o padrão e que facilitará sua vida na hora de contratar e treinar novos membros.
Eu poderia divagar aqui, agora, sobre ferramentas de CI, CD, configuração, infraestrutura, etc, mas se é o caso de que a equipe mal usa git, talvez ainda não seja a hora para isso (ademais, aí já seria um outro artigo).
De qualquer forma,
Testes
Escrevi sobre isso no artigo anterior. :)
Acesso e controle
Pode parecer um tópico estranho, mas controlar o acesso à equipe é parte fundamental no estabelecimento de um processo sadio.
Sabe aquele situação em que o desenvolvedor está constantemente sujeito a vir alguém de outra área cutucar o ombro dele pedindo que corrija algum “bug urgente” ou que termine logo alguma implementação que está prevista para a semana que vem mas que o cliente está no telefone pedindo para agora e, sabe-se lá por que, alguém disse que ficaria pronta amanhã? Pois é. Isso é caos e confusão.
A equipe de desenvolvimento pode continuar sendo “prestativa” e disposta a ajudar sempre que possível, mas a forma de fazê-lo não pode ser desse jeito todo atabalhoado.
Essa confusão toda geralmente é resultado da falta de controle das tarefas e o resultado imediato é sempre frustração, confusão e desentendimento. Explico: quando o programador não tem controle sobre o que está fazendo agora, também não tem a menor ideia do que fez ontem e tampouco de tudo o que produziu na semana passada. Some a isso a situação caótica do entorno e logo você terá discussões envolvendo “vocês não entregam nada” da parte de quem cobra e “nós trabalhamos feito uns condenados” da parte de quem leva a cobrada.
Essa aparente disparidade entre “não entregar” mas “trabalhar muitão” não parece ser possível, certo? Como pode a equipe se matar de trabalhar e ainda assim “não entregar nada”?
Acontece que a equipe provavelmente está entregando bastante coisa, mas a falta de contabilidade faz com que as impressões imediatas e emocionadas tomem conta do panorama e eclipsem a realidade que termina habitando somente a falha memória dos envolvidos.
Por isso mesmo trouxe estes dois pontos simultâneamente: não tem como tentar limitar o acesso aos membros da equipe (geralmente estabelece-se um proxy, provavelmente o CTO ou o líder técnico) se no fim do dia a impressão que a equipe passa é sempre a de que ninguém está realmente fazendo nada. Lembra da frustração, confusão e desentendimento? Bem, queremos eliminar isso, não somente mover para algum outro lugar.
Acesso
Requisições à equipe jamais podem se dar diretamente a qualquer membro da mesma. É necessário haver algum representante que controle o andamento do trabalho e que seja capaz de prover um mínimo de retorno bem embasado a respeito de prazos, por exemplo.
Mas para isso ser possível, é necessário que este representante tenha substrato para poder embasar suas respostas.
Controle
No que você está trabalhando nesse exato momento? Se essa resposta não vem fácil, é sinal que algo está errado.
Por que, afinal, um desenvolvedor estaria em horário de trabalho sem ter noção do que estaria fazendo? Não é como se programadores fossem profissionais baratos a ponto de permitirmos que fiquem “moscando” por aí, certo?
É claro, isso é diferente de imaginar que o desenvolvedor estará 100% do tempo batendo no teclado empolgada e apressadamente. Desenvolver software é desenvolver a teoria do software, afinal, e “codar” acaba sendo o último passo do processo. Mas mesmo nos momentos mais hammock-driven, saber qual é o objetivo imediato é muito importante, pelo menos para os membros da equipe cuja função principal seja explicitamente escrever código.
Mas como tornar esse conhecimento algo cotidiano?
Metodologias ágeis
Muita besteira tem sido dita a respeito de “metodologias ágeis”. Se você ainda está em dúvida a respeito do que seria o resumo da coisa toda, já te adianto: metodologias ágeis são meramente sobre abraçar a realidade.
Precisamos abraçar a realidade de que mandamos muito mal em planejamento de médio e longo prazo, então talvez seja melhor dividirmos os problemas em partes menores para conseguir previsões mais realistas.
Precisamos abraçar a realidade de que mandamos muito mal em entender o que diabos o cliente realmente quer, então talvez seja melhor irmos entregando funcionalidades com maior frequência e de maneira incremental, de forma que jogar alguma dessas partes fora não seja um grande desperdício de recursos (pelo contrário: fazendo do jeito certo, é até uma economia).
Precisamos abraçar a realidade de que mandamos muito mal em controlar nosso próprio trabalho, então talvez seja melhor fazermos planejamentos curtos e com tarefas extremamente claras e que, de preferência, possam ser feitas em um dia.
Mas nem tanto
Precisamos abraçar a realidade de que mandamos muito mal em documentar as coisas, então talvez seja melhor desenvolvemos técnicas para documentar melhor.
Precisamos abraçar a realidade de que mandamos muito mal em manter a documentação atualizada, então talvez seja melhor desenvolvemors técnicas para conseguir manter a documentação atualizada.
As pessoas naturalmente tendem aos extremos, e diversas vezes ouvi “mas somos uma startup” como mera desculpa para ninguém documentar nada.
O famigerado “manifesto ágil” fala sobre working software over comprehensive documentation, mas também admite que there is value in the items on the right.
Há valor, sim, em documentar. Como disse anteriormente, é um passo crucial para tirar uma boa quantidade de trabalho de treinamento das costas dos desenvolvedores, além de servir de referência útil caso, por algum motivo, estes desenvolvedores não estejam mais disponíveis para ajudar.
Em 2001, quando o manifesto foi escrito, os autores referiam-se a um outro tipo de mentalidade com relação a “comprehensive documentation” (termo que não deve ser traduzido como “documentação compreensível”, mas como “documentação exaustiva ou completa”). Nós não podemos cometer o erro crasso e anacrônico de tentar torcer esta referência para o que nós hoje entendemos por “documentação”.
Sugiro novamente a leitura do artigo do Peter Naur. A teoria do software é importante, e digo que há muito valor e proveito em pelo menos tentar transcrever o máximo disso.
Ademais, tal documentação geralmente é feita a posteriori, ou seja, depois que o working software já é, bem, working software.
Cerimônias
Grooming
Você não é obrigado a fazer o que os Sacerdotes Do deus SCRUM mandam.
Na verdade, você não é obrigado a nada.
O que é importante que aconteça é que em algum momento a equipe de desenvolvimento se reúna com a equipe de negócios (caso sejam equipes distintas, claro) e escolha-se algumas das tarefas que se sabe precisam ser feitas e, de maneira conjunta, vão destrinchando-as de maneira que (1) todos entendam o que precisa ser feito e qual valor é entregue para o usuário e (2) seja possível quebrar essas tarefas em tarefas menores, de preferência reduzindo o escopo da entrega para que seja possível entregar algo avaliável pelo usuário com o mínimo de esforço de maneira razoável.
Há uma porção de pessoas inteligentes que recomendam passar longe do que chamam de “minimalismo exagerado”. Novamente, as pessoas tendem a exageros, e com a ideia do “MVP” não é diferente. Nem sempre é razoável entregar algo útil e usável sendo apenas “o mínimo”. Pode ser que seja necessário algum esforço extra. Junto a “desenvolvimento” e negócio anda, obviamente, uma certa questão “política” que muitas vezes pode envolver, por exemplo, provar para o cliente que é possível desenvolver algo específico ou a equipe toda simplesmente pode querer apostar em determinada funcionalidade baseado no que quer que seja.
É bom ficar apostando? Eu, particularmente, sou avesso. Mas você não é obrigado a nada. Se todos os adultos inteligentes, responsáveis e cientes das eventuais consequencias resolveram que vão apostar em algo… bom… quem sou eu para tentar dissuadi-los, certo?
Talvez esse tipo de coisa seja vista como uma forma de dissolver as “regras” em algo como “é proibido dançar agarrado, mas se quiser pode”, mas considero irreal e até arrogante acreditar que eu, aqui da minha torre de marfim, distante da realidade alheia, posso dar um conselho definitivo e final a respeito do que quer que seja.
Mas o resumo, afinal, é o seguinte:
- determine um tamanho de “sprint” e
- procure definir um conjunto razoável de tarefas que pretende entregar no final desse próximo ciclo
Mas não pire!
Dividir o trabalho em ciclos de prazo limitado serve para abordar o problema do planejamento de maneira iterativa, ou seja, para que vá-se melhorando a cada ciclo.
Isso tem uma consequencia simples: o primeiro provavelmente será péssimo, mesmo.
Muitas equipes, afoitas que estão para tentar acertar de primeira e, muitas vezes, mostrar para a diretoria que a “escolha da metodologia foi acertada”, acabam tornando as primeiras reuniões de grooming um pesadelo terrível: elas são longas, elas adentram nos detalhes de maneira insatisfatória e há discussões intermináveis sobre coisas que bem poderiam ser definidas em qualquer outro momento.
A primeira iteração é ruim, mesmo. A ideia é que a próxima será um pouco melhor. Por isso minha sugestão é ser estrito com relação ao time box da reunião: não deixe passar de 1 hora para cada 1 semana de ciclo.
(E outra recomendação minha é nunca ter ciclos maiores que 2 semanas.)
Então, em resumo, faça o melhor possível, mas não exagere. E tenha ciência plena de que no final dos primeiros ciclos muita coisa ficará faltando. Haverá oportunidade de melhorar isso, e a melhoria em si não é um trabalho a ser feito de antemão.
Daily
Fazendo a reunião de grooming, todos saberão qual é o conjunto de coisas que pretendem fazer durante o ciclo. Agora é hora de cada desenvolvedor conseguir saber o que fará hoje.
E, sabendo o que faz a cada dia, é fácil saber o que fez ontem e anteontem, também.
Chamo a atenção para o sujeito da ideia toda: o desenvolvedor. A daily é uma reunião que serve para cada um, não “para a diretoria”. Se a diretoria quisesse saber o que está sendo feito on a daily basis, não estaríamos sem processo algum, certo? E se ela quer saber disso, então estamos diante de um caso claro de micromanagement e encorajo a todos a irem embora o mais rápido possível.
Novamente: você não é obrigado a nada. Mas a minha experiência pessoal é a de que, realmente, limitar essas reuniões a 15 minutos tem sido o ideal.
Reunião, afinal, é o trabalho que mais me cansa e não faz sentido começar o dia com muito tempo de reunião. Queremos ajudar, afinal, não atrapalhar.
“Mas… mas… e se minha equipe tem 30 desenvolvedores?”. Para isso minha resposta é “não, não existe equipe de 30 desenvolvedores. Equipes tem no máximo 12 pessoas e mesmo estas geralmente estão realmente dividias em outras duas ou três.
Metodologias ágeis, lembre-se, são sobre aceitar a realidade. E a realidade é que não tem como 30 programadores estarem trabalhando numa mesma coisa. Se você acha que isso está acontecendo, eu acho que você é bem louco. (Mas, novamente, quem sou eu?…)
Digo isso porque a daily é da equipe. Não é do departamento, tampouco da diretoria. Não permita que managers participem desta reunião ativamente. De preferência, nem como ouvintes. Isso tira autonomia da equipe. Ademais, descubra qual é, afinal, o tamanho real de cada equipe e já faça as divisões necessárias, seja isso temporário ou não.
Retrospectiva
Todo esse primeiro ciclo foi uma droga, certo? Certo. Todos estão meio perdidos e muitos duvidam que a coisa toda vai funcionar.
Tudo certo. É assim mesmo. Tudo está de acordo com os planos, mesmo sem você perceber (sinto-me meio Palpatine falando isso).
Agora chegou a hora de identificar o que deu errado e terminar com uma lista de como melhorar. As tarefas eram muito grandes? Vamos aprender a dividir melhor. Não ficaram claras? Vamos adotar alguma técnica que ajude nisso. Subestimamos o trabalho e não conseguimos concluir? Vamos tentar estimar melhor. Faltou trabalho no fim do ciclo e ficamos puxando coisas do backlog sem muita ordem? Então vamos deixar já uma fila razoavelmente ordenada. E por aí vai.
Importante lembrar que não conseguir concluir todas as tarefas propostas não deve ser motivo de frustração, apesar de sempre ser. É assim que a coisa funciona, mesmo, e é um consolo saber que pelo menos agora é possível identificar claramente o que foi feito e o que ficou faltando.
A reunião de retrospectiva é mais importante do que a de grooming e, portanto, minha recomendação é que seja dedicado a ela 2 horas para cada 1 semana de ciclo. Se seu ciclo é de 2 semanas, o time box da retrospectiva é de 4 horas.
E o conselho permanece: não pire. O que importa é conseguir identificar como melhorar. E não se confunda: não é para listar o que saiu errado. Isso tem pouco proveito prático. Faça uma lista de pontos de ação.
Métricas
A única métrica que acredito ser realmente relevante é a porcentagem do tempo que é gasta com desvios.
Um desvio acontece quando o programador precisa parar de fazer o que foi definido na reunião de grooming para fazer alguma outra coisa, qualquer que seja: corrigir bugs, participar de reuniões, treinar funcionários novos, etc. Exceto coisas pessoais, como visitar o médico. Isso não é “desvio”. Desvio é quando a empresa desvia o funcionário do que foi proposto inicialmente.
E essa métrica é relevante porque, no fim do ciclo, ajuda a entende por que talvez a equipe não conseguiu entregar tudo o que planejava e serve de bom argumento para a equipe demandar mudanças no próprio processo. “Gastamos metade do nosso tempo corrigindo bugs que poderiam ser evitados com testes automatizados”, por exemplo, é um fato que traz à tona uma necessidade clara e um ponto de ação objetivo (que é aumentar a cobertura de testes, no caso).
E o que dizer para a diretoria?
Nada. Apenas entregue. Que a equipe busque adquirir ritmo para que se consiga mostrar muito mais do que falar, mas absolutamente não recomendo que qualquer “métrica” vaze para fora da equipe, por “melhor” que seja.
Repito: números não tem significado absoluto, mas na falta de visão mais clara, eles acabam servindo de confortável muleta para a diretoria tirar as conclusões mais bizarras possíveis.
Não me entenda mal: não estou defendendo não ter métrica alguma. Tenha os números, mas não permita que eles trafeguem pra lá e pra cá sem o devido contexto. Acompanhados eles são ótimos, sozinhos são um perigo.
Ademais, resultado concreto mesmo provavelmente só aparecerá no segundo mês. Não adianta nada usar N ferramentas e seguir M cerimônias se a mentalidade das pessoas à volta também não mudar. O objetivo, no fim, é diminuir o caos e a incerteza, e a primeira certeza que se tem é que as engrenagens que por tanto tempo estavam simplesmente paradas vão demorar, sim, algum tempo para rodarem com suavidade e devidamente lubrificadas.
Resumo
Há uma infinidade de detalhes que apenas um trabalho sério de consultoria poderia trazer à tona, mas a visão geral é mais ou menos essa.
Considerei neste artigo equipes sempre maiores do que 3 pessoas. Se a equipe é formada por 2 ou 3 pessoas, a dinâmica pode ser um pouco diferente e certas “concessões” ao padrão apresentado podem ser benéficas a curto e médio prazo (coisa que em determinados nichos pode significar a sobrevivência ou morte da empresa).
E, acima de tudo, meu conselho é sempre abraçar a realidade, por mais humilhante que possa parecer. Ficar fingindo que um plano de 2 anos será seguido sem surpresas ou que o programador consegue pegar uma tarefa “monolítica” de 1 semana e depois integrar tudo sem maiores problemas e no prazo é uma espécie de atitude esquizofrênica que não ajuda as entregas a fluírem e não diminui a frustração da equipe no geral. Imaginar que é o controle estrito da diretoria e não a autonomia responsável da equipe que trará os melhores resultados também.
Ademais, conheça minha newsletter:
