Devops for Growth

Dans la dernière colonne, on multiplie le Bénéfice par le Coût. On obtient ainsi un classement des actions à mener en priorité. Dans notre exemple, l’entreprise s’attaquera d’abord à la formation et au changement de l’outillage. Comme vous le constatez, il y a parfois des égalités, le stress et l’éclairage sont tous les deux à 12. Dans ce cas, soit vous arbitrez vous-même, soit vous ajoutez un coefficient à l’une des colonnes. Admettons que pour des raisons de budget, vous donner priorité au Coût. Vous ajouter donc un coefficient 2 à cette colonne. Après calcul, on voit que le Manque d’éclairage devient prioritaire par rapport au facteur Stress.

 Résumé 5M et diagramme d’Ishikawa

Voilà, ce qu’il faut retenir c’est que les 5M (Main d’œuvre, Matière, Méthode, Machine, Milieu) sont les 5 causes de variabilité d’un processus. Pour résoudre un problème de variabilité on peut utiliser le diagramme d’Ishikawa qui a l’avantage d’illustrer et de structurer la réflexion. On peut décomposer la méthode en 4 étapes :

• Constituer le groupe de travail
• Poser le problème et récolter en vrac les idées
• Structurer les idées selon les 5M
• Hiérarchisez les causes pour mettre en place un plan d’action

Ce système a été introduit en 1972 et permet de tenir compte simplement du ralentissement de la rotation de la Terre.

Les systèmes d’exploitation ordinaires ne peuvent pas s’adapter à une minute qui a plus de 60 secondes, pour cette raison, les organisations ont dû mettre en place des solutions pour gérer cette seconde additionnelle. Cependant, elles sont parfois amenées à faire face à des problèmes liés aux opérations qui prennent place durant cette seconde. Dans le passé, des systèmes de Google ont carrément refusé de fonctionner après la seconde intercalaire. Pour remédier à ce problème, Google va modifier ses serveurs NTP pour faire tourner les horloges plus lentement (-0.0014 %) pendant 10 heures avant la seconde intercalaire et 10 heures après. Grâce à cette technique appelée “smeared time”, les systèmes auront déjà pris en compte la seconde intercalaire. Google ne sera pas le seul à recourir à cette technique, Akamai compte ralentir ses horloges durant 24 heures avant et après la seconde intercalaire. Amazon et Microsoft ont suivi la même méthode dans le passé.

Although some Agile teams prefer to deal with bugs in a separate backlog, teams practicing Scrum generally find that it's cheaper and more efficient to handle bugs in the product backlog itself. Dealing with bugs on the product backlog can often be done effectively via "Three Amigos" meetings, which involve a product owner (or a business analyst), a developer and a QA tester who get together (either face-to-face or on-line) to review the bug, the tests used to detect it, and any other dependencies.

IEC 62304 prefers using the term Anomaly. It is defined at the beginning of the document and is used many times in the standard. That means that IEC 62304 focuses a big part of the efforts to reduce the amount of anomalies that remains when a software is delivered to end-users.

Characterization of defect

Defects can be so numerous, diverse and annoying that software engineers have defined a lot of attributes to characterize and categorize them. A bit like entomologists do with real bugs.
A defect has a title and an explanation plus a bunch of criteria. The most used criteria are:

• Severity: how it affects the use of software,
• Frequency: how often it appears,
• Version of Software: on which version of software,

Other "administrative" criteria are also useful:

• Status: is it open (still there), closed (fixed), pending (being fixed),
• Creation date: when it was found,
• Creator: who found it,
• Owner: who's in charge to fix it.

Some companies like to add a looong list of criteria in their databases to characterize defects. This is not very useful, as most of engineers only use a small set of them.

Severity, the most important criterion

Most of times, the severity is defined by values like:

• Critical: software stops or can't be used,
• Major: software doesn't give expected results, but there is a workaround,
• Minor: software gives a result with a non-significant discrepancy compared to expected result.

Some engineers like to add the Cosmetic value, for very minor things. When a word is misspelled in the user interface, but the whole thing remains understandable, then that defect can be set as cosmetic.

Severity is the most important criterion for software engineers because this is the one which is usually taken to sort defects by priority. The critical defects are fixed at first. The cosmetic ones are fixed when time remains.
This way of sorting defects can lead to epic situations when beta testers and engineers review and choose the defects that have to be fixed at first.
If you are an end-user that already participate to this kind of meeting, you already had to get along with a stubborn engineer that didn't want to set a high priority to a damned annoying bug!
If you are a software engineer, you already participate to this kind of meeting, and you already had to get along with a stubborn end-user that didn't understand anything to the way your software works and wanted to break something that works pretty well!
If you are a project manager, you know how long this meeting is going to be! :-)