Blog Liste

    Aktuelle Seite:  
  1. Startseite
  2. Blogs
Quality rocket
Blogs
Zugriffe: 2201

Wie findest du das richtige Gleichgewicht zwischen Qualität und Effizienz bei der Entwicklung eines Softwareprodukts? Eine zu geringe Qualität wird die Akzeptanz des Produkts bei deiner Zielgruppe (Stakeholdern) reduzieren, die Entwicklungszeit entscheidend verzögern und zusätzlich Kosten verursachen, da vermehrt Fehler analysiert und behoben werden müssen. Ein zu hohes Maß an Qualität, bzw. Qualitätssicherungsmaßnahmen, das deiner Zielgruppe keinen Mehrwert mehr liefert, erzeugt unnötige Entwicklungs- und Produktionskosten. Beide Extreme, eine zu geringe Qualität und eine zu hohe, wirken sich auf die Effizienz der Produktentwicklung aus, da die Entwicklungszeit und die Kosten steigen.

Der Schlüssel liegt darin, das ideale Maß an Qualität zu finden! Dazu gehört es, die Bedürfnisse und Erwartungen der Zielgruppe genau zu verstehen, die Entwicklung der Produktfunktionen zu priorisieren und angemessene Testverfahren vom Beginn der Entwicklung an einzuführen und zu erweitern. Somit werden Abweichungen von den Qualitätskriterien und somit Fehler frühzeitig erkannt und können behoben werden.

Hier sind einige Tipps, wie du bei der Entwicklung von Softwareprodukten das richtige Qualitätsgleichgewicht erreichst:

  1. Definiere klare Qualitätsziele: Lege spezifische, messbare Qualitätsziele fest, die mit den Gesamtzielen des Projekts übereinstimmen (z.B. Funktionale und Nicht-Funktionale Anforderungen).

  2. Qualitätsaktivitäten priorisieren: Identifiziere die wirkungsvollsten Qualitätssicherungsaufgaben und weise Ressourcen entsprechend zu.

  3. Automatisiere möglichst viele Prozesse: Nutze automatisierte Testtools (Continuos Testing), um den Testprozess zu optimieren und Fehler frühzeitig zu erkennen. Ein automatisiertes Deployment (Continuos Deployment) hilft dir das Qualitätsziel beim Ausrollen der Software zu erreichen. Automatisierung spart Zeit, Ressourcen und somit Geld.

  4. Stakeholder frühzeitig einbeziehen: Arbeite mit Kunden und anderen Stakeholdern zusammen, um Feedback einzuholen und sicherzustellen, dass das Produkt ihren Erwartungen entspricht.

  5. Qualität messen und überwachen: Verfolge kontinuierlich Qualitätskennzahlen (Continuos Monitoring), um Bereiche mit Verbesserungspotenzial zu identifizieren und einen hohen Standard aufrechtzuerhalten.

  6. Qualität mit Zeit und Kosten in Einklang bringen: Finde den idealen Punkt, an dem Qualität auf Effizienz trifft, ohne dabei Kompromisse einzugehen. Gehe hierbei von den Anforderungen der Stakeholder an das Produkt aus.

  7. Kontinuierliche Verbesserung anwenden: Verfolge einen iterativen Qualitätsansatz und verfeinere und verbessere das Produkt im Laufe der Zeit ständig.

  8. Effektiv kommunizieren: Förder eine offene Kommunikation innerhalb des Entwicklungsteams und mit den Stakeholdern, um Qualitätsbedenken (Risikomanagement) umgehend anzugehen. Etabliere eine positive Fehlerkultur im Team/Unternehmen.

  9. Stärke das Team: Stelle dem Entwicklungsteam die Tools, Schulungen und den Support zur Verfügung, die es zur Bereitstellung hochwertiger Software benötigt und beseitige Blockaden (Impediments) frühzeitig. Eine Retroperspektive hilft hierbei, Umstände, die das Team blockieren, frühzeitig aufzudecken.

  10. Nutze externes Fachwissen: Wende dich an erfahrene Qualitätssicherungsexperten, um Probleme bei der Produktqualität bzw. Qualitätssicherung aufzudecken und diese durch professionelle Hilfe zu beheben.
