Eu entrei recentemente em um projeto de desenvolvimento e de repente recebi o trabalho de desenvolvedor líder. Minha principal responsabilidade é dividir a parte de programação do projeto em tarefas, entregá-las aos outros desenvolvedores e garantir que as peças funcionem juntas.

O problema, porém, é que eu não tenho idéia de como fazer isso. Passei meu fim de semana com lápis e papel tentando descobrir, mas continuo inventando uma lista de tarefas a serem trabalhadas sequencialmente em vez de em paralelo. Pensei em talvez dividi-lo em recursos, mas você acaba com tarefas que exigem a edição dos mesmos arquivos, o que poderia exigir que uma tarefa inteira fosse completamente reescrita por causa do início do desenvolvimento. Eu poderia fazer com que alguns desenvolvedores esperassem até que o programa fosse um pouco mais completo e mais fácil de criar tarefas, mas então eu teria pessoas sentadas em suas mãos por quem sabe quantas semanas.

Tive uma conversa com meu chefe sobre minhas qualificações para fazer isso e não tive escolha no assunto. Não tenho ideia do que estou fazendo, portanto, qualquer dica e sugestão na direção certa serão muito apreciadas.

Uma resposta adequada para sua pergunta preenche vários livros . Vou apresentar uma lista de palavras-chave que me vêm à mente sobre isso, o Google e os livros farão o resto por você.

1. Fundamentos

   • Não vá sozinho . Tente envolver seus companheiros de equipe o máximo possível.
   • Viagem leve .
   • Democracia, mas não muito. Às vezes, não é sobre o que satisfaz o maior número de pessoas, mas o que machuca o menor número de pessoas.
   • Mantenha o que (precisa ser feito) e como (é feito) separado .
   • Aprenda sobre Scrum ("o que"), XP (Extreme Programming, "como"), Kanban ("quanto"), Lean ("o que não é") e DevOps ("com quem").
   • O lean também se refere ao fluxo : para eficiência geral, a eficiência do fluxo geralmente é mais importante que a eficiência individual.
   • Aprenda sobre artesanato de software , código limpo e programação pragmática .
   • Uma boa arquitetura é maximizar o número de decisões não tomadas .
   • Scrum / XP / Lean / Agile é maximizar a quantidade de trabalho não realizado : YAGNI .
   • O valor principal do software é que você pode alterá- lo facilmente . O fato de fazer o que deve fazer é importante, mas esse é apenas o seu valor secundário.
   • Prefira uma abordagem iterativa e incremental , use caixas de horário para quase tudo, especialmente reuniões, faça da Lei de Parkinson sua amiga porque a Lei de Hofstadter se aplica.
   • Equilibre a estrutura da equipe com um entendimento da Lei de Conway e dos estágios de desenvolvimento da equipe de Tuckman .
   • Programar é uma quaternidade, é ciência , engenharia , arte e artesanato, tudo ao mesmo tempo, e esses precisam estar em equilíbrio.
   • Só porque Scrum / XP / XYZ é bom para alguém (incluindo eu) não significa necessariamente que é bom para você / se adapta ao seu ambiente. Não siga cegamente o hype, entenda-o primeiro.
   • Inspecionar e adaptar! (Scrum Mantra)
   • Evite duplicação - uma vez e apenas uma vez! (XP Mantra), também conhecido como DRY - Não se repita, também conhecido como SPOT - Single Point of Truth

2. Processo de detalhamento do trabalho "Que mundo"

   • Colete requisitos como histórias de usuário / histórias de trabalho em um backlog do produto .
   • Usuário (da história do usuário) semelhante ao ator (na UML) semelhante ao Persona semelhante ao papel .
   • Refine as Histórias de Usuário até que elas atendam à Definição de Pronto da sua equipe com base no INVEST (Independente, Negociável, Valioso, Estimativo, Pequeno, Testável). (Reunião do Scrum: Refinamento da lista de pendências )
   • Classifique o Backlog do produto por valor comercial .
   • Não comece a trabalhar em uma história antes que ela esteja pronta, pronta (de acordo com a definição de pronta).
   • Use o Planning Poker para estimar o esforço de Stories nos Story Points . Use a Comparação de triangulação para garantir a consistência das estimativas.
   • O tempo de ontem é a melhor estimativa, espero o pior.
   • Divida as histórias se elas forem muito grandes.
   • Melhore a cultura de entrega com uma Definição de Concluído .
   • Não aceite a implementação de uma História de usuário antes de Concluído (feito de acordo com a Definição de Concluído).
   • Várias equipes na mesma base de código devem concordar e compartilhar a mesma Definição de Concluído (especialmente os Padrões de Codificação ).
   • Verifique seu progresso com Burndown Charts .
   • Verifique regularmente com as partes interessadas se o que a equipe entrega é o que é realmente necessário. (Reunião do Scrum: Revisão da Sprint )

