Ein agiles Projekt mit dem RedSpark Framework von A bis Z

Agil mit Stil
Kommentare

Technisch wurde das RedSpark Framework bereits in einer der letzten Ausgaben vorgestellt. Es wird Zeit, das System dort zu beobachten, wo es hingehört: im Projekt. Beginnend mit der Projektanbahnung über Kalkulation und Konzeption liegt der Schwerpunkt naturgemäß auf der technischen Umsetzung der Projektanforderungen mit agilen Methoden. Als Abschluss kommen aber auch Aspekte wie Qualitätssicherung, Service und natürlich Upgrades im laufenden Betrieb der Plattform nicht zu kurz.

Morgens halb zehn in Deutschland: „Bin ich da richtig bei Kuborgh? Ich hätte gerne eine Webseite, nichts Besonderes, nur ein paar Seiten und einen kleinen Blog. Ein paar Designideen haben wir auch schon. Was kostet denn so etwas?“ So oder so ähnlich beginnt es häufig – das nächste Projekt. Dieser Artikel richtet sich an Projektleiter und zeigt die Nutzung des RedSpark Frameworks im Projektzyklus. Alle Phasen, speziell die Umsetzungsphase werden nicht vorrangig technisch, sondern eher aus Sicht eines (agilen) Entwicklungsprozesses betrachtet. Dabei gilt die Betrachtung nicht einem speziellen Prozess, sondern eher der Nutzbarkeit allgemeiner agiler Prinzipien. Die meisten Ansätze entsprechen entweder eigenen Erfahrungen im Projektgeschäft oder den Erfahrungen aus der RedSpark-Community. Jeder Projektleiter wird sich hoffentlich an der einen oder anderen Stelle des Artikels mit seinen Aufgaben und vor allem den passenden Lösungen wiederfinden.

Anbahnungsphase

An dieser Stelle gilt es zunächst, eine Entscheidung für eine passende Technologie zu treffen. Da sich dieser Artikel mit dem RedSpark Framework beschäftigt, ist diese Entscheidung eigentlich schon gefallen, aber schauen wir dennoch zunächst, für welche Projekte sich das RedSpark Framework unserer Meinung nach eignet:

  • Einfache CMS-Seiten, die durch die Kunden selbst gepflegt werden sollen.
  • Individualentwicklungen auf Basis des Zend Frameworks, die ein Backend, ein CMS und viele weitere vorgefertigte Funktionen benötigen.
  • Backends für Flash- und mobile Anwendungen, die z. B. per JSON angebunden werden.
  • Eigene Plattformen, die vom Zend Framework sowie den Funktionen und Erweiterungen des RedSpark Frameworks profitieren und laufend an neue Technologien und Entwicklungen angepasst werden müssen.
  • Projekte, die später entweder komplett oder teilweise von Zend-Framework-Entwicklern beim Kunden betreut werden sollen.

Die in der Einleitung vom Kunden genannte Anforderung ist letztlich eine einfache CMS-Seite mit zusätzlichem Blog; wir werden später sehen, dass das RedSpark Framework dafür sehr gut geeignet ist. Aber erst einmal einen Schritt zurück. Worum geht es überhaupt ganz genau? Schließlich erwartet der Kunde von uns ein Angebot für eine bislang eher vage formulierte Anforderung. Wir nehmen den Kunden erst mal ein wenig „an die Hand“ und versuchen im Gespräch, einige weitere Eckpunkte zu fixieren. Am Ende erhalten wir das so genannte „Briefing“, das wir ausformulieren und uns nach einer Feedbackschleife bestätigen lassen. An dieser Stelle gibt es natürlich zahlreiche weitere Möglichkeiten, z. B. Workshops. Um die Anforderungen weiter zu spezifizieren, gehen wir aber der Einfachheit halber davon aus, dass wir inzwischen ein klares Briefing in Händen halten. Als nächsten Schritt werden einige Grundanforderungen zur Auswahl des Systems abgestimmt:

  • Open-Source-System
  • Einfache Bedienung des CMS und der Erweiterungen
  • Nötige Erweiterungen: Blog
  • Komplett individuelles Design

Für die Zukunft gerne auch:

  • Ausgereiftes CMS-System mit Option auf Erweiterung um neue Sprachen und Freigabeworkflow
  • Jederzeit mögliche Erweiterbarkeit einzelner Systemkomponenten (bevorzugt auf Zend-Framework-Basis)
  • Servicevertrag für Pflege und Support des Systems

Nun sind diese Eckpunkte natürlich auf das RedSpark Framework abgestimmt, allerdings treffen viele dieser Anforderungen auf zahlreiche Projekte so oder in sehr ähnlicher Form zu.

Angebot/Preis

Die Entscheidung, das Projekt mit dem RedSpark Framework anzubieten, ist also gefallen. Als Nächstes geht es an die Kalkulation des Preises. Da die komplette Basis des RedSpark Frameworks kostenlos zum Download bereit steht, fallen als Lizenz lediglich die Preise für die Apps aus dem RedSpark Store (Kasten: „RedSpark Store“, Abb. 1) an, in diesem Fall also lediglich RedSpark-Blog. Da die Nutzung aller Apps für Entwickler und nicht kommerzielle Produkte frei ist, steht einem unverbindlichen Download bereits in der Angebotsphase nichts im Weg.