Tags: , , ,
Retrospective
Blogs
Zugriffe: 829

Retrospektiven sind das ultimative und unverzichtbare Werkzeug des agil arbeitenden Teams. Wenn Ihr Retrospektiven richtig durchführt, könnt Ihr die Zufriedenheit und Produktivität eures Teams mit einfachen Methoden steigern. Allzu oft wird das Potenzial von Retrospektiven oft gar nicht oder nicht vollständig ausgeschöpft, obwohl die Vorteile einer regelmäßig durchgeführten Retrospektive klar auf der Hand liegen:

  • Sie bietet eurem Team eine Plattform für Reflexion, Dialog und Verbesserung und fördert eine Kultur des kontinuierlichen Lernens.

  • Durch Steigerung der Effektivität und Produktivität wird die Teamleistung erheblich beschleunigt.

  • Hindernisse (Impediments), die das ganze Team ausbremsen, werden identifiziert und können beseitigt werden.

  • Die Stimmung im Team kann regelmäßig gemessen und verbessert werden. Wodurch Stress und Unzufriedenheit frühzeitig vermieden werden.

  • Die gegenseitige Wertschätzung (Kudos) im Team wird gefördert.

Damit eine Retrospektive erfolgreich durchgeführt wird, solltet ihr folgende Punkte beachten:

  • Die Retrospektive sollte am besten mit einer Stimmungsabfrage im Team (Team-Radar) beginnen. Dies hilft später auch die entscheidenden Hindernisse und Probleme aufzudecken.

  • Die Retrospektive ist ein Teamevent bei dem persönliche Offenheit wichtig ist und sollte deshalb auch nur von Mitgliedern des Teams durchgeführt werden, damit äußere Beeinflussungen vermieden werden.

  • Eine Retrospektive ist ein Team förderndes Ereignis, bei dem Respekt und Wertschätzung der Kollegen an erster Stelle stehen. Finger-pointing und Blaming haben hier keinen Platz.

  • Zum gemeinsamen Aufdecken von Hindernissen und Problemen solltet Ihr eine etablierte Methode verwenden, wie zum Beispiel ‚Mad Sad Glad‘. Schreibt hierfür eure Problemthemen am besten auf Karten (z.B. Post-it), klebt sie auf ein Whiteboard und priorisiert sie zum Schluss.

  • Wählt von den Problemthemen nur so viele aus, wie Ihr bis zur nächsten Retrospektive auf wirklich bearbeiten bzw. beseitigen könnt. Es werden immer die Themen mit der höchsten Priorität zuerst abgearbeitet.

  • Die Lösung zur Beseitigung eines Hindernisses wird vorab im Team besprochen und es sollte immer ein Verantwortlicher pro Problemthema im Team ernannt werden, der sich darum kümmert.

  • Der Bearbeitungsfortschritt eines Problemthemas wird ebenfalls in jeder Retrospektive vom Team verfolgt. Dazu solltet ihr in der Retrospektive aufzeigen, welche Themen bereits bearbeitet sind und welche noch nicht beseitigt werden konnten.

 

 

Tags: , ,
YAGNI principle
Blogs
Zugriffe: 576

Die Entwicklungszeit in Projekten ist teuer und sollte deshalb möglichst Wert schöpfend und effizient genutzt werden. Dazu sollte das Entwicklungsziel immer im Auge behalten werden und nur die vom Kunden bzw. Stakeholder geforderten Produktfunktionen implementiert werden.

