Woher wissen Sie, wann Sie das Hinzufügen von Funktionen beenden müssen?


16

Vor einiger Zeit habe ich ein sehr kleines Python-Skript geschrieben, das in regelmäßigen Abständen einen XML-Feed auf neue Einträge überprüft und den Benutzer auf neue Einträge aufmerksam gemacht, wenn diese vorhanden sind. Ich habe dies für mich selbst geschrieben, es war also im Wesentlichen ein konsolenbasiertes Programm, das jeder, der mit einer Konsolenschnittstelle vertraut ist, hätte verwenden können.

Nach einer Weile entschied ich, dass es für andere Menschen von größerem Nutzen sein könnte und begann, es aufzuräumen, Eingaben zu bereinigen, Fehler zu beseitigen. Mir fiel auf, dass ich, weil ich das Skript geschrieben hatte, wusste, wie man es effizient, genau usw. verwendet. Andere konnten es nicht, also begann ich, eine GUI hinzuzufügen. Dies begann als einfaches Menü und wurde dann zu einer umfassenderen Benutzeroberfläche mit einer Benutzeroberfläche und einem Optionsmenü erweitert. Ich habe dann gespeicherte Benutzereinstellungen und auch Speicher für zuvor durchsuchte XML-Feeds hinzugefügt, um die wiederholte Suche zu beschleunigen.

Ich habe die Protokollierung hinzugefügt, um das Debuggen der Anwendung für den Fall eines Fehlers zu unterstützen, die Anwendung auf die neueste verfügbare stabile Python-Codebasis für die von mir gewählte Plattform gebracht und die Dialogfunktionen verbessert.

Ich habe meinen Code fehlerbereinigt und klar kommentiert, und dennoch habe ich Dinge, von denen ich denke, dass sie getan werden können, um die App zu verbessern, bevor ich sie Alphatestern zur Verfügung stelle. Es ist weit entfernt von meinem ursprünglichen 20-30-Zeilen-Skript. Was ich erwartet hatte, brauchte ich nur ein oder zwei Stunden, um vom Proof-of-Concept zu einem akzeptablen Anwendungsprogramm zu gelangen. (Ich bin immer noch ein Noob, und das Zeug dauert lange, aber immer noch ...)

Woher weißt du, wann du aufhören sollst, Dinge hinzuzufügen / zu optimieren / zu reparieren und dein Baby im Freien krabbeln lassen sollst?

Antworten:


8

Wenn Sie die Frist eingehalten haben.

Wenn Sie keine Frist haben, ist dies Ihr Problem ...

So arbeite ich:

  1. Ich füge neue Funktionen / Fehler in mein Produkt-Backlog ein.
  2. Ich priorisiere den gesamten Produktbestand nach dem Geschäftswert und dem geschätzten Wert (der letzte Wert ist bei persönlichen Projekten optional).
  3. Ich teile mir selbst Arbeitszeit zu. Das Veröffentlichungsdatum ist das Ende dieser Zeit.
  4. Ich beginne mit dem allerersten in der Liste. Ich arbeite eine Zeit lang an einem Feature. Ein Feature muss vollständig sein, einschließlich der Dokumentation (am Ende eines Features kann ich das Produkt möglicherweise ausliefern).
  5. Ich nehme die nächste, bis meine zugewiesene Zeit verbraucht ist.
  6. Wenn die Zeit beim Erstellen eines Features verbraucht ist, verwerfe ich es vorübergehend.
  7. Wenn die zugewiesene Zeit verbraucht ist, nehme ich den neuesten Build und mache eine Veröffentlichung damit.
  8. Ich wiederhole den Vorgang ab Punkt 1.

Hmm, ich mag den Workflow hier sehr. Dies ist ein Hobbyprojekt, ich bin mir nicht sicher, ob ich versuchen werde, es zu monetarisieren. Es wird eher kostenlos angeboten oder als Open Source bereitgestellt.
Fearoffours

4
Im oben genannten Vorschlagsworkflow bedeutet "Wert" nicht "Geld". Sie entscheiden, was der Wert ist.

OK, das ist großartig. Ich wende das an, seit ich die Stelle heute zuvor gesehen habe. Meine Frist ist Mittwoch, 15 Uhr, und alles läuft gut! Ich bin sicherer darüber, wohin die Dinge gehen und woran ich arbeite. Ich habe (in den Kommentaren am oberen Rand des Skripts) die Dinge priorisiert, die vor dieser Veröffentlichung ausgeführt wurden, und Dinge, die bis zu einem späteren Zeitpunkt verbleiben können. Und ich schreibe die Funktion auf, an der ich gerade arbeite, um sicherzustellen, dass ich mich immer auf eine Aufgabe konzentrieren kann. Vielen Dank!
Fearoffours

3. I allocate work time to myself. The release date is the end of that time.@ Pierre 303, als du gesagt timehast, meintest du Stunden, dh nächtliche Builds? oder Zeit wie ein voller Sprint?
Kenan D

@LordCover: Zum Beispiel weise ich mir 3 Wochen (5 Tage die Woche, 8 Stunden am Tag) zu, um an dem Produkt zu arbeiten. Ich versende am Ende der 3 Wochen.

3

Erstellen Sie einen SRS- Code entsprechend den Anforderungen. Wenn Sie alle im SRS genannten Ziele erreicht haben, ist es Zeit, Ihr Produkt anzuhalten und zu testen.


Hm guter Punkt. Ich habe im Moment nichts über seinen Zweck aufgeschrieben.
Fearoffours

