Software

Vamos falar de negócios!

Um ponto bastante observado em diversos trabalhos que realizei por aí é a incapacidade da equipe técnica de perceber o seu trabalho como parte de um negócio. É intrigante ver esses desenvolvedores (e aqui incluímos todos os papéis que desenvolvem um produto, não apenas os programadores) buscando a pureza técnica, o estado da arte daquilo que estão fazendo no seu dia a dia. Essa busca do trabalho pelo trabalho leva a um perfeccionismo negativo, conduzindo seu artista a pensar que sua obra jamais estará acabada.

Por outro lado também temos times que não estão comprometidos com nada, apenas com as atividades para si alocadas. Tais times (ou membros em cenários melhores) se enxergam apenas como parte de uma engrenagem maior, como parte de uma linha de produção cujo o seu papel é transformar análise em código. Eles apenas trabalham ali e antes que você os amaldiçoe, lembre que tem um desse cara dentro de você, algumas vezes por dia.

Tanto no primeiro como no segundo cenário o resultado é o mesmo: desenvolvimento desconectado do negócio, trabalho sem um propósito claro. Tudo o mais que falo aqui é sobre isso, entender o quanto o time compreende do seu lugar no mundo e se realmente compreende o propósito daquilo que estão desenvolvendo.

Usualmente quando esse é o ponto mais fraco da uma avaliação, uso técnicas que aproximam cliente do desenvolvedor, buscando diminuir a quantidade de telefones sem fio no meio do caminho. Quanto mais pontos houver, pior a comunicação como a própria brincadeira homônima ensina. O que a brincadeira não passa é que a relevância de qual problema o time está resolvendo diminui inversamente proporcional ao aumento dessa cadeia. A causa é a despersonalização do usuário. Até o termo “usuário” é ruim. Usando personas e escrevendo os requisitos como histórias de usuário ajudam a reconectar o desenvolvedor ao negócio e consequentemente ao usuário final.

O que estou tentando explicar é que na maioria dos casos que vi, o problema não era primariamente do método escolhido. Os times eram bons em desenvolver software. O software errado, mas eram bons. Não adianta você ser o Usain Bolt e correr pro lado errado da pista. É preciso aceitar que não se conhece o software que resolve o problema do usuário e você só vai descobrir isso criando esse software. Em resumo, traga para a mesma mesa desenvolvedores e usuários finais e aproxime essa conversa tanto quanto possível. Os resultados são mágicos e você só tem a ganhar.

Como avaliar a agilidade da sua empresa?

Essa semana meus colegas e eu entregamos mais um trabalho de assessment ágil em uma grande empresa em SP. Foi muito interessante como sempre poder olhar para um outro ambiente diferente do seu, sem as paixões do dia a dia no intuito de ajudar outro a não cometer os mesmos erros que você já fez. Esses momentos sempre me fazem pensar em coisas que vi e coisas que vivi. Vou comentar algumas nesse texto.

Ah, como é bom fazer esse tipo de trabalho! Você se torna um avaliador, passando para aquela empresa contratada a sua visão sobre o seu processo atual. O quão legal é isso? É fantástico! Afinal é sempre mais legal ajudar os outros a resolver os seus problemas do que resolver os seus próprios. O modelo de avaliação que usamos eu criei baseado em outros que vi por aí, juntando um pouco de cada um que vi, colocando um pouco de meu próprio estilo e passando para o resto do time ágil validar. Considero um bom modelo, pois avalia quatro aspectos que considero importante para uma empresa possa ser considerada ágil: cultura, organização, técnica e negócio. O número quatro não é a toa e tem forte influência do manifesto ágil e como a empresa endereça cada um dos quatro valores ali presentes. Em textos futuros pretendo escrever um pouco mais sobre cada aspecto.

Um diferencial que a Objective tem sobre as demais empresas do mercado parece até meio contraditório porém depois que eu conto a história toda passa a fazer sentido. Não somos uma empresa de consultoria. Ou ao menos não éramos. A empresa nasceu como desenvolvimento e assim se mantém até hoje. Porém temos resolvido muita coisa, tivemos muitas dores no caminho é isso nos tornou mais fortes. Contando essas histórias de guerrilhas para os amigos, esses nos pediram para contar mais e então passamos a palestrar. As palestras nos aproximaram de pessoas que queriam saber de como resolvemos nossos problemas e então passamos a oferecer-lhes consultorias e assessments. Veja, todo esse empirismo não quer dizer que não estudamos e não buscamos conhecimentos de fontes externas. Muito pelo contrário. Estamos buscando conhecimento a todo tempo, lendo livros, blogs, conversando com outras referências e participando ativamente de eventos. Nós mantemos em constante evolução e gostamos disso. Porém, somos desenvolvedores como a maioria de vocês (eu particularmente trabalho com iOS) e compreendemos os problemas que vocês passam pois passamos por eles também em algum ponto da estrada. O Agile que falo não é algo que simplesmente li num livro ou vi numa palestra, mas sim algo que vivi e vivo a todo tempo, é como solucionei os meus problemas e como sanamos nossas dores. Enfim, falar de agilidade é um enorme prazer, contar meus casos é algo que realmente me fascina. Ser pago para isso é melhor ainda.

