Melhor maneira de planejar a programação para equipes pequenas? [fechadas]

Sou o diretor de uma pequena organização de inicialização. Atualmente, temos dois programadores (um experiente e outro menos experiente) que estão criando uma plataforma de aplicativos da web.

Um dos maiores desafios até agora é o processo de planejamento. Os programadores geralmente são responsáveis ​​por planejar seu próprio trabalho, mas continuamos excedendo os prazos auto-impostos. Por exemplo, uma tarefa que eles estimam levará 2 dias e terminará em 8 dias.

Para mim, é difícil apoiá-los no planejamento, pois não tenho o conhecimento técnico para estimar com precisão quanto tempo uma determinada tarefa durará.

Você tem alguma ideia:

1. Qual é o motivo disso, isso é comum para programadores?
2. O que posso fazer para apoiá-los no planejamento? Existem métodos ou ferramentas úteis para programadores em equipes pequenas?

As técnicas gerais são um pouco de senso comum, o importante é saber que elas não requerem muita experiência técnica.

O ponto de partida do planejamento é identificar o problema exato que precisa ser resolvido e ter um requisito claro e inequívoco. Se você não tiver isso, suas estimativas estarão incorretas. Ter isso documentado em algum tipo de especificação de recurso antes que alguém comece a escrever o código significa que todas as perguntas que precisam ser feitas serão feitas antes do início da codificação. Este é um economizador de tempo surpreendentemente eficaz. Voltar e esclarecer os requisitos interrompe o fluxo de alguém como programador e esperar respostas pode bloquear o progresso.

Depois de identificar o requisito, você precisa identificar as tarefas de trabalho envolvidas na sua resolução. Este é um exercício clássico de dividir e conquistar - qualquer tarefa que possa ser mais detalhada precisa ser mais detalhada.

Em uma equipe maior, você pode usar o poker de estimativa para obter uma estimativa com base na experiência de todos os envolvidos. Isso não funciona tão bem em uma equipe menor, mas ainda é útil obter uma estimativa independente de seus desenvolvedores e talvez incluir uma de você também - sua falta de conhecimento específico pode ser útil aqui, porque, para explicar a você o que Se a tarefa envolver da perspectiva deles, a equipe de desenvolvimento provavelmente entenderá melhor o problema.

Com uma equipe menor, pode ajudar a obter uma estimativa do melhor / esperado / pior caso para cada tarefa, o que fornece um intervalo de valores, mas se você estiver recebendo muitas estimativas de excesso, poderá se inclinar para o pior caso até seus desenvolvedores Aprenda a estimar com mais precisão.

Em uma pequena loja, os desenvolvedores geralmente acabam dobrando como administradores de sistemas, equipe de suporte e até testadores (embora de todas as coisas que eles poderiam estar fazendo, o teste é o que você deve evitar a todo custo), por isso é necessário prestar contas. Descubra quanto tempo seus desenvolvedores realmente gastam trabalhando em novos recursos e leve isso em consideração em suas estimativas. Se uma tarefa for estimada em 2 dias, mas seus desenvolvedores só puderem trabalhar no novo desenvolvimento 60% das vezes, você precisará de 4 dias para concluir. Você também pode ajudar com isso, controlando o pipeline de outras tarefas que eles precisam executar, para que tarefas não urgentes de administrador ou suporte possam ser agrupadas um pouco em vez de serem tratadas ad-hoc. Muitos programadores (certamente me incluindo neste) não são grandes gerentes de tempo, então qualquer coisa que você possa fazer para ajudar nesse sentido ajudará. A tarefa única é sempre mais fácil para os programadores do que a tarefa múltipla. Bloquear o tempo durante o dia também pode ajudar com isso.

