Les techniques générales sont un peu de bon sens, la chose importante à savoir est qu'elles ne nécessitent pas beaucoup d'expertise technique.
Le point de départ de la planification est d'identifier le problème exact qui doit être résolu et d'avoir une exigence claire et sans ambiguïté. Si vous ne l'avez pas, vos estimations seront incorrectes. Le fait de documenter cela dans une sorte de spécification de fonctionnalité avant que quiconque ne commence à écrire du code signifie que toutes les questions à poser auront été posées avant le début du codage. Il s'agit d'un gain de temps étonnamment efficace. Revenir en arrière et clarifier les exigences brise le flux en tant que programmeur et attendre des réponses peut bloquer les progrès.
Une fois que vous avez identifié l'exigence, vous devez identifier les tâches de travail impliquées dans sa résolution. Il s'agit d'un exercice classique de division et de conquête - toute tâche qui peut être décomposée doit être décomposée davantage.
Dans une équipe plus grande, vous pouvez utiliser l'estimation poker pour obtenir une estimation basée sur l'expérience de toutes les personnes impliquées. Cela ne fonctionne pas aussi bien dans une équipe plus petite, mais il est toujours utile d'obtenir une estimation indépendante de vos deux développeurs et peut-être d'en inclure une de vous-même - votre manque d'expertise spécifique peut être utile ici car en vous expliquant ce que la tâche implique de leur point de vue, l'équipe de développement comprendra probablement mieux le problème.
Avec une équipe plus petite, cela peut aider à obtenir une estimation du meilleur / attendu / pire cas pour chaque tâche, ce qui vous donne une plage de valeurs, mais si vous obtenez beaucoup d'estimations de dépassement, vous pouvez incliner vers le pire des cas jusqu'à ce que vos développeurs apprendre à estimer plus précisément.
Dans une petite boutique, les développeurs finissent souvent par doubler d'administrateurs système, d'équipe de support et même de testeurs (bien que de toutes les choses qu'ils pourraient faire, le test soit celui que vous devriez essayer d'éviter à tout prix), vous devez donc en tenir compte. Calculez combien de temps vos développeurs passent réellement à travailler sur de nouvelles fonctionnalités et intégrez-les à vos estimations. Si une tâche est estimée à 2 jours mais que vos développeurs ne sont capables de travailler sur de nouveaux développements que 60% du temps, vous aurez besoin de 4 jours pour qu'elle soit terminée. Vous pourriez également être en mesure d'aider à cela en contrôlant le pipeline d'autres tâches dont ils ont besoin pour gérer de sorte que les tâches d'administration ou de support non urgentes puissent être regroupées quelque peu plutôt que d'être gérées de manière ponctuelle. Beaucoup de programmeurs (y compris certainement moi-même sur celui-ci) ne sont pas de bons gestionnaires de temps, donc tout ce que vous pouvez faire pour prêter main forte à cet égard vous sera utile. Les tâches simples sont toujours plus faciles pour les programmeurs que les tâches multiples. Bloquer le temps pendant la journée peut également vous aider.
Gardez une trace - chaque fois que vous avez une session de planification, enregistrez les estimations et les chiffres réels. Vous pouvez ensuite utiliser ceci a) comme un guide pour savoir combien gonfler leurs estimations pendant la planification et b) pour les aider à affiner leurs compétences d'estimation. À la fin de chaque itération (ou l'équivalent que vous avez), toute l'équipe devrait revoir le travail qui a été fait et comprendre pourquoi cela a pris plus de temps que prévu afin que cela puisse être incorporé dans les estimations futures. Cela doit être une tâche irréprochable - vous semblez avoir la bonne attitude ici, mais cette réponse peut prendre environ un certain temps, donc je ferai l'observation. Si quelqu'un dit "J'ai fait une erreur ici", vous pouvez transformer cela en "qu'est-ce que vous auriez pu faire mieux", mais dire aux gens qu'ils ont été trop lents ou ont mal tourné ne fera qu'empirer les choses.
Je ne connais pas de solution miracle pour ce type de problème, mais le principal facteur est la communication - qui est en fait plus facile avec une équipe plus petite - et l'utilisation des commentaires pour affiner vos compétences collectives.