Mapeando Escopos

No capítulo anterior, começamos o projeto finalizando uma fatia integrada logo no início. Essa prática faz parte de uma técnica mais geral que a equipe pode usar ao longo do projeto.

Organize por Estrutura, Não por Pessoa

Quando solicitadas a organizar tarefas para um projeto, as pessoas muitas vezes separam o trabalho por pessoa ou função: elas criam uma lista para Designers e uma lista para Programadores. Isso leva ao problema que discutimos no capítulo anterior — as pessoas completarão tarefas, mas as tarefas não se somarão a uma parte concluída do projeto cedo o suficiente.

Para dar um exemplo fora do contexto de software, considere alguém organizando um evento de arrecadação de fundos. Eles poderiam criar uma lista de tarefas para cada um dos seus três voluntários e acompanhar o trabalho dessa forma. Mas então não haveria como ver a visão geral de como o evento está se saindo — o que está feito e o que não está feito no nível macro. Em vez disso, eles deveriam criar listas com base na estrutura do projeto — as coisas que podem ser trabalhadas e concluídas independentemente umas das outras. Para isso, eles criariam listas para Alimentação, Localização e Iluminação/Som. Dessa forma, o organizador pode ver facilmente quais áreas estão concluídas e quais áreas têm trabalho pendente.

No desenvolvimento de produtos, as categorias não são predefinidas para nós. Normalmente construímos coisas que nunca construímos antes. Cada projeto é um território desconhecido que precisamos percorrer antes de podermos desenhar um mapa. Ao nos aprofundarmos no trabalho, descobrimos onde estão as interdependências, como as coisas estão conectadas e o que podemos separar.

Como vimos no capítulo anterior, as fatias de trabalho integram tarefas de front-end e back-end. Isso nos permite finalizar uma fatia do projeto real e seguir em frente de forma definitiva. Isso é melhor do que ter várias peças que — cruzando os dedos — deveriam se unir até o final do ciclo.

Chamamos essas fatias integradas do projeto de escopos. Dividimos o escopo geral (singular) do projeto em escopos separados (plural) que podem ser concluídos independentemente uns dos outros. Neste capítulo, veremos como a equipe mapeia o projeto em escopos e os aborda um por um.

O Mapa de Escopo

Imagine uma visão aérea do projeto. No início, há apenas um esboço do trabalho de modelagem que precedeu o projeto. Ainda não há tarefas ou escopos.

Quando os membros da equipe assumem o projeto, eles começam a descobrir tarefas. Tarefas são um ponto de partida natural porque são concretas e granulares. É muito cedo para organizá-las em categorias de nível superior. Seria artificial tentar agrupá-las arbitrariamente. No início, basta capturar uma variedade de coisas que precisam acontecer.

Mas não queremos permanecer com essa visão por muito tempo. É muito detalhada. Não há nada visível de uma altitude maior.

À medida que a equipe começa a trabalhar de verdade no projeto, eles aprendem como as tarefas estão relacionadas e como é realmente a estrutura do projeto. Então, eles se tornam capazes de dividir o projeto em escopos. Isso é como dividir o mapa do projeto em territórios separados.

Os escopos refletem as partes significativas do problema que podem ser concluídas de forma independente e em um curto período de tempo — alguns dias ou menos. Eles são maiores que as tarefas, mas muito menores que o projeto como um todo.

O mapa é uma imagem mental. Na prática, definimos e acompanhamos os escopos como listas de tarefas. Cada escopo corresponde a um nome de lista. Então, todas as tarefas para aquele escopo vão nessa lista.

A Linguagem do Projeto

Os escopos são mais do que apenas fatias. Eles se tornam a linguagem do projeto no nível macro. Quando estávamos construindo o recurso de Clientes em Projetos, a equipe usava a linguagem dos escopos assim: "Depois que o Acesso ao Bucket estiver concluído, podemos implementar Convidar Clientes. Então, Atualizar Visibilidade de Gravação quando as pessoas na empresa acionarem a Alternância de Visibilidade."

Quando é hora de relatar o status, a equipe usa a linguagem dos escopos para explicar o que está feito e o que não está. É mais satisfatório ter a conversa em um nível alto e apontar para peças de software concluídas, em vez de entrar nos detalhes e defender os propósitos e o status de tarefas individuais pendentes. (Veremos mais no próximo capítulo sobre como relatar escopos usando o Gráfico de Colinas.)

Estudo de Caso: Rascunhos de Mensagens

Um designer e um programador estavam criando um recurso para criar e salvar rascunhos de mensagens em um novo aplicativo. Após o início do projeto, identificaram várias tarefas que precisariam fazer em algum momento.

