Agile&Scrum

Qualität – Codequalität, Debuggingfähigkeit und Infrastruktur

Parameter wie die Codequalität, Debuggingfähigkeit oder die Build-Infrastruktur entscheiden bei großen Projekten letztendlich, wie einfach es ist, die Software zu warten und zu erweitern. Aber auch die Analytics spielt eine wichtige Rolle.


Qualität – Ein entscheidender Wettbewerbsfaktor

Neben den Features einer Software und dem Design der Benutzeroberfläche hat die Qualität aus der Nutzersicht eine besonders hohe Bedeutung.

Eigentlich galt ein hoher Qualitätsanspruch schon immer. Aber heutzutage ist die Qualität vielleicht noch wichtiger geworden, da viele Nutzer über ihre mobilen Devices eigenes technisches Know How besitzen, und damit einen eigenen Anspruch an ihre Software.


Enterprise 2.0: Cloud-Kollaboration in der Praxis

Der heutige Artikel stammt aus der Feder von Claudia Ketzer, und handelt von den Möglichkeiten und dem Nutzen, Arbeits- und Geschäftsprozesse kollaborativ zu gestalten.

Frau Ketzer verantwortet das Marketing bei der Firma →Comindware GmbH, die sich mit Themen wie der adaptiven Geschäftsprozessverwaltung oder Workflow-Automatisierung beschäftigt


Agile Entwicklungsmodelle zur Abwicklung komplexer Projekte

In ihrem Artikel „Achieving success in large, complex software projects“ schreiben McKinsey über die Besonderheiten komplexer Entwicklungsprojekte. In einem der Schaubilder kann man sehr gut erkennen, welchen eigentlichen Vorteil die agile Entwicklungsmethode bietet.


Usability und Komplexität – Tipps zur Fortbildung

Zwei Online-Schulungen der Stanford University befassen sich mit verwandten Themen, die dabei helfen, gebrauchsfähige Software zu entwickeln.

In der einen Vorlesung geht es um das Thema „Wahrnehmungspsychologie“, also die Frage, wie die Biologie des Wahrnehmens beim Menschen funktioniert, und welche Anforderungen sich daraus an Software ableiten lassen.

Der zweite Vortrag befasst sich mit der Komplexität von technischen Systemen, und räumt u.a. mit dem Mythos auf, dass Nutzer immer die einfache Lösung suchen.


Entwurfsmethodiken – Minimum Viable Scope

Die Akzeptanz einer Software lebt unter anderem davon, daß sie sich agil weiterentwickelt, und, daß sie die Aufgaben erledigt, die sie erledigen soll.

Konzepte wie der „Minimum Viable Scope“ helfen dem Entwicklungsteam dabei, genau die Anforderungen zu finden, die dem späteren Anwender der Software wichtig sind. Und man kann mit diesem Konzept auch entscheiden, welches Feature man nicht entwickelt – um so ggfs schneller am Markt sein zu können.


Entwurfsmethodiken zum „Rapid Prototyping“ – Der Designsprint

„Google Ventures“ haben eine längere Artikelserie zu einer sehr flexiblen Entwicklungsmethodik herausgebracht, die wie die agile Entwurfsmethodik in der Softwareentwicklung funktioniert – angewandt auf ein Projekt.

Bekanntermaßen sind lange, unflexible Entwicklungszyklen hier ja eher nachteilig, alleine schon, weil man am Anfang der Entwurfsarbeit oft nicht weiß, was am Ende herauskommen soll, und man daher auf Iterationen angewiesen ist. Der Autor bespricht relativ detailliert eine Vorgehensweise, die man anwenden kann, um relativ schnell und iterativ gute Produkte zu entwickeln.


Management-Knowhow für (zukünftige) Produktmanager

Neulich hat mich die Fachhochschule Schmalkalden angesprochen, und mich gefragt, ob ich nicht ihren Studiengang „Produktmanagement“ hier vorstellen könnte. Da gelegentlich auch Schüler hier vorbeikommen, die gerade vor der Berufswahl stehen, halte ich einen solchen Artikel für keine schlechte Idee.

Teile des Artikels hier stammen aus der Lehrgangsbeschreibung, die mir die FH gegeben hat. Am Ende des Artikels gehe ich kurz auf meine eigenen Erfahrungen ein, die ich vor einigen Jahren hierzu schon einmal in einer Artikelserie zum Thema „Aus-, Fort- und Weiterbildung“ zusammengefasst hatte.


Walking Skeleton – Das laufende Skelett

