Vie secrète de Windows : Éliminer les étapes d'approbation inutiles
Dans le cadre du développement intelligent d'un produit, il est important de savoir comprendre qu'une étape du processus n'est pas absolument indispensable.
Raymond Chen
Comme un produit se rapproche de l'expédition, que ce soit une version préliminaire comme un aperçu de la consommation ou la final release to manufacturing (RTM), chaque changement est soumis à un examen plus approfondi pour s'assurer que l'effort d'ingénierie limitée restante se concentre sur les questions importantes. Cet examen est également destiné à vérifier que chaque changement approuvées n'aura des conséquences inattendues qui font le remède pire que le mal.
Développement de produits de logiciel n'est pas seulement non linéaire, elle est discontinue. Une perturbation mineure dans une partie du code peut agrandir en un grand changement quelque part d'autre. Qui peut à son tour cascade dans un échec catastrophique.
Dans les premiers stades du processus de libération, un examen est livré au niveau local. Propriétaires de fonctionnalité regarder au-dessus de chaque demande de modification et décident quels sont ceux à accepter, que de reporter et que de rejeter. Par exemple, si le problème n'affecte un petit nombre de personnes ou a une solution de contournement facilement découverte, il est plus susceptible d'être reporté ou rejeté.
En supposant que le changement proposé passe les obstacles de l'impact de l'utilisateur et de la pertinence, le code pour implémenter la modification est écrit et testé. Puis l'équipe va examiner la modification proposée et accepter ou de rejeter selon divers critères, tels que le niveau de risque associé à ce changement. Ce n'est pas une procédure distincte. Évaluation se produit en continu, mais ces deux phases (acceptation initiale et examen final) sont généralement les plus controversées.
Comme la date limite approche à grand pas, il y a souvent une couche supplémentaire de contrôle ajouté au niveau de l'équipe. Chaque changement qui rencontre l'approbation des propriétaires caractéristique doit ensuite présenté pour les gérants de l'équipe globale. Les gérants de l'équipe peuvent décider de rejeter une modification qui a accepté les propriétaires de la fonctionnalité.
C'est généralement à ce niveau que les gens commencent à poser des questions embarrassantes. Combien de temps ce bug est là ? Ce bug même existent nulle part ailleurs ? Comment ce bug a été introduit ? Qui a signé au large sur le changement qui a introduit le bug ? Pourquoi n'essais trouver ce bug plus tôt ?
Ces questions ne sont pas destinées à embarrasser les propriétaires de la fonctionnalité. (Ce n'est pas leur seul but, au moins.) Chefs d'équipe doivent connaître ces réponses parce que corriger un bogue fourni dans la version précédente de Windows peut présenter un problème de compatibilité. Un bug avec l'ancienneté se transforme souvent en une contrainte de compatibilité. Un bug présent dans démoulante aperçu qui est allé non découvertes jusqu'à une date récente ne peut-être pas même vaut le risque de fixation.
Encore plus proche de l'expédition, commentaires étendre davantage la chaîne. Tout d'abord, ils êtes heurtés au groupe de niveau, puis enfin à toute l'équipe de produit de Windows. Dans ces dernières étapes, chaque modification proposée pour le produit est emmenée à la salle de navire de Windows. Ici vous devez représenter le changement et expliquer pourquoi vous croyez qu'elle devrait être acceptée dans le communiqué.
Windows 8 suivi ce processus, tout comme son père et son grand-père. Puis quelque chose d'intéressant qui s'est passé.
Après une des versions bêta de Windows 8 expédiés, les gens de la salle de navire de Windows a traversé leurs dossiers de tous les correctifs proposés pour approbation Windows salle de navire au cours de ce cycle préliminaire. Chaque bogue a été présenté, embarrassantes questions ont été posées, risques ont été mis en balance avec le bénéfice, et il s'avère que chacun a été finalement accepté.
Les gens qui dirigeaient la chambre d'expédier de Windows a conclu que cela signifiait que les chambres de groupe et niveau navire faisaient un bon travail de décider quels bugs fix et permettant de reporter ou de refuser. Le contrôle supplémentaire de la salle de navire de Windows n'était pas toute valeur ajoutée, parce qu'il n'a jamais annulé une décision du tribunal inférieur.
À la suite de cette analyse post-mortem, l'équipe de gestion de version a simplement reporté le processus Windows navire chambre pendant un certain temps. Ils observaient les décisions des chambres au niveau groupe de navire. La chambre de navire de Windows n'a pas été dissous indéfiniment, mais après avoir reconnu que ce n'était pas une partie essentielle du processus, arrêtant pendant un certain temps tout le monde laisse à obtenir quelques heures de retour de la vie.
.jpg)
RaymondDe Chen Web site, The Old New Thing et livre de même titre (Addison-Wesley, 2007) traitent d'histoire de Windows et de la programmation Win32. Ne pas être pris à l'intérieur.