Allgemeine Entwicklungsinfos

Tryton ist richtige OpenSource Software die auf öffentlichen Technologien basiert. Das hat den Vorteil, dass verschiedene Personen und Firmen sich engagieren können und dies auch sehr intensiv tun. Die Entwickler sprechen sich gemeinsam ab, kontrollieren Code gegenseitig helfen sich gegenseitig aus und geben sich sogar gegenseitig Aufträge, wenn der andere mit etwas Bestimmten schon Erfahrung hat und etwas gut kann. Mit dem Kernteam zusammen werden die Entwicklungen koordiniert.

Hier die Seite, wo neue Idee und aktuelle Entwicklungen diskutiert werden: https://discuss.tryton.org/

Agile Entwicklung / rollende Planung

Das Projekt passt sich laufend neuen Situationen an, was zu konzeptionellen, technischen und inhaltlichen Anpassungen und Neuausrichtungen führen kann. Das Resultat kann sich also durchaus von der einstmaligen Idee unterscheiden. Das hat auch Folgen für Sie:

  • Wir brauchen von Ihnen eine grosse Flexibilität um mit neuen Rahmenbedingungen konstruktiv umgehen zu können.
  • Wir brauchen von Ihnen ein Verständnis, dass Umplanungen zu Terminverschiebungen führt. Planen Sie z.B. keine terminbezogenen Folgeprojekte in Ihrer Firma.

Arbeiten

Hier geht es um komplexere Entwicklungsprojekte mit folgenden Arbeitsbereichen (prozentuale Anteile nur grob geschätzt).

  • Analyse der Kundenanforderungen (~ 10%)
  • Anforderungen beschreiben und gegenprüfen (~ 10%)
  • Programmierungskonzept erstellen (~ 50%)
  • Programmierung (~ 30%)

Komplexität und "Unterwartetes"

Die Erweiterung einer Business Software kann je nach Wunsch jedoch weitreichende Folgen haben. Nicht selten schaut der Wunsch relativ einfach aus, aber die Umsetzung ist es vielleicht nicht. Mögliche Gründe sind:

  • Der Eingriff hat strukturelle Folgen auf andere Module.
  • Die neue Funktion muss Resultate von anderen Modulen abholen und verarbeiten.
  • Die von Ihnen gewünschte Ausgabe der Daten muss speziell aufbereitet werden.
  • Know-How fehlt.
  • Eine spezielle Art der Bedienung ist gewünscht.
  • Es müssen mehrere neuen Module gebaut werden.

Während des Projektes können verschiedene Probleme auftreten. Man muss dann einen kühlen Kopf behalten und oft "kurz einen Schritt zurück" machen, bis es wieder im geplanten Rahmen weiter geht.

  • Erwartungen der Kundschaft wurden nicht kommuniziert oder jemand hat etwas "vergessen".
  • Die Entwickler haben sich verplant oder eine Funktion ist nicht so umsetzbar wie vorgesehen.
  • Code von Dritten steht nicht oder nicht in ausreichender Qualität zur Verfügung.
  • Entwickler fallen aus (geplante Ferien, Krankheit, Umweltereignisse wie im Sommer 2021, etc.)
  • Regulatorische Änderungen in Ländern zwingen uns zu umgehenden Anpassungen und Projekte müssen daher pausieren.

Zeit, Qualität und Kosten

Das Dilemma bei Entwicklungen besteht aus "Zeit", "Qualität" und "Kosten"

  • Will man schnell was daherprogrammieren (quick and dirty), so leidet die Qualität und das Resultat wird in der Zukunft immer wieder neuen Ärger und Folgekosten hervorbringen.
  • Will man schnell etwas entwickeln, so kann man das Entwicklungsteam vergrössern, was aber zu überproportional steigenden Kosten führt, da die Koordinationsaufwände, um das Team zusammenzuhalten, massiv zunehmen.
  • Bei grösseren Entwicklungsteams steigt die Fehlerquote überproportional.
  • Somit entwickelt man besser in Etappen und in unabhängigen Modulen, damit gegebenenfalls mehrere Entwicklungsteams parallel (asynchron) arbeiten können.

1. Analyse

Als ersten Schritt schauen wir, was Sie wollen, falls Sie das nicht schon mit einem externen Spezialisten gemacht haben. Falls Sie schon ein "Lastenheft" haben, ist das super und hilft uns sehr. Wir treffen diesen Fall aber selten an. Also machen wir folgendes.

  • Prüfen Ihres betrieblichen Hauptprozesses.
  • Notieren der "Features", die Sie brauchen.

Wir gehen so vor, dass wir im Voraus Ihre Wünsche zusammenstellen. Dabei machen wir

  • Mockups (Bilder, wie das Resultat aussehen könnte).
  • Einen Beschrieb Ihrer Wünsche.

Falls später neue Anforderungen dazu kommen, was oft der Fall ist, so schätzen wir die Zusatzkosten und lassen einen solchen "Zusatzauftrag" von Ihnen absegnen. Dabei passt sich in der Regel auch der Terminplan an, was nicht selten "übersehen" geht.

2. Konzeption

Aus der Analysephase ergibt sich eine Feature Liste.

  • Wir gehen nun alle Features und Funktionen und Felder durch.
  • Dabei schauen wir, welche Module es schon gibt und was wir ohne viel Aufwand abdecken können.
  • Die kritischen und aufwändigen Features versuchen wir zu erkennen (was nicht immer gelingt) und schauen sie im Detail an.
  • Für weitere neue Module schätzen wir den Entwicklungsaufwand.

