Share
Agile oder Agile Development - diese Worte hören wir heutzutage häufiger. Aber wissen wir wirklich, worum es geht? Wie kann es uns dabei helfen, effektiver zu werden und gleichzeitig viel Spaß beim Entwickeln von Software zu haben? Wie können wir es nutzen, um mit Geschäftsleuten zu kommunizieren und diese Kommunikation für beide Seiten einfach und konstruktiv zu gestalten?
Es gab eine Menge sehr talentierter und erfahrener Leute, die ernsthafte Software entwickelten. Diese Entwickler beobachteten andere Unternehmen und Entwicklungsteams und wie ihre Prozesse ihre Arbeit erleichterten. Sie stellten ihre Beobachtungen zusammen, um das Agile Manifest zu erstellen. Und sie sagten:
Wir entdecken bessere Möglichkeiten, Software zu entwickeln, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit haben wir zu schätzen gelernt:
Das heißt, während die Elemente auf der rechten Seite einen Wert haben, legen wir mehr Wert auf die Elemente auf der linken Seite.
In diesem Artikel werde ich zwölf Theorien und Techniken der agilen Entwicklung vorstellen. Dies ist nur der erste Schritt in die neue Welt des Softwareentwicklungsprozesses.
Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller, aber nicht voll funktionsfähiger Software zu überzeugen. Dies bedeutet, dass wir Software entwickeln und pro Iteration mindestens eine Funktion hinzufügen.
Stellen wir uns vor, wir möchten eine Blog-Engine erstellen. Wir könnten dies mit dem folgenden Verfahren tun:
Es ist eine einfache Herangehensweise, aber der Kunde sieht den tatsächlichen Fortschritt seiner Software und gibt Ihnen sofort Feedback zu jeder neuen Funktion. Es kann perfekt sein oder eine Anpassung erfordern, aber Sie können schnell auf Änderungen reagieren: eine Win-Win-Situation.
Agile Prozesse ermöglichen es Ihnen, Änderungen auch für den Wettbewerbsvorteil des Kunden zu treffen.
Der Kunde möchte, dass das Projekt schnell und so nah wie möglich an das geplante Design ist. Dies kann leicht erreicht werden, indem einfach auf ihre Eingaben reagiert wird und für Änderungen bereit ist. Wenn wir schnell auf veränderte Anforderungen reagieren können, sind wir wahrscheinlich die beste Wahl, die unser Kunde jemals getroffen hat. Bei Agile dreht sich alles um Kommunikation und Veränderungen. Wir machen die Dinge so, wie wir sie fordern, und beschleunigen den Software-Entwicklungsprozess. Dies wird erreicht, weil wir kleine Software entwickeln und sich die Anforderungen nicht ändern.
Wir sollten Updates von ein paar Wochen bis zu einigen Monaten liefern; Je kürzer die Zeitspanne, desto besser.
Kunden fühlen sich in uns und unser Produkt sicherer, da es aktualisiert wird
Aufgrund meiner Erfahrungen fühlen sich die Kunden in Bezug auf uns und unser Produkt bei der Aktualisierung sicherer - was für unsere Beziehung zu ihnen von entscheidender Bedeutung ist. Ein weiterer Vorteil ist das Feedback unseres Kunden. So können wir reagieren, indem Sie Klassen, Features, Module oder sogar die Architektur ändern. Wir werden nach Tagen oder Monaten der Arbeit nicht aufwachen, nur um zu sehen, dass alles in den Müll gelangt. Betrachten wir eine hypothetische Situation:
Sie wurden aufgefordert, ein Modul zu erstellen, das einfachen Text in einem Content Manager anzeigt. Plötzlich ändern sich die Anforderungen und Sie müssen ein Formular hinzufügen, das eine E-Mail an eine konfigurierte Adresse senden soll. Außerdem sollte das Formular anpassbar sein, damit der Benutzer neue Felder hinzufügen und Prüfer definieren kann. Sie müssen also grundsätzlich die ursprüngliche Anforderung an einfachen Text vergessen. Wie bald möchten Sie von dieser Änderung erfahren??
Wenn Sie mit Ihrem Kunden an einem Projekt arbeiten und regelmäßig liefern, werden Sie diese Änderungen schneller kennen, und Änderungen wie diese werden für Sie beide einfacher.
Dies kann sich als das schwierigste Prinzip erweisen, an das Sie sich gewöhnen sollten, wenn Sie Software im alten Wasserfallstil entwickelt haben. Als Entwickler sprechen Sie normalerweise nicht die gleiche Sprache wie Ihr Client. Sie können jedoch nach Möglichkeiten suchen, eine sinnvolle Kommunikation mit ihnen aufrechtzuerhalten. Eine der besten Möglichkeiten, meiner Meinung nach, ist es, alles mit einer einfachen Geschichte zu beschreiben, die uns, dem Entwickler, für den das Feature heißt, was seine Verantwortung ist und warum wir es überhaupt brauchen. Das wird natürlich einfacher, je mehr wir mit unserem Kunden zusammenarbeiten. Ein weiterer hilfreicher Ansatz ist Behavior Driven Development (BDD), aber das ist ein Thema für einen anderen Artikel.
Geben Sie den Menschen, die Sie mit der Umgebung und der Unterstützung arbeiten, die sie benötigen, und vertrauen Sie vor allem darauf, dass sie ihre Arbeit erledigen.
Es ist wichtig, eine einladende Atmosphäre und alle Werkzeuge zu schaffen, die für die Erstellung guter Software erforderlich sind. Unternehmen verlieren ihre besten Mitarbeiter meistens, weil sie sich nicht wirklich für sie interessieren. Die Überzeugung, dass Entwickler Software auf einem Server mithilfe eines FTP-Clients schreiben, testen und bereitstellen können und Live-Produktionsdateien bearbeiten, ist irgendwo verloren gegangen. Wenn Sie diese alten Schulgewohnheiten nicht verurteilt haben, tun Sie dies jetzt besser.
Die Bindung von Mitarbeitern ist nur ein Vorteil. Sie können auch schnellere und bessere Software entwickeln. Denken Sie nur daran: Das Schreiben von wiederverwendbarem Code, automatisierte Tests und die automatisierte Bereitstellung auf einem beliebigen Server (unter anderem) kann die Entwicklungszeit positiv beeinflussen. Normalerweise denken wir, wir verlangsamen ein Projekt, weil wir lernen müssen, wie man hilfreiche Tools wie Jenkins, GIT, SVN, Gerrit, Behat usw. einsetzt.
Dies ist die effizienteste und effektivste Methode, um Informationen an unsere Kunden und das Entwicklungsteam zu übermitteln.
Wer ist nicht überfordert und / oder wütend geworden, als er 6.255.384 E-Mails in Ihrem Posteingang sah, weil Ihr Unternehmen verlangt, dass alle Gespräche "auf dem Papier" sind? Ich habe das einige Male in meinem Leben persönlich gesehen und empfehle die Arbeit in einem Unternehmen mit solchen Gewohnheiten nicht. Gespräche von Angesicht zu Angesicht machen die Kommunikation einfacher und reibungsloser und geben uns die Möglichkeit, mehr Informationen zu geben. Wir können verbale und nonverbale Kommunikationswege nutzen, um unseren Teamkollegen zu zeigen, was wir denken. Es ist offensichtlich schneller als sich gegenseitig zu mailen.
Vor allem aber müssen wir einander vertrauen. Vertrauen kann leicht in einer Umgebung gewonnen werden, die die Kommunikation von Angesicht zu Angesicht fördert.
Dies ist eine meiner Lieblingsregeln; es lässt uns frei nach unseren eigenen Prozessen arbeiten. Softwareentwickler unterscheiden sich von anderen Mitarbeitern. Daher sollten sie natürlich so behandelt werden. Aus meiner persönlichen Erfahrung habe ich gelernt, niemanden aus dem Entwicklungsteam zu richten, solange die Arbeit erledigt ist. Entwickler möchten keine schlechte Software erstellen und tun dies weniger, wenn wir sie nach ihren eigenen Vorlieben arbeiten lassen. Immerhin ist der Kunde zufrieden, solange die von ihm beauftragte Arbeit korrekt ausgeführt wird; es ist ihnen egal, wie es gemacht wurde.
Agile Prozesse fördern eine nachhaltige Entwicklung, sodass ein konstantes Tempo auf unbestimmte Zeit beibehalten werden kann.
Die bekanntesten Vorteile von Agile (z. B. Akzeptanz wechselnder Anforderungen, schnelle Reaktion auf Rückmeldungen usw.) sind allgemein anerkannt, aber der beste Vorteil ist meines Erachtens die Möglichkeit, die Zeitdauer eines Projekts oder einer Funktion genau zu bestimmen verbrauchen. Nach einigen Lieferungen wird das Entwicklerteam die wertvollste Geschäftsnummer produzieren: Kapazität. Kapazität ist die Menge an Arbeit, die das Team in einer Iteration ausführen kann. Die Kapazitätszahl ist nach einigen Iterationen stabil, und wir können die lächerlichen Fristen und Zeitschätzungen, die "aus dem Hut gezogen" werden, vermeiden, während wir dem Kunden unser Angebot präsentieren.
Viele Leute sagen, es sei unmöglich und die Terminplanung erweist sich als genauer. Ich stimme dir nicht zu; Der Zeitplan geht davon aus, dass es keine Fehler oder unvermeidlichen Verzögerungen gibt.
Es ist ein perfekter Plan für ein perfektes Team, und das gibt es nicht.
Die ständige Aufmerksamkeit für unsere Branche erhöht die Beweglichkeit.
Von uns wird erwartet, dass wir uns weiterentwickeln und Fortschritte machen. Wir müssen jeden Tag weiter lernen, weil sich die Branche so schnell bewegt. Da sowohl Hardware als auch Software besser werden, müssen wir uns auf dem Laufenden halten. Ansonsten finden wir uns im "Meer des Neuen" verloren und es wird schwer sein, wieder auf Kurs zu kommen.
Refactoring ist die Lösung für die meisten Probleme. Durch ständiges Refactoring (bei Bedarf) können wir leicht neue Techniken anwenden und unsere Softwarearchitektur verbessern.
Bill Gates sagte einmal:
Wenn ich etwas komplizierte Arbeit zu erledigen habe, werde ich es der faulsten Person geben, die ich habe, weil sie den einfachsten Weg finden wird.
Einfachheit ist die goldene Regel. Dies bedeutet nicht, dass Sie faul sein müssen, es bedeutet jedoch, dass Entwickler ihre eigene Arbeit meistens komplizieren. Wenn Sie nur die Arbeit erledigen, die der Kunde ohne zusätzliche Funktionen und Verbesserungen wünscht, wird Ihre Arbeitsbelastung geringer und Sie werden Ihre Ziele erreichen. Letztendlich kümmert sich der Kunde darum.
Die besten Architekturen, Anforderungen und Designs entstehen aus selbstorganisierenden Teams.
Wir sind nur Menschen. Wir können nicht alles vorhersagen.
Haben Sie sich jemals in einer Situation befunden, in der Sie eine umfangreiche und zeitaufwändige Anwendung entwickelt haben, und nachdem Sie unzählige Stunden vor dem Bildschirm verbracht hatten, Tausende Codezeilen geschrieben und Artikel, Tutorials und Bücher gelesen hatten, sahen Sie sich etwas Schlechtes an Code) dachte: "Jetzt weiß ich, wie ich es besser schreiben kann"? Ich denke, wir hatten alle diese Momente.
Hier setzt die elfte Regel an. Wir haben ein Entwicklerteam, das die Prinzipien von Test Driven Development (TDD) befolgen kann, wobei das Refactoring ein Teil des Prozesses ist. In gewisser Weise ist unsere Software nützlich, schön, gut geschrieben, getestet und schnell erstellt. Wir sind nur Menschen. Wir können nicht alles vorhersagen.
Das alles kommt von der Idee eines sich selbst organisierenden Teams, in dem jedes Mitglied eine Rolle hat - nicht gegeben oder erzwungen -, die jedoch nach einiger Zeit der Zusammenarbeit entstanden ist. Das ist die Schönheit der Teamarbeit.
In regelmäßigen Abständen muss Ihr Entwicklerteam darüber nachdenken, wie Sie effektiver werden und sein Verhalten entsprechend anpassen können.
Dies kann einige Entwicklungszyklen erfordern, aber das Team arbeitet in perfekter Harmonie. Selbst das Hinzufügen neuer Personen zu diesem Team wäre nicht schädlich. Bei einem agilen Entwicklungsteam geht es darum, die Arbeit zu erledigen. Wenn sie in einer freundlichen Umgebung arbeiten, finden sie die „Melodie der Arbeit“ und Sie werden sehen, wie schnell die Softwareentwicklung sein kann.
Es gibt einige Methoden, die auf agilen Prinzipien beruhen und darauf aufbauen. Ich werde sie nicht alle beschreiben, da jede Methode in einem eigenen Artikel behandelt werden kann. Ich werde jedoch einige der bekannteren agilen Ansätze skizzieren. Es ist zu beachten, dass es keine einzige Methode gibt, um sie alle zu beherrschen. Wählen Sie eine aus, die Ihren Anforderungen am besten entspricht, und konfigurieren Sie sie sogar für Ihre spezifischen Anforderungen.
SCRUM wurde von Ken Schwaber und Jeff Sutherland entwickelt und ist ein geschäftsorientiertes Framework für das Management von Softwareentwicklungsprozessen. Es gibt viele verschiedene Arten von SCRUM. Denken Sie daran, dass das Hauptziel darin besteht, effektiv und effizient zu arbeiten und sich nicht an Regeln zu halten.
XP wurde von Kent Back erstellt und enthält eine Liste bewährter Methoden, die Entwickler beim Erstellen von Software befolgen sollten. Es wird oft als "Erweiterung von SCRUM" bezeichnet. Diese Methode der entwicklungsorientierten Regeln wurde geboren, da SCRUM eher geschäftsorientiert war.
Zwei Hauptprinzipien von Lean sind: DALAP (so spät wie möglich entscheiden) und DAFAP (so schnell wie möglich liefern). Ich persönlich empfehle, mehr über diese Methode zu lesen, da sie sehr nützlich sein kann.
Es gibt mehr Methoden in der Agile-Familie. Ich habe einfach auf die beliebtesten Optionen verwiesen. Wenn Sie sich für Agile in Ihrem Entwicklungsprozess entscheiden, müssen Sie wissen, was diese Methoden sind, um die richtige für Sie zu wählen.
Funktionieren agile Techniken wirklich??
Funktionieren agile Techniken wirklich und sind die Methoden wirklich so magisch wie jeder sagt? Nicht immer.
Das Problem, dem ich in Unternehmen begegnet bin, bei denen agile Methoden keine Ergebnisse lieferten (oder die Dinge sogar verschlimmerten), war eine schlecht gewählte Methodik und mangelnde Überzeugung unter den Anwendern (Geschäftsmitglieder, das Entwicklungsteam usw.). Aus diesem Grund müssen Sie nach Ansicht des Verfassers sicher sein, dass alle am Prozess Beteiligten die Regeln verstehen und dass sie wissen, worum es geht.
Danke fürs Lesen!
Accentsconagua