Mantenha um registro - sempre que tiver uma sessão de planejamento, registre as estimativas e os valores reais. Em seguida, você pode usá-lo a) como um guia de quanto inflar suas estimativas durante o planejamento eb) para ajudá-los a refinar suas habilidades de estimativa. No final de cada iteração (ou qualquer equivalente que você tenha), toda a equipe deve revisar o trabalho realizado e descobrir por que demorou mais do que o esperado para que isso possa ser incorporado em estimativas futuras. Isso precisa ser uma tarefa sem culpa - você parece ter a atitude certa aqui, mas essa resposta pode demorar um pouco, então eu farei a observação. Se alguém disser "eu cometi um erro aqui", você pode transformar isso em "o que você poderia ter feito melhor", mas dizer às pessoas que elas eram lentas demais ou entendiam errado as coisas só pioraria as coisas.

Não conheço nenhuma bala de prata para esse tipo de problema, mas o maior fator é a comunicação - o que é realmente mais fácil com uma equipe menor - e o uso de feedback para refinar suas habilidades coletivas.

Qual é o motivo para [a estimativa de 2 dias levando 8 dias], isso é comum para programadores?

É se:

• Na verdade, não está claro o que eles devem fazer; portanto, eles levam mais tempo para acertar (e devem dizer isso, não adivinhar quanto tempo levará)
• Eles não estão familiarizados com a tarefa em questão (devem mencionar isso e incluir pesquisas na estimativa)
• A integração da tarefa finalizada com o produto maior leva mais tempo do que o previsto (o que pode significar que a arquitetura do produto é inferior)
• O desenvolvedor gosta de reinventar a roda e, assim, se depara com problemas que foram resolvidos por outros, disponíveis gratuitamente em uma biblioteca
• As alterações são introduzidas pelo proprietário do produto enquanto a tarefa está sendo implementada, exigindo uma abordagem diferente e o refazer do trabalho já realizado
• Os desenvolvedores não trabalham em um ambiente produtivo (por isso, quando em casa, eles acham que levaria dois dias, mas no trabalho eles precisam de oito para compensar todas as distrações)

Para citar algumas coisas.

Talvez seja melhor perguntar aos seus desenvolvedores por que eles acham que suas estimativas estão muito longe. :-)

Você não seria o primeiro a tentar descobrir a melhor maneira de planejar o tempo de desenvolvimento. Isso se deve, em parte, ao fato de ser difícil quantificar algo que você não pode realmente ver sendo construído e, em parte, ao mítico mês do homem , que contrasta diretamente com a idéia intuitiva de que, se você tem 2 programadores, deve ser capaz de desenvolver duas vezes mais rápido do que se você tivesse 1 programador.

Como você provavelmente já percebeu, é muito mais complicado que isso. Uma abordagem para estimar o tempo de desenvolvimento é arredondar um grupo de indivíduos altamente qualificados para o desenvolvimento de software e pedir que eles calculem quanto tempo levaria para concluir um projeto (explicando o mais detalhadamente possível). Você pega a mais alta de todas as estimativas e o dobro . Sim, você leu corretamente. Você dobraa estimativa mais alta e você deve ter uma estimativa razoavelmente precisa. Eu sei, porque com o tempo, é assim que consigo dizer com precisão aos meus chefes quanto tempo leva para eu fazer alguma coisa. Reúno as opiniões dos meus colegas programadores e os meus e duplico a estimativa mais alta. Se isso parecer muito alto, considere que testar novas funcionalidades é crucial e considere possíveis correções de erros posteriormente, e isso parecerá um número mais razoável.

Na minha própria experiência pessoal como programador, posso dizer que isso ajuda a dividir projetos em marcos. Quanto tempo leva para atingir o marco 1, depois do marco 1 ao marco 2, depois o marco 2 ao marco 3, etc.? Quando discriminada dessa maneira, a resposta geralmente é muito mais precisa do que tentar estimar todo o projeto na sua totalidade. Estranhamente, se você resumir as estimativas de todos esses marcos, geralmente será maior que a estimativa original de todo o projeto (se o programador estiver sendo honesto consigo mesmo), o que me leva a pensar que os detalhes são a chave aqui.