3. Descrição da história

   • Listar e descrever usuários / personas / atores / funções (proprietário do produto)
   • Épica -> Histórias (História do usuário ou História do trabalho) (Dono do produto)
   • História -> Critérios de aceitação (Product Owner)
   • História -> Subtarefas (equipe de desenvolvimento)
   • Critérios de aceitação -> Testes de aceitação (especificação: proprietário do produto, implemento: equipe de desenvolvimento)
   • Comece com um esqueleto ambulante que é um minimalista -to-End (Half-End) .
   • Crie um MVP - Produto mínimo viável .
   • Expanda o MVP usando SMURFS - conjuntos de recursos especificamente comercializáveis, úteis e liberáveis .

4. Realização "como mundo"

   • Use cartões OOA / D , UML e CRC , mas evite o grande design antecipadamente .
   • Implemente orientado a objetos , estruturado e funcional ao mesmo tempo, tanto quanto possível, independentemente da linguagem de programação.
   • Use o Controle de versão (de preferência distribuído ).
   • Comece com testes de aceitação .
   • Aplique o TDD , permitindo que as Três Leis do TDD conduzam você pelo Ciclo de Refatoração Verde-Vermelho , com regra de afirmação única , 4 A's , GWT (dada quando então) do BDD .
   • " Testes de unidade são testes que são rápidos ." - Michael Penas
   • Aplique os princípios do SOLID e da embalagem para gerenciar o acoplamento e a coesão . Exemplo: S no SOLID é SRP = Princípio de responsabilidade única, reduz significativamente o número de edições. conflitos de mesclagem em equipes.
   • Conheça a lei de Deméter / Tell, não pergunte .
   • Use a integração contínua , se aplicável, até a entrega contínua (DevOps).
   • Use a propriedade do código coletivo com base em um padrão de codificação comum acordado (que deve fazer parte da definição de feito ).
   • Aplique a Melhoria Contínua do Projeto (refatoração contínua fka).
   • O código fonte é o design . O pensamento inicial ainda é indispensável e ninguém contestará alguns bons diagramas de UML esclarecedores.
   • XP não significa que nenhum dia é dia da arquitetura, significa que todo dia é dia da arquitetura. É um foco na arquitetura, não um desfoque, e o foco está no código.
   • Mantenha sua Dívida Técnica baixa, evite os quatro cheiros de design: Fragilidade , Rigidez , Imobilidade e Viscosidade .
   • A arquitetura é sobre lógica de negócios, não sobre persistência e mecanismos de entrega.
   • A arquitetura é um esporte de equipe ( não existe um "eu" na arquitetura ).
   • Padrões de projeto , refatoração e a premissa de prioridade de transformação .
   • O código do projeto é o ATP-Trinity com prioridades: 1. Código de automação , 2. Código de teste , 3. Código de produção .
   • Verifique regularmente com seus colegas de equipe se o desempenho da equipe pode ser aprimorado. (Reunião do Scrum: Retrospectiva da Sprint )
   • Os testes devem ser PRIMEIROS - Rápido, Independente, Repetível, Autovalidável e oportuno.

A lista acima é certamente incompleta, e algumas partes podem até ser discutíveis!

Se tudo isso te assusta - não se preocupe, porque deve assustá-lo! Ter êxito em projetos de desenvolvimento de software em equipes não é uma tarefa fácil, e raramente as pessoas são adequadamente treinadas e educadas nesta arte. Se isso te assusta, sua intuição está funcionando corretamente, ouça. Você quer estar preparado. Converse com seu chefe, ganhe algum tempo e treinamento.

Veja também

• Quem escreve as 'histórias de usuários' técnicas no scrum

