Zukunft
Nicht ohne Relevanz ist für Anwender die Zukunft des eingesetzten Programms. Shareholder wird in meiner Freizeit vorangetrieben, aus Spaß und Experimentierfreude an der Entwicklung und an der Börse. Hintergrund bei der Arbeit ist immer die eigene persönliche Nutzung des Systems. Dies steht dabei aus meiner Sicht nicht im Widerspruch zur kostenpflichtigen Bereitstellung des Programmpaketes, da Änderungswünsche von Anwendern eingearbeitet, Support geleistet und eine Basisinfrastruktur für Website, Softwarelizenzen und Betrieb finanziert wird. Jede verkaufte Lizenz bestätigt mich dabei, indem was ich tue und motiviert mich weiter zu machen. Einen komplett idealistischen Ansatz fahre ich damit nicht.
Shareholder ist in der Entwicklung vollständig unabhängig von wirtschaftlichen Entwicklungen eines Geschäftsmodells/-betriebes, da es unter dem Motto "Hobby" läuft. Die Entwicklung ist damit allein abhängig von meiner Zeit und Motivation für das Projekt. Zurzeit sind es dennoch mehr als 10 Jahre (ab 1999), so dass hier eine gewisse Kontinuität auch in der Zukunft vorausgesetzt werden kann.
Weiterentwicklungs-Leitlinien
Hinter einer Entwicklung eines Systems sollten Grundideen stehen, so dass Entwicklungen zielgerichtet forciert werden können. Die nachfolgende Mindmap zeigt die kommenden Entwicklungsschwerpunkte der kommenden Monate:
Aktuellste Projektplanung
Die zur Zeit eingeplanten Tasks innerhalb der kommenden Monate sind im Issue-Tracking festgehalten und nachfolgend mit dem aktuellsten Planungsstand gezeigt oder mit allen Details hier: Aktuellste Projektplanung von Heute. Neue Tasks werden über Shareholder oder über Mail an issues@shareholder24.de eingetragen.
Grundsätzliches Projektvorgehen
SCUM-Verfahren mittels JIRA/Greenhoopper, d.h. mittels Kundenstories und -priorisierung und kleinen Release-Zyklen. Die Release-Zyklen sind auf 1 Monat abgesteckt, wobei Bug-Fixe auch auf Tagesbasis jederzeit verfügbar gemacht werden.
Priorisierungen
Die Weiterentwicklung wird grundsätzlich durch Anwender-Stories bestimmt, d.h. Anfragen die zu Shareholder R/2 gestellt worden sind. Die hierfür möglichen Klassifizierungen sind immer "Bug" oder "Verbesserung/Neue Funktion". Die Stories werden in Release geplant, die so transparent planbar sind.
Die Priorisierung von Stories erfolgt zur Zeit nur von mir selbst aufgrund von "geschätzter Relevanz" für Neukunden und Bestandskunden. Es ist angestrebt bis Ende 2009 ein Voting-Mechanismus für das Planungstool zu integrieren. Zur Zeit verhindern zu hohe Lizenzkosten eine entsprechende Nutzung.