Quando o fim da primeira semana se aproximava, eles tinham completado algumas das tarefas, mas não havia nada para mostrar pelo trabalho deles. No espírito de “concluir uma parte”, focaram em uma interação chave que poderiam integrar: criar um novo rascunho.

Eles chamaram o novo escopo de “Iniciar Novo”, criaram uma lista de tarefas para ele e moveram tarefas para essa lista. Restava apenas uma tarefa de design para considerarem esse escopo concluído.

Após finalizar a tarefa de design, o escopo estava completo.

As tarefas não escopadas restantes não representam todo o trabalho que ainda resta. Mais tarefas serão descobertas à medida que começarem a trabalhar em cada uma delas. Ainda assim, há variedade suficiente no trabalho para definir mais escopos. A equipe estava motivada a dividir os escopos já neste ponto porque sabiam que queriam que seus esforços se somassem a outra parte visível sendo concluída em breve.

Analisando as tarefas que restavam, decidiram separar as tarefas relacionadas a encontrar os rascunhos em um novo escopo chamado Localizar e a tarefa de excluir em um escopo chamado Lixeira. O trabalho restante parecia estar relacionado a salvar e editar o rascunho, então chamaram isso de Salvar/Editar.

Dê uma olhada no escopo Localizar. Há apenas uma tarefa lá agora. Mas certamente haverá mais trabalho a ser feito além de projetar o índice. Quando houver tarefas de implementação a serem feitas, elas irão para lá.

O designer começou a trabalhar em Localizar enquanto o programador se concentrava em Salvar/Editar. Enquanto ela se aprofundava, percebeu que podia dividir algumas partes para fazer mais progresso visível. Na verdade, havia três escopos nisso.

Primeiro, ela separou o trabalho relacionado a enviar a mensagem rascunhada. Chamou isso de Enviar.

Finalmente, algumas das tarefas restantes de Salvar/Editar estavam relacionadas a armazenar informações e outra era realmente não relacionada — era um caso especial para lidar com rascunhos ao responder a outra mensagem. Ela dividiu essas em dois novos escopos: Armazenar e Responder.

Neste ponto, a equipe de repente sentiu que podia ver todo o projeto em um nível alto. Todas as partes principais eram visíveis no nível macro como escopos. Nenhum deles era tão grande que tarefas importantes ou desafiadoras pudessem se esconder dentro deles sem serem notadas.

Enquanto isso, o designer havia feito progresso em Localizar. Após algumas conexões, puderam marcar como concluído. Tarefas estavam sendo concluídas em Enviar e Armazenar também.

Uma vez que Enviar e Armazenar foram concluídos, restaram apenas algumas tarefas para Lixeira e Responder.

E então o projeto estava concluído.

Descobrindo Escopos

Mapeamento de escopos não é planejamento. Você precisa percorrer o território antes de poder desenhar o mapa. Escopos bem desenhados não são agrupamentos ou categorias arbitrários para fins de organização. Eles refletem a realidade do que pode ser feito de forma independente — as interdependências e relações subjacentes no problema.

Os escopos surgem das interdependências. A maneira como as partes dependem umas das outras determina quando você pode dizer que uma determinada parte do trabalho está “concluída”. Você não sabe quais são o trabalho e as interdependências de fato com antecedência. Falamos anteriormente sobre tarefas imaginadas versus tarefas descobertas. O mesmo princípio se aplica aos escopos. Os escopos precisam ser descobertos fazendo o trabalho real e vendo como as coisas se conectam e não se conectam.

É por isso que, no início de um projeto, não esperamos ver escopos precisos. É mais provável que os vejamos no final da primeira semana ou início da segunda semana, depois que a equipe teve a chance de fazer algum trabalho real e encontrar as linhas divisórias naturais na anatomia do problema.

Também é normal ver algum rearranjo e instabilidade nos escopos no início. As linhas são redesenhadas ou os escopos renomeados à medida que a equipe sente onde as fronteiras realmente estão, como no exemplo acima. A equipe estava focada em problemas específicos de salvar e editar rascunhos, então foi mais fácil identificar esse escopo cedo. Só quando eles se aprofundaram é que perceberam que havia tarefas específicas sobre enviar o rascunho e fizeram disso um escopo separado.

Como Saber se os Escopos Estão Corretos

Escopos bem feitos mostram a anatomia do projeto. Quando você sente uma dor no corpo, não precisa questionar se está nos braços, nas pernas ou na cabeça. Você conhece as partes e seus nomes para poder explicar onde está a dor. Da mesma forma, todo projeto tem uma anatomia natural que surge do design que você deseja, do sistema no qual você está trabalhando e das interdependências dos problemas que você precisa resolver.

Três sinais indicam quando os escopos estão corretos:

