Wie sollten Standards und Prozessverbesserungen in einer Organisation ohne sie eingeführt werden?


10

Ich wurde beauftragt, den Softwareentwicklungsprozess durch die Implementierung von Prozessverbesserungen zu verbessern, von denen wir höchstwahrscheinlich CMMI for Development, Version 1.3 als Richtlinie verwenden und die Best Practices ganz oder teilweise übernehmen werden. Was ist der beste Weg, um Standards und Prozessverbesserungen einzuführen, damit das Ausmaß des Zurückdrückens und des Widerstands von Entwicklern minimiert wird?


Nur neugierig, haben Sie bereits eine Idee, warum mehr Fehler durchkommen als gewünscht?
Chris Pitman

2
@ S.Lott Können Sie dafür eintreten, dass Fehler (auf der Verbraucherseite) nicht ohne Standards reduziert werden? Meine Erfahrung mit einem Prozess und Standards reduziert das, was der Verbraucher bei Fehlern sieht, erheblich. Nicht, dass sie nicht existieren, sie werden vom Kunden einfach nie gesehen.
Rig

@RobZ: Ich habe nicht gefragt, was Sie aktuell haben. Ich versuche immer noch, die Frage zu verstehen. "Implementieren von Prozessverbesserungen" scheint die genaueste Beschreibung dessen zu sein, wonach Sie fragen. Ich würde vorschlagen, dass "Standards" ein verwirrender Begriff ist, da er eine formale Definition hat und Sie diese formale Definition nicht verwenden.
S.Lott

@Robz: "Coding Standards" ist kein "formaler Standard". Das wird die Frage klären. Nochmal. "Formale Standards" sind W3C-, Posix-, ISO-, IEEE- und ANSI-Standards. Entworfen und genehmigt von einer anerkannten Standorganisation. Wenn Sie über Codierungsstandards sprechen, aktualisieren Sie bitte die Frage, um das Wort "Formal" zu entfernen und das Wort "Codierung" zu verwenden. Mit dieser Änderung macht Ihre Frage Sinn. Und ist ein Duplikat.
S.Lott

"In Bezug auf die Wörter" Standards "im Titel in Verbindung mit Prozessverbesserungen gilt das Wort Standards nicht nur für den Code, den jemand schreibt"? Was? Hier ist ein Hinweis. Bitte verwenden Sie das Wort "Standard" nicht ohne ein Qualifikationsmerkmal. es ist verwirrend. Wenn Sie "Codierungsstandards" meinen, verwenden Sie bitte diesen Ausdruck. Wenn Sie eine andere Art von "Standard" meinen, qualifizieren Sie das Wort "Standard" bitte mit einem qualifizierenden Satz, um zu verdeutlichen, wovon Sie sprechen. "Standard" ist vage und verwirrend.
S.Lott

Antworten:


2
  1. Starten Sie das SPI-Projekt (Software Process Improvement) . Definieren Sie den Umfang und die Ziele. Es ist auf jeden Fall hilfreich, wenn die Standardisierung ihre eigenen Ziele und Maßnahmen hat, die für Ihr Unternehmen gelten.
  2. Beauftragen Sie die Person, die für die Annahme von Standards verantwortlich ist . Bei großen Organisationen können es auch mehrere Personen oder sogar Abteilungen sein. Wichtig ist, dass alle Verantwortlichen für die Normung sind:
    • professionell genug , um das ganze Bild zu sehen
    • einflussreich genug , um mit Teams umzugehen und ihnen zu helfen, Änderungen zu übernehmen / zu verhandeln
  3. Entwickeln Sie Schulungen, die sowohl den Standard abdecken, den Sie übernehmen möchten, als auch die für Ihr Unternehmen geltenden Besonderheiten. Und es ist wirklich wichtig, solange alle Menschen, die nicht geschult wurden, potenziell resistent gegen Veränderungen sind. Als ich zum Beispiel in einem großen Unternehmen arbeitete, unterrichtete ich alle neuen Mitarbeiter über QS-Prozesse, CMMI, ISO und Qualitätsmanagementsystem. Eine solche Ausbildung war obligatorisch. Es hat dazu beigetragen, das Wissen über die Qualitätsmanagementprozesse zu verbessern und die Mitarbeiter für das wichtige Thema Softwarequalität zu sensibilisieren.
  4. Verhandeln Sie Änderungen und passen Sie allgemein anerkannte Praktiken an Ihre spezifischen Bedürfnisse an. Dies wird dazu beitragen, Bürokratie und die Implementierung schwerer Prozesse zu vermeiden, die niemand wirklich braucht.
  5. Überwachen Sie, wie implementierte Prozessverbesserungen unterstützt werden und ob sie in Ihrem Unternehmen effektiv genug sind.

Es ist auch hilfreich, wenn Sie alle Personen in Ihrem Unternehmen finden, die sich wirklich um die Qualität sorgen. Dies ist höchstwahrscheinlich die wichtigste Ressource, die Ihnen hilft, Veränderungen zu fördern und ausgereifte Praktiken zu etablieren.


6

Ein paar Gedanken aus der Schule der harten Schläge:

