menu

Um passo a frente ou o suficiente?

Por

Recentemente passei por uma experiência interessante em uma das minhas equipes de desenvolvimento que trouxe à tona uma comparação com um evento de alguns anos atrás. Permitam-me uma rápida divagação sobre o assunto.

Há 2 anos eu era gerente/scrum master/negociador/diplomata/mago (entre outras entidades que o PO acredita ser capaz de alterar as leis do universo) de um projeto web. Na época, com menos experiência em ágil do que hoje, eu já estava em “modus desespero” tentando navegar por todas as dificuldades de um projeto próximo da data de lançamento. Lembro-me de um planning em que as histórias eram todas de evolução de funcionalidades já implementadas e que todos os esforços orçados estavam saindo mais caros do que esperado.

Em um desses casos, um C.R.U.D. muito importante para a empresa desenvolvido anteriormente, deveria enviar notificações por email aos usuários das entidades alteradas e excluídas informando quem havia feito a alteração e o que havia sido alterado. Na minha singela concepção era um serviço que leria o histórico do banco e enviaria um email.  Para minha surpresa e de todos, o custo em pontos de implementação da funcionalidade ficou o triplo do esperado.

Quando questionado o porquê, a resposta dos desenvolvedores foi que o histórico das alterações não era persistido, muito menos quem tinha feito as alterações e a única coisa implementada era a alteração/remoção do registro no banco. A minha reação foi a de alguém percebendo que os registros da entidade mais importante da empresa eram alterados e removidos sem que ninguém soubesse o que foi alterado ou quem fez a operação.

Após o planning, em uma reunião de emergência igualmente estressante, tentei entender como aquele evento havia ocorrido sem que ninguém se atentasse para o fato e a resposta gravitava sempre em torno do “foi implementado o que o PO havia pedido na história”

Voltemos ao presente. Um grooming muito menos estressante, um projeto diferente, os desenvolvedores orçando evoluções de funcionalidades já implementadas e os custos são ridiculamente baixos, tão baixo que me incomodam. Após o Grooming, em uma conversa  informal com o time para tentar entender como as evoluções estavam saindo tão baratas, a explicação de tão simples me soou como um soco no estomago: “Quando implementamos a funcionalidade a primeira vez, antevemos a evolução dela e já preparamos o código mesmo não estando na história. O preço em pontos que o PO não pagou hoje, pagou na primeira implementação”. De imediato lembrei do projeto de 2 anos atrás e fiquei pensando o que teria acontecido se essa mentalidade estivesse presente na época.

Uma diferença nas equipes de 2 anos atrás e na de hoje é que esta última já tinha um grande conhecimento do negócio e estava na empresa há algum tempo, enquanto que a primeira, apesar de já ter trabalhado em projetos semelhantes, não tinha conhecimento daquilo que estava construindo.

Analisando a situação pelo lado da velocidade de entrega, no primeiro caso as histórias iniciais são mais baratas e o MVP sai mais rápido, mas a implementação de um aprendizado do projeto é mais custoso. No segundo o investimento inicial do projeto é maior, o MVP custa mais, entretanto aprendizados com o projeto antevistos pelos desenvolvedores são implementados com menos esforço.

O primeiro caso não tem perdas por retrabalho enquanto o segundo corre o risco de perder trabalho já feito se o PO resolver não caminhar na direção prevista pelos desenvolvedores. Levando em consideração a natureza de abraçar a mudança das práticas ágeis, não sei se uma abordagem traz mais vantagens que a outra.

Qual sua opinião?

