Blog

Die Bedeutung und der Ursprung von „Technical Debt“ Die Metapher von Technical Debt (TD) im Zusammenhang mit Software wurde von Ward Cunningham geprägt, der zu dieser Zeit an der Codierung eines Finanzsystems arbeitete. Er nutzte die Metapher, um seinen Finanzkollegen die Gründe für das Refactoring und Umschreiben von Teilen des Codes zu erklären, wenn sich das Wissen über die Anforderungen weiterentwickelte. „Wenn ein Entwicklungsteam Abkürzungen nimmt und Code liefert, der nicht ganz für die aktuelle Programmieraufgabe geeignet ist, entsteht TD. Diese Schulden verringern die Produktivität. Dieser Produktivitätsverlust liegt im Interesse des TD.“ Wards ursprünglich beabsichtigte Erklärung war ziemlich [...]

Hier finden Sie einige Einblicke in den Wert der Erkennung von Anforderungsfehlern vor dem Entwurf oder der Codierung. Für ein Softwareentwicklungsteam ist es sehr wertvoll, Fehler frühzeitig zu erkennen. Noch besser ist es, Defekte gänzlich zu vermeiden. Exzellente Anforderungen sind eine wirksame Form der Fehlerprävention und Nacharbeitsprävention. Eine mehrdeutige Anforderung kann zu erheblicher Aufwandsverschwendung führen. Es treten Mängel auf, bevor mit der Codierung begonnen wird. Es treten Mängel in den Anforderungen und in der Architektur auf, bevor mit der Codierung überhaupt begonnen wird. Stellen wir uns vor, wir sind in einem Versicherungsunternehmen tätig und die Geschäftsleute haben entschieden, dass ein neues (oder geändertes) System [...]

Story-Splitting – Verfeinerung auf eine optimale Granularität Eine scheinbar kleine Story kann sich als viel größer herausstellen als erwartet. Nur durch Verfeinerung oder Aufteilung der Geschichte können Sie dies herausfinden. Die Aufteilung der Story kann früh oder kurz vor dem vorangegangenen Sprint erfolgen. Wir empfehlen, dies so früh wie möglich zu tun, um späte Überraschungen zu vermeiden. Wir betrachten „Story Splitting“ und „Story Refinement“ als sehr ähnliche Aktivitäten. Es geht darum, die Granularität der geschriebenen User Story zu optimieren. Was sind User Stories? Für Teams, die sich zusammenschließen können, kann die User Story lediglich eine Erinnerung an ein Gespräch sein. [...]

Bei der Anforderungsermittlung geht es darum, die tatsächlichen Geschäftsanforderungen und die Systemanforderungen jedes Softwareunternehmens zu ermitteln. Es geht zunächst darum herauszufinden, was benötigt wird, und dann darum, die destillierten Entdeckungen in Artefakten zu artikulieren, die als Grundlage für die Beschreibung dessen, was getan werden muss, dienen können. Es ist ungewöhnlich, dass die tatsächlichen Geschäftsanforderungen (und nachfolgenden Systemanforderungen) schnell gefunden werden können. Obwohl die Anforderungserhebung manchmal als Anforderungserfassung bezeichnet wird, ist dies ein irreführender Ausdruck. Die tatsächlichen Anforderungen ähneln eher einem vergrabenen Schatz auf einem Feld und nicht den Ernten, die geerntet werden können. Manchmal ist ein Hinweis auf [...]

Schauen wir uns an, wie und warum wir User Stories qualitätssichern möchten. Schlechte User Stories führen zu unnötigen Besprechungen, Verschwendung und Nacharbeit. Die Verbesserung der User Story so früh wie möglich im Entwicklungslebenszyklus ist eine wirksame Möglichkeit, Verschwendung und Nacharbeit zu minimieren. Qualitätssicherung ist ein systematischer Ansatz, um festzustellen, ob ein „Produkt“ akzeptable Kriterien erfüllt. Für die Qualitätssicherung von User Stories müssen wir zunächst definieren, was gut ist. Was ist der Unterschied zwischen guten User Stories (und einer Reihe von User Stories) und schlechter Qualität? Für die agile Softwareentwicklung neigen wir dazu, [...]