Donc j'ai ramassé encore un livre sur le développement de logiciel et ai commencé à lire. Je n'étais pas capable de le finir parce qu'il me donne un tel mal de tête. Toutes les deux ou trois pages je reçois le désir irrésistible de donner une claque à mon front. À ce taux, je vais recevoir une secousse par le chapitre trois. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, ce gars continue des exigences : Comment le fait de ne pas avoir des exigences convenables provoque des projets d'être sur le budget et derrière le programme, comment le lèche-bottes de trait mène au programme de projet ingérable et aux promoteurs démoralisés, yadda, yadda, yadda. Non, vraiment ? No, really?

Et sa prescription est que quelqu'un copie les exigences et finit par toutes les parties prenantes terminer sur eux. Évidemment, il y a non seulement une sorte d'exigence - noooooo! - il y a beaucoup la sorte d'exigences. Aussi bien que les exigences d'utilisateur, sont là des exigences d'affaires et conçoivent l'exigence et les exigences thingajig et.... Je ne sais pas, mais beaucoup de beaucoup d'exigences funky et nom d'un chien, si le directeur de projet reçoit toutes les exigences écrites en haut et a terminé par toutes les parties prenantes, donc l'alléluia, ce sera UN projet qui finira à l'heure et sur le budget. Si seulement ces directeurs de projet stupides pourraient écrire en haut qu'un bon ensemble des documents d'exigence bat....! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Désolé, qui était ma tête frappant le bureau. Je crois que j'ai perdu la conscience depuis quelques secondes.

Bien, essayons de réfuter ce point de vue qui semble être la sagesse conventionnelle avec une exception où les exigences écrites à toute épreuve sont la règle : systèmes fixés. Fondamentalement, il est vraiment difficile de changer un fragment après qu'il a été conçu. Duh. Basically, it's really hard to change a chip after it's been designed. Duh.

Pour à peu près tout l'autre travail de développement de logiciel, c'est une bonne idée de mettre un ensemble d'exigences préliminaires par écrit. Et imprimez-les ensuite. Mais imprimez-les sur le papier très doux qui peut être utilisé dans la plus petite pièce de la maison. Puisque dans une période très courte, c'est la seule pièce où ce morceau de papier va être utile. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

Il y a deux raisons principales pourquoi, un évident & un subtil. Je commencerai avec l'évident : faisons semblants que vous êtes le client. Vous avez signé un contrat avec une maison de développement de logiciel pour construire un programme chic qui fait quelque chose. Vous avez accepté de payer de l'argent. Dans la plupart des cas, vous payez beaucoup d'argent. Vous avez mis votre signature sur un morceau de papier pour quelque chose qui n'existe pas dans le présent. Vous êtes douloureusement conscients aussi que quand ce morceau de logiciel est créé, si c'est ne satisfait pas les attentes de vos parties prenantes, ils vont vous permettre d'en être au courant. Et comment les temps une libération de logiciel rencontrent-ils 100 % des attentes du client ? Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Maintenant, après avoir signé un morceau de papier pour ce que beaucoup dans votre organisation considèrent une quantité obscène d'argent, une certaine période s'écoule et vous finissez par un autre morceau de papier lire, avec un titre en déclarant que c'est un design/utilisateur case/business/whatever le document d'exigences. Vous feuilletez le document. Cela semble pas mal. Il y a un espace pour votre signature. Peut-être vous le signez. Peut-être vous rendez un e-mail en disant que vous avez signé un morceau de papier pour des millions énièmes de dollars et c'est le seul morceau de besoin en papier de signer, jamais. Mais faisons semblants que vous terminez sur le docteur d'exigences signifie-t-il que vous, le client, avez renoncé au droit de jamais contacter, communiquez ou harcelez le développement associent à de nouveaux traits et/ou des exigences ? It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

Non. Jamais. Jamais. Il n'y a aucun client qui existait jamais depuis la nuit des temps qui ne harcèlera pas continuellement le développement pour de nouveaux traits directement jusqu'au moment de libération et après. Arriver. Utilisé. À. Cela. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

Donc la leçon pour n'importe quel directeur de projet n'est pas passent trop de temps lors de le fait d'enrôler des docteurs d'exigence bien sûr, les raccrochent brutalement vite et je veux dire les raccrochent brutalement, mais si, les miracles de miracles, le client rend un pas mal et un document terminé, même ne croyez pas que votre travail soit fini. L'amusement vient de commencer.

