Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
Agile Softwareentwicklung
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 261 Zeilen
- hallo und herzlich willkommen zu einer neuen folge von damit die galf wir werden uns heute in diesem video mal dem thema agile softwareentwicklung widmen
- denn das ist eines der themen das ihr euch in der kanal umfrage gewinn statt wenn ihr versucht euch mit dem thema zu beschäftigen wie die richter einarbeiten
- möchte dann werdet ihr im internet zahlreiche definition von agiler softwareentwicklung finden die mal mehr und mal weniger hilfreich sind ich gebe
- euch mal ein beispiel die giants schreibt agile softwareentwicklung ist ein sammelbegriff für eine reihe von methoden und praktiken die auf werten
- und prinzipien des manifests agiler softwareentwicklung basieren wenn ihr noch ein bisschen weiter lesen dann werdet ihr feststellen dass die
- ganze agile softwareentwicklung aus agen leitsätzen agieren prinzipien agilen methoden und agieren prozessen besteht alles richtig aber für die erarbeitung
- des verständnisses oder für ein überblick was agile softwareentwicklung ist hilft an dass meistens nicht wirklich weiter
- genau darum soll es heute in diesem video gehen ich möchte euch mal zeigen warum man die softwareentwicklung super gut ist und warum das für jeden von euch
- für alle unternehmen da draußen die software entwickeln fast immer der richtige ansatz ist mein name ist david auf diesem youtube kanal
- geht es um die themen softwarequalität softwarearchitekturen und alles was spaß macht im bereich der softwareentwicklung mein credo auf diesem kanal ist es auf
- jeden von euch jeden tag ein stückchen besser machen möchte im bereich der softwareentwicklung wenn ihr dem video einen daumen hoch gibt
- dann helft ihr mir dabei noch mehr entwickler zu erreichen und damit noch mehr entwickler jeden tag ein kleines stückchen besser zu machen wenn ihr das
- video gut finde wenn ich das thema gut finden und mehr zu dem thema sehen wollt dann empfehle ich euch abonniert den kanal und wenn ihr das macht dann
- bekommt ihr jede woche eine benachrichtigung wenn ein oder merken videos pro woche fertiggestellt werden und sei quasi von vornherein beim video
- mit dabei was werden wir heute machen wir werden uns mal das thema agile softwareentwicklung anschauen was sagt ich bereits aber wir fangen erst mal
- daran was agile softwareentwicklung nicht ist also die klassische art wie man software entwickelt hat oder heute das unternehmen auch nur machen wenn wir
- uns mal anschauen was daran so besonders gefährlich ist und werden dann mal die brücke geschlagen was denn genau agilität ist und dann wenn wir uns mal
- anschauen warum ist die agilität genau das richtige für die softwareentwicklung warum können wir damit wesentlich besser software entwickeln und welche vorteile
- ergeben sich daraus dann möchte ihn auf einen punkt eingehen nämlich aktivität ist nicht gleich chaos das erlebe ich in ganz ganz vielen
- projekt situationen in vielen beratungen und werden in sachen einmal müssen mehr mit dem thema beschäftigen ich denke da spreche ich einigen von euch aus der
- seele und wahrscheinlich jeder von euch wird die situation schon mal erlebt haben die ist aber ganz ganz gefährlich deswegen soll mit aber darauf eingehen
- wenn ihr bis zum ende dran bleibt da würde ich euch mal meine top drei gründe sagen warum jeder von euch software ag entwickeln sollte warum jedes team agil
- arbeiten sollte und jede software projekt ag durchgeführt werden sollte da gibt es eine ganze menge gründe aber ich zeige euch mal aus meiner erfahrung
- heraus in die top drei gründe die ich in jedem projekt sicher dass die dort einfach einen entscheidenden mehrwert für das ganze unternehmen für das
- projekt und verlusten ich würde sagen wir verlieren jetzt nicht viel zeit nach dem intro witzlos viel spaß
- [Musik] [Applaus] um zu erklären warum agilität für uns genau das richtige ist müssen wir erst
- mal erklären was aktivitäten nicht ist wie also eine klassische software entwicklung aussieht in der klassischen softwareentwicklung
- ist es so dass wir erst mal am anfang stakeholder das ist natürlich in der modernen auch so wir haben also irgendein fachbereich
- oder irgendeinen kunden und dieser kunde dieser fachbereich möchte gerne dass wir ein softwareprodukt wien entwickelt also die fachliche idee der weiß wie er
- seinem geschäft einen mehrwert hinzufügen kann und die softwareentwicklung ist jetzt quasi mit der aufgabe betraut dazu ein stück
- software zu entwickeln damit ich so ein stück software entwickeln kann muss sich allerdings erst mal zu sehen dass sich natürlich die anforderungen zu ermitteln
- und mit solchen klassischen vorgehensmodellen ist es so dass man normalerweise hingeht und einer liste eine vollständige liste einen
- anforderungskatalog zusammenstellt pflichten lastenheft kennen bestimmt einige von euch und dann von diesen pflichten lastenheft geht man dann hin
- und entwickelt die software das heißt wir neben erst alle anforderungen auch für dieses projekt was vielleicht fünf oder sechs jahre lang dauern wird
- wenn also mehrere leitz ordner voller szenario habe ich noch oftmals miterleben müssen leider und dann nehmen dann irgendwie nehmen wir diese
- leitzordner übergeben die in die softwareentwicklung und die software-entwicklung baut dann dazu entsprechend ein stück software so diese
- software entwicklung da reden wir jetzt ein bisschen genauer darüber wie das ganze intern aussieht aber am ende der entwicklung kommt dann hinten anfertigen
- software aus und diese software produkt können wir dann entsprechend unseren kunden zur verfügung stellen so dass er damit arbeiten können was ist jetzt das
- problem von dieser klassischen entwicklung nun das problem ist erstmal die vorgehensweise wie das ganze entwickelt wird es gibt in der
- softwareentwicklung verschiedene vorgehensmodelle diese vorgehensmodelle beschreiben einen prozess eine arbeitsweise die wir von der anforderung
- hin zum fertigen softwareprodukte hier in diesem fall arbeiten wir mit dem sogenannten wasser fallen oder das heißt am anfang geht marine sammelt alle
- anforderungen dann in meine anfordern gibt die in den nächsten schritt in die architektur macht ein architekt quasi an einen
- architekturgerüst außenrum zeigen verschiedene will diagramme und dann wird dann diese wuchs von urmel diagrammen und dieser riesenmenge an
- anforderungen an die entwicklung übergeben die entwicklung entwickelt das ganze dann mehrere jahre und irgendwann werden diese art effekte
- alle zusammen an die qualitätssicherung übergeben die führen dann die tests sind irgendwann nach ganz ganz langer zeit meistens mehrere jahre nachdem der kunde
- der stakeholder die software bestellt hat stellen wir diese software irgendwann mal bereit dadurch ergeben sich jetzt natürlich
- zahlreiche nachteile oder erste nachteil natürlich ist es dass wir lange brauchen bis wir ein ergebnis bekommen wenn also ein kunde eine ein stück software
- bestellt dann muss er warten bis diese software vollständig entwickelt wurde wenn ich jetzt größere software projekte habe heißt das dass ich meistens erst
- nach vielen vielen jahren nach längerer zeit eben diese software produkt als kunde bekomme und dann das erste mal der visuell visuelles feedback zu meinen
- gestellten anforderungen bekomme und dann sagen kann ob das ganze richtig war da nicht in dem zusammenhang ist es natürlich oft vorgekommen dass der kunde
- anforderung vielleicht um genau definierten anforderungen vergessen hat oder sonst irgendwelche fehler bei der anforderungsanalyse gemacht wurden und
- dieser fehler dieser fauxpas ist dann erst aufgefallen als die software nach langer langer zeit an den kunden ausgeliefert wurde
- was natürlich den kunden nicht zufrieden stellt und zum beispiel in meinen projekten vor langer zeit zum glück auch dafür gesorgt hat dass zum beispiel ein
- großes software produkt entwickelt wurde was dann zum zapfen des willys es gar nicht mehr verwendet werden durfte entweder war etwas falsch entwickelt
- wurde oder weil es mittlerweile gesetzesänderung gegeben hatte oder sonstige dienen das zweite ist natürlich dass dieser prozess extrem
- fehleranfällig habs grad schon mal bei den anforderung beschrieben aber ihr später ein fehler in diesem prozess in diesem wasserfall prozess entdeckt wird
- umso teurer wird es natürlich diese fehler zu werden das heißt wenn ich schon bei den anforderungen erkennt okay da hab ich irgendwas falsch aufgenommen
- weil die anforderung des inkonsistent dann kann ich das noch recht einfach beheben aber wenn ich zum beispiel erst in der
- entwicklung feststellen dass dort irgendetwas nicht passt oder welche anforderung nicht konsistent sind da muss ich diesen schritt davor eine
- architektur und die anforderung muss ich noch mal erneut durchführen und das testen ist ja quasi noch mal der entwicklung nachgelagert das heißt wenn
- ich dort fehler erkennen dann kann es sein dass sich in der entwicklung etwas neu machen muss oder vielleicht die architektur am ende
- oder ich dann dort feststellen dass der kunde gar nicht gestellt dann muss ich diese ganze kette also noch mal durchlaufen
- das heißt für für all diese aspekte die wir bis jetzt angesprochen haben ist eigentlich die klassische software entwicklung nicht besonders gut geeignet
- das nächste was wir haben ist natürlich verbunden mit dem was wir gerade gesehen haben dass diese fehler extrem teuer werden die meisten fehler
- erfahrungsgemäß einen solchen prozessen passieren in der anforderungsanalyse aus der kunde also an folgen nicht genannt hat sie nicht richtig aufgenommen wurden
- oder sonst irgendwelche dinge und wenn ich jetzt irgendwann das ganze auslieferung nach 45 jahren und deckung da hat bei einem modul zum beispiel ja
- irgendwas nicht richtig benannt oder die anforderung würde mich richtig formuliert da muss dieses modul unter umständen neu entwickelt werden dann
- muss dieser ganze prozess durchlaufen werden und das sorgt natürlich für extreme verzögerungen und nicht wirklich für eine akzeptanz im bereich der
- software beim kunden und der letzte problematischen punkt zumindest in dem wir uns hier anschauen ist es dass wir änderungen diesem prozess nicht machen
- können ich hatte ihn schon mal ein beispiel beschrieben mein kunde hat eine software entwickelt im versicherungsbereich und während der
- entwicklung des wahren entwicklungszeit von zweieinhalb jahren ist eine gesetzesänderung gekommen und diese gesetzesänderung hat dafür gesorgt dass
- wir beim release der software diese software gar nicht mehr benutzen konnten weil wir diese gesetzesänderung währenddessen nicht erfasst haben in den
- anforderungen und die dementsprechend auch gar nicht implementiert wurde in der software das waren jetzt mal nur vier probleme
- die mir die wir noch mal das waren die 24 probleme die wir mit so einem wasserfall prozess und so einem klassischen entwicklungsmodell in der
- praxis haben da gibt es eine ganze menge mehr ich denke wir können alleine ein ganzes video über die probleme der wasserfall entwicklung machen aber es um
- einen groben überblick darüber geben ich denke mal ihr habt da wahrscheinlich auch ein paar dinge die ich im kopf herumschwirren vielleicht hat ja schon
- mal dem wasser fragen gearbeitet können wir unterschreiben die kommentare was dieser für erfahrung gemacht hat dass ihre probleme und gab daher können wir
- einen ganzen katalog zusammenstellen aber wenn jetzt das wasser fallen modell so unglaublich schlecht ist für die
- software-entwicklung warum hat man das überhaupt genommen dazu müssen wir eine historie ein bisschen zurückgehen in den 80er 90er jahren gab es nur wenige
- unternehmen die software entwickelt haben es wurden aber immer mehr es kann immer mehr anwendungsfelder nation die geräte wurden immer günstiger und so
- fing die software an in alle bereiche reinzugehen alle industriebereiche in alle branchen rhein zu nehmen und deswegen auch branchen an software zu
- entwickeln die das eben nicht von der pike auf gelernt haben oder die nicht spezialisiert auf die softwareentwicklung machen ich habe am
- beispiel einen kunden um dieser kunde fertigt schaltschränke und haben schon schaltschränke gebaut seit knapp 100 jahren mittlerweile das verfahren des
- elektro schränke heute sind das die schaltschränke und die haben immer schon nach dem wasserfall modell gefertigt das heißt in so einem schaltschrank
- entwickelt wurde dann haben die am anfang erstmal wurde eine studie durchgeführt wurde geschaut was braucht der markt überhaupt dann gab
- es eine phase in der alle anforderungen gesammelt wurden und dann dokument angefertigt wurde über diesen schaltschrank der gebaut werden sollte
- dann wurde der konstruiert und dann wurde irgendwann eine produktionslinie aufgebaut und in dieser produktion produktionslinie wurde dann dieser
- schaltschrank gefertigt hinten dann vom band runtergenommen in der qualitätssicherung aber durch geprüft und dann entsprechend an den kunden
- ausgeliefert das ist so so oder so ähnlich der klassische prozess den man bei industrieller fertigung verwendet und da
- funktioniert das ganze auch ziemlich gut sondern diese unternehmen haben seit jahren mit genau diesen prozessen gefertigt und da ist es ja naheliegend
- wenn man jetzt mit seiner neuen ingenieurs disziplin die softwareentwicklung anfängt dass man die prozesse nimmt die man kennt und die
- seit jahren schon erfolgreich unternehmen laufen deswegen haben viele unternehmen angefangen mit dem wasserfall modell zu entwickeln und
- literatur mäßig mal ein bisschen zu rückblick war das damals auch der empfohlene prozess genau für die software-entwicklung malheurs disziplin
- mäßig sind in der software entwicklung relativ jung mit im vergleich zum beispiel zur mathematik und deswegen gibt es in unserer branche einfach nicht
- so viele erfahrungen damals dachte man das ja gut und hat daneben festgestellt das ist nicht so gut ist weil viele projekte schief gelaufen sind viele
- softwareprodukte waren irgendwann fertig und konnten dann gar nicht mehr eingesetzt werden und das hat sich mir so weitergezogen
- verstehen wollen warum da das wasser fallen modell so unglaublich schlecht ist da muss man verstehen was dass wir unterschiedliche
- prozessoren sind die dort abgebildet werden sollen wenn wir uns jetzt die schaltschrank fertigung anschauen david quasi die
- studie gemacht denn die konstruktion dann wird der wird die produktionsstraße aufgebaut und wenn wir uns an das ende von diesem produktionsband stellen dann
- nehmen wir mehr oder weniger immer denselben schaltschrank von diesem band runter diese art von prozessen nennt man wohl prozesse weil ich jedes mal
- dasselbe elemente daraus ziehe also bin ich jetzt pull prozesse habe dann kann ich das wasserfall modell oder wasser fertige prozesse verwenden ohne durch
- überdenken da ist das sogar ziemlich gut aber wie in der softwareentwicklung haben keinen pool prozess weil der softwareentwicklung werden quasi hinaus
- diesem prozess niemals dieselben arten von software ausgenommen das heißt jedes mal wenn wir neue iteration haben oder sonstiges dann kommt ein neuartiges
- produkt aus unserem software entwicklungsprozess raus warum ja und das nicht wie bei einem schaltschrank ist das vorne einmal anforderung rein
- gedrückt werden konnte mir das produkt raus sondern wir pushen kontinuierlich neue anforderungen vorne in diesem prozess rein und hinten nehmen wir dann
- immer ein andersartiges produkt runter ist eine wahre prozesse weil ihm das selbe raus geholt wurde und bei diesen software entwicklungs artigen prozessen
- reden wir von pusch prozesse mal vorne immer wieder neue anforderungen in die softwareentwicklung eingedrückt werden rein gepusht werden
- dabei ist das wasserfall modelleben extrem schlecht wenn wir das ganze noch mal grafisch wie sollen sie denn jetzt einmal quasi einmal die klassische
- variante und wir stellen uns mal so ein projekt einfach zweidimensional vor dann könnten wir sagen okay irgendwann haben wir mal einen staat das heißt wir
- starten mit unserem projekt mit unserem software projekt und wenn wir jetzt ein klassisches software entwicklungsmodell nehmen dann gehen wir hin und sagen okay
- wir wollen am anfang schon alle anforderung aufnehmen eine studie durchführen und wollen damit dann genau prognostizieren wo wir nach am ende
- irgendwann landen wollen das heißt wir jetzt davon ausgehen dass das ganze über mehrere jahre entwickelt wird dann ist das hier quasi das ziel das wir
- erreichen sollen also soll ziel und unsere aufgabe in der softwareentwicklung ist es jetzt quasi von dem start hin zu diesem ziel zu
- diesem soll ziel zu entwickeln das ist aber das problem dass wir manchmal anforderungen die richtig aufnehmen gerade wenn es solche großen mengen sind
- der kunde manchmal nicht weiß was er genau haben möchte in der entwicklung fehler gemacht werden und so weiter und so fort so dass es meistens so ist dass
- wir dieses ziel hinten gar nicht genau erreichen das heißt wir haben kein ziel wo wir hin wollen sondern wir haben erzählt was sie
- tatsächlich erreichen das ist ziel das heißt wir haben hier oben das hier gar nicht so entwickelte sondern wir gehen in eine ganz andere richtung und
- nun schon sondern entwickeln hier hin zu unserem ziel das heißt das was sie erreichen wollten haben wir nicht wenn das unter unterwegs änderungswünsche
- beim kunden gegeben hat haben wird die nicht erfasst ihr könnt euch denke ich mal dieser visualisierung ziemlich gut vorstellen was das problem genau von
- wasserfall prozessen werden kann und was man dort für für probleme bekommen kann und dann bekommt man auch so ein gefühl dafür warum damals wenn ihr schon ein
- bisschen älter seid genauso viele projekte in der schief gelaufen sind sollen wir uns hingehen und sagen wir wollen nicht klassisch sein sondern wir
- sind agiert haben wir ein ähnliches ausgangsszenario das heißt wir sind hier haben wir einen startpunkt und bei diesen startpunkt ist es ja so dass wir
- nicht sagen wir wollen jetzt alle anforderungen aufnehmen findigsten 34 56 jahre wir wollen nicht hingehen und wollen
- keine ahnung das gesamte produkt schon im kopf haben oder den kunden über das ganze produkt aus fragen sondern wir gehen zum kunden und sagen den kunden
- nokia konnte du willst ein produkt bauen aber sagen uns jetzt nicht was du alles haben willst und sagt uns erst mal was für dich das wichtigste ist und sagt uns
- die funktionalität die du gerne nächsten monat schon in der ersten kleinen version der software ist sondern kann der kunde sagen okay wir definieren uns
- hier so ein kleines winziges zwischenziel und wenn wir dann dieses zwischenziel haben in der entwicklung dann gehen wir
- hin und entwickeln quasi dieses stück software das stück software entwickelt haben dann können wir zum kunden gehen und können beim kunden sagen hier
- schauen wir bitte ist das völlig in ordnung oder nicht in ordnung kannst du dir so vorgestellt und was ist jetzt genau das
- nächste wichtige für dich da kann der kunde sagen okay für mich ist es jetzt das sind das wichtig das heißt er kann den kurs noch mal korrigieren und so
- entwickeln wir quasi von iteration zur integration entwickeln wie immer weiter und der kunde kann quasi die ganze zeit auf diesem weg immer wieder
- änderungswünsche einbringen und kann sagen okay hier hinten da will ich dann irgendwann mal sein das sagt dann natürlich erst ganz am ende mit seinem
- letzten änderungswunsch das heißt wie so eine kleine schlange hier nähern wir uns quasi immer diesem ziel an wir verfolgen also die wünsche unseres unseres kunden
- und durch diesen continental conti sportcontact feedback was wir bekommen von unseren kunden das ist so eine agile methode von der ich anfangs mal
- gesprochen habe durch dieses kontinentes feedback geben wir quasi von innen wie nach jeder operation hin und versuchen das wieder alles so zu machen das
- genauso ist wie der kunde des st das hier ist nur eine visualisieren das sag ich mal ungefähr ein gefühl dazu geben was ist klassisch und was genau ist
- daran anders an der agilität hier müsste jetzt aufpassen verwechselt das nicht mit integrativer software-entwicklung nur interaktiv ist nicht agil war die
- agilität sagen wie entwickelt integration und nach jeder operation sprechen wir mit unseren kunden holen und zum kunden feedback und lassen den
- kunden die nächste generation planen nachdem jetzt gerade einmal schon kurz auf die agile entwicklung drauf geschaut
- haben wollen wir das ganze jetzt mal ein bisschen konkreter machen wir haben ja eben auf den slides schon mal das beispiel gesehen wie die klassische
- entwicklung high level view mäßig aussieht jetzt gehen wir mal schauen uns das mal an für die agile entwicklung oder für die moderne entwicklung wird
- sie hier genannt wir haben natürlich genauso wie auf der linken seite auf der rechten seite aus der kohle wir haben also stakeholder die
- anforderung gegenüber der softwareentwicklung haben so weit so normal der erste unterschied ist jetzt aber
- dass die anforderungen die art und weise wie anforderung aufgenommen werden wir gehen nicht mehr hin und nehmen einen oder erstellen ein riesengroßes dokument
- wo alle anforderungen drin sind so die klassischen projekt dokumente sondern wir sagen den kunden einfach nur ok wir planen jetzt so eine integration von 30
- tagen beispielsweise was möchtest du nach diesen 30 tagen fertig haben das heißt dieser scope den wir betrachten der ist wesentlich kleiner als in der
- klassischen entwicklung wir fokussieren uns einfach nur auf das nächste ergebnis das nächste stück software das für diesen kunden präsentieren wollten das
- heißt wir haben viel kleinere menge an anforderungen die wir viel präziser formulieren können weil wenn es nur auf diesen einen bereich fokussieren müssen
- und nicht schon darüber nachdenken müssen was brauchen wir in drei vier fünf monaten oder sonst etwas diese anforderung die dort seht die wir
- auch so genannten story cards formuliert das heißt ja nicht mehr ein großes dokument sondern ihr könnt euch das vorstellen einfach nur wie normaler den
- a4 zettel auf denen diese antwort darauf steht das heißt ja eine nummer wir haben titel wir haben eine beschreibung vielleicht oberflächen produkttypen wir
- haben akzeptanz kriterien und so weiter und so fort denn diese anforderung auf diesem zettel die dort definierte die user story oder
- später auch bei scrum product backlog altem genannt wie wird später an den entwickler übergeben dass er das feature entwickelt
- das heißt entwickler muss seinerseits nicht hingehen und dieses riesengroße dokument der herunter brechen auseinander pflücken den einzelnen
- aufgaben darunter brechen sondern diese tätigkeit wird schon bei der anforderungsanalyse durchgeführt und diese user stories die wir dann dort
- schreiben auf diesen story cars die werden dann an die entwicklung weitergehen soll entwicklung weiß jetzt wir machen jetzt eine iteration über 30
- tage mal wegen die können sich jetzt von diesen stapel von anforderungen so viele anforderungen unternehmen wie sie in den nächsten 30 tagen oder je nach
- wie lange die situation ist wie dort entwickelt werden kann so das heißt wir nehmen jetzt diese anforderungen und in der entwicklung entwickeln wir das ganze
- schreiben hatte quellcode dazu setzen diese anforderungen mit programmiert technischen mittel um so dass wir nachher ein stück software sei am ende
- der entwicklung müssen wir den kunden natürlich ein stück software zeigen wir wollen ja den kunden zeigen dass er jetzt bestellt hat vor einem monat und
- man dieses customer feedback zu kommen das ganze machen wir mit so einer sogenannten pipeline das heißt wir haben hier eine gehen wir später ein bisschen
- genau darauf ein bisschen bild server oder eine eine ja eine kette von verschiedenen dingen die dort automatisiert durchgeführt wird und am
- ende des tages hier so ein produkt bereit zu stellen und dieses produkt können wir dann wieder den kunden zuführen und der kunde kann dann von
- sich aus sagen okay bin ich total zufrieden mit oder da wir uns vielleicht ein bisschen missverstanden oder jetzt wo ich das glaube ich noch eine coole
- idee das heißt sie entwickeln von integration zur integration entwickeln wir so dass unser kunde immer sagen kann direkt einfluss auf das nächste auf die
- nächste generation geben kann und uns neuen input und neues wertvolles feedback darüber gehen kann wie diese software weiterentwickelt werden soll
- das ist genau das was sie in der vorigen grafik gesehen habe wie therapieversuche nadine krause den kundenwünschen zu folgen um nachher genau bei dem ziel
- raus zu kommen was der kunde auch tatsächlich am ende des tages haben jetzt haben wir mal geklärt was ist agilität agilität ist es also wenn wir
- nicht nur integration entwickeln sondern immer nur portionsweise die anforderung von unseren kunden holen und nach jeder operation dem kunden das funktionsfähige
- zwischenprodukt zur verfügung stellen und feedback darüber einholen und dann gemeinsam mit dem kunden die nächste iteration planen sie quasi immer die
- kundenwünsche folgen wie wir das in der einen grafik eindrucksvoll gesehen haben jetzt habe ich auch mal eingangs erwähnt nach dieser definition dessen was die
- agile methoden geben und agile techniken gibt usw und unter anderem auch agile prozesse wir gucken uns jetzt mal diese agile
- prozesse an als die agilität damals aufgekommen ist so anfang der 2000er jahre war die das erste der erste agile prozess also die vorschrift wie man
- jetzt agieren so einem prozess software entwickelt das sogenannte extreme programming das ist damals vom comeback glaube ich erfunden worden ich weiß es
- gar nicht mehr genau und auf jeden fall extrem programmhinweise die erste sammlung an methoden die wir an die hand bekommen
- haben um agile software zu entwickeln diese story cars zum beispiel waren die in extreme programm unit tests war auch ein bestandteil von extreme programming
- und testament ebenfalls glaube ich wenn wir gar nicht genau sicher aber es war der erste ansatz ein prozessmodell zusammenzubauen roubira die software
- bereitstellen können das problem dabei war immer dass die anforderungsanalyse so ein bisschen stiefmütterlich behandelt wurde das heißt für die
- entwicklung gab es viele vorschriften wie man agilität umsetzen kann im bereich der anforderung war der meinung nach war das ganze ein bisschen
- schwach und dann ist irgendwann der primus auch das meistverwendete prozess agile prozessmodell von heute herausgekommen nämlich bei scrum gibt es
- zwei sehr starke prozessschritte einmal die anforderungsanalyse und daneben die tatsächliche produktentwicklung und tram setzt diese ganzen agieren wehrte diese
- agile manifest dieser agilen methoden und dinge extrem gut und wir haben am anfang eine anforderungsanalyse bei der eine separate personen sogenannte
- product owner mit diesen stakeholder zusammen diese anforderungen erarbeitet werden es kam dann product backlog altem genannt und danach gibt es dann einen
- 30-tägigen sprint sondern man die integration was kommen bei dem das ganze entwickelt wird das wird es nur eine möglich
- ein agiler prozess mit dem ich agile software entwickeln kann ein anderer zb iskender erkennbaren funktioniert ähnlich auch da wird die
- anforderung anforderungs vermittelt so ähnlich durchgeführt wie wir es gerade was kommen gesehen haben und danach blick wenn ich ihre integration sondern
- wir entwickeln in einem flow das heißt wir haben wir haben einen prozess und in diesem prozess darf immer nur eine gewisse menge an elementen bearbeitet
- werden vor das nächste angefangen wird und damit bekommen wir quasi so einen kontinuierlichen feature stream durch unsere entwicklung hindurch wir wollen
- jetzt doch gar nicht so sehr in diese bereiche reingehen aber erstmal agile softwareentwicklung beschreibt die art und weise wie wir das ganze umsetzen
- und dann gibt es dazu agile prozesse wie extreme programming scrum can bern mit denen wir das ganze dann konkreter machen können wenn ihr das ganze
- einfinden wollt dann solltet ihr euch diese agilen prozessmodelle mal anschauen weil es ist eigentlich immer das dorf entwickeln so entweder passt
- bei uns kommen sehr gut in der konstanten oder ihr könnt das ganze mit kälbern machen wenn ihr dazu war noch ein paar videos haben will schreibt
- unter die kommentare dann machen wir mal als dazu nachdem wir uns die agilität jetzt allgemein angeschaut haben uns die agile
- prozesse angeschaut haben will ich noch auf einen punkt ganz explizit hinweisen ich habe schon gesagt ich bin berater und ich bin öfters in kundenprojekten
- unterwegs und am anfang analyseprozesse entwicklungen technologie stacks architektouren und so weiter und wenn zum prozess kommt immer ganz schnell die
- aussage wir die wir entwickeln agieren und wenn man dann mal ein bisschen nach port und findet man einfach heraus okay die entwickeln zwar immer wieder in so
- einer art integration aber total planlos mal dauert die in der woche x 2 x 3 x noch ein paar tage anwendungen werden nur hier und da mal bereitgestellt
- anforderungsanalyse gibt es gar nicht in der cool beruf direkt beim entwickler an entwickler muss immer wieder direkt beim kunden nachfragen es ist also kein
- wirklicher prozesse und es ist einfach nur eine rein chaotische entwicklung ganz ganz wichtig ist es dass ihr das nicht verwickelt er verwechselt wenn wir
- so chaotisch wie gerade entwickeln oder wahrscheinlich werde die auch da draußen genügend beispiele habe wie gesagt da freue ich mich nach einer woche
- kommentare hat das überhaupt nichts mit agilität zu tun agilität heißt einfach nur dass wir nicht in großen blöcken entwickeln sollen dass wir in kurzen
- integration entwickeln und den kunden mit einbeziehen das heißt nicht dass wir keine anforderungsanalyse machen das heißt auch nicht dass wir in irgendeiner
- art und weise keinen expliziten prozess haben sondern quasi einfach nur frei schnauze entwickeln sondern wir haben feste prozesse wir haben eine feste
- anforderungsanalyse aber wir machen das ganze in kurzen integrationen bin dabei den kunden mit ein ganz ganz wichtig dass sie das nicht mit der chaotischen
- software-entwicklung vermixt oder sonst irgendetwas sondern in der agilen softwareentwicklung gibt es ganz ganz ganz klare regeln wie gesagt diese agile
- manifest solltet ihr euch mal durchlesen wenn ihr in dem bereich was machen wollen weil darin diese regeln relativ geschrieben wenn ihr dann hingeht und
- nutzt 1 diese agieren prozessmodell die wir eben besprochen haben heute ist es meistens kennen lernen oder es kam dann solltet ihr peinlichst genau darauf
- achten das ist auch genau so umsetzt wie es gefordert ist man kann da hier und da anpassungen machen aber sie müssen sich das so vorstellen es gibt agile methoden
- da gibt es ganz ganz viel gewonnen und diesen ag prozessmodellen kennen lernen und zusammen sind gezielt bestimmte methoden aus diesem werkzeugkasten
- rausgenommen und sind in so prozess framework diese methoden miteinander funktionieren extrem gut werden aber einzelne
- anpassungen macht aus eigener motivation heraus dann kann es sein dass man mit dieser anpassung das gesamte prozess modell komplett kaputt macht bestimmt
- beste beispiel wenn ich ins kommen zum beispiel kann scrum master habe kann dedizierten dann ist der ganze prozess für die tonne
- wenn ich in scrum kein keine retrospektive mache habe ich keinen kvp kontinuierlicher verbesserungsprozess ist das ganze ebenfalls für die tonne
- deswegen gebe ich selber hart ins gericht und versucht selber mal genau zu definieren sei die agile ja oder nein macht ist gramm ja oder nein
- und am ende des tages immer noch besser wenn ihr zu der ehrlichen einsicht kommen wir sind nicht agieren wir haben einfach keinen prozess entwickelt
- chaotisch weil dann habt ihr habt ihr ein gutes resultat auf dem wir aufbauen können und dann richtung agilität staaten können richtung im konkreten
- agieren prozessmodell wie scrum oder campen gehen können aber seit an der stelle ehrlich weil ich sehe das wirklich ganz ganz oft sich selber in
- die tasche zu packen bringt an der stelle überhaupt nichts wir müssen über eine ganze menge nachteile das wasser fallen modells gesprochen auf der
- anderen seite von den ganzen vorteilen der agilen softwareentwicklung ich hatte ja schon versprochen am ende die euch mal meine top drei vorteile
- oder geschenke die er mit der agilität bekommt das sind nur drei von ganz ganz ganz vielen also die agile software entwickelt sich eine großartige sache
- und jeder von euch sollte sich genau mit diesem thema beschäftigen aber ich habe im laufe der zeit herausgefunden dass eine ganze oder ist das eine reihe von
- vorteilen da ist die die kunden am anfang gar nicht so wertschätzen nach vielen jahren lieben der erste punkt ist zum beispiel das
- direkte kundenfeedback wenn man in unternehmen agile softwareentwicklung anfühlt dann sehe ich das ganze oft dass dort bereits eine gewisse spannung ist
- durch eine fachabteilung und den software entwicklern oder zwischen der software gegen verteilung den zahlreichen kunden in dem moment wo man
- switched auf einer software entwicklungsmodell und dieses rapid- feedback von seinem kunden bekommt der kunde also in hoher frequenz neue
- software version bekommt und immer wieder quasi direkt einfluss auf die nächste rationen kann sorgt das einfach für ein unglaubliches
- zusammengehörigkeitsgefühl für eine unglaublich enge kundenbindung und unglaublich gute ergebnisse die wir mit diesen sprint zu ziehen
- deswegen ist für mich der erste unglaublich positive punkt dieses direkte kundenfeedback und diese nahe zusammenarbeit die man dadurch
- ja mit dem kunden bekommt dieses horrorszenarios ich geschrieben habe dass irgendwann stück software rauskommt und der kunde sagt bo ist hab ich
- überhaupt nicht gestellt da kann ich nichts anfangen habe ich den agilen software-entwicklung einfach noch nie erlebt so das zweite
- der zweite große vorteil sind natürlich die schnellen time-to-market ich kenne viele kunden die in ihrem bereich marktführer sind die software systeme
- entwickelt haben für gewisse nische und unglaublich viele kunden haben und unglaublich arrogant sind und denken dass sie an diesem bereich ja überhaupt
- nicht angegriffen werden können und dann kommt ein kleines startup und ist kleine start up entwickelt agil und ist unglaublich schnell in der lage neue
- software-version raus zu bringen und neue features haus zu bringen die dann mag gerade braucht während die mit klassischer anwendungsentwicklung
- meistens auch mit großen monolithen eben nicht mehr so flexibel sind nicht mehr so agil sein können und dann habe ich schon oft jetzt erlebt das eben solche
- kleinen unternehmen die großen ruck zuck eingeholt haben und ruckzuck quasi große kunden mengen abgeworben haben und mein kunde dann in großen problemen gekommen
- ist deswegen da müsste ja auch immer darüber nachdenken wir reden hier offen natürlich über die entwicklungs vorteile klar aber aus geschäfts strategischer
- sicht sind diese tank to mark its heute immer mehr software da ist wo wir systeme da sind eine immer größere rolle spielt einfach unfassbar wichtig und
- wenn die tante markets aus agiler softwareentwicklung mit der traditionellen vergleich sind einfach welten zwischen heute mit klassischer
- softwareentwicklung zu arbeiten ist ein unglaublich großes risiko sagte dritte und letzte punkt mein persönlicher liebling doch sonst mal platz eins ich
- mach das doch ein ranking das ist kvp kontinuierlicher verbesserungsprozesse vollständig ausgeschrieben es ist in scrum zum beispiel die retrospektive
- wenn ich etwas wiederholen mache wenn ich immer wieder integration irgendetwas macht habe ich am anfang der aktion immer die möglichkeit alles besser zu
- machen als beim letzten mal deswegen gibt es supervisionen deswegen gibt es in scrum die retrospektive und in diesem meeting setze ich mich hin
- überlege was habe ich im letzten sprint schlecht gemacht und der letzten generation was ist schief gelaufen das hat mir nicht gut gemacht und wie kann
- man das in den nächsten spielen besser machen und was haben wir gut gemacht und wie kann ich das ganz für den nächsten spielen konservieren wenn man das
- wirklich ernst nimmt das kontinuierlich mit männer mit einer gewissen hingabe macht dann kann man unglaublich gute dinge erreichen wenn
- ich mit scrum anschaust kam richtig machen und noch mal immerhin scrum master haben immer eine retrospektive machen die wichtigsten dinge was klang
- meiner meinung nach dann können wir nach 67 sprints eine dermaßen hohe performance erreicht haben wo alle entwickler sich wohlfühlen wo die kunden
- super mit eingebunden sind wir alle prozesse automatisiert sind das wo die systeme weitgehend automatisiert sind und so weiter und so fort
- es ist einfach ein unglaublich tolles und schönes arbeiten wenn man quasi nach jeder operation die nächste generation noch besser machen kann und ganz ehrlich
- das ist definitiv mein lieblings punkt deswegen nochmals zusammengefasst einmal das direkte kundenfeedback dann zwei die schnelleren time-to-market und 300
- profitieren wie entwickler ganz besonders von kontinuierliche verbesserung ist einfach einer der wichtigsten dinge in so einem putsch
- prozess wieder softwareentwicklung und deswegen allein deswegen solltet ihr also ich mich dagegen dass dort entwicklung beschäftigt am ende doch
- sehen wir natürlich auch was denkst du was sind deine top drei gründe die drei top benefits die du hattest als neuer unternehmen die ergebnisse
- software-entwicklung angeführt hat schreibt mal wieder runter in die kommentare lasst uns mal wieder über das thema diskutieren
- das hat schon in den letzten videos echt großartig funktioniert wir haben jetzt in diesem video mal überblick geben über die agile
- softwareentwicklung und nachdem wir jetzt agil anforderungen können ag das ganze entwickeln ist nur noch ein großes fragezeichen über dem wie liefere ich
- jetzt diese software agil schnell zu meinem kunden und damit kommen wir dann zum thema des aber dazu mehr im nächsten video
- ich hoffe die hat dieses video gefallen ich hoffe das trio hatte ich wieder ein kleines stückchen weiter nach vorne gebracht und wie immer am ende wenn es
- dir gefallen hat und du den kanal helfen willst die reich war der hinweis gibt dem video und daumen hoch wenn du noch nicht abonniert hat dann macht das und
- ich würde sagen ich wünsche dir einen schönen tag viel spaß bei der arbeit bis zum nächsten mal machs gut
Zum Nachlesen
Agile SoftwareentwicklungAgile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams sowie eine iterative und inkrementelle Vorgehensweise aus. Agile Ansätze können sich …
ScrumScrum (englisch für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung.
Adaptive Software DevelopmentASD ist eine Umsetzung des Prinzips der „kontinuierlichen Anpassung“ an immer neue Anforderungen und soll das konventionelle Wasserfallmodell ersetzten.
WasserfallmodellEin Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, das insbesondere für die Softwareentwicklung verwendet wird und das in …