sur l'exploration de 2-3 cadres / outils alternatifs
Parfois, cela peut se produire si vous avez une exigence particulière, vous devez faire un POC pour choisir le meilleur outil pour résoudre l'exigence. C'est à cela que sert Spike, car sans savoir quel framework vous utiliserez, vous ne pouvez probablement pas estimer l'histoire et stocker sans estimation ne peut pas être planifié et divisé en tâches.
puis sur l'apprentissage du cadre que nous sélectionnons pour le projet
Bien. C'est assez dangereux. Lorsque le client vous paie pour un SW, il s'attend à ce que vous soyez un professionnel qui sache déjà comment utiliser ses outils. Le client ne vous paie pas pour l'apprentissage ou l'approche de développement d'essai / d'échec. Il est de la responsabilité du développeur d'apprendre de nouveaux outils dans son temps libre ou dans le temps spécial alloué payé par son employé et non par le client. Dépenser de l'argent client pour apprendre sans en informer le client n'est pas professionnel.
Si vous devez vraiment utiliser quelque chose de spécial (par exemple, l'API d'un client ou un outil client sélectionné) que vous n'avez jamais utilisé auparavant, vous devez informer le client que le prix sera augmenté par le temps nécessaire pour apprendre à utiliser l'API. Peut-être que le client changera d'avis si l'augmentation des prix est trop importante.
Bien sûr, je ne parle pas d'une situation où vous devez rechercher un nouveau problème particulier dans le cadre que vous avez utilisé plusieurs fois. Je veux dire la situation où vous commencez à utiliser une nouvelle API ou un nouveau cadre sans passer un certain temps (en dehors du projet) pour l'apprentissage.
Si vous ne respectez pas cela, il sera de toute façon visible dans votre vitesse, car vous apporterez une très petite valeur commerciale par itération. Si le client n'est pas au courant de la raison, il annulera très probablement le projet.
Ceci est toujours valable en cas de projets internes - vous devez informer votre manager / entreprise du temps nécessaire pour apprendre une nouvelle API ou un nouvel outil. Cela a généralement de très mauvaises conséquences si le gestionnaire compte avec votre productivité normale et que votre productivité n'est qu'une fraction en raison de la nouvelle API que vous essayez d'apprendre pendant vos tâches. C'est évidemment encore pire si certains vendeurs calculent avec une productivité normale lorsqu'ils signent un contrat avec le client.
sur la configuration des serveurs (SVN, bases de données, etc.)
Ce sont votre infrastructure et vos coûts internes. Lorsque vous démarrez le projet, vous devez avoir préparé votre infrastructure. La configuration de votre environnement de développement n'a aucune valeur pour le client et ne doit faire partie d'aucun indicateur lié au projet - par exemple la vitesse dans Scrum. J'ai vu cela implémenté comme une itération spéciale d'avant-projet utilisée uniquement pour configurer l'environnement, créer une infrastructure de base, etc.