O processo de assessment é relativamente simples. Vamos até a empresa, conversamos com pessoas chaves no processo, observamos algumas evidências é baseado no que vimos e ouvimos redigimos um relatório mostrando os principais pontos de alavancagem, aqueles que com o menor esforço geram o maior resultado. Isso é extremamente pessoal e depende da avaliação de cada agilista. Tento ser imparcial e para isso sempre busco um par que me complete nesse trabalho. Minha visão pessoal busca sempre aspectos culturais e de negócio, por isso preciso de alguém técnico para me ajudar. Esse meu par tem o trabalho de olhar para onde eu não olhei, fazer as perguntas que eu não fiz, olhar os aspectos que eu deixei passar. É belo ver que o mesmo princípio do pair programming são aplicáveis aqui também. Já escrevi algo sobre isso por aqui, recomendo a leitura.

Após essa avaliação inicial vamos até a empresa e de posse do relatório, explicamos ponto a ponto da nossa visão sobre o processo para os membros da equipe e discutimos as diferenças de visão. Expomos então um plano de ação que consideramos ser o mais interessante. Esse é um aspecto que julgo ser um dos mais legais. Normalmente, quem trabalha com consultoria já faz isso como parte do processo. Você não chega numa empresa e joga um modelo pronto. Você avalia os pontos em busca da onde se pode atuar. A diferença é que numa consultoria isso funciona como uma venda casada, você coloca essas horas dentro do seu trabalho de consultor e as vende num pacote só. Gosto mais de como fazemos porque se você se sentir capaz de implementar essas melhorias propostas vá em frente! Se sentir que precisa de ajuda com alguma delas estamos aqui de qualquer forma. Nem precisa nos contratar para ajudar em todas, somente para os aspectos que sentirem que precisam de apoio. Isso sai muito mais barato para o cliente e logo estamos livres para pegar um próximo projeto e aprender e ensinar mais em um novo contexto.

Você pode estar pensando nesse momento que serviços assim devem ser caros e contratar profissionais de uma empresa de consultoria pode ser um passo grande em direção à melhoria contínua portanto, podemos deixar para depois. A parte legal é que caso queira começar com um modelo mais simplificado e auto aplicável o meu amigo Klaus Wuestefeld escreveu um template chamado os 9 registros da agilidade. Nesse trabalho, disponível aqui, você encontra uma planilha para compartilhar com sua equipe e tem 9 aspectos que vocês devem dar notas entre 1 e 5, dependendo de como a equipe se avalia. É importante que se visualize o modelo como sendo um grande cano é que os nove registros estão ao longo desse cano. Com esse modelo em mente pode se ter certeza que a vazão desse cano se limita pelo registro que está mais fechado. Assim se em vários aspectos a sua nota for 4, mas em colaboração por exemplo a sua nota for 1, então a nota final do seu processo é 1. O seu sistema se limita pelo elo mais fraco e esse é o ponto de alavancagem, pois ele desobstrui o seu sistema para crescer.

Querendo conversar sobre avaliações de sua equipe ou querendo conhecer um pouco mais sobre os modelos da torneira, me procure que terei o maior prazer em explicar.

Extreme Pair Programming

É importante destacar, antes de mais nada, que programação em pares é uma das responsabilidades sua como desenvolvedor em XP. Não cabe ao seu chefe, à sua organização muito menos ao seu cliente interferir nessa sua decisão de qual dessas práticas no centro do diagrama você vai utilizar ou não. Então da próxima vez que alguém disser: “eu não faço programação em par porque meu chefe não deixa” mostre esse desenho abaixo e peça para ele repensar o assunto.

xp practices

Eu sempre começo meus textos com definições. Elas ajudam a entender melhor do que estamos falando e quando eu for contar os meus causos a coisa fica um pouco mais clara. Já que é assim, precisamos entender dois conceitos importantes antes de continuar. O de par e o de programação. Para começar, o par é um conjunto com dois elementos de mesma natureza, mesma espécie. Duas criaturas semelhantes juntas então formam um par. Já programação é o ato de elaborar um programa de computador. Assim, criamos código para solucionar os problemas do mundo. De maneira mais bonita é mais ou menos isso o que fazemos. Bom, então estamos falando de duas criaturas da mesma espécie trabalhando na mesma solução de um problema, no caso através de um código de computador.