1) Die meisten Initiativen zur Prozessverbesserung verbringen 80% ihrer Zeit mit Prozessdesign und 20% mit Bildung und Sozialisation. Drehen Sie diese Prozentsätze um. Ein mittelmäßiger Standard, der befolgt wird, schlägt einen perfekten, der es nicht ist.

2) Identifizieren Sie klare Gründe, warum Sie die Leute bitten, ihre Arbeitsweise zu ändern. Was ist der Business Case? Im Idealfall kommt es jedem Team individuell zugute. Manchmal ist es nur eine systemische Verbesserung. Machen Sie den Fall in jedem Fall sichtbar.

3) Vereinfachen und dann standardisieren, nicht umgekehrt.

4) Sie können dies nicht vollständig an ein PMO delegieren. Direkte Manager müssen eingekauft werden, und der Leiter der Geschäftseinheit muss die Verbindung trennen, wenn Beschwerden eingehen.

5) Finden Sie freundliche Early Adopters. Die Leute werden sich darüber beschweren, wie viel Zeit das alles dauert. Sie brauchen jemanden, auf den Sie zeigen und sagen können: "Es hat nur 15 Minuten gedauert."

6) Drücken Sie bei Metriken auf Quantität und nicht auf Qualität. Andernfalls haben Sie Projekte, die bis zu einem Tag vor Go Live grün sind, wenn alles um einen Monat abrutscht.

7) Betonen Sie Techniken gegenüber Werkzeugen. Gute Planung ist wichtiger als MS Project.

8) Setzen Sie eine Prozessebene in Bezug auf die Bedürfnisse ein. Jedes Restaurant braucht einen Prozess, aber Nobu und die französische Wäscherei brauchen eine andere Art als McDonalds. Gleiches gilt für Softwarefirmen.

Viel Glück!


1
Gute Antwort - ich werde auch hinzufügen, seien Sie sehr vorsichtig mit dem Prozess, den Sie einführen - Stellen Sie sicher, dass Sie nicht in die Falle tappen, das Beste für den Prozess zu tun, nicht das Beste für den Kunden - dh der Prozess muss kundenorientiert sein. Seien Sie auch vorsichtig, was Sie messen - per Definition ist es wichtig, was gemessen wird und was nicht gemessen wird, ist unwichtig. Messen Sie die falschen Dinge (SLOC / Tag, Bugs / SLOC usw.) und Sie werden keine Verbesserung erhalten, aber die Messungen werden Ihnen sagen, dass Sie es sind.
Mattnz

1
@mattnz - Ich weiß nicht, Fehler / SLOC kann eine nützliche Metrik sein, wenn Sie sie richtig anwenden. Wenn jemand sagt, dass er durchschnittlich 1 Fehler / 10 SLOC hat, wäre ich wahrscheinlich besorgt. Der Trick ist, dass man wissen muss, wo sich die Bars befinden, was schwierig sein kann.
rjzii

Guter Punkt. Menschen optimieren auf ihre Metriken. Wenn Sie zuerst Finanzkennzahlen erstellen, optimieren die Mitarbeiter diese auf Kosten der Funktionalität oder des Kundendienstes. Es geht um Ausgewogenheit und Prioritäten.
MathAttack

1
Messen Sie mich an Fehlern / SLOC, SLOC / Tag, und Sie werden überrascht sein, wie ausführlich ich meinen Quellcode erstellen kann, ohne etwas Nützliches hinzuzufügen. Zum Beispiel das Platzieren von geschweiften Klammern in einer neuen Zeile - je mehr Zeilen, desto weniger der Status, desto besser werde ich sofort zum Programmierer. Geben Sie mir JEDES Maß, und ich zeige Ihnen, wie ich mit diesem Maß besser aussehen kann.
Mattnz

1
@mattnz - Dafür ist die Codeüberprüfung gedacht. Wenn jemand seinen Code unnötig ausführlich macht, um die Tatsache zu verbergen, dass er voller Fehler ist, sollte er wahrscheinlich zunächst keinen Code schreiben. Sie können sich auch Fehler pro Funktionspunkt ansehen, die extrem schwer zu fälschen sind, da Sie entweder eine Darstellung in der Anzahl der Funktionen sehen, bei der die Anzahl abnimmt (schlechtes Vorzeichen), oder die Anzahl beginnt nur zu sinken, wenn der Code besser wird (gut) Schild).
rjzii

2

Es ist wahrscheinlich eine gute Idee, Ihre Bemühungen auf das CMMI zu stützen, auch wenn Sie sich nicht den Bewertungen unterziehen und sich formell prüfen und bewerten lassen. Es gibt viel Literatur über CMMI , CMMI und andere Techniken zur Prozessverbesserung wie Lean und Six Sigma sowie CMMI und agile Softwareentwicklung . Das SEI verfügt über eine ganze Sammlung von Ressourcen , von denen einige kostenlos zur Verfügung stehen, zu verschiedenen Aspekten des CMMI und Leitlinien für verschiedene Arten von Organisationen.

