Wie oft sind Sie schon auf Probleme mit einer Lieferung Ihres Software-Lieferanten gestoßen? Das ist eher die Regel als die Ausnahme. Warum eigentlich? Weil es einige technische Regeln oder Best Practices gibt, die Ihr Lieferant unbedingt einhalten sollte, wenn er bei seinen Kunden als stressfreier Lieferant gelistet werden möchte. Wir haben diese Regeln als unsere Top 10 Best Practices bei der Entwicklung von Software zusammengestellt.
1. Verwenden Sie ein Code-Repository
Es gibt keinen Grund, dies in Frage zu stellen. Es ist eine Notwendigkeit, um die Arbeit und die Zusammenarbeit von Entwicklern zu organisieren oder um Releases zu erstellen, zu reproduzieren und auszuliefern und es ist eine obligatorische Praxis in der Software-Entwicklergemeinschaft.
2. Verwenden Sie einen Issue Tracker
Issue Tracker sind viel mehr als nur Bug Tracking Tools. Es ist eine großartige Möglichkeit, die vertraglichen Anforderungen in nachvollziehbare Teile zu zerlegen und diese transparent als Tickets zu verfolgen, welche die Funktionalität erfassen. Erlauben Sie dem Lieferanten, jeden funktionalen Issue-Typ zu verwenden, den Sie oder der Lieferant für angemessen halten, wie z.B. Feature/User-Story/Improvement/welche funktionalen Issue-Typen auch immer Sie verwenden wollen.
Darüber hinaus ermöglicht die Beschreibung der jeweiligen Work-Items eines funktionalen Tickets auch die Verfolgung des Arbeitsfortschritts. Die Verwendung eines Issue Trackers ist die einzige effektive Methode, um den Überblick über neue Funktionalitäten zu behalten, die Teil eines neuen Releases sein sollen. Mit einem Issue Tracker haben der Kunde und der Lieferant eine gemeinsame Plattform, um Informationen über die vertraglichen Verpflichtungen und den detaillierten Fortschritt des Projekts auszutauschen.
3. Beschreiben und spezifizieren Sie funktionale Tickets
Teil des Lieferantenprozesses ist es, funktionale Tickets/Änderungswünsche zu spezifizieren, um ausgerichtet zu bleiben, wenn Abweichungen von den ursprünglichen Vertragsbeschreibungen und Vereinbarungen unvermeidlich oder wünschenswert werden. Der Prozess sollte pragmatisch, schnell und klar sein und folgende Fragen beantworten (Minimum):
- Worum handelt es sich?
- Was ist der Nutzen? Warum wird die Funktionalität aus Anwendersicht benötigt, was verbessert sie, welche Einschränkung löst sie oder welche ursprüngliche Anforderung ersetzt oder macht sie obsolet?
- Etwaige Implementierungsideen oder Designfragen sollten ebenfalls skizziert werden, um sie für diejenigen, die entscheiden sollen, verständlich zu machen.
- Akzeptanzkriterien sollten so genau wie möglich spezifiziert werden.
4. Verknüpfen Sie Commits mit Issues oder Pull Requests, die wiederum mit Issues verknüpft sind
Dies ist eine Notwendigkeit, um eine automatisierte Rückverfolgbarkeit von den Anforderungen zu den Issues und hinunter zum Code zu gewährleisten. Nur dadurch können beide Seiten wissen, welche Funktionalität es wirklich in ein Release geschafft hat. Alternativ ist es auch in Ordnung, einen Sub-Task eines funktionalen Tickets oder eines Bugs anzugeben.
Ein Commit kann auch mit einem Pull Request verknüpft werden. Es ist aber darauf zu achten, jeden Pull Request wiederum mit einem bestimmten funktionalen Ticket zu verknüpfen (siehe Punkt 5). Mindestens 75% der Commits sollten explizit oder implizit mit einem Issue verknüpft sein. Die Arbeit sollte ebenfalls sinnvoll aufgeteilt werden, um nur für ein bestimmtes Issue zu committen und nicht für zwei oder gar mehr.
5. Missbrauchen Sie Pull Requests nicht fürs Requirements Engineering
Pull-Requests sind dazu gedacht, Entwicklern eine effektive Zusammenarbeit zu ermöglichen, z.B. das Code Review der Arbeit von Kollegen vor dem Commit, das Organisieren von Branch-Workflows und Integrationsprozessen. Pull Requests sind definitiv nicht als Ersatz für Requirements Engineering oder einen Issue Tracker gedacht.
PRs mit Labels zu versehen, um sie als Features/was-auch-immer-funktionales-Ticket-Typ oder Bug zu spezifizieren, ist einfach eine schlechte Angewohnheit und wirkt allen zuvor genannten Kriterien entgegen. Kein Entwickler ist geneigt, sich die Mühe zu machen, einen Pull Request im Detail zu beschreiben. Dafür sind Issues gut, wobei andere Rollen (z.B. ein Product Owner) sich die Mühe machen, sie auszuarbeiten.
6. Setzen Sie Continuous Integration auf
Dies ist die beste und wahrscheinlich einzige Möglichkeit, die auszuliefernde Software regelmäßig zu bauen und zu testen, die Erfolgsrate der Builds zu messen und Integrationsprobleme und -fehler frühzeitig zu erkennen und damit die Chance zu erhöhen, den Einführungstermin einzuhalten. Darüber hinaus gibt es keine andere Möglichkeit, eine frühere Version der Software auf effiziente/automatisierte Weise neu zu erstellen. Fordern Sie Ihren Lieferanten auf, dies zu tun und kontrollieren Sie seine Bemühungen.
7. Handhaben Sie Fehler auf effektive Art und Weise
Bugs sind der lästigste Teil der Softwareentwicklung. Es kostet Zeit, den Fehler zu reproduzieren, die Ursache herauszufinden und was noch schlimmer ist, es hält die Entwickler von der kreativen und wertschöpfenden Arbeit an neuen Funktionen ab. Daher sollte das Entwicklungsteam auf automatisierte Weise so viele Details über den Fehler wie möglich als Teil der Ticket-Beschreibung sammeln (z.B. Bug-Traces, Benutzer-/Entwickler-Beschreibungen). Bugs sollten niemals “on the fly” behoben werden (z.B. als Teil einer anderen Feature-Implementierung). Zu jedem Bugfix sollte außerdem mindestens ein Testfall geschrieben werden, um ein Wiederauftreten zu erkennen.
8. Budgetieren Sie 10-15% der Projektkapazität für Verbesserungen/Refactorings
Dies ist ein Kriterium, das zwischen dem Kunden und dem Lieferanten gut kommuniziert werden sollte. Jedes Softwaresystem benötigt aufgrund der technischen Realität und/oder aufgrund von nicht berücksichtigten Aspekten in den ursprünglichen Spezifikationen ständige Verbesserungen und Refactorings. Hinzu kommt, dass der technologische Fortschritt, die Tücken der Programmiersprachen und die ständige Notwendigkeit für die Entwickler on-the-fly zu lernen ohnehin das Projektbudget aufzehren und in diesen 10-15% berücksichtigt werden sollten.
9. Monitoren Sie Verbesserungen und Refactorings
Um kein Misstrauen zwischen Kunde und Lieferant aufkommen zu lassen, ist Transparenz über den Zeitaufwand äußerst wichtig. Jede Verbesserung/Refactoring muss als Ticket eines bestimmten Typs angelegt werden, die Arbeit und ihre Notwendigkeit müssen skizziert und motiviert werden (als Teil des Tickets) und mit den oben beschriebenen Mechanismen bis hinunter zum Code verfolgt werden. Es gibt Möglichkeiten, den Aufwand pro Ticket-Typ (wie Verbesserungen/Refactoring, Bugs oder funktionale Tickets) durch bestimmte Werkzeuge wie die DETANGLE Analysis Suite zu überwachen.
10. “Soft” Kriterien
Ein potenzieller Lieferant erfüllt vielleicht nicht alle vorgeschlagenen Kriterien. Seine Bereitschaft, dies zu erreichen, ist ebenso wichtig. Einigen Sie sich auf einen Plan und einen Zeitrahmen und geben Sie dem Lieferanten die Möglichkeit, sich zu verbessern. Gute Software hat etwas von einem “Wunderprodukt”, deshalb ist es auch sehr wichtig, eine vertrauensvolle Beziehung zwischen allen am Projekt Beteiligten aufzubauen. Wenn ein Projekt trotz aller ausgeklügelten Prozesse und Metriken in Schwierigkeiten gerät, ist es das Vertrauen zwischen den Beteiligten, das dieses Projekt noch zu einem Erfolg führen kann.