![\"Zeit](\"https:\/\/kokoen.net\/wp-content\/uploads\/2020\/07\/how-to-develop-apps-300x217.jpg\")
Copyright \u00a9 www.projectcartoon.com under the Creative Commons Attribution 3.0 Unported License<\/p><\/div>\n
Am besten ist es dabei dann, keine Zeit mit endlosen Gespr\u00e4chen und Dokumenten mit vielen technischen Spezifikationen zu verschwenden. Die Anforderungen aufzuschreiben ist zwar eine gute Idee. Aber meistens nur, um das “gro\u00dfe Bild” dessen zu definieren, was die App k\u00f6nnen soll und einige spezifische W\u00fcnsche, die im Vertrag enthalten sein sollten. Es ist jedoch ineffizient, die kleinsten technischen Details auf Papier zu bringen, da es unm\u00f6glich ist, alle Bed\u00fcrfnisse, Fragen und Probleme abzusch\u00e4tzen, die die Entwickler haben k\u00f6nnten, rein von der Vorstellung, wie die App sein sollte.<\/p>\n
Stattdessen versuchen wir, einen Klick-Dummy zu bauen, um dem Kunden und uns selbst dabei zu visualisieren, was wir machen werden. Bei der Arbeit an diesem Klick-Dummy werden alle technischen Details und Anforderungen fortlaufend spezifiziert.<\/p>\n
Die Erstellung eines Klick-Dummys hilft, die Anforderungen besser zu definieren und Probleme oder Fragen zu entdecken, die ohne einen Klick-Dummy verborgen geblieben w\u00e4ren.<\/p>\n
Agil arbeiten – Definieren der einzelnen Schritte (Increments)<\/h2>\n
Die Anforderungen k\u00f6nnen und werden sich zweifelsohne \u00e4ndern. Warum sollte man sich also jetzt auf Elemente konzentrieren, die vielleicht nie programmiert werden oder – noch schlimmer – die vielleicht bald komplett neu programmiert werden? Deshalb ziehen wir es vor, agil zu arbeiten!<\/p>\n
![\"Anforderungen](\"https:\/\/kokoen.net\/wp-content\/uploads\/2020\/07\/requirements-software-300x93.gif\")
Copyright \u00a9 Andrews McMeel Syndication – dilbert.com<\/p><\/div>\n
Das Konzept einer agilen Vorgehensweise stellt die traditionelle Arbeitsweise eines Unternehmens v\u00f6llig auf den Kopf – im wahrsten Sinne des Wortes. Agile Unternehmen \u00fcbertragen die Verantwortung vom Management hin zu den Entwicklerteams. Diese Teams \u00fcbernehmen die Verantwortung f\u00fcr ihr eigenes Handeln. Das Management erh\u00e4lt eine v\u00f6llig andere Rolle. Kontrolle und F\u00fchrung werden zur Unterst\u00fctzung und Ermutigung der Mitarbeiter (Stichwort: Servant Leadership). Die Pyramide kehrt sich um. Was jetzt gebraucht wird, ist eine breite, von unten gest\u00fctzte Basis, auf der die Mitarbeiter erfolgreich arbeiten k\u00f6nnen. Klare Ziele und Richtlinien ersetzen eine kleinr\u00e4umige Planung und erm\u00f6glichen eine schnelle Reaktion auf Ver\u00e4nderungen und unerwartete Ereignisse.<\/p>\n
Die Steuerungsfunktion wird vom Team selbst \u00fcbernommen. Das Team \u00fcberwacht nicht nur den Arbeitsfortschritt, sondern versucht st\u00e4ndig, sich zu verbessern, Hindernisse zu beseitigen und die Aufgaben sinnvoll zu verteilen. Dies ist dann erfolgreich, wenn alle Teammitglieder die Ziele oder Visionen, auf die sie hinarbeiten, genau kennen. Im Idealfall haben sie sogar an der Formulierung dieser Ziele oder Visionen mitgewirkt.<\/p>\n
Diese drei Schritte f\u00fchren schnell zu mehr Agilit\u00e4t:<\/p>\n
1. Organisieren von Teilprojekten<\/h3>\n
Das Gesamtprojekt wird in Teilprojekte unterteilt, von denen jedes einen Mehrwert f\u00fcr den Kunden generiert. Es ist wichtig, dass sich die Teilprojekte nicht \u00fcberschneiden, damit sie unabh\u00e4ngig voneinander verfolgt werden k\u00f6nnen. Jedes Teilprojekt muss in konkrete Aufgaben zerlegt werden, bevor es bearbeitet werden kann.<\/p>\n
2. Kurzfristige Planung<\/h3>\n
Es werden nur das n\u00e4chste und das nachfolgende Teilprojekt geplant, da in der Regel nur f\u00fcr diese Teilprojekte die notwendigen Details vorliegen. F\u00fcr zuk\u00fcnftige Teilprojekte sind die verf\u00fcgbaren Informationen oft zu ungenau; das Risiko von \u00c4nderungen und Neuplanungen ist hoch.<\/p>\n
3. Die Sicht des Kunden einnehmen<\/h3>\n
Das Teil- und Gesamtprojektergebnis wird aus der Sicht des Kunden formuliert. Auf diese Weise verliert kein Teammitglied das Ziel aus den Augen und alle Teammitglieder k\u00f6nnen bei Problemen selbstst\u00e4ndig im Sinne des Kunden reagieren, wobei der Kunde extern oder intern sein kann.<\/p>\n
Die Summe aller erledigten Aufgaben am Ende eines gew\u00e4hlten Zeitraums (ein so genannter Sprint) wird als “Done Increment” bezeichnet. Diese Increments sind die Zusammenfassung der aktuell erledigten Aufgaben mit allen in fr\u00fcheren Sprints erledigten Aufgaben. Wir ziehen es vor, mit w\u00f6chentlichen Increments zu arbeiten. Bei einem neuen Projekt gibt es in der Regel noch viele Unsicherheiten und ungel\u00f6ste Probleme\/Fragen. Diese stellen Risiken f\u00fcr die Entwicklung dar, da sich der Aufwand f\u00fcr einzelne Anforderungen nur schwer absch\u00e4tzen l\u00e4sst. Daher ist es naheliegend, in m\u00f6glichst kleinen Einheiten zu arbeiten, insbesondere wenn sich das Projekt noch in einer fr\u00fchen Phase befindet. Fragen Sie sich, was die Vorteile dieser Arbeitsweise sind? Hier sind sie:<\/p>\n
- \n
- Regelm\u00e4\u00dfige Reflexion \u00fcber den Entwicklungsprozess<\/li>\n
- Software so fr\u00fch wie m\u00f6glich produktiv einsetzen und dann schrittweise erweitern<\/li>\n
- Den Beteiligten regelm\u00e4\u00dfig laufende Software pr\u00e4sentieren<\/li>\n<\/ul>\n
Verringerung der Risiken mit MVPs<\/h2>\n
Diese Vorteile sind auch der Grund, warum wir mit dem so genannten “Minimum Viable Product” (MVP) arbeiten. Also einem Produkt mit den Mindestanforderungen und -eigenschaften. Bei der Entwicklung eines MVP besteht die Grundidee darin, so schnell wie m\u00f6glich ein Produkt zu schaffen, das nur die notwendigsten Merkmale aufweist. Dieses wird dann sofort ver\u00f6ffentlicht und es wird zun\u00e4chst ein Feedback von den (potenziellen) Kunden eingeholt. Dieses Feedback wird im Folgenden zur Erweiterung und Verbesserung des MVP verwendet.<\/p>\n
<\/p>\n
![\"Minimal](\"https:\/\/kokoen.net\/wp-content\/uploads\/2020\/07\/minimal-viable-product-300x202.jpg\")
Copyright \u00a9 Henrik Kniberg – Making sense of MVP (Minimum Viable Product)<\/p><\/div>\n
Alle weiteren Funktionen sollten aus dem MVP herausgelassen werden. Es werden nur die Funktionen aufgenommen, die f\u00fcr den eigentlichen Zweck des Produkts erforderlich sind. Dies spart eine Menge Arbeit, Zeit und Kosten bei der App-Entwicklung<\/a>.<\/p>\n
Der Hauptgrund f\u00fcr die Entwicklung eines MVP ist die Risikominimierung. Wenn man sich dazu entscheidet, ein Produkt komplett zu entwickeln und zu ver\u00f6ffentlichen, k\u00f6nnen viele Probleme auftreten.<\/p>\n
Zum Beispiel nimmt die Entwicklung eines solchen vollwertigen Produkts viel Zeit und Geld in Anspruch. Weit mehr, als es bei der Entwicklung eines MVPs der Fall w\u00e4re.<\/p>\n
Ein weiteres Risiko bei der Entwicklung besteht darin, den tats\u00e4chlichen Markt und die Kundenbed\u00fcrfnisse zu ignorieren. Wenn monatelange Entwicklungszeit in ein Produkt investiert wird, aber niemand will es nach der Ver\u00f6ffentlichung haben, dann haben alle Zeit und Geld damit verschwendet, etwas zu entwickeln, das niemand braucht.<\/p>\n
Die Entwicklung eines MVP hingegen reduziert das Risiko f\u00fcr Unternehmen, indem nur ein Prototyp mit den notwendigsten Funktionen entwickelt wird, und spart dem Unternehmen zun\u00e4chst viel Zeit und Geld. Au\u00dferdem wird bei einem fr\u00fchen Markteintritt schnell bewertet, ob die Idee und das Produkt \u00fcberhaupt eine Chance auf dem Markt haben.<\/p>\n
Zeit und Kosten bei der App-Entwicklung sparen: Nutzung der am besten geeigneten Technologien<\/h2>\n
Bevor wir mit der Entwicklung beginnen, haben wir viel Zeit damit verbracht, dar\u00fcber zu diskutieren, welche Technologien wir verwenden und wie die Anwendung entwickelt werden sollte – ganz im Sinne von “Wochen des Programmierens k\u00f6nnen Ihnen Stunden der Planung ersparen”. Die grundlegenden Fragen bei der App-Entwicklung sind nat\u00fcrlich die Anforderungen und die gew\u00fcnschten Betriebssysteme. Kombiniert mit dem verf\u00fcgbaren Budget ergibt sich aus dieser einfachen Berechnung die endg\u00fcltige Entwicklungsstrategie.<\/p>\n
Heutzutage gibt es verschiedene M\u00f6glichkeiten, eine App zu entwickeln: Nativ, Hybrid<\/a>, Kompiliert<\/a> und PWA<\/a>. Jede von ihnen hat ihre Vor- und Nachteile und mit der richtigen Wahl k\u00f6nnen Sie viel Zeit und Kosten bei der App-Entwicklung sparen. Mehr dar\u00fcber k\u00f6nnen Sie hier lesen: \u00dcberblick \u00fcber die Optionen zur App-Entwicklung<\/a>.<\/p>\n
Nat\u00fcrlich ist es nicht m\u00f6glich, eine allgemeing\u00fcltige Bewertung f\u00fcr einzelne Projekte vorzunehmen. Einfache Anforderungen k\u00f6nnen durchaus webbasiert umgesetzt und \u00fcber ein natives Framework in den App-Stores verteilt werden. Oftmals bringen jedoch die aktuellen technologischen Beschr\u00e4nkungen das Projekts an seine Grenzen. In diesem Fall ist eine Hybridl\u00f6sung unter Kosten\/Nutzen-Gesichtspunkten meist eine hervorragende Alternative. Sind die Anforderungen jedoch zu kompliziert oder aufwendig oder betritt man das Terrain der Spielentwicklung, f\u00fchrt kaum ein Weg an einer nativen L\u00f6sung vorbei.<\/p>\n