Grober Etappenplan

Sie sagen uns dann, welche Funktionen Sie brauchen um starten zu können.

  • Basierend auf dem dafür nötigen Entwicklungsaufwand schätzen wir die Entwicklungskosten.
  • Ein einhaltbarer Terminplan ist nicht möglich, aber es wird sicher schon klarer, mit was für einer Projektzeit etwa gerechnet werden muss.

Termine

Zur Terminierung kann man ganz generell sagen, dass diese ein grosses Problem ist in der Softwareentwicklung sind. Die Projektbeteiligten jedwelcher Couleur überschätzen sich, wie die Entwicklungsprojekte der letzten Jahre gezeigt haben. Niemand mach das extra oder in böser Absicht, sondern jeder geht von der idealen Welt aus und will das Resultat "effizient und schnell auf den Boden bringen".

  • Gehen von keinen starren Terminvoraussagen aus. Sie sind illusorisch.
  • Brechen Sie grosse Projekte in kleine Teile und nehmen Sie kontinuierlich kleine neue Entwicklungsschritte in Betrieb.

Kosten nach Aufwand

Standardmässig machen wir ein Angebot mit einer groben Kostenschätzung und arbeiten dann jedoch nach Aufwand. Die effektiven Kosten können somit stark abweichen, je nach Situation.

Kosten pauschal

Was wir eigentlich nie machen sind Pauschal-Entwicklungen. Solche Konditionen müssen speziell in der Offerte erwähnt sein. Bezüglich "nötigen" oder "selbstverständlichen" Funktionen gibt es in solchen Projekten immer wieder grosse Diskussionen. Wir möchten hier klar erwähnen, dass wir nur jenes als "beinhaltend" klassifizieren, was bei Beauftragung schriftlich "in der Offerte" definiert war. Falls etwas hinzu kommt, so müssen Sie woanders etwas "Gleichwertiges" reduzieren. Geht das nicht, so definieren wir mit Ihnen die Zusatzkosten.

3. Umsetzung

Nachdem mit vernünftigem Detaillierungsgrad geklärt ist, was es braucht, starten wir mit der Umsetzung.

Anzahlung

Der Kunde begleicht die Anzahlung. Das Entwicklungskonzept wird erstellt.

  • Die Entwicklungen werden in kleine überschaubare und abgrenzbare "Häppchen" unterteilt.
  • Daraus entstehen die Anleitungen für die Programmierungsarbeiten.
  • Die Programmierer werden reserviert.

Entwicklungsumgebung

Der Staging Server wird erstellt.

  • Die Basismodule werden aktiviert.
  • Die Grundkonfiguration wird gemacht.
  • Der Zugriff für Entwickler und Kunde wird bereitgestellt.
  • Die Kundschaft erstellt Demodaten.

Entwicklungsschritt (Sprint)

Die Entwicklungsarbeiten starten.

Sprints Planung

Die nächsten 3 bis 4 Sprints werden terminlich und inhaltlich geplant.

  • Mehrere Entwicklungshäppchen werden genommen und in "einem Rutsch" (Sprint) programmiert.
  • Der Sprint dauert 2 Wochen.
  • Danach werden die nächsten Sprints allenfalls angepasst.

Umsetzung des aktuellen Sprints

Der Sprint wird abgearbeitet

  • Nach 2 Wochen zeigen wir das Resultat auf dem Staging Server. Dabei ist in der Regel eine Person aus dem Entwicklungsteam und die verantwortliche Person des Kunden (Product Owner), allenfalls unterstützt mit weiteren Personen des Kunden.
  • Das Resultat wird durch das tryton.cloud Team "mit sinnvollem Aufwand" geprüft. Wenn die Funktion ok ist, wird sie freigegeben und das Arbeitspaket auf die Seite gelegt. Falls es sich um eine grössere Sache handelt, prüft auch die Kundschaft schon auf dem Staging Server.
  • Das Resultat wird auf den operativen Server im Rahmen einer neuen Release-Nummer aufgespielt. Dies passiert in der Regel im gleichen Sprint-Zeitfenster.
  • Bei gemeinsam genutzten Servern (was die Regel ist), wird die Kundschaft punktuell über die bearbeiteten Arbeitspakete informiert. Hat die Kundschaft einen eigenen Server, so folgt Kontrolle und Aufschaltung nach gegenseitiger Absprache.

Weiter geht es mit dem nächsten Sprint mit dem gleichen Vorgehen.

Nacharbeiten

Mit der Inbetriebnahme eines neuen Softwaremoduls ist die Arbeit aber oft noch nicht abschliessend gemacht.

  • Vielleicht müssen Ihre Datenbank-Daten erweitert werden, damit die neuen Funktionen auch eingesetzt werden können.
  • Vielleicht braucht es eine Dokumentation oder Schulung für Ihre Mitarbeiterinnen und Mitarbeiter.
  • Es kommen Abhängigkeiten oder Probleme mit anderen Modulen Ihrer Datenbank an den Tag, die angegangen werden müssen.
  • Es kommen andere Probleme zum Vorschein. Auch diese gehen wir nach Dringlichkeit und verfügbaren Ressourcen mit Ihnen an.
  • Es werden neue Funktionen gewünscht und wir erstellen mit Ihnen daraus ein Zusatzprojekt.