Do Scrum ao Kanban: a diferença entre o pré-lançamento e o pós-lançamento de um projeto de comércio eletrônico

Pré-lançamento: os sprints direcionados ao prazo de entrega

No princípio há um prazo de entrega, tipicamente decidido pela equipe de marketing ou pelos gestores de alto nível, desejavelmente validado pela equipe de desenvolvimento. O lançamento de uma plataforma de comércio eletrônico caminha de mãos dadas com as campanhas de marketing, a fim de potencializar a máxima atenção para a nova loja virtual. Todo o desenvolvimento é, então, organizado de acordo com a data de seu lançamento, com flexibilidade no escopo mas sempre visando maximizar o valor do negócio.

Na Valtech utilizamos a metodologia ágil para nosso projetos e organizamos nosso desenvolvimento em um processo temperado com o Scrum, necessário para garantir a alta qualidade do software. Utilizamos os papéis e ritos do Scrum. O desenvolvimento é organizado em sprints que terminam com uma reunião de revisão, para a qual trazemos as pessoas da organização que estão envolvidas no projeto (ou seja, nosso cliente e outros patrocinadores do projeto) junto à equipe de desenvolvimento. Em nosso caso, isso acontece uma vez a cada duas semanas.

Durante essas reuniões de revisão, a organização contribui com feedback e também apresenta seus mais urgentes requisitos, com base no estado corrente do sistema. O diretor de marketing fala se gostou, e como, de uma determinada página, mas explica que gostaria de outra função que permitiria à sua equipe a melhor comunicação de suas campanhas. O gerente da loja, ao descrever como normalmente trabalha com produtos e preços (que é diferente da forma como é feito na loja virtual) sugere ajustes no sistema. Eles também experimentarão alguns cliques na interface do sistema e relatarão quaisquer problemas encontrados.

Tudo isso é muito bom. Precisamos mesmo de feedback. É essa valiosa informação que nos ajuda a aprimorar a qualidade dos resultados e é essa a razão pela qual organizamos nossos projetos dessa maneira. Afinal, as reuniões de revisão, especificamente, incentivam a organização a fornecer respostas, comentários e opiniões. Tudo isso será discutido e, eventualmente, será atendido, de uma maneira ou outra, no software. As melhorias baseadas nesse feedback serão, por exemplo, agendadas para o próximo sprint e apresentadas após duas semanas. Esse é o período de desenvolvimento sobre o qual falamos em nossos projetos típicos: um sprint. Se algo for absurdamente importante, é claro, podemos fazer uma exceção. Mas o processo é configurado para que todas as (potenciais) entregas ocorram após o sprint.

Pós-lançamento: tudo é urgente

Com o lançamento de uma plataforma de comércio eletrônico, a perspectiva da organização, com relação à loja virtual, muda repentinamente. Muito. Nessa transição, a plataforma que se apresenta ao cliente tem que ser o carro chefe. Isso aumenta a pressão e encurta todos os prazos nos quais podemos pensar.

Se um problema é encontrado, ele tem que ser imediatamente solucionado. Se o departamento de marketing precisa de uma funcionalidade para comunicar suas ideias, isso passa a ser urgente. E se os gestores da loja têm dificuldades com produtos e preços, isso também tem que ser tratado rapidamente. Cada um desses exemplos pode causar sérios impactos negativos na experiência do cliente, custando caro para a organização. Por isso, não existe a opção de esperar pelo próximo sprint para tratar dessas questões.

Rápidas entregas, então, transformam-se em algo comum. Versões que violam o ciclo do sprint tornam-se mais regra do que exceção. De repente, qualquer coisa é um problema urgente que deve ser imediatamente resolvido. Este é o momento em que um Product Owner forte torna-se crucial, alguém que realmente decida o que deve ser resolvido imediatamente e o que pode esperar. Essa é uma linha tênue, uma vez que envolve não apenas o conhecimento técnico mas consciência política e habilidade no trato com pessoas para que se possa lidar com as pressões dos patrocinadores.

