La plupart du temps, pendant la phase d'appel d'offres d'un projet, je reçois les exigences d'un système logiciel de nos clients potentiels dans un format très non structuré provenant de diverses sources [e-mail, documents Word, Excel]. C'est généralement un groupe de gars du «développement de produits» du côté du client qui proposent ces «solutions proposées» aux problèmes commerciaux qu'ils rencontrent. Bien qu'ils soient les experts dans le domaine des affaires, la plupart du temps, ils n'ont pas les bonnes solutions.
Il en résulte
- plusieurs versions de la même exigence
- mélange de deux exigences en une seule
- quelques versions de l'exigence plus tard sur la ligne, les exigences qui ont été combinées sont à nouveau séparées, chacune emportant avec elle certains des nouveaux ajouts
Comment travaillez-vous avec ces exigences qui arrivent et triez-les dans des cas d'utilisation appropriés et avant le début du développement? Quels outils pouvons-nous utiliser pour suivre l'historique d'une exigence particulière, de la première fois qu'elle a été conçue jusqu'à ce qu'elle se cristallise dans un cas d'utilisation approprié? L'estimation du travail par rapport aux exigences reçues de cette manière est un cauchemar qui finit par faire des erreurs dans la compréhension correcte de l'exigence et l'estimation correcte de l'effort par rapport à elle.
Une fois que nous avons remporté le projet, les clients ont réfléchi davantage à leurs besoins et ont pu l'articuler correctement. Ce qui se passe dans ce cas, c'est que certaines fonctionnalités sont supprimées, certaines améliorées, certaines prennent un tout nouveau tournant. Cela peut essentiellement annuler certaines des estimations de l'élément de travail qui ont été faites avant que le projet ne soit remporté. Je serais intéressé de savoir s'il existe un système par lequel nous pouvons construire un arbre d'une exigence particulière et comment chaque branche a abouti à une estimation différente.
Des conseils, des outils, des astuces pour rendre cette activité plus facile à gérer? J'essaie simplement d'obtenir des informations de quelqu'un de plus expérimenté que moi dans la gestion des exigences et l'estimation des efforts.
la source
Réponses:
Les exigences vont grandir et changer. Je ne pense pas que quiconque puisse contester cela.
Comment collecter et traiter les demandes entrantes .
D'après mon expérience, cela aide lors de la collecte des exigences s'il existe un seul ou très petit groupe de clients agissant comme un filtre pour fournir des exigences nouvelles ou mises à jour à un petit groupe de planificateurs de développement. N'importe qui de leur côté peut les proposer ou les rédiger, mais la livraison ne doit se faire que par un très petit nombre. Moins il y a de personnes impliquées dans l'échange d'une partie à l'autre, mieux c'est.
Le filtrage à travers un plus petit groupe de personnes n'a pas pour but de rejeter ou de diminuer l'effort et les informations que d'autres mettent, même s'ils sont en double ou apparemment sans importance à la surface, mais de limiter les points de défaillance: informations perdues ou mal gérées. Il suit un principe similaire à celui de l'encapsulation et des interfaces: protéger les données privées et établir un protocole commun pour traiter les demandes similaires. Permettez-moi de répéter: la soumission de doublons est acceptable. En tant que planificateur, cela me dit que ce dont ils parlent ou proposent est important. Enregistrez ou enregistrez tout.
Comment suivre et organiser les exigences
A court terme, passez à la low tech
De toute évidence, il existe des solutions à faible technologie qui peuvent être efficaces dans une large mesure pour organiser et suivre les besoins entrants: tableaux blancs, adhésifs, affiches, etc. Ceux-ci peuvent être parfaits pour la planification à court terme. Ils sont très visibles, acceptent la notation de forme libre et sont faciles à «reconfigurer».
À long terme, utilisez un outil logiciel consultable, triable et pouvant être lié
Pour des efforts à plus longue portée, une sorte de logiciel serait utile. Il existe des outils spécialisés de gestion des exigences: Portes, Clearcase / Clearquest et bien d'autres. Ces outils hautement spécialisés sont excellents dans ce qu'ils font, mais sont souvent excessifs. Parfois, même un simple vieux tableur est plus que suffisant. Personnellement, je trouve les systèmes de suivi des problèmes généraux assez utiles pour y parvenir, et en ce moment mon préféré est Redmine, mais d'autres, j'en suis sûr, iraient bien aussi.
Avec un système de suivi des problèmes, toute personne que vous choisissez d'autoriser peut créer un `` nouveau problème '' ou une exigence, et ajouter tout détail qu'elle juge opportun d'inclure. Ils peuvent regarder le problème et donner leur avis sur toutes les actions que vous entreprenez. Vous pouvez le reclasser, ajuster la priorité, réécrire le corps, joindre des informations supplémentaires, l'associer à d'autres `` problèmes '', promouvoir à un niveau supérieur ou un `` cas d'utilisation '' ou une histoire ou la terminologie qui convient à votre système, ad nauseum. En d'autres termes, vous pouvez faire beaucoup pour créer une liste d'exigences liées, traçables, triables, hiérarchisées et liées à l'historique via des problèmes. De plus, étant assez configurable prêt à l'emploi et open source, si l'outil n'est pas tout à fait ce dont j'ai besoin ou que je veux à tout moment, je peux le changer assez facilement pour mieux répondre aux besoins de mon processus.
Une dernière remarque sur les outils, certaines personnes avec qui j'ai parlé ont beaucoup de succès à utiliser des fichiers de texte ancien dans un système de gestion des modifications et de gestion des versions. Ils bénéficient évidemment des avantages des versions historiques. Ils utilisent également le système d'exploitation de base et des outils supplémentaires pour rechercher, lier et cataloguer les exigences. Ils ne sont pas en mesure d'ajouter autant de méta-informations structurées et connexes, mais ils ne pensent pas en avoir besoin, et pour leurs efforts n'ajoute pas suffisamment de valeur. Cela peut ou non être le cas pour vous. L'avantage est qu'il y a potentiellement un peu moins de logiciels sur votre pile de développement à gérer et à maintenir.
Exigences d'attribution du contrat après l'attribution du contrat / de développement du projet
Le dernier aspect de la question est de savoir comment gérer les exigences après le début d'un effort. Je pense qu'il y a deux réflexions principales à ce sujet, et une partie de la façon dont vous les gérez dépend de la nature de votre relation avec le client: premièrement, si sous contrat à valeur fixe, les exigences qui surviennent après l'attribution du contrat peuvent être incorporées. L'implication est qu'ils peuvent changer la portée de l'effort, donc le taux ou la facture seront plus élevés lorsque ces articles supplémentaires seront livrés et acceptés; à moins qu'un effort équivalent ne soit supprimé de la proposition acceptée. S'il s'agit d'un changement de portée, vous devez vous assurer que le client comprend et accepte la conséquence, sinon, ces soumissions tardives devront être déposées.
Deuxièmement, pour les nouvelles exigences à venir après l'attribution du contrat, et le contrat est davantage orienté vers un temps et un effort matériel (tout ce qu'il faut pour terminer le travail), vous pouvez et devez être un peu plus flexible si le le client insiste pour l'inclure lors de cette opération. Vous serez payé, que vous l'incluiez ou non, tant que tout ce que vous dites que vous ferez sera fait.
Si vous ne les connaissez pas, vous pouvez envisager une approche Kanban et des méthodes Agiles. Ces techniques peuvent aider à se concentrer sur les préoccupations immédiates, sans nécessairement perdre de vue les objectifs de développement à plus long terme.
Présentez les options comme des scénarios de simulation et donnez au client le choix et la décision
Dans les deux cas, une estimation par simulation est une bonne stratégie à utiliser lors de la négociation avec le client et votre équipe. Construisez une comparaison côte à côte des tâches, de leurs coûts et du calendrier comme prévu, avec une colonne montrant les mêmes informations pour les approches alternatives. Microsoft Project est probablement un bon candidat pour cela, car vous pouvez construire différentes estimations basées sur un ensemble de tâches largement similaires.
Cependant, même une feuille de calcul de base est souvent tout aussi efficace pour démontrer comment des changements ou des inclusions spécifiques pourraient affecter le coût et le calendrier. Dans ce cas, une liste est probablement aussi efficace qu'un arbre pour démontrer les différences. L'outil et la méthode que vous choisissez pour construire ces scénarios dépendent en grande partie de la taille du projet et du personnel (mais même un logiciel triple A comme MS Project a ses propres limites d'utilité et de capacité).
Considérez ces scénarios comme des éléments de travail internes et enregistrez-les pour la durée du projet. Ils ont été des manifestations critiques du processus de prise de décision et de négociation. Vous devrez peut-être également les revoir, ou les répéter pour une série successive de ce qui se passe.
Lors de la préparation de scénarios hypothétiques, une explication supplémentaire des avantages et des inconvénients d'un point de vue technique ou de mise en œuvre (en termes simplifiés) pourrait être utile pour aider à justifier pourquoi une alternative aurait un impact si important.
la source
Je considérerais cela comme un processus itératif. L'étape 1 consiste à rassembler les exigences. L'étape 2 consiste à les trier. L'étape 3 consiste à les hiérarchiser. L'étape 4 consiste à décomposer chacun en bits suffisamment petits pour estimer l'effort. L'étape 5 consiste à fusionner ces bits en un ensemble d'efforts globaux (disons 84 jours-personnes). L'étape 6 consiste à mapper l'effort sur les ressources (84 jours / personne / 2 devs = 42 jours).
Donc, en ce moment, vous êtes coincé entre l'étape 1 et l'étape 2. Vous avez des exigences, mais vous ne les avez pas sous la forme dont vous avez besoin.
Supposons que vous ayez plusieurs versions de la même exigence. Sont-ils essentiellement les mêmes? Si oui, choisissez ce qui semble être le plus clair et utilisez-le. S'ils varient dans les détails, choisissez ce qui semble être le plus logique et utilisez-le. Envoyez ensuite un message au client pour lui demander de vérifier l'exigence. Vous devrez peut-être faire des allers-retours et un certain nombre de fois pour obtenir la bonne exigence. N'abandonnez pas et ne vous découragez pas. De nombreux projets ont échoué en raison de mauvaises exigences.
Utilisez Microsoft Project pour synchroniser le travail et le calendrier avec l'évolution des exigences. Si le client demande une modification, spécifiez le travail supplémentaire, branchez-le dans votre modèle et informez-le de la nouvelle date. Ne vous laissez pas croire que vous pouvez simplement apporter de nouveaux développeurs à des intervalles aléatoires pour prendre le relais. Votre calendrier doit tenir compte du temps de montée en puissance chaque fois qu'une nouvelle ressource est ajoutée. Vous ne pourrez modéliser cela correctement que si vous prêtez attention à chaque projet et en tirez des leçons. Supposons que vous ayez amené Bob à bord du projet X après qu'il se soit déroulé pendant 4 mois. À quel point était-il productif au premier mois? Le 3ème?
Vous devez revoir le modèle de projet chaque semaine, en effectuant des mises à jour chaque fois que cela est nécessaire. Gardez une trace historique des changements. Cela vous aidera à fournir de meilleures estimations à l'avenir.
doug
la source