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.
Grenzen der Innovation
Der Artikel →Innovation Is Not the Holy Grail von Christian Seelos & Johanna Mair im Stanford Social Innovation Review befasst sich mit der Thematik „Innovation“ im öffentlichen Sektor, bzw in Non-Profit Organisationen. Die Autoren schlagen vor, Innovationen weniger als Ideologie zu begreifen, sondern vielmehr als Prozess, und geben dem Leser mehrere Punkte an die Hand, die dabei helfen, diese Forderung umzusetzen. Die Autoren betrachten hierfür unterschiedliche Bereiche, und die dort vorherrschenden, typischen Fehler. Beides, die typischen Fehler aber auch der Punkteplan läßt sich auch in einem profitorientierten Unternehmen nutzen.
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.
Fragmentierung und Plattformstrategie
Oft denkt man im Hinblick auf den Kundennutzen daran, neue Features zu liefern, und ist darauf aus, die Featurewünsche möglichst agil und auf Kundenzuruf zu implementieren.
Dabei wird nur zu gerne vergessen, daß der Produkterfolg auf unterster Ebene des Entwicklungszyklus vordefiniert wird. Dort bestimmen die Produktarchitektur zusammen mit der Strategie, mit der die Anforderungen umgesetzt werden, was Kunden später überhaupt nutzen können.
Living Specification und Qualität der Software
Bereits an anderer Stelle habe ich über die Rolle von „guten“ Anforderungen im Softwareentwicklungsprozess geschrieben, und bin zu dem Ergebnis gekommen, daß es sich durchaus lohnt, Anforderungen so sauber und detailliert zu beschreiben, wir irgend möglich.
Auch ist es wichtig, professionelle Methoden zu verwenden, um zu prüfen, ob das entwickelte System die Anforderungen auch so abdeckt, wie von ihr verlangt.
Heute habe ich das Konzept der lebenden Spezifikation kennengelernt, das eine wichtige Rolle in der Schnittstelle zwischen Produkt-Owner, Entwicklung und Qualitätsicherung spielt. Dies will ich heute kurz skizzieren.
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.
SSNiF (Stakeholder, Situation, Need, Feature) Analyse
Gerade in der Entwurfsphase einer Software hat man auf der einen Seite die Wünsche der „Kunden“. Auf der anderen Seite stehen die einzelnen Realisierungen. Die Analysemethode, um die es heute geht, hilft dabei die Produktanforderungen, und die Featureentwicklung zusammenzubringen.
Die Stakeholder-Stituation-Need-Feature Analyse kann dabei auf verschiedenen Leveln angewendet werden, und sie hilft sowohl bei der Strukturierung, als auch bei der Qualitätsprüfung der Produktanforderungen.
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.
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?
Definition of Done
In an agile development model, you and your team releases each takt software that your (interal and external) stakeholders can consume immediately. You and your team specify, design, develop and test these potentially shippable products during the sprint. Thus, one of the most important aspects for your agile development project is the question, when you should consider a development task as done.
Formalized Done Criteria that match with the characteristics of your development product help you with this release decision.
Good Friday – Nutzen
Google ist ein prominenter Vertreter von Firmen, die es Ihren Mitarbeitern gestatten, einige Tage in der Woche „ungerichtet“ zu arbeiten. Google Mitarbeiter dürfen an Ihrem „Good Friday“ 20% der Arbeitszeit in freie Projekte investieren.
Diese Projekte werden nicht weiter überwacht. Wissenschaftliche Forschungen, aber auch die Erfahrungen der Verwenderfirmen dieses Modells berichten viel Gutes darüber.
ScrumBut – We use Scrum, but… – Eine Ergänzung
Einer meiner Leser der ersten Stunde hat mich neulich auf einen interessanten Blogbeitrag zum Thema Scrum hingewiesen, der auf dem PM-Blog unter dem Titel „ScrumBut – We use Scrum, but…” zu lesen ist. Wie Sie wissen, arbeiten heute viele Unternehmen im IT Sektor nach der SCRUM Methode, d.h. einem Ansatz, der sich den Zielen Lean (Einfachheit) und Agile (Agilität) verschrieben hat. Der erwähnte Artikel befasst sich mit der Umsetzung dieser Methode. Ich beschäftige mich heute mit dem „Aber“ bei der ‚Umsetzung.
Technical Debt, and Test Categorization
Recently, Tom Grant from Forrester has written about technical debt and its relevance to Product Management. He made some good points (in particular that technical debt is evil), so that it is with me today to add a few thoughts about quality.
Google and the Myth of Free Time
Google is known as a very innovative company. In particular their innovation friday is famous. Here in my blog, I have written several articles, in which I discuss the usefulness of this approach.
In his article in the Harvard Business Review → Google and the Myth of Free Time, Chris Trimble writes about this strategy as well. In contrast to me and others, he basically does not think very positive about Google’a approach to foster innovation.
Using my experiences with both, a similar approach, and the development of innovative products, I would like to comment on his article.
Requirements Tools – A New Study by Forrester
Und zwar hat Forrester Research eine neue Studie über den Markt für Softwaretools herausgebracht, mit denen man Anforderungen erhebt, verwaltet, und bewertet.
Sie kennen das Problem ganz besonders, wenn Sie Software anbieten, die besonders umfangreich ist. Dann erreichen Sie – getreu dem Motto „der Appetit kommt beim Essen“ – relativ schnell viele Verbesserungsvorschläge, Bugbeschreibungen, oder Erweiterungswünsche. Um Ihre (agilen) Teams richtig versorgen zu können, benötigen Sie einige Informationen über die Requirements, und den jeweiligen Use Case.
Pair Programming
Unter dem Titel „Großbaustelle – Making of Windows 7“ gab es in der Computerzeitung CT aus dem Heise Verlag vor einiger Zeit einmal einen interessanten Artikel zum Entwicklungsprozess für das neue Windows 7 Betriebssystem zu lesen.
Heute geht es mir um das geänderte Entwicklungsmodell, das Microsoft gegenüber Windows Vista angewandt hat, da ich in anderem Zusammenhang heute wieder auf diesen Artikel gestoßen bin. Die Frage ist: Lohnt sich das?
Requirementsmanagement
Heute geht es mir um das Requirements Management, da ich gesehen habe, dass dieses Thema viele Leser interessiert. Zunächst befasse ich mich kurz mit der Frage, was Requirements sind, wie man sie formuliert, und wie man den Requirementsprozess verbessert. Dann werde ich einige Tools einführen, die Unterstützung für den Requirementsprozess bieten.
Mehr Innovation durch den Innovationday?
Heute war zu lesen, dass unser Land dringend neue Geschäftsfelder benötigt, da bezweifelt wird, dass die traditionellen Industrien zu der alten Bedeutung zurückkehren werden. So merkwürdig es vielleicht auf den ersten Blick klingen mag – es kann helfen, wenn man Mitarbeitern genügend Freizeit gibt, in der diese ungerichtet, und ohne Ziel an neuen Themen forschen können. Viele große Firmen tun dies, aber auch ich im Kleinen verfolge seit einiger Zeit ein solches Modell, mit dem ich gute Erfahrungen gesammelt habe. Deshalb will ich die Idee zum „Innovation Day“ heute kurz vorstellen.
Lesenswerte Beiträge in anderen Blogs
Mir sind in der letzen Zeit einige interessante Artikel und Blogs aufgefallen, die ich hier kurz erwähnen möchte. Es geht in diesem Artikel, um einen Überblick über die agile Softwareentwicklung, um eine Schätzmethode, und um die wichtige Rolle des Productowners in einem Scrum-Team.
Lean Innovation
Das WZL der RWTH Aachen verfolgt einen interessanten systematischen Ansatz, um die Wertorientierung in das Innovationsmanagement einzuführen. Diesen Ansatz möchte ich hier nur kurz anreissen, und lege Ihnen nahe, sich den Ansatz bei der RWTH Aachen selbst näher anzusehen.
Mit System zu neuen Ideen
Hier geht es um die Kreativität, und um eine Systematik, die man verwenden kann, um systematisch neue Ideen zu erzeugen und zu Konzepten weiterzuentwickeln. Die folgenden Schritte werden behandelt: ERFOLGSCHANCEN ERKENNEN, DENKMUSTER ERWEITERN, INSPIRATIONEN SUCHEN, SPANNUNG ERZEUGEN, ORDNEN UND OPTIMIEREN, NUTZEN MAXIMIEREN
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren. 