Talvez você não tenha o conhecimento técnico, mas ainda deve tentar seguir em um nível mais geral. Programadores não têm problemas com repetição. São as voltas e reviravoltas que ocupam o tempo todo no desenvolvimento de um programa. Portanto, o mais provável é que, quanto mais funcionalidade você deseja incluir, mais complicado o programa se tornará e, assumindo que essa nova funcionalidade não tenha influência nas seções do código implementadas anteriormente, o desenvolvimento será linear de acordo com a quantidade de trabalho a ser executado. ser feito. Provavelmente, a nova funcionalidade influencia fortemente as seções implementadas anteriormente e, portanto, o desenvolvimento envolve não apenas implementar a nova funcionalidade, mas também consertar o código antigo, tornando o tempo de desenvolvimento exponencial.

Meu conselho a você seria: sem dizer aos programadores como fazer seu trabalho, tente entender como o programa funciona em um nível geral e em breve você poderá ver como as novas funcionalidades modificam esse comportamento e, assim, fornecem uma estimativa razoável de quanto tempo levaria para fazê-lo. Combine isso com suas estimativas (o dobro do valor mais alto) e você começará a ter uma idéia melhor de como estimar o tempo de desenvolvimento.

Espero que ajude!

Uma das razões pelas quais as estimativas estão muito distantes é porque a estimativa é realmente bastante difícil e requer que a experiência e o conhecimento sobre o sistema sejam alterados. Na maioria das vezes, é útil dividir grandes etapas em etapas menores.

Agora você tem muitas possibilidades daqueles que mencionarei dois:

• Planejando Poker
• PERT (Avaliação do Programa e Técnica de Revisão)

Planejando Poker

Isso funciona muito bem em pequenas equipes ágeis.

Trecho da wikipedia:

• Um moderador, que não vai jogar, preside a reunião.
• O gerente de produto fornece uma breve visão geral. A equipe tem a oportunidade de fazer perguntas e discutir para esclarecer suposições e riscos. Um resumo da discussão é registrado pelo Gerente de Projeto.
• Cada indivíduo coloca um cartão com a face para baixo, representando sua estimativa. As unidades utilizadas variam - elas podem ter dias de duração, dias ideais ou histórias. Durante a discussão, os números não devem ser mencionados em relação ao tamanho do recurso, para evitar a ancoragem.
• Todo mundo chama seus cartões simultaneamente, virando-os.
• Pessoas com estimativas altas e baixas recebem uma caixa de sabão para oferecer sua justificativa para a estimativa e, em seguida, a discussão continua.
• Repita o processo de estimativa até que seja alcançado um consenso. O desenvolvedor que provavelmente possuía a entrega tem uma grande parte do "voto de consenso", embora o Moderador possa negociar o consenso.
• Um cronômetro é usado para garantir que a discussão seja estruturada; o moderador ou o gerente de projeto pode, a qualquer momento, virar o cronômetro e, quando acabar, toda a discussão deve cessar e outra rodada de pôquer é jogada. A estrutura da conversa é reintroduzida pelas caixas de sabão.

Os bits importantes aqui são esclarecimento, discussão, chamando simultaneamente a estimativa, para que nenhum viés seja introduzido e consenso.

PERT

Muitas vezes, é difícil fornecer uma estimativa exata. O que é mais fácil é dar uma probabilidade. O PERT usa 3 valores para a estimativa:

• hora mais otimista para terminar (se houver menos problemas do que o esperado)
• tempo mais pessimista para terminar (se tudo der errado - excluindo grandes catástrofes)
• provavelmente o tempo para terminar (se tudo correr como esperado) <- é isso que seus desenvolvedores provavelmente estimam agora

Ao ponderar essas três estimativas, você obtém uma estimativa mais confiável.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

E / ou você é capaz de usar esses três valores para construir uma distribuição de probabilidade que possa refletir ainda mais a incerteza do mundo real. Distribuição beta e distribuição triangular são escolhas proeminentes. Usando isso, agora você pode aplicar estatísticas como "qual a probabilidade de concluir na data x com base nas estimativas atuais" ou "se eu quiser 95% de certeza, em que momento isso será concluído".