IJetzt wird es gruselig – könnte man meinen. Stimmt aber nicht, wie Sie gleich sehen werden.

In der Praxis können Produktbacklogs schnell sehr groß werden. Hinzu kommt, daß sich Wünsche an das Produkt häufig ändern. Um mit den Anforderungen umzugehen, die sich daraus ergeben, benötigen sowohl das Entwicklungsteam als auch der Produktowner Methoden, die ihnen dabei helfen, den Produktbacklog zu strukturieren, und die Software iterativ zu erweitern.

Das Konzept des „Walking Skeleton“ zusammen mit den Ansätzen rund um das Thema „Specification by Example“ helfen hierbei.


Weniger Features sind oft mehr

In einem typischen Softwareprodukt werden viele Funktionen kaum benutzt. Ein Produkt mit weniger Features zu haben, wäre hier von Vorteil, sowohl was die Komplexität betrifft, als auch die Wartung der Software, und die Kosten.

Heute geht’s um des „minimal viable scope“ eines Produktes, als eine Möglichkeit, genau das zu entwickeln, was für den Markterfolg notwendig ist (und nicht mehr).


Specification by Example

In marktorientierten Entwicklungsprojekten ist es notwendig, daß das Entwicklungsteam und die einzelnen Stakeholder eine gemeinsame Sprache sprechen.

Nur diese gemeinsame Sprache gewährleistet, daß man auch sicher sein kann, daß alle Beteiligten von den gleichen Anforderungen sprechen, und, daß man allerseits dieselbe Auffassung vom funktionalen Umfang der späteren Software hat.

Die Methode der Specification by Example, die zum Beispiel von Gojko Adzic vertreten wird, leistet genau das.


Unterschiedliche Innovationsmodelle und die Tendenz zur offenen Innovation

Heute stehen zwei Artikel im Fokus, die zeigen, daß das Innovationsmodell zur Firma und zu den Produkten passen muss.

Der eine Artikel bespricht die Gegensätze in den Innovationsstrategien von zwei erfolgreichen Unternehmen (Apple und Google), deren Vorgehensweise sich diametral voneinander unterscheidet.

Der andere Artikel behandelt die Rolle, die die offene Innovation heute und in Zukunft spielt, und plädiert dafür, daß sich Firmen öffnen.


Qualität, Features und Termindruck

Wahrscheinlich ist die Entscheidung für jeden Produktowner ein Klassiker: Worauf den Schwerpunkt legen – Features oder Qualität? Oft steckt hinter der Frage jedoch mehr.

Termindruck kommt in der Praxis oft durch Faktoren zustande, die ein einzelner Produktowner nur schwer beeinflussen kann, wie zum Beispiel das Ziel der gesamten Firma, möglichst oft ein komplettes Release abzuliefern, das dann noch möglichst viele neue Funktionen enthalten soll.


Requirement versus Specification

Apple hat neulich ein neues iPhone präsentiert, das von der Fachwelt zerrissen wurde. Im Gegensatz dazu ist das Smartphone jedoch von den Konsumenten sehr gut aufgenommen worden. Fragt sich, welche Rückschlüsse aus dieser Fehleinschätzung abgeleitet werden können.

Gerade heute war die übliche Frage mal wieder ein Thema, die da lautet „Was sollen Anforderungen, Spezifikationen, und Design-Dokumente leisten, und wer liefert sie?“. Heute will ich kurz auf die Rolle von Kundenwünschen, und auf die Rolle der Entwicklungsabteilung und damit auf das Thema „Spezifikationen“ eingehen.


Fokussieren eines Scrum Teams

Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.

Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.


Feature versus Qualität

Die Frage taucht ja gerne mal wieder auf, und beschäftigt dann den oder die Product Owner: Soll das Scrumteam lieber ein Feature mehr entwickeln, oder sollte man die Zeit in einen Test stecken, der dazu dient, die Qualität zu verbessern.

Heute geht es um die Frage, wie wichtig ein neuer Ansatz für viele IT Unternehmen ist. Oft drückt der Markt, und fordert „Feature, Feature, Feature“. Sie werden aber sehen, daß es durchaus sinnvoll sein kann, auch mal nicht auf den Markt zu hören, und statt ein Feature zu entwickeln, einen Test zu machen. Es ist zwar ungewohnt, aber es stimmt – Kunden haben doch nicht immer recht….


User Stories und Use Cases

Im Rahmen der userzentrierten Entwicklung konzentriert man sich auf die Situation des Anwenders; schliesslich soll die neue Anwendung den Bedürfnissen dieses Anwenders dienen.