SRS sind gut, aber für ein Single-Man-Team bei einem persönlichen Projekt etwas übertrieben. Die Dokumentation ist gut, aber für diese Art von Projekt ist meines Erachtens noch nicht die gesamte SRS erforderlich.
Chris

@ Chris - Ein SRS ist immer eine gute Sache. Was ein persönliches Projekt ist und heute kostenlos veröffentlicht wird, ist immer noch ein kostenloses Stück Software, das von Dutzenden von Menschen geschrieben wurde. Ein gutes Beispiel dafür, warum Dokumentation wichtig ist Facebook, es war ziemlich einfacher, die Dokumentation in einem frühen Stadium zu schreiben und diese Dokumentation zu aktualisieren, als sie heute zu schreiben. Wenn Sie Ihr Design nicht aufschreiben können, erklären Sie das Design und dokumentieren Sie, wie das Feature funktioniert. Wie können Sie es dann codieren?
Ramhound

2

Kurzfristig, wenn Sie etwas haben, das zuverlässig funktioniert und nicht ausfällt. Auch wenn es nicht alles kann, was es kann , wenn Sie auf unbestimmte Zeit daran gearbeitet haben. Versand wie das Sprichwort sagt ist ein Feature . Zuverlässigkeit und eingeschränkter Funktionsumfang bieten Ihnen die Möglichkeit, die Kernfunktionalität von echten Menschen in der realen Welt zu testen. Sie werden feststellen, dass Dinge, an die Sie nie gedacht haben, Ihren Code auf eine Weise brechen, die Ihnen nie in den Sinn kommt. Je weniger Funktionen zu diesem Zeitpunkt zur Verfügung stehen, desto einfacher ist es, diese frühen Probleme zu beheben. Da die Kernfunktionalität zuverlässiger arbeitet, können Sie mit der Implementierung der anderen "nice to have" -Stoffe beginnen, mit dem Wissen, dass Ihr wichtigster und zentraler Code immer noch gut funktioniert.

Langfristig: Wenn Sie das Plug-in-System fertiggestellt und dokumentiert haben, können Ihre Benutzer (und natürlich Sie) neue Funktionen bei Bedarf schnell und einfach implementieren. Dies sollte die letzte Funktion sein, die Sie hinzufügen müssen - danach sind alle Plug-Ins vorhanden.


1

Wenn Sie sich über die Stabilität Ihrer Software sicher sind, sollten Sie eine Veröffentlichung anstreben, obwohl möglicherweise noch Funktionen ausstehen. Stabilität ist wichtiger als Funktionen. Holen Sie sich das Feedback, integrieren Sie vorhandene Funktionen und entscheiden Sie, was als Nächstes und wann geliefert werden soll!


1

Sie können ein Projekt immer und ewig pflegen.

Eine sehr gute Regel ist, dass Sie niemals Dinge hinzufügen sollten, die nicht in einem genehmigten Anwendungsfall enthalten sind. Dies stellt sicher, dass Sie nicht mit vielen Dingen enden, die schön wären, aber von niemandem benutzt werden. Durch das Genehmigen wird sichergestellt, dass andere Personen als Sie zustimmen, dass dies in Ihrem Projekt erforderlich ist.


1

Es hängt davon ab, warum Sie Funktionen hinzufügen. Fragen die Projektinhaber danach? Benutzer? QA? Programmierer?

  • Fügen Sie die Funktionen hinzu, die Sie benötigen.
  • Durchsuchen Sie wichtige Funktionen.
  • Ignoriere Funktionen, die schön sind.

Konzentrieren Sie sich auf den Zweck des Programms und konzentrieren Sie sich auf den Zweck. Funktionswünsche, die den Zweck erweitern, sollten gründlich hinterfragt werden, bevor es sich um ein Schweizer Taschenmesser handelt.


Ich mag die Idee, ein Produkt fokussiert zu halten. Ich versuche das zu tun und finde immer noch Möglichkeiten, mich selbst zu beschäftigen!
Fearoffours

2
@fearoffours, Sie können immer Wege finden, um Ihre eigene Arbeit zu verbessern. Der Punkt ist, von den Benutzern herauszufinden, wie man es besser für sie arbeiten lässt. Löse echte Hindernisse. Glatte echte raue Stellen.
Huperniketes

netter Rat in diesem Kommentar, (+1) danke!
Fearoffours

0

Ich höre nicht mehr auf, Features hinzuzufügen. Ich versuche nur, die App so schnell wie möglich herauszubekommen und txt-Dateien zu schreiben, wenn ich muss. Dann kann ich entscheiden, wann ich aufhören und wann ich an etwas anderem arbeiten soll

Es hilft auch, dass ich es mag, das Minimale zu tun, um etwas zu erledigen (ohne zu hacken).


0

Ich würde vorschlagen, Sie timebox es. Gönnen Sie sich eine Woche mitreden. Erstellen Sie eine Liste der Arbeiten, die in dieser Woche abgeschlossen werden sollen, und stellen Sie sicher, dass Sie sie zurücksetzen können, wenn Sie eine Funktion haben, die nicht abgeschlossen werden kann.

Am Ende der Woche veröffentlichen Sie es. Vorzeitig freigeben, oft freigeben.


aber was tun, wenn einige funktionen voneinander abhängig sind?
Kenan D

0

Wenn Sie etwas Zuverlässiges und Nützliches haben, lassen Sie es los. Sie müssen nicht aufhören, Features hinzuzufügen, aber wenn jemand das verwendet, was Sie da draußen haben, erhalten Sie eine viel bessere Vorstellung davon, welche Features gewünscht werden. Derzeit raten Sie.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.