Leitura adicional (online)

• Repositório de Padrões de Portland por Ward Cunningham et al
• Princípios de OOD por Robert "tio Bob" C. Martin
• Dicas pragmáticas para programadores

Leitura adicional (livros)

• Código Limpo por Robert C. Martin
• Desenvolvimento Ágil de Software: Princípios, Padrões e Práticas de Robert C. Martin
• O Programador Pragmático - De Journeyman to Master por Andrew Hunt e David Thomas
• Trabalhando efetivamente com o código legado de Michael Feathers
• Refatoração - Melhorando o design do código existente por Martin Fowler
• Refatoração de padrões por Joshua Kerievsky
• O MBA de dez dias por Steven Silbiger (sic!)
• Design orientado a domínio por Eric Evans
• Histórias de usuários aplicadas por Mike Cohn
• Análise e Design Orientados a Objetos com Aplicações por Gray Booch et al
• Padrões de Design da Gang of Four
• Desenvolvimento Orientado a Testes por Kent Beck
• Programação extrema por Kent Beck
• [if Java] Java eficaz por Joshua Bloch

Agile

Eu sugeriria o seguinte:

Editando os mesmos arquivos

Primeiro, use o Git (ou um sistema de versão simultâneo semelhante). Enquanto estiver editando partes diferentes dos mesmos arquivos, você não terá conflitos. Se você tiver conflitos, eles serão claramente marcados como tal.

Tentar gerenciar um projeto multi-desenvolvedor sem o Git é como tentar fazer um pudim sem uma tigela de pudim. É possível, mas vai ficar bem bagunçado e rápido.

Como foi apontado nos comentários, o Git não é uma panacéia, mas combinado com testes automatizados certamente ajuda bastante.

Listar todos os recursos

Segundo, divida o projeto em recursos visíveis para o usuário. Por exemplo "quando o usuário se inscrever, ele receberá um email" ou "O usuário pode adicionar um item". Envolva todas as partes interessadas aqui. Coloque todos em uma sala e peça que todos gritem seus recursos.

Esses devem ser recursos visíveis ao usuário. Você pode falar sobre a estratégia de implementação posteriormente.

Escreva todas as sugestões em fichas, mesmo as idiotas. Racionalize rapidamente a lista para remover duplicatas e coloque todas as cartas em uma mesa grande ou até no chão.

Adicione quaisquer cartões adicionais necessários. Digamos que seu aplicativo envie alertas de texto por SMS. Você pode não saber como fazer isso, então você tem uma pergunta. Escreva "Investigar portais de SMS" em um cartão. Da mesma forma para outras grandes incógnitas. Você precisará desempacotá-los mais tarde. Esses recursos provavelmente não entrarão no seu primeiro sprint.

Agora, organize suas cartas em grupos, embaralhe-as, sinta-as para eles. Esse é o escopo do seu projeto.

Planejando poker

Tente planejar o poker. Ainda com todos juntos, dê a todos os cartões de desenvolvedores que digam "1 ponto", "2 pontos", etc., até "4 pontos". Também um cartão "mais". Um ponto é aproximadamente equivalente a uma hora.

Percorra a lista de recursos, um por um. Enquanto você lê um recurso, todos precisam jogar um cartão. Se uma pessoa joga 1, e outra pessoa joga 4, há um problema de comunicação lá. Uma pessoa entende que o recurso significa algo diferente da outra pessoa. Converse e descubra o que realmente significava e anote-o no cartão.

Se você concorda que um recurso é "mais", esse recurso é muito grande. Você precisa quebrar esse recurso. Faça isso da mesma maneira que antes.

Conforme você concorda, escreva os números nos cartões em uma caneta de cor diferente.

Pontos são melhores que horas

O uso de pontos em vez de horas tira a coisa de "olha o quão rápido eu posso codificar" que os desenvolvedores costumam fazer. É uma diferença sutil, mas achei que funciona muito bem.

Agora componha um sprint

Um sprint é uma rápida explosão em direção a uma meta. Decida a duração do sprint, talvez 5 ou 10 dias. Multiplique o número de dias pelo número de desenvolvedores pelo número de pontos por dia.