Da ja nicht jedes Teammitglied mit den Anwendern jedes Detail mündlich klären kann, ist es notwendig, die Situation des Nutzers nachvollziehbar zu dokumentieren. Heute haben wir einige Zeit über die begriffliche Abgrenzung der beiden Themenkreise „Use Case“ und „User Story“ gesprochen. Beide Konzepte leisten wertvolle, jedoch unterschiedliche Dienste in der Softwareentwicklung.


Die Produktvision und die Rolle des Produktowners

Wie Roman Pichler von der Scrum Alliance in seinem Artikel The Product Vision sagt, benötigt jedes Scrum Team eine Produktvision, die dem Team das Ziel vorgibt und die Richtung, um dorthin zu gelangen. Die Produktvision hilft zudem, das Scrum Team inhaltlich zu lenken.

Die Produktversion beschäftigt viele Produktowner. Daher geht es heute um die Frage, wie Sie zu Ihrer Produktvision kommen.


Exploratory Testing – Weitere Testtouren

Da letztendlich der Productowner zusammen mit dem Entwicklungsteam für die Qualität verantwortlich ist, gehören ja auch qualitätsbezogene Aktivitäten zum Scope der Aktivitäten. In dem ersten Artikel zur Serie über die Methode des exploratorativen Testens bin ich bereits auf die Testmethode selbst, und die Anwendungsgebiete eingegangen.

Heute geht es um die Testtouren, für die im ersten Artikel zu dieser Serie der Raum nicht mehr gereicht hat.


Exploratory Testing – Scrum Teams testen wie Touristen

Beim Exploratory Testing (Exploratives Testen) handelt es sich nach James Bach um eine informelle Testtechnik, bei der der Tester das Testdesign aktiv kontrolliert, während er diese Tests ausführt.

Bei dieser Methode benutzt der Tester die beim Testen gewonnene Information dazu, um neue und bessere Tests zu entwerfen. Erfahrungsgemäß kommt diese Testmethode im Scrum Team besonders gut an, da sie darüber hinausgeht, die üblichen vorgegebenen Testpläne und Done-Kriterien abzuarbeiten.

Letztendlich ist der Produktowner ja auch für die Qualität verantwortlich. Daher will ich heute kurz auf diese Technik eingehen, und einige der wichtigsten Testtouren erläutern.


Wie Google Software testet – die Rolle des Entwicklungsteams

Neben den Features einer Software hat die Qualität der Produkte eine überragende Bedeutung. Viele von Ihnen kennen noch den alten Ansatz, der daraus besteht, Qualität in das Produkt hineinzutesten.

Viel sinnvoller ist es aber, die Produkte gleich qualitätsgerecht zu entwickeln. Besonders vielversprechend ist eine Organisationsform, die die Qualität im Entwicklungsteam anordnet.


FedEx-Tour

In dem Modell der agilen Softwareentwicklung haben Teams eine andere Rolle, als in einer Softwareentwicklungsabteilung, die nach dem „Wasserfallprinzip“ arbeitet. Es gibt verschiedene Qualitätssicherungsmethoden, die ein Scrum Team anwenden kann. Eine dieser Methoden, die geradezu die Mitwirkung des Productowners verlangt, ist das explorative Testen. Die FedEx Tour ist eine besondere Methode, wie der Productowner und Team diese Tests organisieren können.


Statusreports – Jeder hasst sie, keiner liest sie

Gerade, wenn Sie im Produktmanagement einer großen Firma arbeiten, kennen Sie Statusreports sicherlich zur Genüge. Manche Manager lieben sie so sehr, daß sie ihre Teams jede Woche mit solchen Reports beschäftigen. Eigentlich kenne ich niemanden, der diese Reports gerne erstellt, und ich sehe auch immer wieder Manager, die den Anschein geben, als hätten sie die Reports überhaupt nicht gelesen. Die Frage ist: Brauchen wir Statusreports, und wenn ja, wie können wir diese Statusupdates möglichst einfach erstellen, und was sollte in diesen Reports stehen?


Produktmanagement und Burnout

Ich habe etwas Marktforschung zu der Frage betrieben, welche Inhalte die Leser eines Produktmanagement Blogs interessieren.

Interessanterweise wollen viele Leser auch einmal etwas über die Thematik „Produktmanagement und Burnout“ wissen. Darauf gehe ich heute gerne einmal kurz ein, da ich denke, daß wir zwei Beiträge dazu leisten können, um das Thema zu entschärfen.