 |
Wollen Sie Neuigkeiten zum Thema Reviewtechnik rechtzeitig erfahren? Dann lassen Sie sich in die Mailingliste aufnehmen: eine E-Mail mit Betreff "subscribe Reviewtechnik-Mailingliste 1" an ros@reviewtechnik.de genügt. Sie erhalten maximal 2 E-Mails pro Jahr! Die Mailingliste erreicht derzeit ca. 1000 Personen.
Folgende E-Mails wurden bis jetzt gesendet:
[E-Mails sind z.T. gekürzt und Links aktualisiert]
12.04.2022
Ab Juli werde ich meine Arbeitszeit als Qualitätsmanager Softwareentwicklung bei ZEISS Microscopy auf 20 Stunden pro Woche reduzieren (um mehr Zeit für mein "Hobby" Schnell-Lesen zu haben). Auch deswegen suchen wir ab Oktober eine neue Kollegin oder Kollegen in der Rolle "Manager Regulatory Affairs". Das wird die Person am Standort München sein, mit der ich am engsten zusammenarbeiten werde. Das Steuern von Software Reviews steht zwar nicht explizit in der Stellenanzeige, wird aber von uns gemeinsam durchgeführt.
24.11.2020
am Mittwoch, 09.12.2020 17-18h MEZ findet ein ACM TechTalk über "Code Reviews – From Bottleneck to Superpower" statt, Teilnahme kostenlos auch für Nichtmitglieder. Die Referentin Dr. Michaela Greiler ("Doctor McKayla") ist eine Expertin auf dem Gebiet der Code Reviews mit viel praktischer und theoretischer Erfahrung (Publikationen).
Zum Thema Reviews sind Veranstaltungen wie diese übrigens ziemlich selten. Über diese Mailingliste hatte ich zuletzt in 2003 einen eWorkshop zu "Software Inspections and Pair Programming" angekündigt (Sie erinnern sich sicher :-). Wenn Sie am 09.12. teilnehmen können, wäre das eine gute und seltene Gelegenheit!
20.06.2020
Im Jahr 2019 wurden 42 Software-Entwickler am Münchner Standort der Carl Zeiss Microscopy GmbH zu ihren Code-Review-Aktivitäten befragt. Die meisten von ihnen waren 2017 in Reviewtechniken geschult worden. Ergebnis:
- Die Entwickler verwendeten 18,7 % ihrer Arbeitszeit für informelle Code-Reviews und (wie aus der Review-Datenbank ersichtlich) 0,5 % ihrer Arbeitszeit für formale Code-Reviews.
- Die Zeit für Code-Reviews teilte sich etwa halbe/halbe in "Fehlersuche" und "Behebung gefundener Fehler" auf.
- 74 % des geänderten/neuen Codes wurden informell überprüft (Vergleichswert von 2015: ca. 16 %).
- Etwa 2.800 "Major defects" pro Jahr wurden durch Code-Reviews entdeckt (Vergleichswert: ca. 2.500 Fehler wurden durch Tests entdeckt).
Disclaimer: Diese Ergebnisse wurden aus Umfrageantworten und aus dem Inhalt der Review-Datenbank abgeleitet (und basieren u.a. auf der Annahme, dass ein Reviewer mit "demselben Gehirn" prüft, d.h. dass er oder sie mit einem informellen Review ebenso viele "Major defects" pro Prüfstunde entdecken kann wie mit einem formalen Review). Außerdem dürften die Antworten einem gewissen "Bias" in Richtung höherer ("gewünschter") Werte unterliegen.
22.02.2019
Zum Anlass "20 Jahre Reviewseminare" hier ein bisschen Statistik. Mein erstes Seminar fand vom 22.-23.02.1999 bei der
Technischen Akademie Esslingen statt (mit nur mittelprächtiger Qualität, wie ich im Nachhinein zugeben muss; auch war ich noch nicht von Tom Gilb ausgebildet). Bis jetzt haben 1.784 Teilnehmerinnen und Teilnehmer insgesamt 185 Review-Seminare
besucht. Fast alle Seminare fanden in Deutschland statt, vier Seminare in Österreich, drei in der Schweiz und je eines in UK und Singapur. Die Seminare in Deutschland waren übrigens geographisch nicht besonders gleichverteilt, z.B. sechs Seminare in Karlsruhe und dagegen nur vier in Berlin und nur zwei in Hamburg (und spiegeln wohl wider, wo die IT-Industrie im Land ihre Schwerpunkte hat).
"Hoher Besuch" im September 2018 in München: Dr. Ernest Wallmüller ist einer der bekanntesten SW-Qualitätssicherungs-Experten im deutschsprachigen Raum und ich hatte die Freude, dass er mich spontan besuchte und wir uns erstmalig persönlich austauschen konnten, u.a. über sein neues Buch "Praxiswissen Digitale Transformation".
21.07.2018
In der Softwareentwicklung bei ZEISS Microscopy München wurden 2017 über 80% der Entwickler in Reviews geschult. Es werden viele informelle und einige formelle Reviews durchgeführt. In die Reviewdatenbank sind bis jetzt die Ergebnisse von über 100 formellen Reviews eingegangen, davon 20% Textdokumentreviews und 80% Code Reviews. Bei den Textdokumentreviews betrug der Aufwand, einen "Major Defect" zu finden, 1,5 h. Dieser Wert ist ungefähr so hoch, wie aus der Literatur zu erwarten (Gilb&Graham, 1993). Bei den Code Reviews waren ungefähr 4 h Aufwand nötig, um einen "Major Defect" zu finden. Dieser Aufwand sieht zuerst hoch aus, ist aber erklärbar. Die Software ist GUI-nah und die meisten Code Reviews wurden auf Software durchgeführt, die schon einige Testphasen durchlaufen hatte, also schon "vorgesäubert" war.
Das Reviewtemplate Review_Template_RC_en_v1.3.xlsx (Quelle) hat sich im Prinzip bewährt. Ein neues Feld "Quality of review object before review"“ müsste eigentlich noch eingeführt werden. Derzeit schreiben wir diese Information in das "Additional remarks"-Feld. Ein typischer Eintrag lautet: "Code quality before review: UI tests done by developer. Unit tests available with estimated 80% automated statement test coverage." Das erlaubt uns, die Daten später besser interpretieren zu können.
Die Rolle des Moderators übernimmt bei uns meist der Autor selbst. Das machen wir absichtlich so, damit die Autoren den Reviewprozess selbstbestimmter erleben. Und wie zu erwarten war, gehen die Moderatoren damit unterschiedlich um. Daher unterstützen wir Qualitätsmanager bei Bedarf die Kollegen bei der Vorgehensweise z.B. bei der Anwendung des Templates oder auch bei der Terminverfolgung, damit ein Review zügig durchgeführt wird.
Die in der Rundmail vom 23.03.2017 erwähnten agilen Inspektionen haben wir noch nicht eingesetzt. In unserem derzeitigen Entwicklungsprozess schienen uns die klassischen Inspektionen sinnvoller zu sein.
27.07.2017
... es geht um ein Java-Online-Experiment der Uni Hannover, an dem Sie bis etwa 6. August, evtl. bis 13. August teilnehmen können. Es sollen mehrere Code-Änderungen ("Commits") gereviewt werden, die ein Entwickler im fiktiven Beispiel einchecken will.
"Hilf der Forschung, finde heraus wie gut du im Code Review bist und gewinne 200 Euro! Wir suchen Teilnehmer für eine Studie zu Code Reviews. Voraussetzung sind grundlegende Java-Kenntnisse und ein bis zwei Stunden Zeit. Teilnahme online unter http://reviews.se.uni-hannover.de" [Link veraltet] ...
23.03.2017
Bei ZEISS Mikroskopie wollen wir testweise mit agilen Inspektionen beginnen. Aufgrund der Literatur nehmen wir stark an, dass agile Inspektionen besonders nützlich bei neuen Mitarbeitern sind, um diese schnell in eine steile Lernkurve zu bringen. Wir haben selbst aber noch keine praktische Erfahrung mit agilen Inspektionen. Hat jemand von Ihnen schon agile Inspektionen ausgetestet und wäre bereit, darüber zu berichten?
Unseren theoretischen Wissensstand zu agilen Inspektionen finden Sie hier: Reviewbuch_Roesler_Schlich_Kneuper_2013_S-144_147-152.pdf (Kopie mit freundlicher Genehmigung des dpunkt.verlags).
13.03.2016
Eine frei verfügbare Review-Vorlage ist jetzt auch in deutscher Sprache unter www.reviewbuch.de herunterladbar:
Review_Template_RC_de_v1.4.xlsx
Reviewdurchführung mittels pdf-Kommentaren (anstelle von Excel-Vorlage):
Ein Kunde, für den ich eine Kurzanleitung für "Dokumenten-Reviews mittels Adobe Reader XI" erstellt hatte, hat freundlicherweise erlaubt, eine anonymisierte Version dieser Kurzanleitung weiterzugeben: Kurzanleitung_pdf-Reviews.pdf bzw. .doc. Für einige Reviewer ist damit erfahrungsgemäß die Hemmschwelle niedriger, am Review teilzunehmen, als bei Verwendung von Excel-Vorlagen. Diesen Vorteil erkauft sich ein Autor oder Moderator aber mit einigen Nachteilen. Man muss beispielsweise über eine Kurzanleitung oder über Anweisungen in der E-Mail-Einladung die Reviewer dazu bringen, die Befunde in Major / minor etc. zu klassifizieren. Die Anzeige von Kennzahlen (Anzahl gefundener Major Defects etc.) ist bei diesem Verfahren auch nicht möglich. Meine persönliche Einschätzung nach einigen Erfahrungen mit pdf-Reviews ist: Im Vergleich zur Verwendung von Excel-Vorlagen haben es die Reviewer leichter, die Autoren und Moderatoren aber schwerer.
09.10.2014
Reviewdurchführung mittels pdf-Kommentaren (anstelle von Excel-Template):
Die Kommentarfunktion von Adobe Reader bietet den Gutachtern die Möglichkeit, Reviewkommentare gleich direkt in das Reviewobjekt einzutragen. Acrobat Standard und Acrobat Pro unterstützen den Moderator zusätzlich mit einem Workflow für die Einladung der Gutachter und beim Zusammenführen der Befunde in eine einzige pdf-Datei. Neben diesen Vorteilen gibt es gewisse Nachteile, beispielsweise fehlt die Möglichkeit, die Befunde in Major / minor etc. zu klassifizieren und es fehlt die Anzeige von Kennzahlen (Anzahl gefundener Major Defects, etc).
Hat jemand von Ihnen Erfahrungen mit beiden Varianten (pdf-Kommentare vs. Excel-Template)? Welche Variante bevorzugen die Entwickler in Ihrem Projekt? Für ein aktuelles Verbesserungsprojekt in einem Technologiekonzern würden mir Ihre Angaben weiterhelfen. ...
Haribo verprellt Reviewbuchautoren! Auf dem Cover des Buchs "Reviews in der System- und Softwareentwicklung" finden sich fünf absichtlich eingebaute "Fehler" bzw. Auffälligkeiten. Darunter der Fehler, dass es blaue Gummibärchen nicht gibt. Im Juli brachte Haribo leider eine Fan-Edition heraus, die auch blaue Heidelbeer-Gummibärchen enthält. Die Gegenmaßnahme "Prozess führen" wurde von den Autoren wegen zu geringer Erfolgsaussicht verworfen, ebenso die Maßnahme "Aufessen aller blauen Gummibärchen". Geprüft wird gerade die Maßnahme "Lamentieren".
02.08.2013
Hinweis auf Bucherscheinung: Reviews in der System- und Softwareentwicklung – Grundlagen, Praxis, kontinuierliche Verbesserung. (Rösler, Schlich, Kneuper; dpunkt-Verlag).
15.04.2013
Im Anhang finden Sie eine Reviewvorlage auf Excelbasis (Review_Template_RC_en_v1.3_filled.xlsx, Review_Template_RC_en_v1.3.xlsx). Sie basiert auf den Vorlagen von Tom Gilb und der am besten handhabbaren Vorlage, die wir aus der Industrie kennen. Sie dürfen die Vorlage frei verwenden und ändern. Wir würden uns freuen, wenn Sie die Vorlage an die Qualitätsbeauftragten und Prozessverantwortlichen in Ihrem Unternehmen weiterleiten würden. Neuere Versionen dieser Vorlage werden ab August 2013 auf www.reviewbuch.de veröffentlicht. ...
15.07.2012
Ergebnis der Reviewtool-Umfrage von September 2011: Mehr als die Hälfte der Teilnehmer nannte "firmeninternes Excel-Template" als verwendetes Reviewtool. Genannt wurden auch TFS Code Review Workflow und DOORS, aber die meisten der sonst im Zusammenhang von Reviews erwähnten Tools wurden nicht genannt (wie CodeCollaborator, Codestriker, RevAger, Crucible, ReviewPro, LIDS, ARM, Admire, DESIRe, Automatic Review Tool ART).
Es gibt jetzt für Eclipse ein Plugin für Code-Reviews. Mehr dazu können Sie in einem Blog-Eintrag von Maud Schlich nachlesen: secoach.de/2012/04/19/agilereview-org/ [Link veraltet].
12.09.2011
Reviews sind im Prinzip nur eine "Papier-und-Bleistift-Methode", man kann sie aber auch mit Toolunterstützung durchführen (z.B. mit CodeCollaborator, Codestriker, RevAger, Crucible, TFS Code Review Workflow, etc.). Meine Kollegen von ReviewConsult und ich würden gerne ein Gefühl dafür entwickeln, wie verbreitet Toolunterstützung für Reviews in der Industrie überhaupt ist. Wenn Sie uns helfen wollen, senden Sie bitte eine E-Mail zurück mit dem Betreff "Reviewtool" und geben an, ob und welche Tools Sie bei Ihren letzten Reviews verwendet haben. Mögliche Antworten sind beispielsweise auch: "kein Tool, Befunde wurden im Word Änderungsmodus ins Prüfobjekt geschrieben" oder "firmeninternes Excel-Template". ...
Hinweis auf das Buch "Software Quality Engineering - Ein Leitfaden für bessere Software-Qualität" [Link veraltet] mit mehreren Gastbeiträgen, u.a. "Populäre Irrtümer und Fehleinschätzungen in der Reviewtechnik".
Hinweis auf das neue Schwerpunkt-Seminar zur Reviewtechnik: "Klassische und Agile Inspektionen".
15.02.2011
Die in der letzten Mail erwähnte Reviewtechnik-Firma ist jetzt gegründet und die Homepage ist frei geschaltet: www.reviewconsult.de [Link veraltet]. Die Berliner Grafik-Designerin Ruth Weiler hat das Logo entwickelt.
Dr. Ralf Kneuper, Maud Schlich und ich wollen mit Konferenzvorträgen und Fachartikeln gemeinsam für Reviews und Inspektionen werben. Mein bisheriges Portfolio "Review-Seminare" wird durch ReviewConsult u.a. um folgende Leistungen erweitert: Prozessberatung bei der Einführung und Optimierung des Reviewprozesses beim Kunden, Übernahme der Rolle des "Inspection Coordinators" beim Kunden bzw. Coachen des Inspection Coordinators, Planen und Moderieren von einzelnen Reviews, die gerade beim Kunden anstehen.
Hinweis auf nächsten Review-Vortrag [Link 2011.reconf.de/methodenvortrge/peterrsler/ veraltet].
Hier noch eine Weisheit aus der Welt der Qualitätssicherung:
"A week of hard work can sometimes save you an hour of thought."
31.05.2010
In den nächsten Monaten wird eine kleine Reviewtechnik-Firma gegründet werden, Details folgen in einer Rundmail im Herbst. Die Gründer werden auch vermehrt auf Konferenzen aktiv werden. Wenn Sie von all dem etwas mehr mitbekommen wollen, können Sie sich mit "subscribe Reviewtechnik-Mailingliste 2" auf die Mailingliste für die besonders Interessierten setzen lassen. Hier werden z.B. Vorabversionen von Reviewtechnik-Fachartikeln oder neue Folien zur Begutachtung versandt.
Die wichtigste Metrik für Code-Reviews ist angeblich die so genannte WTF-Metrik, die in Review-Seminaren leider meistens verschwiegen wird. ...
Das "QA Manifesto" von Tom Gilb kann hier nachgelesen und unterzeichnet werden: www.gilb.com/Real+QA+Manifesto [Link nok, 12/2020].
20.09.2009
Der Text Populäre Irrtümer und Fehleinschätzungen in der Reviewtechnik wird in leicht geänderter Form als Gastbeitrag im Buch "Software Quality Engineering - Ein Leitfaden für bessere Software-Qualität" erscheinen. Dieses neue Buch von Dr. Ernest Wallmüller wird im 1. Quartal 2010 vom Hanser Verlag herausgebracht.
Die Literaturliste wurde um zwei neue Bücher erweitert: "Best Kept Secrets of Peer Code Review" und "Modern Software Review: Techniques and Technologies". Meiner Meinung nach ist aber nach wie vor "Software Inspection" von Tom Gilb und Dorothy Graham das beste Buch zu Reviewtechnik. Das Buch "Best Kept Secrets of Peer Code Review" behandelt u.a. das Tool Code Collaborator [Link veraltet]. Wer von Ihnen dieses Tool im Einsatz hat, sollte sich bitte melden, damit wir evtl. in der nächsten Rund-Mail darüber berichten können. ...
07.03.2009
Weil sich fachlich im letzten Jahr nicht viel in der Reviewtechnik geändert hat ..., hier ein bisschen Statistik ...:
1000 Teilnehmerinnen und Teilnehmer haben bis jetzt insgesamt 111 Review-Seminare besucht. Die 55 offenen Seminare und die 56 Inhouse-Seminare fanden im Zeitraum von Februar 1999 bis Februar 2009 statt. Das sind im Durchschnitt 10 Seminare pro Jahr und 9 Teilnehmer pro Seminar.
Die Übungsgruppen, die das C-Programm geprüft haben, haben im Durchschnitt 71% der im Programm versteckten Major Defects entdeckt. (Damit ist die Gesamteffektivität des Teams gemeint, die einzelnen Reviewer lagen im Durchschnitt deutlich darunter.) Die Übungsgruppen, die das Textdokument (Spielregel) geprüft haben, haben im Durchschnitt 57% der versteckten Major Defects entdeckt. ...
06.03.2008
Reviewer für Testprozess gesucht:
Für ein Review der Testprozesse in einem großen Software-Haus wird ein Reviewer mit guten Kenntnissen im Software-Testing und Erfahrung in Reviews gesucht. Die Aufgabe besteht darin, die vorhandenen Testprozessbeschreibungen (ca. 250 Seiten) und einige exemplarische Testdokumente zu reviewen sowie die aktuellen Practices durch Interviews vor Ort mit dem Leiter der Test Factory und den Testern zu analysieren. In einem Abschlussbericht sollen die Ergebnisse und Verbesserungsvorschläge festgehalten werden. ... Interessenbekundungen bitte bis 17.03.2008 per E-Mail senden ....
01.01.2007
Hier ein Hinweis auf eine Radiosendung:
zum 100. Geburtstag der Computer-Pionierin Grace Hopper gibt es ein Portrait in der Sendung "IQ - Wissenschaft und Forschung" am Mittwoch 03.01.2007 von 18:05-18:30 auf Bayern 2. Wer nicht im Sendegebiet wohnt, kann sich die Sendung über Webradio anhören: [Link veraltet].
Grace Hopper hat übrigens den ersten Computer Bug gefunden, siehe z.B. http://de.wikipedia.org/wiki/Grace_Hopper.
Mit "subscribe Reviewtechnik-Mailingliste 2" können Sie sich auf die Mailingliste für die besonders Interessierten setzen lassen. Hier werden z.B. Vorabversionen von Reviewtechnik-Fachartikeln oder neuen Folien zur Begutachtung versandt etc., es kommen ca. 10 E-Mails pro Jahr.
15.08.2006
Bei Siemens Nürnberg wurde probeweise ein Dokument doppelt geprüft: mit einem herkömmlichen Review und zusätzlich mit einer Inspektion nach Fagan. Das Ergebnis: mit der Inspektion wurden 16 Mal mehr Fehler entdeckt! (Einzelheiten sind abrufbar unter www.reviewtechnik.de/formulare.html, PowerPoint-Folie www.reviewtechnik.de/2Reviewmethoden.ppt. "Pfeil nach rechts" blendet den Inhalt der Folie ein.)
12.04.2006
Tom Gilb, dessen Buch "Software Inspection" viele von Ihnen besitzen, hat ein neues Buch für Systemingenieure und Softwareentwickler veröffentlicht: "Competitive Engineering". Details und Rezensionen siehe www.amazon.de/exec/obidos/ASIN/0750665076.
Im August 2006 werden die Software-Inspektionen nach Fagan 30 Jahre alt (Michael Fagans Originalartikel vom August 1976: "Design and code inspections to reduce errors in program development". ...
10.02.2005
Alle 5 Jahre findet die "World Conference on Software Quality" statt, jedes mal auf einem anderen Kontinent. Im Jahr 2005 ist Europa an der Reihe: vom 26.-30.09.2005 findet die dritte "World Conference on Software Quality" in Garching bei München statt. Details siehe unter www.isqi.org/isqi/deu/conf/wcsq/3/ [Link veraltet]. Das genaue Programm wird erst ca. April feststehen, aber sicher wird es Vorträge zu Reviews und Inspektionen geben.
Tom Gilb hat eine neue Variante von Inspektionen veröffentlicht, die er "Agile Specification Quality Control" nennt. Einen sehr interessanten Artikel dazu finden Sie unter www.reviewtechnik.de/Agile_SQC_CutterVol_18_No1_2005.pdf (496 kB, vorläufiger Ablageort, wird gelöscht sobald dieser Artikel unter www.gilb.com verfügbar ist). Einige Grundideen der agilen Inspektionen hat Gilb schon lange vertreten: das Sampling (Stichprobenverfahren) und das Ziel der Prozeßverbesserung anstelle des reinen Korrigierens von Dokumenten (s.a. Buch "Software Inspection", S. 361: "The second, but most important, objective of Inspection is to identify and remove the source of defects.")
Nachdem ich über 15 Jahre bei der Softlab GmbH gearbeitet habe, hauptsächlich als QS-Beauftragter, habe ich mich zu Beginn dieses Jahres selbstständig gemacht. Meine Nebentätigkeit "Reviewtechnik-Seminare" wird also zu meinem Hauptberuf. Neben den Seminaren werde ich, wenn Kunden es wünschen, auch als Moderator einzelne Reviews leiten. ...
10.12.2003
Hinweis auf den "eWorkshop" am 16.12.2003 zu "Software Inspections and Pair Programming: Where are the differences?" mit Fachleuten wie Laurie Williams, Victor Basili, Barry Boehm, Dieter Rombach etc.
Literaturhinweis: "High Quality Low Cost Software Inspections", Paradoxicon Publishing 2002, ISBN 0-9645913-1-6, ca. 60$.
Dieses empfehlenswerte Buch ist speziell für diejenigen hilfreich, die den Nutzen von Reviews zahlenmäßig begründen wollen. Für den erreichbaren Produktivitätsfortschritt und die Effektivität von Reviews sind jeweils eine Tabelle von vielen bisher veröffentlichten Ergebnissen angegeben. Der Autor Ron Radice ist einer der allerersten Reviewtechniker: "The first live product Inspection was for Low-Level Design (LLD) and was held in December 1972. I moderated this Inspection." (S. 53).
19.06.2002
Hinweis auf eine internationale Umfrage zu Reviews und Inspektionen von Prof. Dieter Rombach. [Link veraltet] ... To investigate this in more detail, the International Software Engineering Research Network conducts an on-line survey to determine the state of the practice in reviews and inspections.
07.07.2001: Michael Fagan live im Internet
Michael Fagan hat einen Vortrag über Inspektionen auf der "Software-Pioniere"-Konferenz gehalten. Einen Mitschnitt des Vortrags können Sie aus dem Internet abrufen: www.sdm.de/de/termine/sdmkonf-2001/index.html [unauffindbar 10/2010]
Auch die PowerPoint-Folien seines Vortrags sind dort zu finden. Interessant ist, dass er für die Phase "Preparation" (bei Gilb "Individual Checking" genannt) die Empfehlung abgibt: "Learn material, prepare role, DO NOT focus on finding defects." Da hält er noch eisern an der damaligen Sicht fest. Für Gilb und andere ist dies überholt, die Phase "Individual Checking" ist hauptsächlich dazu da, Fehler zu finden. Deswegen haben Gilb und Graham diese Phase auch von "Preparation" nach "Individual Checking" umbenannt! |
