Quando trabalhamos com Desenvolvimento Ágil, nós, desenvolvedores, assumimos uma postura diferente. O perfil do “desenvolvedor ágil” exige mais comprometimento, comunicação e colaboração de acordo com as diretrizes da metodologia. Porém, isso não significa que somos obrigados, por exemplo, a concordar com todas as solicitações do Product Owner.
Não é fazer cara feia. É simplesmente ser profissional.
O assunto de hoje é relacionado com os verbos “tentar” e “achar”. Muitos desenvolvedores, na tentativa de mostrar serviço, se comprometem a entregar um “zilhão” de funcionalidades do Product Backlog, mesmo sabendo que será custoso, cansativo e que, talvez, não será possível. Isso é grave…
Assim como já destaquei em outros artigos, no contexto de desenvolvimento de software, ser ágil não se traduz em ser mais rápido, energético e implementar o dobro de funcionalidades selecionadas. Já vou dizendo: concordar com tudo não é ser profissional.
O motivo é simples. Quando uma equipe ágil se compromete a implementar funcionalidades além da própria capacidade, ela estará automaticamente conduzindo a Sprint para o atraso. Esse comprometimento inviável é fomentado quando a equipe diz que “vai tentar” ou “acha que vai conseguir”. Ao ouvir essas afirmações, os gestores assumem que todos os requisitos serão entregues no final da Sprint e já saem fazendo promessas para o cliente. Para eles, “tentar” e “achar” são sinônimos de “sim” e demonstram confiança. Resultado? Quando terminar a timeline da Sprint e houver funcionalidades ainda não implementadas, começarão os conflitos, busca pelos culpados e a temporada de horas extras. Isso é correto?
Desenvolvedores ágeis devem desconhecer estes dois verbos. Ou a equipe faz ou não faz. Para isso, desenvolvedores devem estabelecer a autonomia de dizer “não” quando identificarem que não é possível entregar as user stories designadas pelo Product Owner.
É justamente aqui que mora o problema. Muitas equipes sentem receio de contestar as solicitações do Product Owner por pensarem que esse comportamento é antiético ou inadequado no contexto corporativo. Para elas, quanto maior o número de funcionalidades implementadas, melhor será a visibilidade conquistada na empresa. Não é assim que funciona! Se uma das funcionalidades já não for entregue, por menor que seja, a equipe transmitirá uma impressão de ineficiência ou, no pior dos casos, irresponsabilidade por prometer uma entrega que não foi concluída. A consequência é a inversão da imagem: ao invés de serem reconhecidos, serão difamados.
Desenvolvedores ágeis dizem “não”. Sabe porque isso é ser profissional?
O Product Owner e os gestores de projeto esperam que desenvolvedores sejam realistas, e não otimistas. Eles esperam que a equipe tenha a coragem de recusar as demandas e apresentar os motivos, encarando a realidade do trabalho a ser realizado. Ser otimista, mais uma vez, nos leva aos dois verbos mencionados acima.
Alguns Product Owners insistirão, claro, na implementação das funcionalidades, e se irritarão quando a equipe contestar. Deixem ficar irritados. É muito mais digno declarar que não será possível entregar uma funcionalidade (por falta de recursos, tempo ou outra condição), do que prometê-la e ter que se desdobrar para conseguir finalizá-la. É assim que uma equipe ágil ganha confiança da gerência. Nas próximas Sprints, os gestores já compreenderão que, quando a equipe diz “não”, é não mesmo!
Olhem só o diálogo abaixo:
Product Owner: “Vamos incluir também essa funcionalidade para gerar gráficos de vendas mensais na nossa Sprint.”
Equipe: “Não, não será possível.”
Product Owner: “Como assim? Isso é importante para o cliente! Precisamos implementá-la.”
Equipe: “Não. Essa user story não se encaixará no nosso Sprint Backlog, pois já temos atividades suficientes.”
Product Owner: “E se fizermos algumas horas extras no final de semana?”
Equipe: “Não. Dessa forma estaremos trabalhando além da nossa competência, logo, não garantiremos a conclusão.”
Product Owner: “Mas o cliente está esperando essa funcionalidade nessa versão. Vamos tentar, pelo menos?”
Equipe: “Não. Há uma possibilidade de tentar e não conseguir. Não gostaríamos de nos arriscar e comprometer a entrega.”
Product Owner: “Preciso disso. O que vocês sugerem?”
Equipe: “Remova uma user story da Sprint para que possamos encaixá-la, ou negocie a disponibilização dessa funcionalidade com o cliente para a próxima versão.”
O segredo é “bater o pé”, pessoal. No final dessa reunião de planejamento, garanto que os desenvolvedores sairão mais confiáveis. Novamente: não é fazer “corpo mole”. É simplesmente saber trabalhar.
Dizer “não” envolve mais do que confiança. O Product Owner e a gerência serão mais assertivos nas próximas decisões com o cliente e apresentarão uma negociação mais realista, melhorando o orçamento do projeto e o ROI. O cliente, por sua vez, sentirá mais segurança nos compromissos da empresa em relação às entregas.
Para fechar, deixo uma mensagem do Mestre Yoda que se encaixa perfeitamente nesse artigo:
Faça ou não faça. Não existe “tentar”
Obrigado, mestre Yoda! 🙂
Abraço, pessoal!
André Luis Celestino
Mais artigos deste autor »
Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.
CONTEÚDOS RELACIONADOS
4 Comentários
Leonardo Teixeira maio 29, 2015 às 8:41 am
1
Ótimo post André! Show!! Parabéns!
André Luis Celestino maio 29, 2015 às 12:14 pm
2
Obrigado, Leonardo!
Gabriela maio 30, 2015 às 9:39 am
3
Olá, gostei muito do post. O diálogo usado como exemplo é exatamente o que devemos fazer, muito bom.
André Luis Celestino junho 1, 2015 às 1:04 pm
4
Olá, Gabriela!
Obrigado pelo comentário! 🙂
Deixe seu comentário Cancelar resposta
Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!
Comentário
Nome *
E-mail *
Site
Salvar meus dados neste navegador para a próxima vez que eu comentar.
artigos aleatórios
Luiz Dias
Coaching: o que é e como você, profissional de TI, pode se beneficiar desse método?
Jorge Pretel
JLCP é o mais novo parceiro oficial Zabbix SIA no Brasil
Redação PTI
Concurso Público: Câmara Legislativa DF
William Meller
Inovação começa com simples mudanças no dia a dia
Carolina Souza
Os Desafios da Mulher na TI
X
O Profissionais TI (PTI) é um portal colaborativo criado em 2008 que tem como principal objetivo a disseminação de informações relacionadas a área de Tecnologia da Informação (TI)