Wie genau sollte ein Softwareprodukt definiert sein, bevor mit dem Code begonnen wird?

Ich wollte wissen, wie gut die Leute ein Softwareprodukt im Allgemeinen definieren, bevor sie mit dem Programmieren beginnen, und wie gut es für sie funktioniert hat. Ich beziehe mich auf das Definieren von Anwendungsfällen, das Analysieren von Risiken, das Zeichnen von Klassendiagrammen usw.

Ich weiß, dass es eine gute Idee ist, eine hinreichende Vorstellung davon zu haben, wie das Endprodukt aussehen wird, um Risiken in Zukunft zu vermeiden, aber es ist auch wichtig, ein Produkt nicht so genau zu definieren, dass es sich nur schwer anpassen lässt Veränderung.

Andere spezifischere Fragen wären wahrscheinlich:

1. Wie viel Prozent der Zeit eines Projekts wird normalerweise in der Planungsphase vor der Entwicklung aufgewendet?

2. Haben Sie bestimmte messbare Kriterien, die Sie zu erfüllen versuchen, bevor Sie mit dem Code beginnen, oder ist das eher eine Darmsache?

3. Stellen Sie alle Klassen grafisch dar, bevor Sie mit dem Code beginnen, oder wird hauptsächlich versucht, von Anfang an ein dynamisches Design zu erstellen, in der Erwartung, dass sich die Dinge ändern werden?

Jede Erfahrung, die Sie bereit sind, zu teilen, wäre fantastisch!

Die wörtliche Antwort auf "Wie gut definiert?" ist

Gut genug definiert, dass Sie loslegen können.

Gut genug definiert, dass Sie einen anfänglichen Arbeitsumfang identifizieren können (für ein anfängliches Konzept). Dies ist gerade genug, um Änderungen zu identifizieren, die unweigerlich eintreten werden.

Gut genug definiert, dass Sie die Sprints priorisieren können.

Ich beziehe mich auf die Definition von Anwendungsfällen,

Immer hilfsbereit Aber nicht alle . Sie müssen die wichtigsten Anwendungsfälle zuerst priorisieren und behandeln. Andere Anwendungsfälle werden in späteren Versionen behandelt. Einige Anwendungsfälle haben eine so niedrige Priorität, dass sie niemals abgeschlossen werden.

Risiko analysieren,

Im Allgemeinen eine Zeitverschwendung.

Zeichnen von Klassendiagrammen usw.

Wenn es hilft.

Wie viel Prozent der Zeit eines Projekts wird normalerweise in der Planungsphase vor der Entwicklung aufgewendet?

Es ist sehr unterschiedlich. Kaufen Sie ein gutes Buch wie Software Engineering Economics, um "maßgebliche" Zahlen zu erhalten.

Haben Sie bestimmte messbare Kriterien, die Sie zu erfüllen versuchen, bevor Sie mit dem Code beginnen, oder ist das eher eine Darmsache?

"messbar". Das ist fast unmöglich zu definieren.

"Darm". Schlechte Politik.

Das Problem ist "Verstehst du, was du tust?"

Es ist keine gute Sache. Es ist eine Ja / Nein-Frage.

Es ist nicht "messbar", da es nur eine Ja / Nein-Frage ist.

Außerdem müssen Sie Prioritäten setzen. Du machst nicht alles. Gerade genug für die ersten Sprints.

Stellen Sie alle Klassen grafisch dar, bevor Sie mit dem Code beginnen, oder wird hauptsächlich versucht, von Anfang an ein dynamisches Design zu erstellen, in der Erwartung, dass sich die Dinge ändern werden?

Sie können nicht alles im Voraus wissen.

Versuche es nicht.

Wenn sich Ihr Kunde als Mitglied des Projektteams aktiv dem Projekt anschließt, der den Entwicklern für Fragen zur Verfügung steht und schnelle Entscheidungen über die Funktionalität trifft. Dann könnte die Spezifikation weniger detailliert sein.

Wenn Ihr Kunde weit weg ist und über einen längeren Zeitraum kein Feedback mehr erhalten kann, sollte Ihre Spezifikation sehr detailliert sein.

In unserem Unternehmen erstellen wir User Stories und spielen Planning Poker mit den Entwicklern des Projekts. Das gibt uns einen angemessenen Hinweis auf die Stunden, die für eine User Story aufgewendet werden müssen.

Wie genau das Projekt definiert sein muss, reicht aus, um Ihnen den Einstieg in die nächsten zwei Wochen zu erleichtern.

Als Scrum Master würde ich einfach sagen, dass Sie Brutto-Features Ihres Produkts in einer Excel-Tabelle oder anderswo definieren müssen, um nur Ihre Features im Auge zu behalten. Das Erstellen von User Stories hilft beim Überlegen, welche Funktion Sie als Nächstes benötigen. Priorisieren Sie sie dann: Das wichtigste oder zwingende Merkmal nach oben und das Wenigste nach unten.

Nachdem Sie einige der wichtigsten Funktionen aufgelistet haben, wählen Sie die Funktionen aus, die Sie nach zwei Wochen oder nach einem Monat entwickeln können. Zerlegen Sie dann diese ausgewählte Funktion, damit Sie in wenigen Schritten mit dem Codieren beginnen können.

Während des Codierens werden Sie sicherlich an andere Elemente denken, die entwickelt werden müssen, um Ihre ausgewählten Features in den Status "Fertig" zu versetzen. Fertig bedeutet, dass Sie nichts mehr zu tun haben, das heißt, das Testen, Codieren, Zusammenbauen und Dokumentieren ist abgeschlossen!