Afinal, não faz sentido apenas seguir o plano original. Planos mudam, aceitamos isso e é por isso que somos ágeis. Isso deve, porém, ser tratado com cuidado para evitar o pânico. Com um novo sistema e novas funcionalidades expostos aos usuários, novos requisitos se apresentam. Alguns podem, até mesmo, ser urgentes. Entretanto, como nem sempre é fácil argumentar com uma equipe Scrum, esses novos requisitos não poderão entrar, imediatamente, no sistema em produção. Eles devem ser colocados dentro do ritmo dos sprints. Para a organização, isso sempre se apresenta como um atraso desnecessário. E este é um ponto válido. Por que devemos, forçosamente, esperar por uma cadência quinzenal se isso não ajuda o cliente da forma como eles precisam, se isso se torna mais uma sobrecarga no processo?

Pessoas e suas interações são mais importantes que processos e ferramentas

Ao desenvolver novas funcionalidades, nos esforçamos em incluir o cliente no processo de desenvolvimento. É importante modelar as histórias de usuário colaborativamente e discutir, em conjunto, o resultado final. Desta forma, podemos avaliar se determinada implementação atende às necessidades e descobrir, com precisão, o que deve ser modificado e sermos capazes de chegar a uma entrega de valor. O Scrum foi projetado para estruturar esse processo de desenvolvimento, beneficiar o cliente ao tornar o desenvolvimento mais efetivo.

Quando se trabalha no pós-lançamento de uma plataforma de comércio eletrônico, desenvolver grandes novas funções é apenas parte do negócio. Em um maior grau, especialmente durante os primeiros meses que seguem o lançamento, o grande esforço se concentra em reparos e melhorias. O software passa por uma estabilização, melhorando o ambiente para os fornecedores, gestores de conteúdo e para os profissionais de web marketing, graças ao feedback imediato.

Os bugs sempre tem a máxima prioridade (pare tudo e conserte), mas as "questões de melhoria" são igualmente importantes para a organização. Cada uma delas é entendida como desvantagem competitiva que custa dinheiro para a organização ou diminui seu valor (o que também custa dinheiro). As razões podem variar, seja em função de uma revisão do escopo após o lançamento ou em função de novas descobertas quando o sistema se torna produtivo. Então, faz sentido usar aspectos do método Lean Startup, no qual temos ciclos de construção-medida-aprendizagem.

Adicionalmente à implementação de grandes funções, da mesma forma que foi usado ou planejado antes do lançamento, temos três tipos de questões: problemas (bugs), melhorias e funcionalidades. Elas trazem ao Product Owner um grande esforço de priorização e um planejamento normal do sprint torna-se um desafio. Rápidos consertos são as frutas mais maduras que devem ser colhidas tão rápido quanto possível. Os bugs devem sempre ser atacados primeiro, obviamente. Mas não podemos nos esquecer do desenvolvimento de novas funcionalidades. A divisão entre esses tipos de questões pode variar enormemente, de acordo com a natureza das necessidades atuais da organização. Essas necessidades são urgentes mas, tipicamente, não acompanham o ritmo de duas semanas, o que viola o ciclo do sprint.

Se questões diferentes são espremidas em um sprint mas, durante o mesmo novas necessidades urgentes devem ser atendidas, você acabará por sempre violar o ciclo do sprint. Assim, durante as reuniões de revisão, dificilmente haverá algo a ser discutido já que a maior parte do desenvolvimento já foi colocada em produção. Isso faz com que a organização sinta que o desenvolvimento não progride e que tudo "demora muito". Mas os sprints também limitam o trabalho do Product Owner, que precisa ser capaz de reagir em ambientes de mudança e deve poder repriorizar adequadamente o trabalho. Acima de tudo, há o sentimento ruim nas tripas de todos por continuamente quebrarem as regras do Scrum. Precisamos ser mais ágeis do que o Scrum nos permite.

Trocando para o Kanban

Colocado de forma simples, o Kanban elimina os sprints no Scrum. Não se planejar mais um sprint traduz-se em não violá-lo, mas mudar seu escopo a todo o momento. Isso facilita o lado da preparação: tarefas específicas com as quais o Product Owner e a equipe concordam podem ser imediatamente trabalhadas. Não há a necessidade de planejar o próximo sprint e trabalhar com certas coisas apenas porque elas foram agendadas há duas semanas. As prioridades das próximas tarefas podem ser mudadas pelo Product Owner a qualquer momento. Isto traz uma flexibilidade muito maior.