Você sente que pode ver o projeto inteiro e nada importante que te preocupa está escondido nos detalhes.
As conversas sobre o projeto se tornam mais fluidas porque os escopos te dão a linguagem correta.
Quando surgem novas tarefas, você sabe onde colocá-las. Os escopos funcionam como baldes nos quais você pode facilmente jogar novas tarefas.

Por outro lado, esses três sinais indicam que os escopos precisam ser redesenhados:

É difícil dizer quão “concluído” um escopo está. Isso geralmente acontece quando as tarefas dentro do escopo são não relacionadas. Se os problemas dentro do escopo são não relacionados, terminar um não te aproxima de terminar o outro. Nesse caso, é bom procurar algo que você possa separar, como no exemplo dos Rascunhos.
O nome não é único para o projeto, como “front-end” ou “bugs”. Chamamos isso de “saco de gatos” e “gaveta de tralhas”. Isso sugere que você não está integrando o suficiente, então nunca conseguirá marcar um escopo como “concluído” independentemente do resto. Por exemplo, com bugs, é melhor arquivá-los sob um escopo específico para que você possa saber se, por exemplo, “Enviar” está concluído ou se precisa corrigir alguns bugs antes de tirá-lo da mente.
É muito grande para terminar em breve. Se um escopo ficar muito grande, com muitas tarefas, ele se torna como seu próprio projeto, com todas as falhas de uma longa lista de tarefas própria. Melhor dividi-lo em partes que podem ser resolvidas em menos tempo, para que haja vitórias ao longo do caminho e fronteiras entre os problemas a serem resolvidos.

Vamos encerrar este capítulo com algumas dicas para lidar com diferentes tipos de tarefas e escopos que surgirão.

Bolo em Camadas

A maioria dos projetos de software requer algum design de interface do usuário e uma camada fina de código abaixo. Pense em um aplicativo de banco de dados onde tudo o que você precisa fazer é inserir informações, salvá-las e exibi-las. Trabalhos como esse se parecem com um bolo em camadas: você pode julgar o trabalho pela área da superfície da UI, pois o trabalho de back-end é fino e distribuído de maneira uniforme. Nesses casos, você pode integrar todas as tarefas de design e programação no mesmo escopo. Essa é uma boa opção padrão para a maioria dos aplicativos do tipo “sistema de informação”.

Icebergs

Mas, às vezes, há significativamente mais trabalho de back-end do que de UI, ou vice-versa. Por exemplo, um novo recurso que só exige o envio de um formulário pode requerer uma lógica de negócios muito complexa para retornar a resposta correta. Esse tipo de trabalho é como um iceberg.

Para icebergs, pode ajudar separar a UI como um escopo de trabalho distinto (assumindo que a UI não seja interdependente com a complexidade do back-end). Se o back-end for suficientemente complexo, você pode dividi-lo em preocupações separadas e depois transformá-las em escopos também. O objetivo em casos como esse é definir algumas coisas diferentes que você pode terminar e integrar em estágios, em vez de esperar até a última hora com os dedos cruzados, esperando que tudo se junte.

Às vezes, você também vê icebergs invertidos, onde há uma tonelada de complexidade de UI com menos complexidade de back-end. Por exemplo, o modelo de dados para um calendário não é complicado, mas a interação para renderizar um evento de múltiplos dias e envolver células da grade pode levar muito tempo e resolução de problemas.

Para icebergs tanto de back-end quanto de front-end, sempre os questionamos antes de aceitá-los como um fato. A complexidade é realmente necessária e irredutível? Precisamos dessa UI sofisticada? Existe uma maneira diferente de construir esse processo de back-end para que tenha menos interdependências com o resto do sistema?

Roupa Suja

Quase sempre há algumas coisas que não se encaixam em um escopo. Permitimos a nós mesmos uma lista chamada “Roupa Suja” para tarefas soltas que não se encaixam em nenhum lugar. Mas sempre mantemos um olhar crítico sobre ela. Se ela ficar com mais de três a cinco itens, algo está estranho e provavelmente há um escopo a ser desenhado em algum lugar.

Marque os desejáveis com ~

Novas tarefas surgem constantemente à medida que você se aprofunda em um problema. Você encontrará códigos que poderiam ser limpos, casos extremos para resolver e melhorias na funcionalidade existente. Uma boa maneira de lidar com todas essas melhorias é registrá-las como tarefas no escopo, mas marcá-las com um ~ na frente. Isso permite que todos na equipe distingam constantemente o que é essencial do que é desejável.

Em um mundo sem prazos, poderíamos melhorar tudo para sempre. Mas em um tempo fixo, precisamos de um facão em nossas mãos para cortar o escopo que está constantemente crescendo. O ~ no início de um item, ou até mesmo de um escopo inteiro, é nossa melhor ferramenta para isso. Voltaremos a essa técnica quando falarmos sobre fazer cortes no escopo no Capítulo 14, Decida Quando Parar.