Ich würde empfehlen, sich eingehend mit dem kontinuierlichen Ansatz zur Implementierung von CMMI und nicht mit dem abgestuften Ansatz zu befassen. Es scheint mir eine viel effizientere Möglichkeit zu sein, genau zu bestimmen, wo Ihre Organisation jetzt steht, und sich in Bereichen zu verbessern, die den größten geschäftlichen Mehrwert bieten. Auf diese Weise können Sie Ihre Verbesserungsbemühungen nicht nur an den Geschäftszielen ausrichten, sondern auch schnell Meilensteine ​​für Fortschritte erreichen und die Auswirkungen von Verbesserungen demonstrieren, wodurch das Buy-in auf allen Ebenen erhöht wird.

Zu beachten ist jedoch, dass die Prozessverbesserung im Allgemeinen erfolgreicher ist, wenn es sich um eine Basisanstrengung handelt. Wenn Prozessänderungen von oben diktiert werden - von Leuten, die die Entwickler "in den Gräben" möglicherweise als nicht in Kontakt mit der Vorgehensweise in den Gräben sehen -, wird es wahrscheinlich einen Pushback geben, selbst wenn die Idee gut ist. Seien Sie darauf vorbereitet.

Eine Art von Engineering-Prozessgruppe kann ebenfalls von Vorteil sein. Bringen Sie Vertreter der verschiedenen Organisationskomponenten und Teams zusammen, die von der Verbesserung betroffen sind, damit die Stimme aller gehört wird. Dies würde nicht nur Vertreter jeder Rolle einschließen, sondern möglicherweise verschiedene Produktentwicklungsteams. Ohne zu wissen, wie Ihre Organisation strukturiert ist, kann ich nicht genau sagen, wen Sie sich ansehen möchten, sondern Personen aus allen Ebenen der Organisation in die Gruppe einbeziehen. Stellen Sie der Organisation auch die Diskussionen und Entscheidungen dieser Gruppe zur Verfügung, um Kommentare abzugeben und Probleme anzusprechen.


Ich bin mir nicht sicher, wie gut es sein wird, die Basisanstrengungen voranzutreiben, da nur sehr wenige Projektteams Prozesse formalisiert haben, weshalb dies eher ein Top-Down-Prozess sein wird. Trotzdem sind alle besorgt, die Dinge so sanft wie möglich zu gestalten, um zu verhindern, dass die Bemühungen aufgrund mangelnder tatsächlicher Implementierung fehlschlagen.
rjzii

@RobZ Per Definition kann man nicht auf Basisanstrengungen drängen - es muss natürlich von unten nach oben kommen. Sofern die Projektteams nicht erkennen, dass es ein echtes Problem gibt, besteht die Tendenz, Änderungen nicht zu ändern und sich Änderungen zu widersetzen, die in irgendeiner Weise als schlecht empfunden werden (z. B. die Arbeit komplizierter oder schwieriger zu machen, was häufig mit Prozessverbesserungen verbunden ist, obwohl dies nicht der Fall ist ist nicht oft der Fall).
Thomas Owens

Genau und deshalb formalisiert das Management die Dinge. Es gab Probleme mit einigen der Software, die aus der Tür gegangen sind, und sie möchten auch die Unternehmenskultur ändern und sicherstellen, dass schlechte Produkte nicht wieder auf den Markt kommen.
rjzii

@RobZ Und wenn das Management eingreift und Aktionen diktiert, widersetzen sich die Entwickler. Sie können keinen kulturellen Wandel vorschreiben und erwarten, dass er einfach und leise stattfindet. Es ist ein langer, schmerzhafter Prozess.
Thomas Owens

Niemand erwartet wirklich, dass dies der Fall ist, und wir sind bereits auf Widerstand gestoßen. An diesem Punkt suchen wir nach Möglichkeiten, ihn zu minimieren.
rjzii

0

Für jede Änderung:

  • Rufen Sie die 1 Änderung auf und wie sie die Entwicklung verbessern wird.
  • Implementieren Sie die Änderung.
  • Verbesserung demonstrieren
  • Entfernen Sie Änderungen, die keine Verbesserung zeigten

Natürlich muss die Analyse im Laufe der Zeit erfolgen, aber keine Änderung sollte akzeptiert werden, bis sich herausstellt, dass sie effektiv ist. Das ist auch der Grund, warum ich nicht mehr als 2-3 Änderungen pro Zyklus implementieren würde, sonst kann man oft nicht messen, ob es Verbesserungen gegeben hat oder nicht.

Nichts irritiert mich mehr, als blind Best Practices zu befolgen, ohne die Analyse durchzuführen, um zu zeigen, dass dies tatsächlich eine Best Practice für Ihre Umgebung ist. Eine bewährte Methode , die keine Verbesserung zeigt, ist bestenfalls verschwenderisch und im schlimmsten Fall schädlich.

Alle Schritte in Ihrem Prozess und alle Methoden in der Methodik sollten analysiert werden und sich als nützlich erweisen. Wenn dies nicht der Fall ist, sollte es entfernt werden. Diese Analyse sollte fortlaufend durchgeführt werden, unabhängig davon, ob Schritte oder Praktiken hinzugefügt oder entfernt werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.