Mas esta flexibilidade tem um custo. A não existência de sprints implica na extinção de reuniões regulares de revisão. E reuniões de revisão são cruciais. A flexibilidade ampliada exige que a organização esteja pronta para revisões menores, com pouca antecedência em seu agendamento. Você também não terá um incremento potencialmente entregável do software ao final de cada sprint. Isso terá que ser tocado de maneira paralela. Um planejamento flexível de versões é, assim, parte do acordo, já que novos desenvolvimentos devem ser entregues apropriadamente. A flexibilidade ganha, aqui, pode facilmente transmutar-se em caos se não houver estrutura. De qualquer maneira, será necessária uma discussão cuidadosa sobre quando e como fazer as entregas das versões do software, já que o trabalho pode ser imenso, conforme a infraestrutura do projeto. O Kanban é menos prescritivo que o Scrum, necessitando ser compensado por acordos adicionais de trabalho.

Em função desses acordos, a mudança para o Kanban não pode ser trivial. A equipe e o cliente devem estar cientes das possibilidades, mas também das armadilhas. Enquanto você não for capaz de encarar os desafios inerentes à troca de um processo por outro, você deve considerá-los com muita seriedade. Em nosso caso, isso foi bastante direto. No projeto em que estou trabalhando, nós analizamos a situação e concluímos que precisávamos da maior flexibilidade do Kanban. Para abordar os fatores negativos, introduzimos o papel do gerente de versões, responsável por sincronizar as entregas de versões com os desenvolvedores e colocá-las em produção em colaboração com o Product Owner. As tarefas do Product Owner são ampliadas por revisões coletivas dentro da organização e reunir as pessoas para discutir problemas e suas soluções em reuniões de planejamento e revisão eventuais, sempre que elas forem necessárias.

Entretanto, é importante refletir o desenvolvimento no Kanban com regularidade. As retrospectivas fazem muito sentido aqui. Minha experiência pessoal com o Kanban deve ser encarada como algo temporário, como uma ponte sobre as águas turbulentas causadas pelo lançamento de um sistema. Mesmo que isso seja importante, o objetivo deve ser, certamente, abandonar essa zona de flexibilidade o mais breve possível. Ela pode facilmente evoluir para um curso de eventos no qual os patrocinadores ficam empilhando novos requisitos, esperando que eles sejam imediatamente atendidos. E, ao adicionar mais e mais requerimentos à pilha parecerá que nada, nunca é atendido. Um processo mais restritivo permite que o Product Owner não fique mudando o mapa da estrada a seu capricho.

Conclusão

Nos esforçamos em desenvolver software de alta qualidade, que beneficia o cliente. Prazos são um aspecto vital disso. Até o software perfeito, se entregue com muito atraso, não terá valor algum. Foi por isso que mudamos para o modo Kanban após o lançamento de um projeto de comércio eletrônico, ao menos por poucos meses, até que a organização possa trabalhar, de maneira eficiente, com os novos sistemas e o desenvolvimento futuro possa ser apenas a realização de novas funções maiores.

A mudança de sprints para Kanban não torna, necessariamente, a vida da equipe de desenvolvimento melhor ou pior. Mas ela pode tornar seus esforços mais benéficos para a organização. Afinal de contas, é por isso que somos ágeis: aumentar o valor de negócio para nossos clientes.

Obrigado à Ines Stuppacher e Dirk Lässig por rever esse artigo e discutir esse tópico comigo.

Karsten Jahn, por ele mesmo

Cresci no distrito de Ruhr, na Alemanha e graduei-me em Ciência da Computação e Multimídia. Iniciei minha carreira profissional como consultor de TI na Valtech em Düsseldorf, onde fiquei por três anos. Lá, dentre outras coisas, trabalhei como gerente de testes. Foi lá, também, que travei meu primeiro contato com Wikis e comecei a estudá-los.

Seguindo meu interesse em gestão do conhecimento, matriculei-me como estudante de doutorado na Aalborg University, na Dinamarca, como parte do KiWi Project. Depois de defender minha tese, em novembro de 2012, voltei para Düsseldorf e comecei minha segunda fase como consultor de TI na Valtech. Agora tento gerenciar as comunicações internas, assim como aquelas com os clientes.

Meu interesse principal é por tópicos relacionados à gestão do conhecimento e comunicações e acredito fortemente em métodos ágeis. Em meus trabalhos e estudos deparei-me com um bocado de reflexões e descobertas muito interessantes que desejo compartilhar em minhas páginas. Estou sempre interessado em novos contatos e na troca de ideias.