Suponha 6 pontos por dia por desenvolvedor inicialmente. Este é um número alcançável. Se você tem 5 pessoas, são 5 * 5 * 6 = 150 pontos. Em conjunto com todos os desenvolvedores e o gerenciamento, escolha os recursos da lista, até 150 pontos. Esse é o seu sprint.

Nunca fique tentado a espremer mais do que o necessário. Prometer demais magoa todo mundo a longo prazo, inclusive você.

Você precisará levar em conta as dependências aqui. Por exemplo, a configuração do ambiente obviamente precisa ser incluída no primeiro sprint. Isso é relativamente fácil de fazer quando todos estão presentes. Você tem 6 cérebros na sala, todos dizendo "isso depende disso", etc. Você pode então embaralhar as cartas para demonstrar dependências.

Depois de ter seu sprint, nada pode ser adicionado a ele, ele fica bloqueado pelos 5 dias. A fluência dos recursos estressará a equipe, prejudicará o moral e diminuirá a velocidade de todos. Eventualmente, a fluência interromperá um projeto. Como líder de equipe, você deve proteger sua equipe contra a falta de recursos. Se uma nova solicitação de recurso chegar, ela deverá ser adicionada ao próximo sprint. Se o próximo sprint já estiver cheio, outra coisa deve ser retirada.

Nunca fique tentado a espremer extras. Prometer demais oferece a você cerca de 1 dia de cliente feliz, seguido por 4 dias de estresse da equipe e, eventualmente, provavelmente, vários clientes insatisfeitos quando a equipe não pode entregar a tempo.

Agora vá para ele.

Distribua cartões, pergunte quem quer fazer o que. Você tem total visibilidade do que está sendo feito e pode contar os pontos marcando até zero. Tenha um stand-up no início de cada dia para que todos saibam quem está trabalhando no quê e no que foi feito.

5 ou 6 desenvolvedores motivados decentes, trabalhando juntos como uma unidade em objetivos gerenciáveis ​​claramente definidos, podem obter uma quantidade bastante grande de coisas em um sprint de 5 dias.

Manter a visibilidade

Certifique-se de que todos possam ver qual é o status do projeto. Pegue o Bluetack em todos os cartões na parede. À esquerda, existem cartões que ainda não foram trabalhados. À direita são feitos cartões.

Quando um desenvolvedor está trabalhando em um cartão, ele o retira da parede e o coloca em sua mesa. Isso mantém a visibilidade e evita que as pessoas pisem demais.

Existem alternativas tecnológicas para cartões de índice, mas nada supera ter uma enorme exibição em papel do status do projeto na parede.

Se possível, tenha todos na mesma sala durante o projeto. Tenha as partes interessadas o máximo possível, idealmente todos os dias.

Queimar

Você pode representar graficamente seus pontos progredindo para zero em um gráfico de burndown. Se sua linha de melhor ajuste ultrapassar zero antes de você atingir seu limite de tempo, você provavelmente estará no caminho certo. Caso contrário, talvez você precise informar seu cliente agora, antes de chegar muito perto do prazo.

Se você falhar, falhe cedo.

Você pode fazer um burndown usando software, mas eu prefiro apenas um grande pedaço de papel na parede. Desenhe e escreva por todo o lado.

Teste automatizado

Quando você tem vários desenvolvedores trabalhando nas mesmas coisas ao mesmo tempo, eles provavelmente quebram o código um do outro de tempos em tempos. A comunicação e a visibilidade ajudam nisso, mas é provável que você queira introduzir alguma tecnologia para ajudar a encontrar problemas.

Teste de unidade é o processo de escrever testes para cada parte individual da sua base de código (idealmente cada método). Seus testes de unidade devem ser executados frequentemente, com todas as salvagens, se possível. Existem muitas ferramentas que podem ajudar nisso, por exemplo, Karma ou Rspec.

O teste de ponta a ponta envolve testar seu projeto como um todo, tratando os internos como uma caixa preta. Baseie esses testes em seus requisitos comerciais de alto nível, por exemplo: "O usuário pode se inscrever" ou "O usuário pode ver uma lista de itens". O transferidor é um bom exemplo de uma estrutura de testes de ponta a ponta baseada na Web.

Existem livros inteiros escritos sobre testes, mas ter pelo menos alguns testes de aceitação pode ajudar a garantir que nada seja quebrado à medida que você trabalha no seu projeto.