Cela aborde mon deuxième point du fait de tomber dans le piège d'exigences de la documentation : le fait de recevoir toutes les exigences est super-dur. Dans la plupart des cas, c'est impossible. Pas même le client et le client du client, peuvent vous donner 100 % des exigences. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Regarde, il est comme aller au fan-club de Julia Roberts et à l'adage : "nous voulons faire une histoire d'amour avec Julia et Brad Pitt. Ils tombent amoureux, ils luttent & la dissolution et ensuite ils inventent et tombent amoureux de nouveau. À la fin du film, tout le monde dans l'audience parce que le film était si magnifique. Voici le script du film. Pouvez-vous nous assurer qu'après avoir vu ce film, vous arriverez pour votre hankie ?" They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Permettez-moi de raconter un exemple du monde réel (j'ai changé certains des détails pour protéger l'innocent) : Un du client de Creo avait un peu de technologie d'imprimerie qui courait avec une suite de logiciel développée au début des années 1990. Creo a un logiciel de pré-presse développé environ une décade plus tard qui est considérablement supérieur. Cependant, il y avait quelques traits uniques qui étaient nécessaires pour être développés et ajoutés à la suite de logiciel de Creo. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

La direction de projet pour le client était coordonnée du siège social au milieu des Etats-Unis alors que la technologie d'imprimerie était basée au site d'équipement près de la Côte Ouest. J'ai volé en bas à l'usine pour mettre en valeur la suite de logiciel de Creo et les exigences de capture. A fait la présentation, a volé en arrière à Vancouver. Deux ou trois semaines plus tard, nous recevons le message diplomatique du siège social que peut-être toutes les exigences n'ont pas été capturées. Donc je vole en bas de nouveau. Je m'arrange aussi pour faire charger la suite de logiciel de Creo sur un serveur et expédié au site d'équipement comme un loaner. Cette fois, pendant la présentation, ils ont leur super-utilisateur, leur administrateur de système sous la main. J'ai de la chance que le client est assez intelligent pour sortir leurs utilisateurs à la présentation pour critiquer la suite. Le super-utilisateur va profondément sur moi. Cela signifie qu'elle fore en bas beaucoup de niveaux à certains obscurcissent vraiment (à moi), mais important (pour eux) l'exigence d'affaires qui n'est pas dans notre suite de logiciel. J'ai promis de confirmer sur ces traits par un peu de PME de Creo (les experts de sujet) quand je rentre au bureau. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Pendant ce temps, le serveur avec le logiciel de Creo arrive sur place avec un représentant de terrain local pour faire installent et l'entraînement préliminaire. Je prends des dispositions aussi pour ce qu'un entraîneur enchaîne une visite sur place au client une semaine plus tard. Je pré-informe l'entraîneur pour regarder & annoncer pour n'importe quelles nouvelles exigences. Six semaines plus tard, j'envoie à un autre entraîneur. Environ cinq mois ont passé depuis ma première visite à la suite de client. Finalement, le super-utilisateur est capable d'articuler les exigences que l'usine ait besoin au représentant de Creo qui est aussi un SME dans ce sous-thème particulier. Donc nous faisons capturer les exigences et nous les transmettons à l'équipe de développement et nous recevons le message en arrière qu'aucune des exigences n'est impossible de réaliser, il faudra environ trois mois pour rouler dans la mise à niveau suivante. Fin d'histoire. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Maintenant, notez que font les études dans ce cas-là :
1. Le client était raffiné, en pensant que nous avions besoin de faire passer le super-utilisateur beaucoup de temps en jouant avec notre logiciel donc elle pourrait découvrir ce qui manquait.
2. Nous avions beaucoup de temps. Le fait de recevoir les exigences convenables a pris cinq mois. Le codage des exigences a pris deux semaines (la charge administrative de rouler de nouvelles mises à niveau dans la suite de logiciel estimée depuis les 2.5 autres mois). Getting the proper requirements took five months. Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. C'était une modification d'une suite de logiciel préexistante. Nous ne présentions pas au client un "morceau en blanc de papier." We were not presenting the customer with a "blank piece of paper."
4. Les affaires ont valu assez pour envoyer à un serveur loaner avec le logiciel à l'usine ET avoir un total de cinq visites séparées à l'usine (deux voyages par le directeur de projet, un par un représentant local et deux par les entraîneurs).

En conclusion, le point de cet essai est que le fait de recevoir des exigences dans le monde réel n'est pas tellement un point de documentation, mais un processus itératif avec le client qui continue par le cycle de la vie du processus de développement (et au-delà).
Je vais essayer de finir le livre que je lis, si seulement me présenter aux employeurs futurs comme la fonte de sagesse (conventionnelle). Mais vraiment, si les bois sont pleins des directeurs de projet qui croient qu'ils sont sans maison dès qu'ils documentent les exigences d'un projet au début du cycle de développement, alors c'est ce n'est pas étonnant que beaucoup d'entre eux reçoivent shredded après quelques années dans les affaires.

Étiqueté comme : 166, 186, 83 166, 186, 83