Agilität erklärt – Die Grundprinzipien der agilen Softwareentwicklung verstehen

1. Einführung: Hallo. Mein Name ist Stephen Holt begrüßt, weil ich John erklärte, ich bin ein Software-Entwickler Führer , die über 25 Jahre. Erleben Sie wie eine Branche. Ich bin auch Online-Trainer, dass jedes Klassenzimmer Workshops auf der ganzen Welt und ebenso wie alles, was ich bin ein Poppet, Sprecher und Autor vor kurzem erstellt. Dieser Kurs ist wegen meiner Karriere. Ich habe viel Zeit damit verbracht, in Unternehmen zu arbeiten, die glauben, dass sie agil sind. Du gehst rein. Sie beobachten das, sicherstellend, dass sie Wiederherstellungen nicht gescrollt haben, was Bretter und Geschichten verbieten kann. Aber dann, wenn eine Veränderung zu einer Anforderung kommt, bricht irgendwie alle Hölle los. Und du kennst diese Art von Panik. Oh mein Gott, die Dinge verändern das, was wir tun werden. Die Leute müssen zur Genehmigung in die Top-Abteilungen gehen. Sie könnten in der Regel ein ziemlich Chaos auf seiner nicht betrunken sein. Das ist nicht das, worum es bei unseren Jobs geht. Also in diesem Kurs auf Streifen weg. Eine Menge Projektmanagement-Methodik ist, dass dieser Kurs nicht über Scrum ist. Es geht nicht um extreme Programmierung. Ob Sie kurz darüber reden, dieses Gericht ist eigentlich über die Kernprinzipien der agilen, was es bedeutet, ein Witz zu sein und vorausgesetzt, Sie folgen diesen Kernwerten, dann könnten Sie agil sein. Es spielt keine Rolle, ob du Scrum XP machst oder was auch immer. Die neuesten Favoriten Methodologien. Warum folgen Sie diesen vier Kernwerten? Dann könntest du ein Job sein. Also damit, lasst uns anfangen. Wenn dir der Kurs gefällt, bin ich sehr dankbar, wenn du mir folgen könntest. Ich sehe einige meiner zukünftigen Ursachen. Auch, wenn Sie den Kurs genießen, wäre ich sehr dankbar, wenn Sie auf Twitter schließen könnten, wenn es für Social Media Größe fantastisch sein . Also damit, lasst uns anfangen. 2. Geschichte des Wasserfalles: hallo und willkommen zu meiner Sache, Agile erklärt. Ich bin dein Gastgeber, sogar Hörner in seinem Kurs. Wir werden uns die Kernprinzipien der agilen Softwareentwicklung ansehen und einige häufige Missverständnisse zerstreuen . Dies ist kein Kurs über Scrum oder Extremprogramm in, da sie nur Techniken sind, um agile Softwareentwicklung zu erleichtern. In diesem Kurs geht es um die Kernprinzipien, an die sich alle agilen Teams halten müssen. Lassen Sie uns beginnen, indem wir uns das traditionellere Wasser für den Softwareentwicklungsprozess und seine Probleme ansehen . Wenn Sie nicht in einem agilen Unternehmen arbeiten, dann sind die Chancen, dass Sie in seinem ersten Abschnitt an einer Form von Wasser für Softwareentwicklungen arbeiten . Wir werden uns ansehen, wofür Wasser ist und seine Hauptprobleme identifizieren, was uns dazu führen wird, über agile im Detail zu sprechen. Die Methode zur Entwicklung von Wasserfällen wurde 1970 vom Informatiker Winston Royce eingeführt . Winston Royce erörterte zunächst die Idee der agilen Softwareentwicklung in einem Artikel namens Managing the Software Developments of Large Software Systems. Royce bezog sich nicht direkt auf das Model in seinen Papieren. Kriege um Entwicklungen. Dieser Artikel war über Prozess, der für Software-Entwicklungen fehlerhaft war, war sein ursprüngliches Design tatsächlich zeigte mehr Wiederholung zwischen den Stufen des Modells, das war für lässt Sie nicht Winston Voices tun. Tatsächliche Modell war intuitiver, wie es funktioniert auf erlaubt mehr Raum zwischen den Bühnen zu manövrieren . Wir werden eine größere Häufigkeit der Arbeitsweise mit mir besprechen. Diskutieren Sie Agile später in diesem Kurs. Obwohl Stimme nicht auf dieses Modell beziehen wurde ausgezeichnet für Modell direkt, er wird mit der ersten Beschreibung von dem, was wir erwähnten ist das Wasserfallmodell gutgeschrieben. Russlands ursprünglicher Artikel besteht aus den folgenden Phasen, die in einem Moment näher eingehen werden. Die Stufen sind die Anforderungen Spezifikationen Stufe der Detail Design Phase, Bau Phase Integration, Prüfung und der Buck in Installation und Wartung. Das ist es also nicht. Werfen Sie einen Blick darauf, wie das Wasserfallmodell tatsächlich funktioniert. 3. Wie funktioniert der Wasserfall?: im Wasserfall. Der Prozess ist in separate Phasen unterteilt, denen das Ergebnis einer Stufe Eingang in die nächste Stufe. Die erste Stufe im Wasser war mit den Anforderungen zu beginnen, die alle Anforderungen abdecken . Analyse. Wo all diese Anforderungen an das zu entwickelnde System in unseren Spezifikationen erfasst sind . Dokumente, Erfordernisse, Spezifikationen. Dann lassen Sie uns von einem anderen Projektstakeholder, in der Regel aus dem Geschäft, abzeichnen . Es liegt in der Verantwortung des Business Analyst für das Projekt, die Anforderungsdokumente zu erstellen . Wenn Sie auf ein kleineres Team warten, dass es eine Zusammenarbeit zwischen Teammitgliedern in dieser Phase des Wasserfall-Zyklus mit Business Analyst oder Personen direkt in einem Dokument getan werden könnte , versuchen Sie, alle Anforderungen zu erfassen und Funktionen des Systems von den wichtigsten Stakeholdern des Unternehmens. Dies könnte den kompletten Satz von Funktionalitäten umfassen Jedes Geschäft, war es nicht automatisiert und dann haben Sie operative Prozesse aus einer Unternehmens- und regulatorischen Perspektive. Der nächste Stufe-Assistent entwirft die Anforderungsspezifikationen von der ersten Stufe oder inspiziert und Assistenzdesigner zusammengestellt. Das ist Ryan half bei der Festlegung der Designanforderungen und half auch in der ovalen Systemarchitektur zu schaffen . In dieser Phase ist es ein technisches Mitglied des Teams, das Entwickler und Architekten umfasst, die entscheiden, wie das Gesamtsystem gebaut werden soll. Sobald ein System entworfene Gesichter abgeschlossen ist, gehen wir in die Implementierungsphase. Hier nehmen die Entwickler des Teams das vorherige Softwaredesign an und beginnen, den Code zu schreiben, damit er nach dem Implementierungsgesicht funktioniert, wo sie zur Integrations- und Testphase übergehen . Hier wird das Testteam alle Systemkomponenten des Systems zusammenbringen und testen dass er ein einziges Produkt ist. Das Testteam sollte in diesem Stadium einen detaillierten Testplan haben, auf den es sogar manuelle Tests durchführen oder automatisierte Tests entwickeln kann. Sobald das Testteam seine Arbeit abgeschlossen und abgemeldet hat, ist das System fit und richtig. Es ist dann bereit für die Bereitstellung für die Endbenutzer. Sie können beginnen, die Vorteile zu sehen, sobald eine Lösung in der Produktion bereitgestellt wurde, und dann während dieses Zeitraums in eine Wartungsphase gehen. Wenn die Endbenutzer Fehler melden, müssen sie behoben werden, getestet wurden erneut in die Produktion eingesetzt. Wenn eine dieser Zahlen am Ende sehr groß ist, könnte eine Entscheidung getroffen werden den Wasserfall erneut zu beginnen, indem die Anforderungen neu definiert werden. Die Implementierung zu entwerfen, testen und dann erneut bereitzustellen, wenn dies nur geschieht, kann ziemlich zeitaufwendig sein, was sich nicht eignet, um dies zu beheben, musste dringend gemacht werden. 4. Wo ist der Wasserfall geeignet?: während in der Adroll Welt, gibt es viel Wert darauf zu sagen, dass Wasser für nicht geeignet ist. Es gibt jedoch einige Projekte, wenn, was für die Methodik angemessen ist. Werfen wir einen Blick auf ein paar. Zunächst einmal, was für ist geeignet, wenn Ihre Software-Projektanforderungen bereits gut definiert dokumentiert sind. Aber in Wirklichkeit, wie oft ist das der Fall aus meinen eigenen Erfahrungen? Als Softwareentwickler und Entwickler kann ich mich nicht an eines der vielen Projekte erinnern, die ich geliefert habe, wo die Anforderungen von Anfang an klar waren, so dass sie im Dokument erfasst werden können, was sich nicht ändert, ist ein Projekt rollt auf der nächsten muss die Produktdefinition stabil sein. Okay, und ich kann mir kein einziges Projekt vorstellen, bei dem das für Mai der Fall war. Als externe Faktoren wie die Veränderung des Marktplatzes oder die Verlagerung des Geschäfts bedeuten Prioritäten, dass sich Ihr Produkt weiterentwickeln wird. Ich habe an vielen Projekten gearbeitet, bei denen das endgültige Lieferprodukt völlig anders war als das, was ursprünglich unter Wasser spezifiziert wurde, denn dies sollte nicht passieren. Aber in Wirklichkeit kann das, was du baust, nichts falsch mit diesem Baby ändern. Das ist Kampf gegen einen Software-Bereitstellungsprozess. Als nächstes sollte die Technologie gut verstanden werden. Dies bedeutet, dass Entwickler verstehen sollten, dass die Technologie dort verwendet werden wird und wie sie funktionieren. Sobald Sie auf die Umsetzung der Bauphase des Projekts gegangen sind, müssen Entwickler in der Regel auf sehr starre und festgelegten Zeitskalen arbeiten. meiner Erfahrung, Arbeit am Wasser für das Projekt, wird viel Aufwand von den Anforderungen und Designphase vertrieben, die normalerweise in die Zeit isst, die benötigt wird, um den Code tatsächlich zu entwickeln. Nächste Wasserfall funktioniert am besten auf Projekte sind kurz. Kurz gesagt meine ich Projekte rund 2 bis 4 Monate insgesamt. Je länger das Projekt läuft, desto größer ist die Chance, dass die Anforderungen und die Produktdefinition veraltet sind . Endlich, was für Works am besten. Wenn alle Ihr Produktteam zur Verfügung stehen, um zusammen zu arbeiten, ist es ganz normal für eine Entwicklung scheinen einen Hafen von Ressourcen zu haben. Es kann zwischen vielen verschiedenen Projekten geteilt werden. Wenn ein anderes Projekt beendet ist, irgendeinem Grund ausgeführt wird, dann haben Sie möglicherweise nicht alle Personen zur Zeit zur Verfügung und jetzt erforderlich dies kann erhebliche Auswirkungen auf Projekte Zeitskalen reichlich Liefertermine gefährdet 5. Vorteile und Nachteile von Wasserfall: Ich möchte jetzt einen Blick auf einige der Vor- und Nachteile für das Wasserfallmodell nehmen. Der erste Vorteil ist, dass durch die Aufteilung Ihres Projekts Lieferungen in kleinere Phasen für eine Organisation einfacher ist, um die Kontrolle über den Entwicklungsprozess zu behalten . Dies erleichtert die Planung von Fahrplänen im Voraus erheblich. Dies macht ein Projektmanager Leben viel komfortabler. Es ist aus diesem Grund, dass ich die Erfahrung gefunden. Projektmanager neigen dazu, den Wasserfallprozess zu begünstigen, da Sie ihr Leben viel einfacher machen könnten . Lassen Sie uns ein Projekt in die verschiedenen Gesichter des Wasserfallprozesses hinunterhören. Sie können leicht Abteilungs ISA Lieferung Ihres Projekts. Sie können verschiedenen Abteilungen verschiedene Rollen zuweisen und sie abrufen. Eine klare Liste der Leistungen und Zeitskalen, wenn eine dieser Abteilungen aus verschiedenen Gründen nicht liefern kann , ist für einen Projektmanager leicht, einen Gewehrplan anzupassen. Leider in Wirklichkeit gesehen, habe ich in Wirklichkeit gesehen,dass die Methode angepasst wurde, wo die Implementierungsphase warm wird oder was bedeutet, dass das Entwicklungsteam weniger Zeit hat, um eine funktionierende Lösung zu liefern, und es kommt. Qualität leidet und Abkürzungen neigen dazu, genommen zu werden. Normalerweise sind es code-basierte Einheiten und Integrationstest, die zuerst betroffen werden. Dies hat einen Schlag auf Wirkung von Test-Teams in der Testphase, wenn sie eine Lösung erhalten. Es enthält mehr Probleme, die ihr Leben sehr schwer macht. Während also die Abteilungsbestimmung als Vorteil angesehen wird, kann es schnell zu einem Nachteil werden, wenn ein anderes Team zu spät in der Bereitstellung ihres Teils des Projekts in Richtung des vollständigen Modells keine Zeit für Reflexion oder eine Vision zu einem -Design. Sobald sich die Anforderungen abgemeldet haben, sollten sie sich nicht ändern. Sie sollten bedeuten, dass das Entwicklungsteam ein festes Design hat, dass ihre Drüsen, Worte, Worte. In Wirklichkeit geschieht dies nicht, und Änderungen der Anforderungen können oft zu Chaos führen, da Entwurfsdokumente aktualisiert und von den Interessengruppen abgeschrieben werden müssen . Zu dem Zeitpunkt, zu dem das Entwicklungsteam beginnt, wird so ziemlich erwartet, dass es das erste Mal richtig ist , und ihnen wird nicht viel Zeit erlaubt, zur Reflexion über den Code, den ich implementiert habe, anzuhalten . Aber die Zeit, die Sie zu dem Punkt kommen, an dem Sie denken, dass eine Änderung der technischen Richtung erforderlich ist , ist normalerweise zu spät, um etwas dagegen zu tun, es sei denn, Sie möchten die Liefertage bewirken . Dies könnte durchaus die Motivation für das Entwicklungsteam sein, mit dem sie fortfahren müssen. 10 umfassen Implementierungen, voll von Kompromissen und technischen Schulden. Sobald das Produkt eingetreten ist, ändert sich die Testphase praktisch unmöglich. Ob es sich um das Gesamtdesign oder das eigentliche Umsetzungswasser handelt, war ein einfacher Prozess. Verstehen Sie nicht auf Papier. Es scheint eine gute Idee für das Ausführen eines Projekts zu sein. Der Wasserfall ist auch einfacher, Ihre Projektmanager zu verwalten. Alles wird in Etappen geliefert. Es könnte nach Plänen geplant werden. Schätze werden nacheinander abgeschlossen, wo die Ausgabe von einer Fläche in den Eingang der nächsten Stufe eingespeist wird . Wasserfall funktioniert gut für kleinere Projekte, bei denen das Risiko der Änderung der Anforderungen und Umfang geringer ist, jeder Schritt im Wasser für eine sehr klar definierte. Es erleichtert die Zuweisung klarer Rollen. Zwei Teams und Abteilungen, die Sie in das Projekt einspeisen müssen, weil jede Phase gut zu finden ist . Es bildet einen Meilenstein, der vom Projektmanager eingerichtet wurde. Einfacher zu verstehen. Wenn Sie an einer Phase bei der Anforderungsanalyse arbeiten, sollten Sie wissen, was Sie für den Prozess und die Ergebnisse jeder Phase aller dokumentierten unter Wasser bis zur nächsten Stufe liefern müssen. Jeder Staat hat klare Ergebnisse dokumentiert und von den wichtigsten Projektbeteiligten in Richtung für Modell passt sehr ordentlich unterzeichnet , INS begann Charles, Also ein Projektmanager ist glücklicher, wenn sie alles beschweren. Kautz und sehen Sie das Projekt Timeline in Anwendung, die von Projekten funktioniert. Einer der größten Nachteile Auszeichnungen für Modelle. Sie erhalten keine funktionierende Software bis spät in den Prozess. Das bedeutet, dass Ihre Endbenutzer ihre Vision erst zum Leben erweckt haben, wenn es zu spät ist, etwas zu ändern. Es kann schwierig sein und für technische Leute, klar zu sein, wie sie eine Anwendung betreiben wollen , und es ist normalerweise, bis sie eine Anwendung visualisieren können, können sie gutes Feedback geben . Sie können dies mildern, indem Sie vom Prototyping im Systemdesign Gesicht tun, um Anwendungen zu helfen, ihr System zu visualisieren. Es gibt nichts Besseres, wie einen tatsächlichen Arbeitscode gegeben, und Software zum Ausprobieren für Modell könnte ein hohes Maß an Risiko und Unsicherheit für alles andere als kleine Projekte einführen . Das liegt daran, dass eine Reihe von Anforderungen und Design abgesagt wurde, bedeutet nicht, dass die Bedingungen nicht in Richtung ändern für war, um die Anforderungen, Design und Implementierung richtig zu bekommen . erste Mal, das ist eine große Idee in einer perfekten Welt, aber in der realen Welt ist sehr selten der Fall, und es ist ein großes Risiko für ein Projekt. Mehr Komplexität, die damit verbunden ist, erhöht das Risiko des Handels, der weiter unten benötigt wird. Komplexität im System ist auch sehr schwer zu implementieren und zu testen, kann es oft zu Verzögerungen in den späteren Phasen des Wassers für die Softwareentwicklung führen. Lebenszyklus Wenn Sie an einem Projekt arbeiten, in dem Änderungen erwartet werden, ist deren Bedarf nicht das richtige Modell für Sie. Ich habe an Projekten von Finanzdienstleistungsunternehmen gearbeitet, wo Variationen im Finanzrecht , weil in Compliance oder Vorschriften zu ändern. Leider sind diese Regeln sehr offen für die Interpretation, was bedeutete, dass das Juristische Team in einem sehr frühen Stadium involviert war. Dies bedeutete, dass sich die Interpretation während des Projekts einige Male änderte. Wenn dies für das Projekt ausgezeichnet worden wäre, waren wir in großen Schwierigkeiten. Produkte kommen häufig mit einem festen Satz von Fristen. Dies war eine perfekte Passform für natürliches Projekt. Wenn Sie an einem großen Projekt in den Umfangsänderungen arbeiten, könnte dies so teuer und kostspielig sein, dass ursprüngliche Geschäftsvorteile für das Projekt und verdunstet. Und dann hat das Projekt beraten. Ich habe gesehen, dass dies ein paar Mal passiert, und es ist eine echte Schande, da Projekte, die echte Versprechen zeigen, aufgrund von Einschränkungen im Prozess stoppt. Schließlich hatte die Integration und Lieferung eines Projekts als Urknall auf Auszeichnungen für Project getan. Das bedeutet, dass Sie massive Mengen an Änderungen einführen werden oder sofort wird es schnell überwältigt Testteams und Ihre operationellen Teams. 6. Was ist Agil?: jetzt, da wir einen Blick auf ein traditionelleres Wasser für den Software-Entwicklungsprozess werfen. Lassen Sie uns nun beginnen, alternative, agile Softwareentwicklungen zu untersuchen . Schließlich ist die Softwareentwicklung eine Reihe von Software-Entwicklungspraktiken, die ein evolutionäres Design mit Teams fördern , die sich selbst organisieren können. Bei unserer Software. Entwicklung inspiriert böse Verletzungen Software-Entwicklung, adaptive Planungsmethoden, eine frühzeitige Wertschöpfung von Ihrer Software an Urin-Kunden. Das Wort agile wurde erstmals 2001 mit Entwicklungssoftware verknüpft, als das agile Manifest von einer Gruppe von visionären Führern und Softwareentwicklern entwickelt wurde. Ich bin nicht traditionell wählen Sie es und Praktiken wie Wasserfall agile Methoden. Solch ein Scrum und extreme Programmierung konzentrieren sich auf selbstorganisierte, disziplinübergreifende Teams, die kontinuierliche Planung und Implementierung praktizierten, um ihren Kunden einen Mehrwert zu bieten . Der primäre Schritt der agilen Softwareentwicklung ist die Bereitstellung von funktionierender Software, die dem Endbenutzer einen höheren Wert verschafft . Jede dieser Methoden betont die laufende Assoziation zwischen Technologie und dem Geschäft , für das Sie die Software entwickeln, schließlich Software-Methodik, ist ein Leichtgewicht, das sie versuchen, zu verhängen einen minimalen Prozess und Overhead innerhalb des Entwicklungslebenszyklus. Adroll-Methoden sind adaptiv, was bedeutet, dass ich Änderungen in Anforderungen und Geschäftsprioritäten unterstütze . Für heraus ändert sich der gesamte Software-Konstruktionsprozess. Die natürlichen Anforderungen sind mit einem agilen Softwareentwicklungsprojekt zu berücksichtigen und zu begrüßen . Es wird auch großer Wert darauf gelegt, Teams für kollaborative Entscheidungen zu befähigen. Machen Sie ihn. Früher habe ich darüber gesprochen, wie der wasserfallbasierte Entwicklungsprozess einer Reihe von Stufen folgt, die einem großen Knall der bereitgestellten Software am Ende des Prozesses führt. Eine der Hauptideen hinter der agilen Softwareentwicklung ist, dass Sie statt ein Big Bang Release in die Produktion zu bringen , mehrere Versionen von Arbeitscodes Ihrer Stakeholder kontinuierlich veröffentlicht haben. Auf diese Weise können Sie Funktionen priorisieren, die den Benutzern den größten Nutzen bieten damit die Organisation frühzeitig ihre Investitionen erwirtschaften kann. Auf diese Investition kommt in Form von Geld ausgegeben und Zeit in der Entwicklung und Planung der Anzahl der Lieferungen in die Produktion verbraucht . Dass Sie dies tun, hängt davon ab, wie lange das Projekt kompliziert ist, aber idealerweise möchten Sie am Ende jedes Sprints oder der Iteration funktionierende Software bereitstellen. Ich liebe einen guten Weg, um die Prämisse unserer Joe zu visualisieren ist in dem Diagramm, das Sie Bildschirm verbergen . Nun, was dieses Diagramm zeigt, ist, ob agile Software Sie inkrementell statt alle auf einmal liefern . Sie sollten seine Schuld in Ihrem Kopf halten, während wir den Rest dieses Kurses durchlaufen. 7. Die Geschichte der Agile: Laufe der Jahre gab es viele Versuche, Methoden zur Softwareentwicklung zu verbessern , und viele von ihnen haben sich aufdringlich mit der Arbeit beschäftigt. Diese neuen Praktiken gingen nicht weit genug, um mit Änderungen der Anforderungen an Kunden umzugehen . In den neunziger Jahren traf sich eine Gruppe von Branchensoftware Fort Leaders in einem Skigebiet in Utah, um zu sehen, dass Sie einen besseren Weg zur Entwicklung von Software definieren können . Der Begriff agile Softwareentwicklungen ist aus dieser Kavallerie hervorgegangen. Der Begriff wurde zuerst in seiner Art und Weise verwendet und veröffentlicht. Das mittlerweile berühmte Manifest Agile Manifesto Theater wurde entwickelt, um die Ideen zu fördern Ihren Kunden einen regelmäßigen geschäftlichen Mehrwert zu bieten, und machte es notwendig, dass Sie sich auf ein kollaboratives, funktionsübergreifendes Team konzentrierensollten sich auf ein kollaboratives, funktionsübergreifendes Team konzentrieren , um passieren. 8. Das Manifesto 4 Kernwerte: Das Bundesmanifest ist wahrscheinlich das wichtigste Artefakt, auf das wir achten können, wenn es um agile Softwareentwicklung geht. Es spielt keine Rolle, welchen Einfluss Sie in Squam extreme Programmierung haben, wenn Sie eine Projektmanagement-Methodologien haben, folgen Sie nicht den Werten im agilen Manifest, dann machen Sie adroll nicht richtig. Lassen Sie uns also einen Blick auf die vier Kernwerte werfen. Dies sind Einzelpersonen und Interaktionen über Prozesse und Touren, Arbeitssoftware über umfassende Dokumentation, Kundenzusammenarbeit bei Vertragsverhandlungen und schließlich Reaktion auf Veränderungen im Hinblick auf einen Plan für den ersten Kern -Wert. Wir haben Einzelpersonen und Interaktionen über Prozesse in Schulen. Menschen bauen Softwaresysteme und immer noch diese richtig, sie nur zusammen zu arbeiten und haben eine gute Kommunikation zwischen allen Parteien. Dies ist nicht nur Softwareentwickler, sondern umfasst Q A Business Analyst, Projektmanager, Business Sponsoren und Senior Leadership und alle anderen, die an dem Projekt oder Produkt in Ihrer Organisation beteiligt sind . Prozesse und Werkzeuge sind notwendig, aber sie sind irrelevant, dass Menschen, die an den Produkten arbeiten, nicht für eine Sekunde der Kernwerte effizient kommunizieren und zusammenarbeiten können. Wir hatten funktionierende Software über umfassende Dokumentation. Seien wir ehrlich, wer liest 100 Seiten Produkte zurück. ich ganz bestimmt nicht. Ihre Geschäftsbenutzer wurden sehr bevorzugt, so kleine Funktionen, die schnell bereitgestellt werden, damit sie dann Feedback geben können. Diese Funktionen können sogar bis zur Produktion ausreichen, um von ihnen profitieren zu können. Frühe alte Dokumentation ist jedoch schlecht, jedoch schlecht, wenn meine Teams, warum es in einem Projekt ist, benutzten sie visuelle Diagrammwerkzeuge aus Physio, um Diagramme wie Bereitstellungsdiagramme, Datenbankschema in Softwareschichten und Anwendungsfalldiagramme. In der Regel drucken wir diese auf drei Drucke aus und legen sie an die Wand, damit sie für alle sichtbar sind . Kleine, nützliche Teile der Dokumentation da draußen so unschätzbar wertvoll 100 Seiten Produkte, Rücken oder nicht. Neun Mal von 10 großen Dokumentationselementen sind ungültig und veraltet, bevor Sie überhaupt fertig sind, sie zu schreiben. Denken Sie daran, das primäre Ziel ist die Entwicklung von Software, die geschäftlichen Vorteile bietet, nicht umfangreiche Dokumentation. Ich bevorzuge die Kernwerte. Wir haben Kundenzusammenarbeit bei Vertragsverhandlungen. Nun, die Software, die Sie entwickelt haben, sollte geschrieben werden. Wenn Ihre Kunden Beteiligung Seien Sie erfolgreich in der Softwareentwicklung, müssen Sie täglich mit ihm arbeiten. Es bedeutet, regelmäßig in Ihre Stand Ups Demo einzuladen und ihn zu Design-Meetings einzuladen . Nur der Kunde kann Ihnen sagen, was er will. Möglicherweise sind sie nicht in der Lage, Ihnen alle technischen Details zu geben, aber das ist es, was Ihr Team ist, ist, um mit ihnen zusammenzuarbeiten, ihre Anforderungen zu verstehen und für sie zu liefern. Aber ein vier vom endgültigen Call-Wert, den wir reagieren, um zu ändern über einen Plan zu folgen, den Ihr Kunde oder Unternehmen gesponsert kann Ihre Meinung über das, was gebaut wird, geschult. Dies kann daran liegen, dass Sie ihnen neue Ideen aus der Software gegeben haben, die Sie in einer früheren Situation geliefert haben . Dies kann daran liegen, dass sich die Prioritäten des Unternehmens geändert haben oder neue regulatorische Änderungen in Kraft getreten sind . Das Wichtigste ist hier, dass du es umarmen solltest. Ja, ein Code kann weggeworfen werden und irgendwann kann verloren gehen. Aber wenn Sie in kurzen Änderungen arbeiten und dieses Mal verloren, seine Minimierung Änderung ist eine Realität der Software-Entwicklungen, eine Realität, die Ihre Software-Prozess reflektieren muss. Es ist nichts falsch daran, einen Projektplan zu haben. In der Tat machen Sie sich Sorgen um jedes Projekt, das keines hatte. jedoch Ein Projektplan mussjedochflexibel genug sein, um geändert werden zu können 9. Methodik Übersicht: Jetzt, da wir die wichtigsten Kernwerte des agilen Manifests verstehen, sie häufig verwendet, um verschiedene Methoden zu untermauern, weshalb Adroll praktischer wird. Lassen Sie uns ein sehr hohes Niveau nehmen. Sehen Sie sich einige der gängigen Methoden an, die Aaron heute verwendet hat. In diesem Kurs geht es nicht um eine bestimmte Methodik, aber Probleme werden ein Glas von jemandem Methoden nehmen, die erfolgreich sind wir haben Scrum Scrum ist ein leichtes Projektmanagement-Framework, das auf einem interaktiven Arbeitsmodell. Ken Schwab könnte Door Jeff Succulent sein und Angebote trugen zu den Entwicklungen bei, die in den letzten Jahren beschrieben wurden. Screamers eigene wachsende Popularität in der Software-Entwicklungs-Community wegen seiner Einfachheit, nachgewiesenen Erfolg und Verbesserung der Produktivität und seiner Fähigkeit, mit sehr leiden Engineering-Praktiken durch unsere zerbrechlichen gefördert zu arbeiten Methoden wie extreme Programmierung. Also als nächstes haben wir Extreme Programmierung oder Ex Pays ist auch neun Extreme Programmierung wurde ursprünglich von Ken entwickelt zurück und hat sich eine der beliebtesten und umstrittenen agilen Methoden entwickelt. Extreme Programmierung ist ein disziplinierter Ansatz zur schnelleren Bereitstellung hochwertiger Software und betont konsequent viele Kundeninteraktionen, schnelle Feedback-Sprünge, kontinuierliche Tests, Fortsetzung der Teamarbeit , um funktionierende Software zu liefern. Häufige Release-Trittfrequenz in der Regel 1 bis 3 Wochen, wenn ein Scrum ein Projektmanagement-Framework ist Exp ist eher eine Engineering-Disziplin. Es ist sehr üblich, dass Teams Peeling übernehmen, aber verschiedene Engineering-Praktiken aus extremer Programmierung ausleihen. Das ursprüngliche Extreme Programmierrezept basierte auf Fork einfache Werte, Einfachheit, Kommunikation, Feedback, ermutigen. Es gibt auch 12 unterstützende Praktiken. Dies sind das Planungsspiel kleine Releases, Kundenakzeptanz-Tests, einfache Design-Paar-Programmierung, testgesteuerte Entwicklung, Re-Faktor in kontinuierlicher Integration, kollektive Code-Besitz-Codierung Standards, Metaphern und nachhaltiges Tempo. Wie ich bereits gesagt habe, geht es in diesem Kurs nicht um Scrum oder extreme Programmierung. Die wichtige Botschaft für Sie,die Sie in diesem Kurs lernen können, ist, worum es bei Pageau selbst geht. geht es in diesem Kurs nicht um Scrum oder extreme Programmierung. Die wichtige Botschaft für Sie, Ich habe gesehen, einige Teams denken, dass sie Scrum machen, aber tatsächlich, wenn es um die vier Kernwerte zu betrachten, wenn eine Änderung kommt in das Projekt und dann muss gehen, um einige Beiräte diskutiert werden , genehmigt undokumentiert, obwohl es aussieht, als ob du agil machst, was in Scrum? Eigentlich bist du das nicht. Es sind also die vier Kernwerte, auf die Sie sich in diesem Kurs konzentrieren sollen 10. Rollen in einem agilen Team: in alten Teams war Teil einer Abteilung eines Unternehmens, das sich primär auf ihre Softwareentwicklungsziele konzentrierte . Jedes Team sollte sich auch auf die Gesamtvision seiner Teams konzentrieren. Dies bedeutet, dass ein Team sehr reaktiv sein sollte, um alles zu tun, was erforderlich ist, um die Arbeit zu erledigen . Das bedeutet, dass Teammitglieder möglicherweise auch außerhalb ihrer normalen Fähigkeiten arbeiten müssen. Sie sollten umarmt und ermutigt werden. Ein funktionsübergreifendes adaptives Team ist viel wahrscheinlicher, dass es erfolgreich ist. Die meisten Teams natürlich verfügen natürlichüber einige Standardkompetenzen und spezielle ISMs, und Sie können auch Personen in bestimmten Bereichen oder Produktkenntnissen haben. Aber es sollte Flexibilität sein, und die Teamplayer erwarteten Rollen und Verantwortlichkeiten. Sie sollten auch gemeinsam sein, dass Teammitglieder Zugriff auf das Geschäft als Ganzes haben, und sie sollten nicht nur auf einige wenige beschränkt sein. Sie sollten Personen haben, die beauftragt sind, sicherzustellen, dass das Team den Entwicklungsprozess befolgt hat, und jemanden, der die Anforderungen koordiniert, die mit dem Unternehmen zusammenkommen, für das es sich handelt, normalerweise wie der Produkteigentümer bezeichnet werden. Wenn Sie innerhalb von Abschaum arbeiten, Framework, Teams werden normalerweise eine Form der Führungsrolle innerhalb des Teams in Scrum diese Person ist der Scrum Master auf agilen Teams. Seine Person zielt darauf ab, den Erfolg des Teams zu ermöglichen und sicherzustellen, die Art der Führer häufig als Diener Führer bezeichnet. Diese Rolle unterscheidet sich ganz anders als eine direkte, transaktionale Führung bei einem Wasserfallprojekt. One Go Oven agile Team sollte es sein, sich als Team jeden Tag zu verbessern. Je größer die Organisation, desto komplizierter können Gruppenstrukturen werden. Übergreifende Projektteams, Shared Services, Betrieb, Konfigurationsmanagement und Datenbankverwaltung könnten ebenfalls ins Spiel kommen. Aber das Ziel bleibt das gleiche. Um ein Softwareprojekt und ein funktionsübergreifendes Team zu finden, das in der Lage ist, einen Plan zu erarbeiten und ein Team dazu ermächtigt hat. 11. Gemeinde agile Missverständnisse: wenn ein Team agil sein muss, könnte es die Hälfte von ihnen sein, sich an eine neue Art der Arbeit anzupassen, vor allem für die Arbeit unter Auszeichnungen für basierte Methodik verwendet. Wenn ein Team mit Veränderungen konfrontiert ist, ist es üblich, wie sie arbeiten, für Ausreden, die von Teammitgliedern getroffen werden, wenn sie sich der Veränderung widersetzen. Keine Teams wie diese, aber meiner Erfahrung nach ist es ziemlich üblich, viele verschiedene Missverständnisse in diesem Abschnitt zu hören, werden viele dieser Missverständnisse diskutieren und warum sie zustande kommen. Ja, Joe ist bei Hark ohne Prozesskontrolle. Um agil zu sein, müssen Sie sich an das agile Manifest halten. Aber das Folgen des Manifests bedeutet nicht, dass Sie einen trotzigen Prozess verwenden. Das Manifest beschreibt eine Reihe von Ideen. Es gibt verschiedene Prozesse und Projektmanagement-Vorlagen, die Sie auf Ihre Projekte anwenden können, um ihnen dabei zu helfen, agil zu werden. Extreme Programmierung in Scrum sind zwei der beliebtesten, aber schlank und Cambon sind auch sehr beliebt. Wenn Sie versuchen, die Manifest Elemente umzusetzen, müssen Sie Deutschland den Verlust von gesundem Menschenverstand und Pragmatismus anwenden, um zu hoffen, dass Sie Ihr Ziel erreichen bevor Sie einen formelleren Prozess um das Wie von agil im Gegensatz zu dem Warum zu wickeln. Und Sie müssen etwas wie Scrum oder extreme Programmierung lernen, die Ihnen einen formelleren Prozess gibt, wie Geschichten, Veränderung, Standups, Demos, Retrospektiven, test-gesteuerte Entwicklungen und Paarprogrammierung. Als nächstes haben wir agile ist verschwenderisch, ohne von der Planung dieser Extreme, Ihr Kunde weiß, dass die Türme aller ihre Anforderungen im Voraus. Wenn dies wahr ist, dann verpflichten Sie sich auf jeden Fall umfassend von der Planung. jedoch In Wirklichkeit ist diesjedoch selten und in der Regel am wenigsten eine größere Verschwendung von Designer-Entwicklungsarbeiten , die letztendlich unnötig war. Als nächstes haben wir agile Entwicklung ist nicht vorhersehbar amerikanisch. Innerhalb eines etablierten, agilen Teams. Sie können ein Maß an Vorhersehbarkeit bringen. Ist Ihr Entwicklungslebenszyklus im Geschäft Da Sie Ihren Kunden direkt funktionierende Software bereitstellen , wird die Häufigkeit dieser Releases mit Ihren Stakeholdern festgelegt. In einer idealen Situation sollten Sie am Ende jedes Sprints oder Iteration veröffentlichbaren Code haben. Als nächstes haben wir agile ist schneller und billiger. Ein agiles Team zu betreiben bedeutet nicht, dass Sie Ihr Projekt schneller oder weniger Geld abschließen werden. Es ist kein direkter Geldsparer in dieser Hinsicht, worum es bei einem Prozess geht. Er liefert dem Unternehmen einen Mehrwert früher, als Sie in Bezug auf funktionierende Versionen Ihres Codes schneller und Ende jeder Entwicklungsiteration hatten . Sie sollten funktionierende Software haben, um das Geschäft zu demonstrieren. Möglicherweise haben Sie nicht alle Anforderungen an Ort und Stelle, aber was es gibt, wird funktionieren. Dies bedeutet, dass Sie in jeder Situation neu überdenken, wie Sie Ihre Arbeitslast planen. Anstatt zum Beispiel horizontale Slices zu liefern , schichtet der Datenzugriff Ihre Situation auf der Benutzeroberfläche in einer Nackensituation, könnte man in vertikalen Segmenten denken. Das bedeutet, dass Sie Funktionen in einer Inspiration finden, die die Arbeit an der Benutzeroberfläche und einer Datenzugriffsebene umfassen kann . Es ist ein Gedankenwechsel. Sind gesehen Teams kämpfen mit. Wenn ich früher horizontal arbeiten, wenn sie es endlich bekommen, ist die Effizienz eines Teams bemerkenswert gestiegen. Draußen zu sein bedeutet auch, auf Veränderungen reagieren zu können. Anforderungen können variieren, und Unternehmen können ihre Meinung für Ihre Lieferung teilweise ändern. Ich kämpfe, wo Teams du behandelst. Das ist eine wirklich negative Sache. Wenn Sie agil sein wollen, werden Sie erwartet. Eine Umarmung der Dinge wird zum Beispiel die Werkzeuge und Prozesse von Scrum verändern , die Ihnen helfen sollen, auf diese Veränderungen effizienter zu reagieren. Also nächstes Missverständnis haben wir seine agilen Teams. Schreiben Sie keine Dokumente oder planen Sie. Ihre John in Ihrem Team zu üben, ist keine Entschuldigung, um Planung oder Dokumentation zu vermeiden. Schreiben von Agile ist ein Akt zu tun, was zum Zeitpunkt der Anforderung benötigt wird, es fördert eine kontinuierliche Planung und Dokumentation, aber nur, wenn es für eine bestimmte Kundenanforderung notwendig ist. Auf diese Weise können Teams zusammen mit ihren Kunden entscheiden, ob der Plan oder das Dokument dem Produkt einen Mehrwert verleiht. Je nachdem, für welche Art von Unternehmen Sie arbeiten. Formale Dokumentation kann nicht etwas sein, das Sie vermeiden können. beispielsweise Wenn Siebeispielsweisein einer sehr dichteregulierten Umgebung arbeiten, gibt es viele Vorabdokumentation. Es kann für Beweismittel, eine Vorlage bei einer Regulierungsstelle benötigt werden. Wenn dies im Lieferteam der Fall ist, müssen wir diese Dokumentation berücksichtigen. Ich ziehe es vor, von großen Diagrammen anstelle der letzten Dokumente der Steuer zu arbeiten. Wenn Sie diese Diagramme ausdrucken können seinen Weg frei Papier und dann legen Sie sie über die Wände, so haben Sie etwas, das Sie in Ihren Standups beziehen können. Mit der Planungsseite müssen Sie es immer noch tun. Wie der Beginn jedes interationalen Sprints. Sie sollten eine Planungssitzung haben. Wenn ein Team selbst Storys für die Änderung zuweist, basiert die Anzahl der zugewiesenen Storys auf den Schätzungen der Geschwindigkeiten für die vorherigen Iterationen. Das nächste Missverständnis ist, dass agil bedeutet, dass keine Verpflichtungen eine gemeinsame Überzeugung ist, dass Menschen agil sind. Teams wollen nicht versprechen, dass Sie Teams von Entwicklern haben, die weg, bis jemand schreit, Wir sind fertig. Ein erfolgreiches unser Kinderteam sollte sehr transparent sein, was sie beabsichtigen, ihre Verwendungen zu liefern . Bei der Verwendung von Methoden sind Scrum oder extreme Programmierung, Sie haben ein Konzept eines Rückstands, der eine Überprüfung enthält. Heil über Benutzer. Geschichten und Aufgaben wurden Sprint oder Iteration gegeben, wie Sie die Arbeitslast für einen Sprint zu finden. Sie sollten als Leitfaden für das, was das Team zu liefern beabsichtigt, gesehen werden. Sobald eine Spencer-Wiederholung eingerichtet ist, ändert sie sich nicht, aber es kann erforderlich sein, dass Sie Ihren Plan teilweise für den Druck ändern müssen. Dies könnte zu einer teilweisen Neubepflanzung dieser Sprints, Wiederholung oder warten, bis der nächste Prinz. Extreme Programmierung mag es nicht, einen Sprint einmal zu ändern. Du fährst es weiter. Dies ist akzeptabler und Scrum, aber kein Gesetz sagt, dass Sie auch die Verpflichtung, wenn erforderlich. Wichtig ist, dass zwischen dem Team und den Stakeholdern der Wirtschaft ein Vertrauensniveau aufgebaut wird. Als nächstes haben wir eine agile Projekte wird nie enden. Dies kann in einigen Situationen zutreffen. Es sollte weiterhin an einem Projekt arbeiten, während der Kunde weiterhin geschäftliche Vorteile erhält . Die meisten Produkte in jeder Branche haben einen Punkt rückläufiger Renditen. Dies ist die ideale Zeit für ein Naturprodukt und Entwicklung. Diese Entscheidung sollte aus dem Geschäft kommen, obwohl für sie, dass Sie einen Mehrwert für agile Arbeiten für Projekte, Teams und Organisationen jeder Größe liefern , nicht nur für kleine Projekte. Dies bedeutet nicht, dass Sie unbedingt für alle Teams arbeiten, aber Größe ist wirklich ein Faktor. Große und komplexe Projekte und Organisationen, oft ausgezeichnete Kandidaten für die natürliche Transformation , erschweren oder unmöglich, alle Anforderungen Ihrer Kunden im Voraus zu kennen. Als nächstes haben wir agil ist die Lösung für Ihre Probleme. Natural ist ein Wandel in Ansatz und Kultur, der mit seinen eigenen Vorteilen und Problemen einhergeht. Wenn Sie in einem gut etablierten Team arbeiten, haben Sie keine agilen Prozesse verfolgt, als sie zu ändern, wird keine sofortige Transformation sein . Sie müssen es langsam tun und sicherstellen, dass jeder ein Mitspracherecht bei der Entscheidungsfindung hat. Wenn du es nicht tust, machst du es Widerstand von Teammitgliedern, die Veränderung fürchten, was eine ganz normale menschliche Eigenschaft ist. Ihr Team zu überzeugen, ist aber nicht die größte Hürde . Ihre größte Herausforderung ist es, sicherzustellen, dass Ihr Führungsteam versteht und übernehmen will . Agil als Arbeitsweise. Sobald Sie dies erreicht haben und hatte Führung durch in den Rest der Adoption braucht nur Zeit und Geduld ist jeder passt. Das nächste Missverständnis ist, dass es nur einen Weg gibt, einen Job zu erledigen. Das ursprüngliche, agile Manifest besteht aus den vier Kernwerten. Es dokumentiert dort keine tatsächlichen Implementierungsdetails. Viele Interpretationen der agilen, die verschiedene Methoden wie scrum extreme Programmierung Cam Verbot der Feature-driven Entwicklung bilden , um nur einige zu nennen. Jeder Stil hat seine Vorteile und Schwächen, und Sie müssen Ihre Situation bewerten, um zu entscheiden, welche Methodik passt Ihr Team extreme Programmierung entschlüsseln zwei der beliebtesten Methoden im Einsatz heute, sondern auch führende Cambon sind sehr Beliebt auch. Wie immer halten wir uns an die adroll Manifeste, Werte und Prinzipien und liefern Ihren Kunden regelmäßig Software mit höherer Wertschöpfung. Sie sollten als agil angesehen werden. Wer schließlich, das letzte Missverständnis, das wir haben, ist Adul Development erfordert kein Vorabdesign. Es ist ein häufiges Missverständnis. Agile Teams machen es einfach, während sie mitmachen. Das ist nicht wahr. Realistischer ist, dass agile Teams sicherstellen sollten, dass ihre Entscheidungen zum letzten verantwortlichen Zeitpunkt für Beschichtungsaktivitäten getroffen werden. Es ist Markensätze mit Code ist so konzipiert, wie ein Entwickler daran arbeitet, alle Faktoren zu einem besseren Design, wie sie entlang gehen. Das ist es, worum es bei evolutionärem Design geht. Mehr Systembreite. Ein architektonischer Entwurf könnte in einem oder mehreren Sprints vor der Zeit zerstört werden, nur so, wie Sie sehen müssen, können Sie effizienter auf Änderungen in Anforderungen reagieren, wenn er versucht, das gesamte System im Voraus zu entwerfen . Alle Design-Entscheidungen, die Sie machen eine Menge es überflüssig zu sein, wenn Sie kommen, um sie zu implementieren 12. Vorteile und Vorzüge von Agile: wie Sie in den vergangenen Videos gesehen haben. Agile Softwareentwicklung ist ein ganz anderer Ansatz der Softwareentwicklung im Vergleich zu dem traditionelleren Wasser-für-Entwicklungsmodell. Werfen wir einen Blick auf einige Vorteile der Verwendung. Agile ist ein Ansatz. Erstens, Kundenzufriedenheit durch schnelle Fortsetzung der Lieferung von nützlicher Software. Ihre Kunden in den Benutzern werden zufrieden sein, da Sie weiterhin einen Mehrwert für sie liefern. Wiederverwendbare Software Dies steht in einem krassen Kontrast zu dem des traditionellen Wassers für die Produktlieferung . Nun, wenn Ihre Kunden an Wasserfall gewöhnt sind, können sie es finden. Fremder. Justin hat früher funktionierende Software. Der große Nachteil von Wasser für Worte, dass Sie große Patienten mit Funktionalität gegen Ende des Projektlebenszyklus liefern, indem Sie Arbeitsteile der Funktionalität früher oder häufiger bereitstellen, geben Sie Ihren Benutzern eine Gelegenheit, eine Rendite auf ihre Investition früher zu bekommen. Sicher, sie haben möglicherweise nicht alle Funktionen, die sie benötigen, im Voraus, aber sie könnten beginnen, die Lösung zu nutzen, um ihr Leben zu erleichtern und beginnen die Vorteile zu realisieren. Früher haben wir Menschen und Interaktionen werden betont, anstatt Prozesse und Touren . Ich versuchte seine Fokussierung sehr stark auf Menschen und die Interaktionen zwischen Menschen und nicht die Prozesse in Touren. Dies ist ein Kernwert des tatsächlichen Manifests. Der Grund, warum dies wichtig ist, ist, dass dies die Importe von Ihrem Team und Kunden, die letztendlich machen Ihr Produkt zum Erfolg im Gegensatz zu dem, was immer verwendet wird. Fortsetzung der Zusammenarbeit für während des gesamten Entwicklungszyklus Ihres Projekts ermöglicht es allen Beteiligten, eine gute, vertrauensvolle Zusammenarbeit aufzubauen. Diese vertrauensbasierte Arbeitsbeziehung ist entscheidend, wenn Software inkrementell erstellt wird. Als nächstes haben wir kontinuierliche Aufmerksamkeit auf hochwertigen Code. Wir arbeiten mit unserem Job. Sie arbeiten kurze Änderungen an nur bauen, was es notwendig ist, um die Anforderungen für seine Belüftung zu erfüllen, und nichts ruft. Dies zwingt Sie dazu, Ihr Design einfach zu halten, was wichtig ist, da Einfachheit Ihnen hilft, testbare und damit zuverlässigere Systeme zu entwickeln . Entwickler verstehen und wählen viele Lösungen, um geschäftliche Probleme zu lösen. Dies sind Entscheidungen, die ein Handwerk widerspiegeln, das Design, Verwendung und Unterstützung ausbalanciert . Entwickler bieten die technische Unterstützung des Teams, das sie benachbart, um die Co-Qualität immer höher zu halten . Entwickler nutzen gerne die neuesten Technologien, um ihre Implementierung unkompliziert und sauber zu halten , ohne ihre Lösungen überarbeiten zu müssen. Einige dieser Techniken umfassen Wieder Fabrik. Die Fabrik ist ein Prozess, der das Design von vorhandenem Code verbessert, ohne sein Verhalten zu ändern . Es hat Änderungen an der Struktur des Codes vorgenommen. Der Faktenraum verwendet eine schnelle Abfolge von kleinen, gut definierten Schritten, die überprüft werden könnten, ist sicher oder funktionale Äquivalente. Re-Factoring wird oft in Verbindung mit der testgetriebenen Entwicklung durchgeführt. Wo, Einheit sagt, und einfaches Design machen es einfacher, Faktor sicher wieder. Der nächste Vorteil ist das einfache Design. Wenn Sie Ihr Design einfach halten oder nicht wiederholen Code hilft Ihnen, ein Niveau an Wartungsfähigkeit für Ihr System zu halten . Wenn Sie Ihren Code so konstruieren, dass er modular können Sie Coplin-zwischen Objekten reduzieren. In der Regel so ein insgesamt, robustere System dank Vorteile. Testgesteuerte Entwicklung. testgesteuerte Entwicklung ist eine Möglichkeit, das Design Ihres Codes zu verbessern, indem Sie Komponententests schreiben , die ausdrückt, was Sie beabsichtigen, die Codes zu machen, um diesen Testdurchlauf zu machen und weiter Factoring Um den Designprozess so einfach wie möglich zu halten, test-gesteuerte Entwicklung kann auf mehreren Ebenen angewendet werden, zum Beispiel Unit- und Integrationstests. testgetriebene Entwicklung folgt einem strengen Zyklus. Sie beginnen damit, dass ein Test fehlschlägt, dann implementieren Sie, dass meine einfache Lösung diesen Test nicht bestanden lässt. Dann legen Sie die Duplizierung im Code fest und entfernen ihn. Es wird oft als rotes Grün bezeichnet. Red Factor ist fast zu einem Mantra für viele testgetriebene Designpraktiker geworden. Verständnis und die Internalisierung dieses Zyklus ist der Schlüssel, um testgesteuert verwenden zu können, um Ihre Probleme zu lösen. Dank Vorteile. Änderungen in den Anforderungen, Ihre Kunden oder Geschäftspartner. Wir möchten Ihre Meinung über die Software ändern, die erstellt wird. Dies könnte daran liegen, dass Sie sie mit neuen Ideen aus der weichen Welle inspiriert haben, die in einer früheren Situation geliefert wurde. Es könnte daran liegen, dass sich die Prioritäten des Unternehmens geändert haben. Das Wichtigste hier ist, dass Sie die Veränderung annehmen sollten. Ja, Code kann weggeworfen werden und manchmal dauern. Wenn Sie Versicherungen arbeiten, wurde diese Zeit minimiert. Veränderungen können zunächst für Kunden und Partner erschreckend sein. Aber wenn beide Seiten bereit sind zu gehen, können Sie nicht gegenseitig lohnend sein. In gewisser Weise ist der Versuch eine einfache Idee, aber die Realität ist, dass es verschiedene Dinge für verschiedene Menschen bedeuten kann, vor allem abhängig von ihrer Rolle im Softwareentwicklungsprozess. Eines der wichtigsten Dinge ist jedoch, jedoch, offen für Veränderungen zu sein, nicht nur auf traditionelle Art und Weise der Organisation von Projekten zu bewegen, sondern das ist Ihre Verwendung von Agilität selbst. Als nächstes haben wir eine frühe Kapitalrendite. Ein weiterer Fortschritt bei der frühzeitigen Freigabe von Features ist, dass Sie früh raus. Rendite auf Ihre Investitionen. Ein Softwareentwicklungsteam zu betreiben ist teuer. Sie haben permanente Entwickler und Tester sowie Berater mit teuren Tagespreisen. Ist auch Business Analyst Projektmanager, sowie andere Hardware-Software-Kosten. Dies sind alle Kosten, die das Geschäft. Indem Sie frühzeitig Einnahmen aus Ihrem Produkt erzielen, könnten Sie damit beginnen, einige der anfänglichen Investitions- und Entwicklungskosten auszugleichen. Auf der anderen Seite, wenn Sie immer mehr Wasser für basierte Ansatz, wo Sie am Ende mit einem Big Bang Bereitstellungen nach einem Jahr oder so, werden Sie bereits eine erhebliche Menge an Geld ausgegeben haben, um eine Entwicklung mit nichts zu finanzieren , um es bis zum Ende anzuzeigen. Als Nächstes erhalten wir Feedback von Ihren Kunden, wenn Sie frühzeitig veröffentlichen. Dies bedeutet, dass Sie viel früher mit dem Feedback von Ihren Kunden beginnen können. Seine Kunden könnten öffentliche Kunden oder Business-Sponsoren sein. Ich habe an vielen Projekten gearbeitet, in denen die Geschäftskunden Anforderungen spezifizieren, die er dann nur für die Kunden bauen wollen Änderungen. Sobald ich etwas gesehen habe, das sie benutzen können, scheint dies immer zu passieren. Es ist schwierig für jemanden, ein System anzugeben, ohne etwas zu spielen. Sie können Prototyping-Software verwenden, um zu helfen, aber es gibt nichts Besseres, ihnen tatsächliche Funktionalität zu geben, um früh mit der Verwendung zu beginnen. Eines der Prinzipien unserer Aufgabe ist es, Veränderungen in den Anforderungen anzunehmen. Dies sollte erwartet werden, dass Sie Ihren Kunden etwas geben, über das sie früher im Stich gelassen werden können , und die Möglichkeit, Änderungen vorzunehmen, ohne später viel Unterbrechung zu verursachen. In der letzten fortgeschrittenen haben wir Vertrauen zurück von echten Kunden. Sobald Sie Feedback von Ihren Kunden erhalten haben, können Sie beginnen, Änderungen einzubeziehen. Und neue Ideen aus dem Feed zurück in das Produkt sind viel kostengünstiger, um Änderungen frühzeitig im Produktentwicklungszyklus vorzunehmen, als bis zum Ende zu warten. Sobald eine große Version erreicht wurde, nicht nur das Kundenfeedback, das Ihnen hilft, den richtigen Produktprotest in Ihren Produkten zu erstellen . Schon früh auf dem Markt engagieren Sie sich für die Kundenaufnahme und sehen, wie beliebt Produkte sein werden, und liefern weiterhin eine bessere Qualität. Alles, was wir bisher besprochen haben, hat geschäftliche Vorteile oder gipfelt in der Tatsache, dass Sie ein qualitativ hochwertigeres Produkt jeder Version bieten sollten, indem Sie frühes Feedback veröffentlichen . Sie können frühzeitig von der Produktleistung lernen und diese Informationen nutzen, um eine qualitativ hochwertige Produkt- und Systementwicklung zu schaffen , alles über kontinuierliches Lernen und Verbesserungen. Es ist viel einfacher zu tun, wenn Sie ein Produkt liefern, indem Sie agil sind. Es spielt keine Rolle, wo überhaupt. Mit extremen Programm in Scrum Crystal Fish Driven Entwicklung Lean Cam Band Wirklich, wenn Sie ein Projektmanagement-Frameworks haben, wenn Sie sich an die Kernwerte des agilen Manifests halten, bin ich routinemäßig einen höheren Wert zu leben Funktionalität frühzeitig für Ihre Kunden. Überwachen Sie ihre Verwendung in ist nicht da? Feedback kann dieses Lernen auf die weitergehende Entwicklung anwenden. Erhöhen Sie die Qualität, wie Sie jetzt gehen, um einen Blick auf einige Vorteile zu nehmen, schauen wir uns ein paar Nachteile. Zuallererst ist es schwer zu beurteilen. Der Aufwand erforderte es Beginn des Software-Entwicklungslebenszyklus, klagt man. Ich habe oft gehört von Geschäftsführern und Projektmanagern gleichermaßen ist es im Vergleich zu Wasser, für? Es ist schwer, den Gesamtaufwand und die Kosten für die Lieferung eines Produkts zu quantifizieren. Auf der einen Seite konnte ich sehen, was ich denken würde. Dies, vor allem kommen sie aus einem regimentierten war voller Prozess Welt. Tat ist es schwieriger zu quantifizieren, wie lange die gesamten Produkte vollständig dauern werden. Aber eine Minderung dafür ist, dass ein Produkt inkrementell geliefert wird, indem es ihnen die wertvollsten Anforderungen zuerst verwendet, was bedeutet, dass Sie sich für die kommenden Sprints beschweren oder vielleicht ein paar Sprints voraus, um spezifische Funktionsumfang. Rassistische Vorteile. Es kann sehr anspruchsvoll für die Anwendungen sein. Zeit Aktive Benutzerbeteiligung in Zusammenarbeit mit den Anwendungen Ihres Systems sind für den Entwicklungszyklus mit agile erforderlich . Das kann sehr lohnend sein. Stellt sicher, dass Sie die richtigen Produkte für Ihre Verwendung liefern. Es ist ein wesentliches Prinzip der Agilität. Um sicherzustellen, dass die Benutzererfahrungen gut auf eine Definition des Fehlers verwaltet werden, ist nicht erfüllt Verwendungserwartungen. jedoch Dieser Grad der Teilnahme kannjedochsehr anspruchsvoll für den Benutzer sein und erfordert eine große Zeitverpflichtung für die Dauer dieses Produkts. Haben in dieser Situation viele Male gewesen, wo die Business-Benutzer lieben die Idee, was ein Witz bringen könnte sie. Aber ich mag die zusätzliche Zeit nicht, die sie für das Projekt aufwenden müssen, da ich am letzten Tag immer noch die gleichen ihrer üblichen Arbeitslasten anpassen muss. Überlebt Jeans Blick auf ist ein Preis kann erhöht werden. Tester werden die ganze Zeit statt am Ende eines Projekts benötigt. Testen ist ein wesentlicher Bestandteil des natürlichen Projekts Jordanien Sprints, und es ist Reationen, die sie bedienen. Wir zeigen Qualität in allen Produkten ohne die Notwendigkeit für 11 Gebühr und unvorhersehbare Testphase es Ende Ihres Produkts. jedoch nicht, Dies bedeutetjedoch nicht,dass der Test für den gesamten Produktentwicklungslebenszyklus dringend erforderlich ist und die Kosten für Ressourcen Ihres Teams drastisch erhöhen kann. Diese zusätzlichen Outfront-Kosten sparen Sie auf lange Sicht Geld , , da Sie ständig Leute Ihren Code testen lassen. Eine Kombination aus manuellem und automatisiertem Test ist der beste Weg, um die Qualität Ihrer Produktezu steigern Qualität Ihrer Produkte 13. Bist du bereit für Agile?: für einige Organisationen weiß, dass sie größer und älter sind. Die Antwort auf die Frage, die ich auf den Wandel vorbereitet, ist wahrscheinlich nein. Die Idee der Implementierung von Methoden fördert die Entwicklung der Geschäftsanforderungen, anstatt sich auf Outfront-Dokumentation zu verlassen. Das Projektteam selbst organisiert zu stärken, anstatt ihre täglichen Aktivitäten beim Ersetzen zu kontrollieren , bedeutet, dass eine Dokumentation ohne Kommunikation von Angesicht zu Angesicht für einige Mitarbeiter etwas entmutigend erscheinen kann . Dies ist vor allem der Fall Phase, die ich mit ihren normalen Daten bequem geworden. Sie Routinen und leben einfach mit den Problemen in ihrem Code auf die Lösungen, die ihn entwickeln werden . Eine große Schwächung beim Versuch agil ist, dass Leute sagen, dass dies die Art und Weise ist, wie wir es immer gemacht haben . Diese Arten von Personen, in der Regel sehr widerstandsfähig gegen Veränderungen, wenn Sie beginnen seine zögerlichen auf den ersten, Sie können feststellen, dass agile, um auf einem Spenderprojekt in Ihrem Team versuchen helfen, sie vertraut und motiviert durch agile. Wenn ich ein oder zwei agiles Projekt ausprobieren muss, ist es immer noch unangenehm, direkt mit den Geschäftsbereichen zu arbeiten, Änderungen in den Anforderungen zu zwingen, während das Projekt fortschreitet und ihre Arbeit selbst verwalten. Es könnte sein, dass die agilen Ansätze einfach nicht für Ihre Organisation geeignet sind. Arbeitskultur. Wenn auf der anderen Seite, Ihr Team reagiert gut auf Testprojekte als seine Pflaster, der Weg für Sie, um in diese Methoden gehen agil zu übernehmen, erfordert keine Änderung in der Einstellung für Manager und traditionell, es könnte häufiger sein, direkte Kontrolle darüber zu haben, woran Ihre Teammitglieder arbeiten. Aber wenn Sie agil sind, müssen Sie einen anderen Ansatz verfolgen. Führungsstile müssen eher wie Diener Führung sein, wo Manager sind da, um Hindernisse aus dem Fortschritt des Teams zu entfernen und ein Team zu ermutigen , für sich selbst zu denken und ihre eigenen Arbeitslasten zu organisieren. Immerhin werden Entwickler sehr gut bezahlt. Sie muss realistischere Maß an Vertrauen haben, dass sie das Richtige tun, nicht für interessante Sache über die Dynamik der sich selbst organisierenden Teams. dem Fortschritt verbessern sie die kontinuierliche Motivation für das Mitarbeiterprojekt. Teammitglieder wissen, dass ihre fortgesetzte Fähigkeit selbst verwaltet wird. Ihre Arbeit hängt von ihrer regelmäßigen Erbringung von hochwertigen Geschäftsergebnissen ab, zusätzlich, weil sie diejenigen sind, die identifizieren, welche Arbeit in der Situation erreicht werden kann und nicht . Sie sind motiviert durch ihre Verantwortung, diese Ergebnisse zu erreichen. Diese Kombination von Faktoren wird durch die Situation und Stolz erhöht, dass Mitarbeiter Phil, wenn sie greifbare Ergebnisse produzieren, wirklich erfüllen die Bedürfnisse ihrer Organisation. 14. Vielen Dank: Vielen Dank, dass Sie zugesehen haben, könnte ich fahren erklärt. Und ich hoffe, er fand heraus, dass die Informationen, die über die Qualität diskutieren, für Sie nützlich sein wird, um tatsächlich auf eine primär agile Organisationen zu verstehen. Wenn Sie genossen haben, wird der Kurs sehr dankbar sein. Du folgst mir. Und auch, wenn Sie könnten die Leute über die Ursache auf Twitter wissen, wenn Social-Media-Websites sind absolut fantastisch auf Sie können auch Kommentare hier auf dieser Seite hinterlassen. Also denke ich sehr viel zum Zuschauen. Ich sehe dich nicht bald wieder.