Evitar dívidas técnicas e concluir o trabalho

Dívida técnica é um conceito que descreve coisas que terão que ser limpas posteriormente. Uma fonte comum de dívida são os recursos que foram marcados como concluídos, mas que nunca foram "concluídos". Um recurso concluído está registrado no Git, foi aprovado pela parte interessada e tem um teste.

Não marque seus recursos até que estejam prontos. Nunca massageie o gráfico. Novamente, isso machuca a todos no longo prazo, inclusive você.

Essa é uma das razões pelas quais inicialmente citamos apenas 6 pontos por desenvolvedor, por dia. Feito, é preciso um trabalho extra, mas é ótimo e dá um impulso à equipe.

Editar os mesmos arquivos não é, por si só, um problema. É apenas um problema se você editar a mesma função para fazer duas coisas diferentes.

Basicamente, o que eu faria é dividir o projeto em 'recursos' separados. Um pode ser algo relacionado ao manuseio do protocolo de rede e outro a um arquivo de configuração, e outro a manuseio do banco de dados. Recursos são grandes coisas.

Em seguida, você deseja dividir esses recursos em tarefas (histórias). Essas devem ser coisas simples, como "quando o usuário clica em um botão, o programa carrega o arquivo", "quando o programa é iniciado, carrega o arquivo de configuração" etc.

Algumas tarefas deverão ser concluídas seqüencialmente ("o programa analisará todos os campos no arquivo de configuração" terá que vir depois de "o programa carregará o arquivo de configuração"). Outros não (você pode trabalhar no banco de dados e na rede ao mesmo tempo).

Mas o mais provável é que você faça errado, e é aí que a experiência se concretiza. Você falhará um pouquinho (ou muito), errará as estimativas de tempo e seu projeto levará um pouco mais de tempo do que deveria. Da próxima vez você estará melhor.

Eu também sugeriria ler "Extreme Programming", de Kent Beck. Ótimo livro que me ajudou quando eu estava prestes a ser gerente de projetos.

O que se resume é que você precisa dividir seu aplicativo em módulos funcionais e depois introduzir contratos (interfaces e contratos de dados) entre os diferentes módulos. Cada módulo pode ser entregue a um desenvolvedor diferente. Quando você reorganiza tudo, os contratos garantem que esses módulos se comuniquem corretamente uns com os outros.

Certifique-se de aplicar o TDD aos desenvolvedores, para garantir que todos os módulos funcionem individualmente.

Para dar um exemplo do que quero dizer:

Digamos que você queira que um de seus desenvolvedores construa um logger SQL.

Você define uma interface e pergunta a um de seus desenvolvedores ( ou cria uma história se estiver usando o Agile ) que deseja um logger específico do SQL de acordo com a seguinte especificação:

interface ILogger
{
    void Log(string message, int level);
}

O que eu espero de volta de um desenvolvedor é o seguinte:

1. A implementação específica do SQL para o criador de logs

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. Qualquer código dependente, como uma implementação para SqlLogRepository

3. Testes unitários ou simulados, dependendo do que foi solicitado. Um teste simulado no caso acima (onde temos outras dependências externas), ou se é, por exemplo, uma função de utilitário simples como String.ReverseCharacters(string input), então, eu simplesmente gostaria de ver testes de unidade que testam alguns cenários diferentes.

Isso significa que:

Agora você e sua equipe podem continuar o desenvolvimento usando essa interface. por exemplo

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

e se você precisar executar seu código antes que ele SqlLoggerocorra, você pode simplesmente criar um NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

E é assim que você pode testá-lo enquanto isso (eu sugiro olhar para uma OIC para injeção de dependência)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Sumário

Não tenho idéia do tamanho do seu projeto, mas isso pode ser uma tarefa bastante assustadora e, se você nunca liderou o desenvolvimento antes, sugiro que leve essa tarefa muito a sério e passe as próximas semanas lendo o quanto você pode em design de software e arquitetura. E seja muito transparente com seu trabalho ( qualidade de software, etc. ), caso contrário, você se encontrará rapidamente em uma confusão profunda da qual não sabe sair.

Eu também sugiro que você leia sobre design e o paradigma orientado a objetos. Você dependerá fortemente da OOP para este projeto.