9 comments

  1. Leonardo Campos

    Hamilton, muito bom o texto e a experiência compartilhada.

    Como sempre conversamos, acredito que realmente seja ideal uma equipe que conhece o negócio e se sente parte e dona daquilo, sentindo-se mais motivada e engajada no trabalho. O que entendo é que o melhor dos mundos, pasme, seria o meio termo, explico:
    A equipe não deveria ter feito algo a mais, pois nos termos colocados isso seria sempre uma atitude especulativa e possivelmente um desperdício, mas se ela é capaz de prever que aquela determinada funcionalidade vai sofrer as alterações A, B ou C, basta conversar com o PO.
    Claro que vemos POs que simplesmente se esquecem das decisões tomadas e acusam as equipes de que era “óbvio” que aquilo seria preciso, mas se for esse o caso, talvez nenhuma alternativa seja muito boa mesmo, exceto fazer coaching do PO, né?

    Posted on fevereiro 9, 2014
  2. Julio Cesar

    Como PO, quando eu coloco uma história, eu me preparo para o pior caso, ou seja, que a equipe não tenha preparado anteriormente nada daquilo. Acho que isso dá mais consistência ao backlog.
    Porém, quando a equipe já preparou algo que vá ao encontro do meu backlog, ótimo.
    Um ponto importante, é o PO dar visibilidade a medio-longo prazo para a equipe, assim, as decisões de implementar algo a mais (ou ao menos prever o ponto de extensão), acaba sendo menos especulativa e mais alinhada com as necessidades.

    Posted on fevereiro 13, 2014
    • Rafael Buzon

      Curti Julião. Interessante a questão da visão medio-longo prazo… Uma visão bem disseminada permite que o time tome micro-decisões no dia a dia em prol da meta… nice!

      Posted on fevereiro 13, 2014
  3. Luiz Rocha

    O que me deixa mais incomodado nesse tipo de discussão — POs, processos, MVP e análises de acerto-erro — é que *sempre* se deixa de lado, se negligencia o objeto do trabalho: O Software.

    As regras, leis e axiomas que regem a criação de software dizem respeito ao desenvolvimento e a engenharia de Software. Tentar olhar para o problema como MVP, como balanço backlog-especulação-desejo do PO leva a análises e conclusões erradas, ao meu ver.

    Software apodrece. Às vezes, de maneira fundamentalmente irremediável. É requisito básico, condição sine qua non, que o software seja desejado para ser alterado, evoluído. A conseqüência é que ele precisa ser desenvolvido para se adaptar a condições futuras não-previstas. Chame de Design, Arquitetura, Programação Defensiva o que for, mas quando se conduz um time de desenvolvimento de software a fazer um MVP desconsiderando completamente que qualquer linha de código produzida pode, e vai, ser alterada, para evitar desperdício naquele momento do tempo-espaço, está se produzindo uma otimização local e nada que foi otimizado para uma condição específica é adaptável, resiliente o suficiente para sofrer novas alterações sem implicar em custos significativos.

    É por isso que o primeiro time do causo pagava caro a cada rodada de otimização local — cada vez que atendia a um caso de uso específico e uma demanda pontual — e o segundo time conseguiu produzir algo que é mais barato de evoluir. O segundo time não é vidente, não prevê o que o PO quer, mas é melhor por ser ciente do impacto que o design do software tem na sua longevidade, e incluem isso no processo de desenvolvimento.

    Independente de processo de acompanhamento do desenvolvimento ou método de definição de valor do projeto. Porque a disciplina que afeta desenvolvimento de software não é Project ou Product Management. É Engenharia de Software.

    Posted on fevereiro 13, 2014
    • Elderclei Reami

      Concordo com o Rocha. No que tange às soluções de software, as disciplinas ligadas diretamente ao que é produzido (algoritmos, teoria da computação, lógica, arquitetura e entendimento de requisitos como testability, scalability, maintainability, security, performance, portability, usability, etc, etc) são as mais importantes e, fundamentais, de serem entendidas.

      De outro lado, um software atende um propósito. Não é preciso ir muito longe, no tempo e no espaço, para saber os efeitos negativos de scope creep de um lado e gold plating do outro, então, há motivos para o minimalismo que alguns agilistas propõem.

      Eu gosto da linha do Tom Gilb, que recomenda que membros do tipo sejam mais que programadores, que sejam engenheiros de sistemas. Há mais requisitos que aqueles expostos apenas pelo PO e identificar e implementar esses requisitos está longe da responsabilidade do PO. Times com maior nível de experiência e senioridade tendem a compreender melhor que o PO dá a direção, mas quem sabe como executar com a qualidade devida é o próprio time.

      Na linha do Uncle Bob, ninguém diz a um neurocirurgião “pra ir um pouco mais rápido”, ou para “cortar um pouco mais para a esquerda”. O neurocirurgião deve saber o que está fazendo e ter autonomia para decidir manter ou mudar seus planos frente a cirurgia e as condições reais do paciente.

      Posted on fevereiro 19, 2014
    • Anselmo Eduardo Martelini Junior

      Meus pitacos:

      Indo aos extremos:

      Cenário 1 – time cheio de junior: desenvolva software com baixo acoplamento, com excelente cobertura de testes automatizados, blablabla, mas faça apenas o que o PO pediu. Existem grandes chances de você não saber para onde o produto/tecnologia irá avançar, e é melhor fazer o mínimo agora, aprender e avançar no desenvolvimento.

      Cenário 2 – time muito experiente: desenvolva software com baixo acoplamento, com excelente cobertura de testes automatizados, blablabla, e use sua experiência para deixar partes do sistema mais suscetíveis a mudanças preparadas para elas. Não desenvolva novas funcionalidade, deixe seu código preparado para elas.

      Está na dúvida? Desenvolva software com ótima engenharia, coloque o mais rápido possível no mercado, meça tudo o que puder, e evolua. É nessa segunda parte que quase todo projeto que participei erra feio. Muito feio.

      Quanto ao MVP: se você está fazendo MVP, mas MVP mesmo, de macho, evolução não é sua preocupação. Se seu MVP está preparado para evoluir ele passou do ponto, e seu time precisa ler um pouco mais de Steve Blank e Eric Ries.

      Posted on fevereiro 20, 2014
      • Leonardo Campos

        Curti a ideia do MVP de macho. Lembrei de um episódio do TV Pirata em que foram entrevistar o estilista Macho (Ney Latorraca) e perguntaram qual “tecido” ele usava. Ele, bravo, respondeu: Macho usa pano, PANO, não tecido!

        MVP de verdade é PANO!

        Posted on fevereiro 20, 2014
  4. Pingback: Tolerância Zero: Uma abordagem para a qualidade | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top