Na verdade, o PERT consiste em mais do que esses aspectos mencionados aqui, que eu omiti por uma questão de brevidade.

É fato que, se você não está mantendo métricas históricas, não pode nem chegar perto de fornecer estimativas razoáveis ​​com um grau razoável de precisão. E perguntar a outra empresa / pessoa quanto tempo levará para eles também não ajuda. O problema é que cada empresa e desenvolvedor tem sua própria maneira de fazer as coisas. Assim, toda empresa terá diferentes períodos de tempo para realizar exatamente a mesma tarefa. Cada desenvolvedor terá diferentes períodos de tempo para executar exatamente a mesma tarefa.

Seu melhor curso de ação é começar a acompanhar o tempo e, de alguma forma, descobrir como categorizar o grau de dificuldade da tarefa. Algumas empresas usam linhas de código, outras usam recursos, outras apenas passam por instinto. Além disso, você também deve levar em consideração se isso é semelhante a algo que os desenvolvedores já criaram ou algo novo, como nova tecnologia, novo recurso nunca criado antes pela equipe, etc. sistema de tempo, a complexidade geralmente aumenta bastante.

A menos que você colete dados reais, não importa quantas vezes seus desenvolvedores lhe dêem estimativas de que eles realmente estarão apenas retirando números deles cada vez que você pedir. Sim, coletar dados reais é trabalhoso e, a princípio, não fornece muitas informações úteis, mas com o tempo começa a fornecer estimativas razoavelmente precisas.

Gostaria também de salientar que as estimativas geralmente são boas apenas para o quadro geral e não para medições de curto prazo. Por exemplo, o desenvolvedor estima 2 dias, mas leva 8. Bem, o desenvolvedor não considerou ter que configurar um ambiente de teste e desenvolver um simulador ou que havia uma tecnologia totalmente nova que eles precisavam aprender ou que estavam presos a um bug eles não conseguiram descobrir ou a funcionalidade exigia uma refatoração do sistema existente. Você nem sempre pode prever esse tipo de coisa para pequenas tarefas. No entanto, ao longo de um projeto inteiro, esses 6 dias extras podem ficar desbotados por outras tarefas que levam 6 dias a menos de duração.

Sou desenvolvedor único em alguns projetos pequenos e tenho alguma experiência industrial trabalhando com uma grande equipe. Percebi que as técnicas usadas por uma grande empresa não funcionam necessariamente para uma equipe pequena. Em um ponto, eu estava fazendo mais planejamento e documentação, em vez de escrever código. Eu sugiro que você tente encontrar uma boa maneira de trabalhar primeiro, tentando diferentes técnicas (as outras respostas fornecem ótimas informações) e ferramentas; isso custará algum tempo e esforço, mas você será beneficiado posteriormente. Algumas ferramentas / técnicas que achei úteis foram:

Rastreador -Pivotal - Ótimo programa para acompanhar as histórias e incentivar a quebra de tarefas, é muito rápido ao inserir histórias e deduz automaticamente a velocidade. https://www.pivotaltracker.com/ .

-Gdocs para documentação, pois é fácil ter vários usuários editando e discutindo ao mesmo tempo.

- Em uma empresa em que eu costumava trabalhar, tínhamos uma reunião para cada história que iniciamos, essa reunião tinha que incluir um programador sênior, pois ele seria melhor em julgar quanto tempo levaria uma tarefa. Ele também seria melhor em julgar qual seria a parte difícil de uma tarefa.

Em resumo, acredito que a chave para trabalhar em equipes pequenas é ter um regime de planejamento sólido, rápido e fluido. Além disso, qualquer dificuldade com a história pode ser identificada cedo, para que o planejamento de uma tarefa tenha isso em mente (isso pode levar à construção de algo diferente).

Espero que isto ajude