Grundsätzlich handelt es sich bei dem YAGNI (You Aren't Gonna Need It) Prinzip um ein einfaches Prinzip, dass in der Praxis aber schwer einzuhalten ist. Besonders Softwareentwickler neigen dazu, ungeplante Funktionen „schnell mal“ einzubauen.

Werden Funktionen in das Produkt eingebaut, die nicht vom Stakeholder gefordert sind, ergeben sich daraus einige Probleme für das Produkt:

  • Da die zusätzlichen Funktionen dem Kunden keinen Wert liefern, wird er sehr wahrscheinlich nicht bereit sein hierfür zu bezahlen. Zudem verlängert sich die Entwicklungszeit für das Produkt. Beides wird sich negativ auf die Zufriedenheit des Kunden auswirken.

  • Der vereinbarte Produktumfang ändert sich (Scope creep) und wird schwerer planbar.

  • Für die zusätzlichen Funktionen müssen Tests entwickelt und Dokumentation geschrieben werden. Im Laufe des Produktzyklus müssen dies Stellen ebenfalls angepasst werden, wodurch noch zusätzlicher Pflegeaufwand entsteht.

  • Die Komplexität des Produkts steigt ohne Nutzen an und das Risiko für Fehler in der Software steigt an.

In der Praxis sind es meistens nicht vollständig neue Funktionen, die in ein Produkt eingebaut werden. Ich erlebe es immer wieder, dass etwas in „weißer Voraussicht“ eingebaut wird, da entweder die Spezifikation noch nicht vollständig fertig ist, aber man schon mal etwas implementiert oder da davon ausgegangen wird, dass die Funktion in Zukunft mal gebraucht wird. Es kann aber auch oft vor, dass nicht mehr gebrauchte Funktionen deaktiviert oder nur teilweise entfernt werden. Dieses Vorgehen birgt zusätzliche Risiken:

  • Für die neuen, ungebrauchten Funktionen müssen bereits Tests implementiert werden, was zusätzlichen Aufwand bedeutet.

  • Werden erst gar keine oder nicht ausreichend Tests für die ungenutzte Funktionalität implementiert, stellt dies ein erhebliches Qualitäts- und Sicherheitsrisiko in der Software dar, auch wenn sie noch nicht verwendet werden. Zudem fehlen bei ungenutzten Funktionen auch System- bzw. explorative Tests, da sie noch niemand verwendet oder verwenden kann.

  • Die Komplexität und der Speicherverbrauch der Software steigt ohne Nutzen an. Dies ist im Embedded-Systems Bereich ein besonderes Problem, da die Software hier ressourcenschonend entwickelt werden muss.

Das YAGNI Prinzip lässt sich einfach anwenden, wenn folgende Punkte beachtet werden:

  • Es werden nur Funktionen eingebaut, für die es eine nachvollziehbare Anforderung von mindestens einem Stakeholder gibt. Ist eine Anforderung oder Spezifikation unklar, muss dies vorab geklärt werden.

  • Wähle eine Architektur, die sich im Produktzyklus einfach skalieren bzw. anpassen lässt, z.B. durch Softwareupdates. Dadurch sinkt der Druck in der Entwicklung, vorausschauend und noch ungenau spezifizierte Funktionen einzuplanen bzw. einzubauen.

  • Entferne Funktionen vollständig aus deiner Software, wenn sie nicht mehr verwendet werden.

  • Es kann es sinnvoll sein, regelmäßig mithilfe von Tools oder durch ein Review die nicht mehr benötigten Teile der Software zu finden, damit sie nachträglich entfernt werden können. 

 

 

Tags: ,
DRY Principle
Blogs
Zugriffe: 2494

Heute berichte ich über ein weiteres, bewährtes Prinzip aus meinen Projekten, dem DRY (Don't Repeat Yourself) Prinzip.

Sicherlich ist dieses Prinzip den meisten Entwicklern bereits ein Begriff.
Meiner Erfahrung nach kann die Anwendung des Prinzips im Projekt Dir aber einen wirklichen Gewinn und eine größere Effizienz bringen.

Das DRY Prinzip wird meistens in Zusammenhang mit der Softwareentwicklung gebracht. Ursprünglich wurde das Prinzip im Buch "The Pragmatic Programmer" erwähnt. Dabei soll das Duplizieren von gleichen Codezeilen vermieden werden, da dies später zu einem höheren Wartungsaufwand und einer höheren Fehlerwahrscheinlichkeit führt. Allerdings kann das DRY Prinzip auch in vielen anderen Bereichen die Arbeit erheblich erleichtern.

Im Grunde soll man bei seiner Arbeit möglichst Redundanz vermeiden. Allgemein formuliert sollte eine Information sich immer nur an einem Ort befinden. 

Als ein sehr einfaches Beispiel können wir uns die Angabe einer Versionsnummer in einem Softwareprojekt betrachten. Statt sie N-mal im Code, in der Dokumentation oder in Konfigurationsdateien anzugeben, sollte sie möglichst zentral mit den Projektdateien abgespeichert werden, wie z.B. in einer zentralen Datei oder besser gleich über die Versionierungsverwaltung. An allen weiteren Stellen, an denen die Versionsnummer angegeben werden muss, wird diese entweder automatisiert eingesetzt oder nur referenziert.

Sicherlich ist dies nur ein sehr einfaches Beispiel, Ich erlebe es aber oft in Projekten, dass Informationen quer durch verschiedene Dateien verteilt sind und bei einem Release manuell angepasst werden müssen. Ein manueller Prozess ist immer fehleranfällig, oft ineffektiv und führt nicht selten zu inkonsistenten Dokumentations- und Softwareständen.

In Projekten ist es immer wichtig alle Dokumente in einem konsistenten Stand zu halten. Deshalb haben ich, in Zusammenarbeit mit dem Kunden, in einigen Projekten das Versenden von Dokumenten über E-Mail abgeschafft. Die bessere Lösung ist hier ganz klar einen zentralen und gemeinsam zugreifbaren Speicherort zu verwenden, wie z.B. Google Drive oder Microsoft OneDrive. Für das Weitergeben von Informationen werden dann nur die Links auf die entsprechenden Dateien verschickt. Dadurch wird sichergestellt, dass jeder Leser oder Bearbeiter immer einen aktuellen Stand besitzt.

Gerade in großen und komplexen Projekten, in denen ich involviert war, hat sich das DRY Prinzip immer wieder bewährt. Aufwände für das Ändern von verschiedenen Dokumenten blieben im erwartungsgemäßen Rahmen und konnten dadurch entsprechend effizient durchgeführt werden.

Zusammenfassung:

  • Schaffe keine Redundanz in Deinem Projekt. Speichere Informationen nach Möglichkeit nur einmal zentralen ab.

  • Versende keine Kopien von Dokumenten, sondern nur Links auf die jeweiligen Dokumente.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tags: , ,
KISS principle
Blogs
Zugriffe: 1398

Das KISS (Keep It Simple, Stupid) Prinzip ist eines meiner liebsten Prinzipien, das ich in Projekten, aber nicht nur dort, immer wieder gerne anwende. Es führt zu einer effizienteren Arbeitsweise und ermöglicht eine einfachere Handhabung der komplexen Strukturen, wodurch es für das gesamte Team und vor allem für das Erreichen der Projektziele einen großen Mehrwert (Value) generiert. Das KISS Prinzip befriedigt ein grundlegendes Bedürfnis des Menschen, komplexe Sachverhalte vereinfacht dazustellen. In Projekten muss es aber oft bewusst angewendet werden, ganz nach dem Zitat von Konfuzius,

"Das Leben ist wirklich einfach, aber wir bestehen darauf, es kompliziert zu machen".

Grundsätzlich wird mit der Anwendung des KISS Prinzips eine möglichst einfache Lösung gesucht, mit der man zum einen das angestrebte Ziel erreicht und zum anderen eine unnötige Komplexität vermeidet. Die Lösung sollte einfach und prägnant sein. Das KISS Prinzip bezieht sich hierbei nicht zwingend auf eine technische Lösung, sondern kann auch auf andere Bereiche, wie Team-Kommunikation, Dokumentation, Prozesse usw., angewendet werden.
Durch die Reduzierung der Komplexität, wird dem Team ein besserer Überblick über das Gesamtsystem verschafft, was zum Beispiel die Entwicklung des Produkts nachhaltig beschleunigt. Zusätzlich werden viele Fehler vermieden, da vieles verständlicher wird.

Wie wende ich das KISS Prinzip an?

Die Anwendung des Prinzips hängt im Detail stark von dem jeweiligen Anwendungsbereich ab. Es gibt allerdings grundlegende Regeln, die sich auf alle Anwendungsbereiche anwenden lassen:

  1. Die Lösung sollte sich am Ziel orientieren. Alles was nicht direkt oder indirekt zur Erreichung meines Ziels dient, erzeugt keinen Wert (Value) und sollte entfernt oder besser noch nicht hinzugefügt werden!
    In der technischen Umsetzung heißt das zum Beispiel, dass ich keine Funktionalität einplane bzw. hinzufüge, die nicht wirklich benötigt wird. Das heißt auch, dass ich nachträglich Dinge, wie zum Beispiel Dokumente, lösche oder anpasse, die veraltet sind. Hiermit trage ich zu einer wesentlichen Verbesserung der Übersichtlichkeit bei. Allzu oft führen veraltete Dokumente zu Missverständnissen, da sich Strukturen und Abläufe geändert haben. Hier ist weniger, aber aktuell, besser!

  2. Das Verhältnis zwischen Arbeitsaufwand, für die Umsetzung der Lösung und dem Wert sollte möglichst effizient sein!
    Konkret heißt dies, dass ich für die Umsetzung oder Anwendung meiner Lösung möglichst wenig Zeit aufwenden muss, im Gegensatz zu dem Wert oder Nutzen die mir diese Lösung einbringt. In der Softwareentwicklung zum Beispiel sollte eine verwendete Architektur, ein Framework oder API die Arbeit vereinfachen und beschleunigen, damit die Entwicklung weiterer Funktionen vom Team effizient durchgeführt werden kann.

  3. Die Lösung sollte möglichst selbsterklärend und leicht nachvollziehbar sein!
    Je weniger ich zusätzlich dokumentieren muss, umso besser. Dadurch spare ich sehr viel Zeit, da ich nicht extra Dokumentation suchen und durchlesen muss, bzw. andere Personen befragen muss.
    Dies gilt übrigens auch für das resultierende Produkt. Je intuitiver ein Produkt benutzt werden kann, um so mehr Wert hat es für den Endbenutzer.

  4. Meine Lösung sollte vom betreffenden Team akzeptiert werden!
    Einfach sind die Dinge nur, wenn sie für alle betreffenden Personen auch einfach und verständlich sind. In einem agilen Projekt kann die Retrospektive oder ein technisches Meeting sehr gut dazu verwendet werden, um mit den betreffenden Teammitgliedern eine Lösung zu erarbeiten. Dies führt letztendlich zu einer größeren Akzeptanz im Team und auch zu einer besseren Lösung.

  5. Ich vereinfache bzw. verbessere meine Lösung stetig, wenn dies mir einen größeren Wert generiert!
    Das heißt, dass ich die zuvor genannten Punkte immer wieder anwende, wenn ich dadurch eine effizientere Lösung (hinsichtlich Wert) erreiche. Im Umkehrschluss tue ich dies nicht, wenn ich dadurch den Wert der Lösung nicht steigere!
    Ich sollte zum Beispiel regelmäßig die angewendeten Prozesse im Projekt hinterfragen, besonders wenn sie vom Team nicht akzeptiert oder sogar umgangen werden. Dann kann ich mit einer Anpassung der Prozesse die Abläufe erheblich vereinfachen und zu einer effizienteren Arbeitsweise beitragen.

Das bewusste Anwenden des KISS Prinzips benötigt natürlich zusätzliche Aufwände. Durch die nachhaltige Effizienzsteigerung im gesamten Team dürften diese Aufwände jedoch schnell durch die resultierenden Einsparungen und die Steigerung der Zufriedenheit im Team bei weitem kompensiert werden.

 

 

Menu