Vielleicht werden Sie nach dem Lesen dieses Artikels denken, dass ich über alltägliche Dinge schreibe, die jeder kennt. Aber in 10 Jahren habe ich nur 3 IT-Unternehmen gewechselt, von denen zwei "banale" Praktiken nicht vollständig angewendet wurden. Der Softwareentwicklungsprozess litt stark darunter. Zusätzlich zu meiner persönlichen Erfahrung wurde ich inspiriert, den Artikel durch die Geschichten von Analysten zu schreiben, die ich kenne und die im IT-Bereich arbeiten, und fast jeder ist mit Organisations- und Kommunikationsproblemen konfrontiert, die gelöst werden müssen und können.
In den letzten 3 Jahren habe ich als Systemanalytiker in der InfoWatch-Unternehmensgruppe gearbeitet. In diesem Artikel möchte ich Ihnen die Vorgehensweise bei der Arbeit mit den von uns verwendeten Anforderungen vorstellen. Das Unternehmen entwickelt Enterprise-Produkte, um Informationssicherheitsrisiken zu minimieren, Unternehmensdaten zu schützen und zu analysieren. Für solche Produkte werden hohe Anforderungen an Zuverlässigkeit, Leistung, Fehlertoleranz sowie Anforderungen an die Zertifizierung gestellt. Aufgrund der Besonderheiten des Marktes für Informationssicherheit sind unsere Lösungen nicht cloudbasiert, sondern werden vor Ort beim Kunden installiert. Daher arbeiten wir mehrmals im Jahr in einem großen Release-Modus. Um das zugewiesene Ziel zu erreichen und die Release-Zeit zu verkürzen, arbeiten wir nach den in der Agile-Methodik festgelegten Prinzipien.Um mit der Entwicklung zu beginnen, bereiten wir keine absolut detaillierten Systemanforderungen vor, sondern beginnen mit einer allgemeinen Beschreibung der wichtigsten Aspekte der neuen Funktionalität. Das heißt, wir treffen Entscheidungen, die sich vor allem auf das Volumen und die Komplexität von Verbesserungen auswirken, und stellen dem Entwicklungsteam die erforderlichen Informationen zur Verfügung, um mit der Arbeit am Architekturdesign und dem Schreiben von Code (für kleine Funktionen) zu beginnen. Im Verlauf der Entwicklung werden dann die Anforderungen schrittweise detailliert und auf einen Detaillierungsgrad gebracht, der ausreicht, um detaillierte Testfälle zu schreiben. Mit diesem Ansatz können Sie nicht viel Zeit aufwenden, um mit der Arbeit zu beginnen, und das Risiko verringern, dass die Anforderungen erheblich überarbeitet werden müssen, wenn neue technische Einschränkungen zutage treten.Dies wirkt sich vor allem auf das Volumen und die Komplexität von Verbesserungen aus und liefert dem Entwicklungsteam die erforderlichen Informationen, um mit der Arbeit an Architekturdesign und -codierung (für kleine Features) zu beginnen. Im Verlauf der Entwicklung werden dann die Anforderungen schrittweise detailliert und auf einen Detaillierungsgrad gebracht, der ausreicht, um detaillierte Testfälle zu schreiben. Mit diesem Ansatz können Sie nicht viel Zeit aufwenden, um mit der Arbeit zu beginnen, und das Risiko verringern, dass die Anforderungen erheblich überarbeitet werden müssen, wenn neue technische Einschränkungen zutage treten.Dies wirkt sich vor allem auf das Volumen und die Komplexität von Verbesserungen aus und liefert dem Entwicklungsteam die erforderlichen Informationen, um mit der Arbeit an Architekturdesign und -codierung (für kleine Features) zu beginnen. Im Verlauf der Entwicklung werden dann die Anforderungen schrittweise detailliert und auf einen Detaillierungsgrad gebracht, der ausreicht, um detaillierte Testfälle zu schreiben. Mit diesem Ansatz können Sie nicht viel Zeit aufwenden, um mit der Arbeit zu beginnen, und das Risiko verringern, dass die Anforderungen erheblich überarbeitet werden müssen, wenn neue technische Einschränkungen zutage treten.ausreichend, um detaillierte Testfälle zu schreiben. Mit diesem Ansatz können Sie nicht viel Zeit aufwenden, um mit der Arbeit zu beginnen, und das Risiko verringern, dass die Anforderungen erheblich überarbeitet werden müssen, wenn neue technische Einschränkungen zutage treten.ausreichend, um detaillierte Testfälle zu schreiben. Mit diesem Ansatz können Sie nicht viel Zeit aufwenden, um mit der Arbeit zu beginnen, und das Risiko verringern, dass die Anforderungen erheblich überarbeitet werden müssen, wenn neue technische Einschränkungen zutage treten.
Wenn Ihr Entwicklungsprozess unserem ähnlich ist oder Sie zu diesem kombinierten Prozess wechseln möchten, sind höchstwahrscheinlich die unten beschriebenen Vorgehensweisen für Sie geeignet. Aber selbst wenn Sie einen anderen Prozess haben, besteht die Möglichkeit, dass die vorgestellten Praktiken für Sie nützlich sind. In jedem Fall empfehle ich Ihnen, sich mit ihnen vertraut zu machen, insbesondere wenn Sie als Systemanalytiker in einem IT-Unternehmen arbeiten.
Die Anforderungen an das zu entwickelnde Produkt liegen im Hauptverantwortungsbereich eines Systemanalysten. Die nachfolgend beschriebenen Vorgehensweisen zielen darauf ab, das Anforderungsmanagement und damit den Produktentwicklungsprozess zu vereinfachen:
- Dokumentation und Versionierung;
- Benachrichtigung über Änderungen;
- Rezension;
- Kundgebungen / Treffen / Status;
- Diskussion / Lösung offener Fragen;
- Protokollierung von Diskussionen;
- Validierung neuer Funktionen;
- Präsentation neuer Funktionen.
Dokumentations- und Versionsanforderungen
Es ist zweckmäßig, wenn die Beschreibung des Produkts in Form von funktionalen und nicht funktionalen Anforderungen in einem Dokument festgelegt ist, die Anforderungen nach Funktionsbereichen aufgeschlüsselt sind, die durch Gruppierung, Übergänge durch Links usw. miteinander verbunden sind. Wenn Änderungen im Rahmen der Beschreibung von Merkmalen oder infolge der Behebung von Fehlern in der entsprechenden Version der Anforderungen berücksichtigt werden.
Die Versionierung der Anforderungen ist dieselbe wie für das Produkt selbst, sodass Sie die Erhöhung der Funktionalität mit jeder neuen Version sehen können. Außerdem erhalten Sie schnellen Zugriff auf Informationen darüber, wie diese Funktionalität in früheren Versionen funktioniert hat und aus welchen Gründen sie geändert wurde.
In einigen Unternehmen muss viel Zeit aufgewendet werden, um solche Informationen zu erhalten, da alle Aufgaben, die mit einer bestimmten Funktionalität verbunden sind, überprüft, ihre Beschreibung untersucht und Kommentare angezeigt werden müssen. Ein schnellerer Weg, um die benötigten Informationen zu erhalten, besteht übrigens darin, den Entwickler zu bitten, sich die Änderungen im Code anzusehen. In diesem Fall dauert es jedoch nicht nur Ihre Zeit, sondern auch die Zeit des Entwicklers, was Ihren Arbeitgeber kostet Mehr. Wenn Sie die Anforderungen an einem Ort beschreiben, können Sie nicht nur die gewünschten Informationen finden, sondern auch den Kontext sofort verstehen.
Wir verwenden Confluence, ein praktisches Tool, das Sie selbst ein wenig optimieren können. Ein Kollege von mir spricht in seinem Artikel ausführlich über unsere Erfahrungen mit Confluence. Wie wir Confluence verwenden, um Produktanforderungen zu entwickeln . " Interessanterweise verfügen viele IT-Unternehmen über dieses Tool, aber nicht jeder verwendet es, um Produktanforderungen zu dokumentieren.
Benachrichtigung über Änderungen der Anforderungen
Es wird empfohlen, alle Beteiligten über Änderungen der Anforderungen zu informieren. Auf diese Weise können Sie auch überwachen, wann und aus welchem Grund die Anforderungen geändert wurden. Wenn ich oben gesagt habe, dass es wichtig ist, alle Änderungen infolge der Behebung von Fehlern in den Anforderungen zu berücksichtigen, dann sprechen wir hier darüber, das Team über diese Änderungen zu informieren.
Es ist wichtig zu verstehen, dass Anforderungen die Daten sind, die Entwicklungsteams, Testteams und technische Redakteure für ihre Arbeit verwenden, und dass Änderungen der Anforderungen in der Implementierung, in Testfällen und in der Dokumentation unterstützt werden müssen.
Wenn die beteiligten Teams nicht benachrichtigt werden, treten wahrscheinlich die folgenden Probleme auf:
- Die Implementierung entspricht möglicherweise nicht den Anforderungen.
- ;
- .
Bis vor kurzem hat unser Analystenteam alle Interessierten folgendermaßen über Änderungen der Anforderungen informiert: Nachdem sie Änderungen an den Anforderungen vorgenommen hatten, hinterließen sie einen Kommentar zum Problem, schickten einen Brief mit einem Link zum Problem, einem Link zu den Anforderungen und eine kurze Beschreibung der Änderungen. Ende letzten Jahres haben wir diesen Prozess automatisiert: Wir haben den Issue-Tracker fertiggestellt (wir verwenden JIRA) und jetzt, nachdem wir Änderungen an den Anforderungen vorgenommen haben, klicken wir in der Aufgabe, in der diese Änderungen vorgenommen wurden, auf "Über Änderungen benachrichtigen" Wählen Sie die Schaltfläche "Interessierte Teams" aus und nehmen Sie eine kurze Beschreibung der Änderungen vor:
Screenshot 1 Der
Brief, der nach dem Klicken auf die Schaltfläche "Benachrichtigung senden" automatisch generiert wird, enthält die folgende Darstellung und enthält alle erforderlichen Informationen:
Screenshot 2
Zusätzlich zum Brief bleibt ein Kommentar mit ähnlichen Informationen im Problem.
Überprüfung neuer Anforderungen
Es ist obligatorisch, neue Anforderungen durch die Leads aller an der Entwicklung des Features beteiligten Teams zu überprüfen. Es handelt sich nicht um Änderungen innerhalb von Fehlern, sondern um völlig neue Funktionen, deren Beschreibung Sie vornehmen. Das Einholen von Feedback ist äußerst nützlich, da möglicherweise die richtigen Fragen auftauchen, die dazu beitragen, die Möglichkeiten der neuen Funktionalität im Detail aufzuzeigen. Wenn Sie lange Zeit einen Gedanken in eine Richtung entwickeln, einen Bedarf und Probleme identifizieren, verschiedene Konzepte entwickeln und eine Lösung im Rahmen des Produkts beschreiben, kann das Auge verschwimmen und es scheint, dass es offensichtliche Dinge gibt, die dies bewirken müssen nicht in den Anforderungen festgelegt werden. Die Überprüfung hilft, auch durch Fragen von Spezialisten, die sich anhand der Informationen, die sie in den Anforderungen erhalten, mit dem Thema befassen, zu verstehen, welche Punkte geklärt oder offengelegt werden müssen.Die Überprüfung hilft auch dabei, die Klarheit des Wortlauts zu verbessern und Änderungen vorzunehmen, damit sie von allen eindeutig interpretiert werden.
Zu diesem Zweck haben wir auch den Issue-Tracker verbessert und eine separate Art von "Überprüfungs" -Aufgabe hinzugefügt, die vom zuständigen Analysten für jede Funktion aller Teamleiter gestartet wird. Manager, die unabhängig voneinander oder an ihre Untergebenen delegieren, lesen die Anforderungen Korrektur, stellen Fragen oder klären sie durch Kommentare und stimmen den vorgenommenen Änderungen zu.
Screenshot 3
Kundgebungen / Treffen / Status
Tägliche Besprechungen des Teams, das an der Funktion arbeitet, sind eine großartige Veranstaltung für kleine Teams, sofern sie häufige Sprints verwenden. Andernfalls nehmen tägliche Besprechungen die Zeit des gesamten Teams in Anspruch und sind nicht von Nutzen. Sie sollten Besprechungen jedoch nicht vollständig abbrechen, sondern nur die Häufigkeit ihrer Abhaltung korrekt bestimmen. Und dann können Sie am Puls der Zeit bleiben, verstehen, ob sich das Team bei der Umsetzung des konzipierten Konzepts in die richtige Richtung bewegt, und frühzeitig Probleme identifizieren, die gelöst werden können, oder Einschränkungen, die vereinbart werden müssen.
Natürlich müssen Sie bei der Entwicklung von Anforderungen mit dem Team kommunizieren, da Sie viele nützliche Informationen erhalten können. Wichtige Momente, die irgendwo in der „Black Box“ passieren, können das Konzept neuer Produktfunktionen stark beeinflussen. Die Kommunikation mit Kollegen hilft, die Aufmerksamkeit auf Momente zu lenken, die für ihre Rollen interessant sind. Beispielsweise ermöglicht die Kommunikation mit Testern die Berücksichtigung alternativer Szenarien, die in den Anforderungen getestet werden sollen, und es ist wichtig, dass sie zunächst festgelegt und in der Entwicklung berücksichtigt und während der Testphase nicht entdeckt werden .
Diskussion / Lösung offener Fragen
Ich möchte die Kommunikation per Sprache als separaten Punkt hervorheben, da ich eine Live-Kommunikation für wichtig halte, da es in den neuen Realitäten keine Möglichkeit gibt, Probleme von Angesicht zu Angesicht zu diskutieren.
Boten werden häufiger verwendet. Sie eignen sich gut für die persönliche Korrespondenz, in der Sie Lächeln, Gifs usw. verwenden können, um Ihre Gefühle auszudrücken. Bei Arbeitsaktivitäten ist dies jedoch nicht ganz akzeptabel. Daher bleibt ein trockener gesichtsloser Text erhalten Das ist für den Empfänger schwer zu interpretieren, da die Wahrnehmung dieses Textes von der Stimmung der Person, ihrer persönlichen Einstellung zu Ihnen, der Beteiligung am Dialog und anderen Faktoren abhängt, die nicht von Ihnen abhängen.
Daher ziehe ich es vor, Probleme in der Diskussion "per Stimme" zu lösen, dh anzurufen und zu diskutieren, sich auf etwas zu einigen. Der Anruf hilft Ihnen herauszufinden, ob Sie den Kontext richtig verstanden haben, stellt sofort Fragen und erhält Antworten. Die Stimme vermittelt Intonation, ermöglicht es Ihnen, die richtigen Akzente zu setzen und auf das zu achten, was wirklich wichtig ist. Darüber hinaus spart die Sprachkommunikation Zeit für alle Teilnehmer und ermöglicht es Ihnen, sich auf ein bestimmtes Thema zu konzentrieren, da die Sprachkommunikation (und nicht der Chat) die Teilnahme und das Verständnis erfordert, um das Problem zu lösen.
Diskussionsprotokollierung
Es ist absolut üblich und obligatorisch, dass jeder die Besprechung von Entscheidungen mit dem Kunden in Form einer TOR aufzeichnet, die wiederholt "auf den Punkt" abgezogen und von allen interessierten Parteien vereinbart wird. Ich möchte Ihre Aufmerksamkeit darauf lenken, dass neben der offiziellen Dokumentation in der Softwareentwicklung die schriftliche Festlegung von Vereinbarungen nicht nur im Rahmen der Kommunikation "Kunde - Entwickler", sondern auch innerhalb des Unternehmens / Teams nützlich sein kann.
Wir üben die Kommunikation des Protokollierungsteams, wenn wir Lösungskonzepte und Systemfunktionen diskutieren. Da sich bei der Arbeit an einem Feature mehrere Lösungen ergeben können, aus denen eine ausgewählt werden muss, ergeben sich natürlich Fragen an das Team, die tatsächlich in Besprechungen besprochen werden.
In der Regel halten wir das Protokoll in einem Frage-Antwort-Format. Das Protokoll begründet auch, warum eine solche Lösung gewählt wurde. Es wird aufgezeichnet, wer diese Entscheidungen getroffen und wer sie koordiniert hat. Es ist jedoch wichtig zu verstehen, dass dies unser internes Dokument ist, das in unserer Arbeit verwendet wird und von nichts oder niemandem geregelt wird. Das Protokoll enthält eine Diskussion zu einem bestimmten Thema und zu einem bestimmten Datum, dh es ist erforderlich, um zu verstehen, warum bestimmte Entscheidungen getroffen oder abgelehnt wurden, welche Fragen im Allgemeinen entstanden sind und welche von ihnen geschlossen sind und welche Nachforschungen erforderlich sind eine Antwort bekommen. ... Dies ist wichtig, da es im Multitasking-Modus schwierig ist, alle diese Informationen im Kopf zu behalten. Außerdem sollten alle interessierten Teammitglieder diese Informationen kennen und darauf zugreifen können. Auch nach langer ZeitSie können dieses Protokoll erneut lesen und Antworten auf Fragen darin finden, oder Sie haben möglicherweise neue Gedanken, die auf den Antworten basieren. Oder Sie stellen erneut sicher, dass die gewählte Lösung korrekt ist.
Validierung bedeutet, die implementierte Funktionalität auf Übereinstimmung mit den Geschäftsanforderungen zu überprüfen. Vor Beginn der Funktionsprüfung führt der für das Feature verantwortliche Analyst eine Validierung durch: Er prüft, ob das Hauptszenario implementiert wurde und ob das Verhalten des Systems den Erwartungen entspricht. Dies ist eine wichtige Vorgehensweise, die unmittelbar vor der Übertragung der Funktionalität zum Testen angewendet werden muss, da es keinen Sinn macht, andere Fälle zu überprüfen, wenn das Hauptskript nicht ausgeführt wird. Zur Durchführung der Validierung wird ein Akzeptanzszenario geschrieben, das die auszuführenden Schritte und die erwartete Reaktion des Systems enthält, um letztendlich das Geschäftsproblem zu lösen, für das die Funktionalität entwickelt wurde. Im Rahmen der Validierung können zunächst das Versagen des Hauptszenarios, die Unannehmlichkeiten der Benutzeroberfläche sowie grobe Funktionsmängel festgestellt werden.Wenn das Hauptszenario ausgeführt wird, gilt die Funktion als validiert und kann zum Testen eingereicht werden. Das Testen ist bereits detaillierter, in Übereinstimmung mit Testfällen überprüft es die implementierte Funktionalität.
Präsentation neuer Funktionen
Eine andere coole Praxis ist meiner Meinung nach die Präsentation der Funktionalität, bevor Testfälle geschrieben oder eine Funktion zum Testen ausgegeben werden. Die Präsentation wird für Künstler durchgeführt, die nicht wie ihre Führungskräfte in den Kontext eingetaucht sind, weil sie nicht an den Phasen der Ausarbeitung der Lösung teilgenommen haben. In der Regel handelt es sich hierbei um eine Kurzgeschichte darüber, welche grundlegenden und alternativen Szenarien zur Problemlösung implementiert sind, welche Einstellungen im Produkt vorgenommen werden müssen, welche technologischen Merkmale diese Lösung aufweist und welche Einschränkungen bestehen. Infolgedessen wird ein allgemeines Verständnis der neuen Funktionen des Produkts gebildet und eine Reihe von Fragen, die sich für eine Person ergeben können, die nicht in den Kontext eingetaucht ist, werden entfernt.
Nach dem Testen der Funktionalität führen wir vor der offiziellen Veröffentlichung der technischen Version eine Präsentation und Demonstration der neuen Funktionalität für die Mitarbeiter der Abteilungen durch, die das Produkt beim Kunden implementieren. Dies ermöglicht es, Feedback zu erhalten, vorläufige Merkmale und Einschränkungen festzulegen und die Weiterentwicklung der Funktionalität anzukündigen. Es ist wichtig, dass jeder ein gemeinsames Verständnis der neuen Funktionalität hat und keine falschen Erwartungen hat.
Oben habe ich eine kleine Liste von Praktiken beschrieben, die meine Kollegen und ich in unserer Arbeit anwenden. Ich finde sie nützlich, deshalb teile ich sie und möchte Ihnen empfehlen, einen Prozess für die Arbeit mit Anforderungen unter Verwendung dieser Praktiken zu erstellen. In den nächsten Artikeln planen wir, über den wesentlichen Teil der Arbeit mit Anforderungen zu sprechen - genauer darüber, welche Praktiken wir verwenden, um die Bedürfnisse / Probleme von Kunden zu identifizieren und Lösungen zu formulieren, die diese vollständig abdecken.
Wenn Sie Fragen haben oder Ihre Erfahrungen teilen möchten, hinterlassen Sie bitte Ihre Kommentare.
Verfasser: Venera Abbyasova AbbyasovaVenera
* Alle Bilder für den Artikel stammen aus dem Open Access im Internet.