Die Liste der von Ihnen ausgewählten Features kann jederzeit erweitert werden, solange Sie das Ziel erreichen. Das heißt, Sie können alles entwickeln, was Sie für den angegebenen Zeitraum angekündigt haben.

Kurz gesagt, nichts muss perfekt sein. Bringen Sie einige Ideen ein, tauschen Sie sie mit Ihren Kameraden aus und prüfen Sie, ob das Geschriebene sinnvoll ist, um die geforderten Produktanforderungen zu erfüllen. Wenn ja, dann bist du dabei! Um dies zu verdeutlichen, werde ich ein einfaches Produkt für das Kundenmanagement verwenden. Was wird benötigt?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

So einfach könnte Ihr erster Entwurf sein! Dann können wir sehen, dass Sicherheit ein wichtiger Teil unseres Systems ist. Ist es wichtig genug, um die höchste Priorität zu erreichen (J / N)? Dies hängt von den Anforderungen ab, die Sie erfüllen müssen. Nehmen wir an, das Kundenmanagement ist hier das Wichtigste. Im nächsten Sprint müssen wir also in der Lage sein, Kunden auf einfache, aber akzeptable Weise zu verwalten. Was ist Kundenmanagement?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Dies zeigt bereits genügend Funktionen, um mit der Entwicklung der Anwendung beginnen zu können. Wenn Ihre Programmierer weitere Anweisungen benötigen, kann möglicherweise ein Entwickler, der mit Klassendiagrammen vertraut ist, die Customer-Klasse und ihre Eigenschaften und Methoden entwerfen! Aber soweit es mich betrifft, hätte ich mit den wenigen, die ich geschrieben habe, genug, um anzufangen. Einige Funktionen können währenddessen hinzugefügt oder geändert werden. Wichtig ist, dass Sie sich auf das konzentrieren, was Sie als erledigt bezeichnet haben. In unserem Beispiel ist es die Sache mit dem Kundenmanagement. Wir müssen uns ab sofort nicht mehr um die Benutzerauthentifizierung kümmern. Dies wird später im nächsten Sprint geschehen.

Ich hoffe das hilft! =)

Was für mich großartig funktioniert, ist, dass die Funktionalität "ziemlich gut" spezifiziert ist und die Softwarearchitektur nur sehr schlecht spezifiziert ist.

Damit ich anfangen kann zu arbeiten, muss ich wissen, worauf ich hinarbeite. Es funktioniert bei mir nicht, wenn ich nur die Bedürfnisse des Kunden verstehe. Selbst wenn ich ein Tool für meinen eigenen Gebrauch schreibe, zeichne ich die Bildschirme, beschreibe die Funktionalität, was jede Schaltfläche macht, alles. Sonst finde ich, dass ich nicht anfangen kann.

Andererseits habe ich es aufgegeben, wirklich genau herauszufinden, wie ich den Code entwickeln werde. Vielleicht ist das die schlechteste Übung, aber sie funktioniert bei mir. Möglicherweise definiere ich eine Reihe von Datenbanktabellen, die ich erstellen möchte, aber nicht die Spalten in jeder einzelnen. Ich denke vielleicht darüber nach, welche Objekte und Klassen ich brauche, aber ich zeichne definitiv keine Diagramme.

Hölle, manchmal weiß ich nicht einmal, wie ich es richtig machen soll, bis ich es falsch gemacht habe. Ich baue es einmal, reiße es ab und mache es wieder, jetzt wo ich weiß wie. An dieser Stelle kann ich eine ziemlich detaillierte Roadmap zeichnen und neu starten.

Welche Sprache und Methodik verwenden Sie?

Einige Sprachen, wie Java und C ++, erfordern mehr Anfangsstruktur als Sprachen wie Common Lisp oder Python (C ++ mehr als Java, da das Refactoring in Java einfacher ist). Leo Brodie (ich denke in "Thinking Forth") gab zwei Ratschläge, wann Sie mit dem Codieren beginnen sollten: Früher, als Sie sich in Forth wohl fühlen, später, als Sie es in einer anderen Sprache wollen.

Die Wasserfallmethode (insbesondere, wenn das frühe Design als Ergebnis verfügbar ist) erfordert mehr Vorarbeit als agiles Arbeiten (auch wenn Sie die frühzeitige Planung in agilen Methoden nicht vernachlässigen möchten). Durch eine gute Anzahl automatisierter Tests ist es sicherer, größere Dinge zu ändern, und Sie kommen mit weniger Vorarbeit aus.

Dies hängt auch von den einzelnen Personen und ihrer Vertrautheit mit der Art der zu erstellenden Software ab. Zu einem Zeitpunkt, als ich hauptsächlich CRUD-Apps ausführte, konnte ich ein ganzes Programm schreiben, beginnend mit ein paar Spezifikationen und einem 3 "x 5" großen Stück leerem Notizpapier. Ich kann das Zeug, das ich jetzt schreibe, nicht so schreiben.

Zwei nützliche Begriffe sind hier MVP (Minimum Viable Product) und MMF (Minimum Marketable Feature). Ein MMF ist die kleinste Version einer Funktion, die geschäftlichen Nutzen bringt. Ein MVP ist der wenige MMF, der als Produkt rentabel ist. Wenn Sie ein Projekt starten, identifizieren Sie am besten die MMFs und MVPs und starten Sie von dort aus.

Geben Sie Ihr Produkt frei, sobald es funktionsfähig ist, und verbessern Sie es dann schrittweise weiter.