As outras respostas falaram sobre os aspectos de programação, mas eu só queria mencionar o aspecto de gerenciamento de programas. Começarei com um aviso: não sou gerente de programa. Fiz um curso no nível de pós-graduação para gerenciamento de programas e minha experiência de trabalho envolve horas de licitação para pequenos projetos que geralmente têm menos de 500 horas e nunca mais de 1000 horas.

Mas tive que ajudar a definir tarefas para um laboratório em que tive que manter 2-3 pessoas ocupadas por 2 a 4 meses (tempo parcial e tempo integral). Uma coisa que realmente me ajudou foi o uso de software de gerenciamento de projetos como o Microsoft Project (não tenho certeza se existe uma versão de freeware por aí, mas seu empregador provavelmente tem algo parecido ... pergunte ao seu supervisor que tipo de software de gerenciamento de programas é usado na sua empresa). Em particular, eu uso bastante os gráficos de Gantt, que é a exibição padrão no Microsoft Project. Ao definir todas as tarefas e quanto tempo você acha que elas levarão, é possível obter uma visualização para brincar.

O gráfico de Gantt me ajuda mais por causa de sua visualização. Ver tarefas no papel não me ajuda muito, mas ver fotos bonitas e um gráfico certamente ajuda. O Microsoft Project também permite que você defina antecessores e datas de início, com a idéia principal "Encontrar a quantidade mínima de tarefas necessárias para a conclusão da tarefa X". Pelo menos em meus pequenos projetos, a quantidade de predecessores 'reais' é bastante pequena. De fato, em um projeto, tive o problema de que quase tudo podia ser feito simultaneamente e tive que sintetizar dois caminhos simultâneos que eram um tanto coesos. Por exemplo, tentei garantir que, se o desenvolvedor A tocasse na GUI, eles também trabalhassem em tarefas próximas à GUI.

Parece que você já estava fazendo muito disso no que diz respeito a papel e caneta, mas sempre acho realmente útil ver os gráficos de Gantt. Observar as tarefas alinhadas sequencialmente realmente me faz pensar: "Espere, a tarefa X realmente precisa ser feita antes da tarefa Y? (Na minha experiência até agora, fiquei surpreso com a frequência com que a resposta é realmente 'não')"

Parece que você se formou de desenvolvedor em engenheiro de software. Perceba que gerenciar o trabalho não é um exercício de design, mas os dois andam de mãos dadas. Você precisa gerenciar o trabalho que está sendo feito, e isso depende de como a sua empresa desenvolve o desenvolvimento. Se você tiver tempo e recursos, adote uma metodologia ágil - existem montanhas de materiais escritos na internet. Encontre um que funcione para você, mas saiba que, como todo o resto, não é gratuito. A adoção de qualquer técnica envolve treinamento, aprendizado e falha antes de você ter sucesso. Se você não tem a largura de banda necessária para adotar uma técnica mais abrangente, o planejamento de marcos pode ser a resposta para você. Se você tiver uma lista de tarefas seqüenciais, pode ser que você não tenha encontrado sequências que possamseja paralelizado. Também pode ser o caso em que você deseja segmentar seu desenvolvimento em tarefas mais gerais, como teste e implementação. Isso, por si só, não resolve o problema dos relatórios, mas você está gerenciando a qualidade. Sua progressão pode ser uma lista seqüencial, mas suas funções são paralelas. Apenas uma sugestão. Um design que mapeia o trabalho realizado por pessoas é chamado de estrutura de detalhamento do trabalho.

Existem muitas sugestões boas que outras pessoas ofereceram, mas lembre-se de que você está gerenciando o trabalho. Às vezes, você pode mapear os conceitos de trabalho no design / arquitetura; às vezes, não é possível fazer isso tão facilmente. Sempre existe uma maneira de estruturar o trabalho para que seja rastreável. Sugiro voltar ao seu gerente e perguntar o que é importante para ele quando se trata de comunicar o estado do projeto. Isso começará a dizer como abordar o que você está fazendo. Se for agendado, você deseja se concentrar no relatório dos progressos. Se for de qualidade, você deseja relatar um conjunto de métricas que precisará apresentar. Se os seus custos, então você provavelmente vai querer olhar para o esforço. Todas essas coisas também podem mapear dentro ou fora das tarefas.