Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
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.
Heute möchte ich diese Methode kurz umreißen.
Die Methode „Specification by Example“ ist eine häufig verwendete Methode, um Produktanforderungen in Einklang zu bringen mit den Produktmerkmalen. Die Methode sorgt auch dafür, daß die Produktfeatures überprüft und getestet werden können.
Konsequent angewandt, erlaubt das Specification by Example den Aufbau einer lebenden Dokumentation.
Gojko Adzic behandelt die Schlüsselideen der Methode auf einer seiner Homepages (siehe →www.specificationbyexample.com/key_ideas.html).
Die einzelnen Phasen werden iterativ durchlaufen, und solange wiederholt, bis das Ergebnis stimmt. Die folgende Tabelle (entnommen der o.a. Quelle) zeigt die wesentlichsten Elemente, zusammen mit der Begründung.
| Schlüsselidee | Warum | Methode |
| Projektumfang aus den Zielen herleiten | Entwicklungsteam als Teil des Spezifikations-/ Scoping-Prozesses | „Instead of requirements that are already a solution for an unknown problem, really successful teams derive scope from goals. They start with a business goal that the customer wants to achieve. They collaboratively define the scope that achieves that business goal, starting from the desired business effect. They allow the team to come up with a good solution together with the business users. The business users focus on communicating the intent of the desired feature–the value that they expect to get out of it. This helps everyone understand what is needed. The team can then suggest a solution that is cheaper, faster, easier to deliver or maintain than what the business users would come up with on their own. “ – Adzic |
| Gemeinsam spezifizieren | Vermeiden von Missverständnissen durch mangelhafte Kommunikation | „Instead of relying on any single person to get the specifications right in isolation, successful delivery teams engage in specifying the solution collaboratively with the business users. People coming from different backgrounds use different heuristics to solve problems and have different ideas. Technical experts know how the underlying infrastructure can be used better, or how emerging technologies can be applied. Testers know how the system is likely to break or where to look for potential issues, and these issues should be prevented from occurring in the first place. All this information needs to be captured as the specification of work. Specifying Collaboratively enables us to harness the knowledge and experience of the whole team. It also creates a collective ownership of specifications, ..“ – Adzic |
| Illustration durch Beispiele | Beschreibungen lassen zu viel Raum für Interpretationen | „If the system works correctly for all the key examples, we know that it meets the specification we collaboratively agreed on. In fact, key examples effectively define what the software needs to do. They are both the target for development and an objective evaluation criterion to check whether the development is done. If the key examples are easy to understand and communicate, we can replace the requirements with the key examples.“ – Adzic |
| Definieren der Spezifikation | Verschiedene Rollen haben einen unterschiedlichen Blick auf eine Spezifikation. Man benötigt jedoch den gemeinsamen Blick. | „By refining the specification from key examples, removing all the extraneous details, successful teams get a very concrete and precise context for development and testing. They define the target with enough detail to implement and verify it but without any additional information. They define what the software is supposed to do, not how it does it. Refined examples can be used as an acceptance criterion for delivery. Development is not done until the system works correctly for all these examples. With some additional information to make key examples easier to understand, they make up a specification with examples, which is at the same time a specification of work, an acceptance test, and a future functional regression test.“ – Adzic |
| Automatische Validierung ohne die Spezifikation zu ändern | Unit Tests reichen nicht aus. Vielmehr benötigt man automatische Integrationstests. | „To get the most out of key examples, successful teams automate the validation without changing the information. They keep everything in the specification literally the same when automating, without any risk of mistranslation issues. As they automate validation without changing specifications, the key examples stay almost in the form they were in on a whiteboard–human-readable and accessible to all team members. An automated specification with examples, still in a human-readable form and easily accessible to all team members, becomes an executable specification. We can use it as a target for development and easily check if the system does what we agreed. We can use that same document to get clarification from business users. If we need to change the specification, we have to do it in one place only.“ – Adzic |
| Häufige Überprüfung | Code ist oft die einzig verläßliche Quelle der Wahrheit – Anwender benötigen jedoch eine Übersetzung | „By checking all their executable specifications frequently, the teams quickly discover any differences between the system and the specifications. Because their executable specifications are easy to understand, the teams can discuss the changes with their business users and decide how to address the problems. They constantly keep their systems and executable specifications in sync.“ – Adzic |
| Ableiten eines Dokumentations-systems | Da Spezifikationen sich ändern, benötigt man ein Dokumentationssystem, das Änderungen erlaubt. | „Living documentation is a reliable and authoritative source of information on system functionality, which anyone can easily access. It is as reliable as the code, but much easier to read and understand. Support staff can use it to find out what the system does and why. Developers can use it as a target for development. Testers can use it for testing. Business analysts can use it as a starting point when analyzing the impact of a requested change of functionality. And it gives us regression testing for free.“ – Adzic |
Die Methode beinhaltet ebenfalls Werkzeuge, die das Entwicklungsteam dazu verwenden kann, um die funktionale Korrektheit der entwickelten Lösung zu prüfen.
Beispielsweise kann man Impact Maps verwenden, um zu beschreiben warum, wer, wie und was fordert (siehe →Impact Maps)
Hier die Vorteile der Methode:
Ich kenne die Methode als hilfreich, wenn es darum geht, komplexe Projekte zu strukturieren. Insbesondere ist die Verknüpfung von Anforderung mit Test hilfreich, sowie die Möglichkeit, sich eine Dokumentation aufzubauen.
Im Internet finden Sie weiterführende Artikel, in denen Sie mehr Informationen über die vorgestellten Konzepte:
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema Innovationsmanagement generell:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
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.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