Uma das maneiras que mais vejo o pessoal usando para explicar é a metáfora do piloto e navegador. O piloto, responsável pelo controle da aeronave, deve ficar atento aos controles, como dirigir para que tudo flua bem. Já o navegador é o responsável pela rota, verifica o caminho, observa aqueles controles que estão fora do campo de visão do piloto e ajuda na difícil tarefa de levar a aeronave em segurança. Na nossa prática é muito semelhante. A diferença fica que fazemos alternancias entre os papéis de tempos em tempos. Ora você é o piloto, ora você é o navegador. Usualmente o que tenho visto são duplas fazerem isso em ciclos de 15 minutos para a troca, mas não há um consenso sobre o assunto então combine entre vocês qual o tempo que lhes é mais confortável.

A prática em si é essa, alternancia de controles entre piloto e navegador, enquanto navega o desenvolvedor tem um foco um pouco mais amplo ao mesmo tempo que o piloto está focado na escrita da sua ideia de melhoria no código. Existem alguns mitos sobre programação em pares. Vamos falar de alguns.

  • Improdutivo: se medido num curto espaço de tempo, a impressão que se tem é que realmente programar em par é improdutivo e portanto mais caro para a empresa. Afinal você coloca dois “recursos” para resolver uma única tarefa, portanto estaríamos custando o dobro nesse cenário. Essa é uma visão de curto prazo e já está mais do que provado que a longo prazo esse custo se paga, com a redução da quantidade de bugs e elevada manutenabilidade do software. O código tende a ficar mais limpo e compreensível, entre outras vantagens que falarei mais a seguir.
  • Invasão de privacidade: certamente que sim. Você divide parte do seu tempo com outro desenvolvedor num espaço físico mais restrito (o espaço de uma mesa). Assim, aquela notificação que chegou para você no cantinho da tela inevitavelmente vai ser percebida pelo colega. Aquele assunto pessoal que você tinha para resolver pelo celular também agora já tem um expectador extra. Parte da sua vida será sim compartilhada.
  • Cansativo: muito! Trabalhar focado em par gera um cansaço acima da média. É recomendável o uso de outras técnicas auxiliares como pomodoro para garantir que não se exagere quando estiver trabalhando demais.
  • Sagrado: de maneira alguma! Se em algum momento você julgar que a tarefa é demasiadamente simples para colocar desenvolvedores nela então não faça programação pareada. Somente tenha cuidado para agora não usar isso como desculpa para não experimentar essa técnica.

As principais vantagens dessa técnica são:

  • Aprendizado: as duplas tendem a colaborar em experimentar novas técnicas e novas maneiras de escrever soluções para os problemas do dia à dia.
  • Motivação Mútua: pode parecer piegas, mas quando o problema que se está tentando resolver for complicado demais, você tem um amigo ao seu lado com o mesmo objetivo que você lhe motivando a seguir em frente.
  • Padronização: o código após a adoção da programação pareada migra de ter a “cara” de determinado programador para ter a “cara” da equipe. É difícil identificar qual o indivíduo dentro da equipe escreveu aquela funcionalidade, o diminui os dedos apontados em caso de falha e distribui o mérito em caso de sucesso. Fortalece o espírito de identidade do time.
  • Redução de Bugs: você tem dois cérebros, duas máquinas pensantes, duas threads abertas para resolver um problema. Enquanto um está focado no micro escopo, olhando aquela função ou aquela parte dela o outro tem uma visão mais macro, pensando nos impactos e se o restante do código fica bem com aquela alteração. Suas chances de criar algo que venha a dar defeito diminuem drasticamente dessa maneira.
  • Proximidade: sim, saímos do nosso mundinho fechado e começamos a conversar uns com os outros e em alguns casos até de coisas não relacionadas à software. Descobrimos novas afinidades, marcamos mais churrascos e confraternizações simplesmente porque começamos a ver mais fortemente mais interseções do que divergências.
  • Comunicação: aprendemos a nos comunicar, temos de expressar nossas ideias ao par antes de implementar para validar se existe alguma brecha de problema nela.
  • Foco: as distrações são bem menos percebidas quando você não está sozinho. Aquela notificação você deixa para ler depois, aquela mensagem do whatsapp que chegou provavelmente pode esperar até a próxima pausa. É mágico perceber que até mesmo o ambiente de trabalho respeita o par, pois sabe que ele está focado resolvendo um problema e interfere menos no seu trabalho.
  • Disseminação do conhecimento: deixei esse para o final pois é, na minha opinião, a mais importante das vantagens. Você reduz drásticamente o tempo de treinamento, pois agora você tem o suporte de alguém muitas vezes mais experiente para realizar a tarefa. Não existe mais o dono de uma parte do código, no mínimo existe uma dupla que é dona. Assim, se você rodar (trocar os pares) de tempos em tempos (algo como quinzenal) é visivelmente a maneira mais interessante de fazer o conhecimento circular dentro da sua equipe e quem sabe até da sua organização.

Com todas essas vantagens, fica difícil se posicionar contra uma prática tão difundida e tão bem defendida na comunidade. Se você ainda não tentou, experimente hoje mesmo e veja o seu código melhorar além é claro, de você crescer muito como profissional.

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.

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.

Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.