RedSpark Store

Der RedSpark Store stellt unter [1] verschiedene Apps zum Download bereit. Die Apps sind teilweise kostenlos, teilweise kostenpflichtig und mit einer derzeitigen Preisspanne von 19,- bis 199,- Euro in einem Bereich, der bei den meisten Individualprojekten das Budget nicht über die Maßen in die Höhe treiben sollte. Die Nutzung als Entwickler und für nicht kommerzielle Projekte ist zudem in jedem Fall kostenlos.

Monetarisierung

Der Store ist vorrangig für Communitymitglieder als Möglichkeit zur Monetarisierung der eigenen Entwicklungen gedacht. Jeder kann seine Apps – mit entweder Templates, Toolboxen, CMS-Assets, Funktionsmodulen, Library-Erweiterungen oder verschiedenen Kombinationen davon – bei der Kuborgh GmbH einreichen. Nach einer Prüfung, einem Code- und Dokumentations-Review und einer hohen Testabdeckung durch Unit- oder Akzeptanztests werden die Apps im Store zur Verfügung gestellt. Die Aufteilung der Erlöse erfolgt nach dem mittlerweile üblichen 70/30-Prozent- Split. Der Store stellt so sicher für viele Entwicklerteams eine einfache Möglichkeit zur „Versilberung“ ihrer Entwicklungen dar.

Service Level Agreement

Für in dieser Form geprüfte Apps ist es zusätzlich möglich, die Service Level Agreements für RedSpark-Projekte durch die Kuborgh GmbH anbieten zu lassen. Speziell Freelancer können damit für RedSpark-Projekte das Dilemma lösen, Kundenwünsche erfüllen zu wollen, aber nicht alleine für einen Servicevertrag bereit stehen zu können. Auf diese Weise können sie dem Kunden eine komplette Dienstleistung anbieten, der selbstverständlich weiterhin Kunde des Entwicklers bleibt.

Abb. 1: RedSpark StoreAbb. 1: RedSpark Store (Vergrößern)

Danach werden die weiteren Angebotsbestandteile kalkuliert. Der komplette, denkbare Prozess wäre in unserem Fall vielleicht der Folgende, wobei einige Schritte unter Umständen nicht für jedes Projekt nötig sein werden:

  • Konzepterstellung und -abstimmung (optional)
  • Designerstellung und -abstimmung
  • HTML-Umsetzung und Template-Erstellung des Designs als RedSpark Template
  • Einrichtung der App
  • Programmierung der individuell zu entwickelnden Features inkl. möglicher Unit Tests
  • Deployment und Installation
  • CMS-Einrichtung und -Erstellung der Seitenvorlagen (Seitenvorlagen optional)
  • Textpflege der vom Kunden gelieferten Texte
  • Handbuch und Dokumentation (optional)
  • Projektmanagement sowie gegebenenfalls technisches Projektmanagement

Viele dieser Angebotsbestandteile können bereits mit ein wenig Erfahrung im Umgang mit RedSpark-Projekten gut geschätzt werden, da Dinge wie Design/HTML, aber auch Vorlagenerstellung und Installation bei den meisten Projekten vergleichbar sind. Anders ist es bei der Abschätzung von Individualfunktionen. Bei diesen bietet das RedSpark Framework die App RedSparkFeatureList [2], die ein XML-Format zur Definition von Featurelisten vorgibt, das später direkt im Front- oder Backend auch zur Dokumentation der erbrachten Leistung, aber auch des Projektforschritts eingesetzt werden kann. In der Regel ist es empfehlenswert, die Featurelisten in grober Form bereits für die Angebotskalkulation vorzubereiten. Der Kunde findet so seine im Briefing geforderten Funktionen bereits in einer ersten Testinstallation auf der Seite wieder. Wir richten häufig die gerenderte Featureliste (Abb. 2 und Beispiel unter [3]) zunächst als „Startseite“ des Projekts ein, sodass bei jedem Besuch der Entwicklungsseite direkt der aktuelle Fortschritt sichtbar ist. Alles in allem sollte es auf diese Art und Weise möglich sein, eine solide Projektkalkulation abzugeben und so hoffentlich den Zuschlag zu erhalten.

Abb. 2: Featureliste im RedSpark BackendAbb. 2: Featureliste im RedSpark Backend (Vergrößern)

Nach Erhalt des Zuschlags erfolgt idealerweise ein gemeinsames Kickoff, in dem das Projekt grob im Team vorgestellt und die aus dem Briefing abzuleitenden Aufgabenbereiche umrissen werden. Im Sinne von Scrum [4] entsteht die erste Version des Product Backlog. Nach dem Kickoff beginnen häufig zunächst die Arbeiten im Bereich Konzeption, Design und natürlich Projektmanagement.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -