Wie schon bei den letzten Videos: lasst uns über das Thema diskutieren! seid Ihr schon agil? Was waren die größten Vorteile die Ihr erzielen konntet und was ist auf dem Weg dahin schiefgelaufen? Und wie immer: *abonniert* den Kanal um kein Video mehr zu verpassen!
Super hilfreich, genau das wonach ich gesucht habe. Ein Thema, dass auch sehr komplex werden kann, sehr simpel und gut strukturiert dargestellt, um einen soliden Gesamtüberblick über agile Softwareentwicklung zu vermitteln. Danke.
Ich bin seid über 10 Jahren in der Business Intelligence Entwicklung tätig. Das klassische Wasserfallprinzip hat schon lange ausgedient, genau aus den besagten Punkten. Azure DevOps, JIRA und Co. machen mir und meinen Kollegen das Leben leichter. Aus Erfahrung kann ich es voll empfehlen. Inzwischen werden diese agilen und iterativen Projektmethoden auch in Verwaltungen und anderen Bereichen eingesetzt. Ein guter SCRUM Master kann Ordnung und Organisation in das Projekt bringen, obgleich wir nicht alle Aspekte des Prozesses nutzen, wie z.B. die Retrospektive, weil eingespielt usw. Danke David 👍
Lieber David, vielen lieben Dank für dieses aufklärende Video wie etablierte Unternehmen Ihre Projekte damals zu heute planen und umsetzen. Nun bin ich doch sehr über die komplexität eines größeren zu betreuenden Projektes in all ihren facettenreichen Phasen von Beginn bis Auslieferung erstaunt und frage mich nun ob es als JuniorDev welcher sich den Abschluss zum Java-Developer mit nem 1,9er Schnitt Autodidaktisch über ein Fernstudium erarbeitet hat, sinnvoll wäre direkt als Freelancer durchzustarten oder dieser Schritt aufgrund fehlender Erfahrungen ein grober Fehler mit bösen erwachen sein könnte? Ich freue mich über jeden inspierenden Ratschlag und bedanke mich für den hochwertigen Content dieses Kanals. 😉 Lg
Hallo Benjamin, kommt darauf an, was Dein Ziel ist. Wenn Du möglichst schnell viel und unterschiedliche Erfahrungen sammeln möchtest, wäre der Job als Freiberufler doch ideal. Auf der anderen Seite wird es natürlich schwer ohne Erfahrung überhaupt Projekte zu bekommen, dafür gibt es natürlich auch Vermittlungsagenturen wie Hays. etc. die Dir dabei helfen. Gruß David
Hallo Martin, da ich das Video nicht mehr genau kenne und mir gerade die Zeit fehlt um es ganz anzuschauen: welches Projekt meinst Du konkret? Gruß David
Hallo David, habe mir mal das Video angesehen um zu verstehen was die Vorteile der agilen Entwicklung zum alten Wasserfallmodell sind (da bei uns in absehbarer Zeit so eine Umstellung im Haus ansteht). Ich habe mal zu dem Thema Pull & Push eine Frage: Bei uns ist es so das in eine seit Jahren bestehen Software immer neue Features/Anforderungen implementiert werden. Das heißt auf der Eingangsseite der Entwicklung sind wir auf Push ausgelegt allerdings ist am Ende der Entwicklung immer die gleiche Software nur mit den erweiterten Funktionsumfang das Ergebnis, also eigentlich Pull. Jetzt stellt sich mir natürlich die Frage ist dann die Umstellung vom Wasserfallmodell auf agile Entwicklung sinnvoll?
Hallo Micha, pull wäre es nur, wenn ihr immer wieder die selbe unveränderte Software liefern würdet - was ja in der Softwareentwicklung gar keinen Sinn macht. Ihr "pusht" vorn immer neue Anforderungen rein, welche hinten dann zu einem immer komplexeren und anderen Produkt werden - also Push. Deshalb: ja, agil macht Sinn - Softwareentwicklung kann per Definition nicht "pull" sein. Gruß David
Was ist wenn man gar keinen Kunden hat? Man entwickelt eine Software für ein Gerät, dass direkt in großen Stückzahlen in den Markt kommt und möglichst fertig und fehlerfrei sein soll. Kann man die Methode dafür adaptieren?
Ich hätte gerne ein Video das SCRUM und Kanban vergleicht. Und Planungssicherheit interessiert mich bei SCRUM. Also was stellst du wann wie dem Kunden in Rechnung?
Danke für das Video! Also wenn ich das richtig verstanden habe ist Agile Softwareentwicklung das Konzept und XP, Scrum und Kanban sind die konkreten Strategien, die das Konzept umsetzen?
Hallo David - Erstklassig beschrieben! Ich konnte zusätzlich noch etwas davon mitnehmen. Ich habe noch nie richtig nach Scrum gearbeitet, noch arbeiten können. Viele machen eher Scrumbaan. Oder ich habe Dailys mit mehr als 3 Stunden Dauer erlebt, gruselig. In Jeff Southerlands Buch, wird aber auch beschrieben, dass Agile Softwareentwicklung, kein Freifahrtschein für zusätzliche Aufgaben oder generelle Änderungen bedeuten soll. Wie Du schon sagtest, auf dem Markt, dem Gesetzänderungen reagieren zu können. Man muss ja auch zu einem Ende kommen. Ein Endziel muss doch definiert sein, um nicht wie der BER zu enden. Oder bedeutet Scrum, immer Ende offen?? Dem würde es ein Fass ohne Boden entsprechen, oder? Gruß Marcus
Hallo Marcus, schön das es Dir gefällt. Bei dem Endziel würde ich eher von einer Vision sprechen, als von einem Ziel weil für mich ein Ziel ein genau definierter Endzustand ist. Das erreichen wir mit Iterationen und am Ende ist es das Ziel, aber der Fokus liegt auf dem Weg dorthin immer auf der nächsten Iteration mit der Vision des Ziels im Hinterkopf. Ich habe bis heute noch nie ein Softwareprojekt erlebt, was nach Fertigstellung nicht mehr geändert wurde, also ist das mit dem "zu einem Ende kommen" immer relativ in meinen Augen :) Gruß David
@@DavidTielke hallo David. Ja das ist richtig. Aber es muss doch erst mal ein Punkt erreicht werden, wo z.B. das Projekt als erfolgreich abgenommen wird. Natürlich wird es in Zukunft Anpassungen geben. Und je nachdem wie das System entwickelt wurde mit mehr oder weniger Aufwand. Das Problem ist doch häufig dass, das Aufsichtsräte und Co. an Zeiten und Zahlen hangeln. Ist ja auch ihr Job. Alle die ich erlebt habe, brauchen eine Dauer und ein Endtermin, um kalkulieren zu können, welche Budget einzuplanen ist. Auch ein BER wird weiter entwickelt werden. Aber es muss ein Ende fixiert werden, wo die Grundvorrausetzungen erfüllt sein müssen, um mit dem Projekt arbeiten zu können. Sonst wäre es ja auch ein Freifahrtschein, einfach als Team irgendwie weiter zu machen. Eine Vision ist schön, aber ich glaube Visionen, ist das letzte was der Geldgeber hier hören möchte. Er will wissen. Wann ist das Projekt fertig, wann ist das alte weg und wann wirft die neue Entwickelte Software Geld für mich ab. Und wenn es nur verbesserte UseCases sind, die dafür sorgen. Natürlich hängt das wieder am Gesamtkonzept ab. Aber ich kann ja auch nicht unbedingt erwarten, dass z.B. die interne Abteilung über Jahre mit 2 Softwaresystemen arbeiten muss, dadurch Mehraufwand hat, weil die Entwicklung, es so tut wie sie es dann tut. Gruß
Soweit ich das verstehe verlagert agile Softwareentwicklung die Erstellung von Pflichten und Lastenheften auf Kundenseite, auch wenn der Umfang iterativ kleiner wird als im klassischen Fall können in der Summe die iterativen Prozesse deutlich länger sein als im klassischen H2OFallmodell. Was ist wenn Softwareprodukte für Geräte entwickelt werden müssen, die nicht am Kunden sondern an einer nicht näher definierten Marksituation orientiert sind ? Ich bin daher der Meinung, dass ein vernünftiges Mixup aus agil und klassischer Methoden angesagt sind. Endgültige vollständige Dokumentation bleibt m.E. bei agiler Arbeitsweise fast immer auf der Strecke.
Diese Unterscheidung zwischen Pull und Push Prozess ergibt überhaupt keinen Sinn. Ich kann doch genauso immer die gleichen Inputs pushen und unterschiedliche Outputs pullen... Die Benennung ist nicht sprechend.
![Scrum - Von A bis Z [Mit Profi-Tipps]](http://i.ytimg.com/vi/QtTH3m8GfN0/mqdefault.jpg)
![Scrum - Von A bis Z [Mit Profi-Tipps]](/img/tr.png)
Wie schon bei den letzten Videos: lasst uns über das Thema diskutieren! seid Ihr schon agil? Was waren die größten Vorteile die Ihr erzielen konntet und was ist auf dem Weg dahin schiefgelaufen? Und wie immer: *abonniert* den Kanal um kein Video mehr zu verpassen!
Super hilfreich, genau das wonach ich gesucht habe. Ein Thema, dass auch sehr komplex werden kann, sehr simpel und gut strukturiert dargestellt, um einen soliden Gesamtüberblick über agile Softwareentwicklung zu vermitteln. Danke.
Ich bin seid über 10 Jahren in der Business Intelligence Entwicklung tätig. Das klassische Wasserfallprinzip hat schon lange ausgedient, genau aus den besagten Punkten. Azure DevOps, JIRA und Co. machen mir und meinen Kollegen das Leben leichter. Aus Erfahrung kann ich es voll empfehlen. Inzwischen werden diese agilen und iterativen Projektmethoden auch in Verwaltungen und anderen Bereichen eingesetzt. Ein guter SCRUM Master kann Ordnung und Organisation in das Projekt bringen, obgleich wir nicht alle Aspekte des Prozesses nutzen, wie z.B. die Retrospektive, weil eingespielt usw.
Danke David 👍
Top erklärt
Super Video ❤
Lieber David, vielen lieben Dank für dieses aufklärende Video wie etablierte Unternehmen Ihre Projekte damals zu heute planen und umsetzen. Nun bin ich doch sehr über die komplexität eines größeren zu betreuenden Projektes in all ihren facettenreichen Phasen von Beginn bis Auslieferung erstaunt und frage mich nun ob es als JuniorDev welcher sich den Abschluss zum Java-Developer mit nem 1,9er Schnitt Autodidaktisch über ein Fernstudium erarbeitet hat, sinnvoll wäre direkt als Freelancer durchzustarten oder dieser Schritt aufgrund fehlender Erfahrungen ein grober Fehler mit bösen erwachen sein könnte? Ich freue mich über jeden inspierenden Ratschlag und bedanke mich für den hochwertigen Content dieses Kanals. 😉 Lg
Hallo Benjamin,
kommt darauf an, was Dein Ziel ist. Wenn Du möglichst schnell viel und unterschiedliche Erfahrungen sammeln möchtest, wäre der Job als Freiberufler doch ideal. Auf der anderen Seite wird es natürlich schwer ohne Erfahrung überhaupt Projekte zu bekommen, dafür gibt es natürlich auch Vermittlungsagenturen wie Hays. etc. die Dir dabei helfen.
Gruß David
Sehr gutes Video! Weiter so 👌
Abo ist raus
Vielen Dank, mache ich!
Gruß David
Tolles Video! Bevor ich mich in weiteren Kommentaren oder Analysen ergehe: hatte dieses Projekt einen Scrum Master?
Hallo Martin,
da ich das Video nicht mehr genau kenne und mir gerade die Zeit fehlt um es ganz anzuschauen: welches Projekt meinst Du konkret?
Gruß David
Hallo David, habe mir mal das Video angesehen um zu verstehen was die Vorteile der agilen Entwicklung zum alten Wasserfallmodell sind (da bei uns in absehbarer Zeit so eine Umstellung im Haus ansteht). Ich habe mal zu dem Thema Pull & Push eine Frage: Bei uns ist es so das in eine seit Jahren bestehen Software immer neue Features/Anforderungen implementiert werden. Das heißt auf der Eingangsseite der Entwicklung sind wir auf Push ausgelegt allerdings ist am Ende der Entwicklung immer die gleiche Software nur mit den erweiterten Funktionsumfang das Ergebnis, also eigentlich Pull. Jetzt stellt sich mir natürlich die Frage ist dann die Umstellung vom Wasserfallmodell auf agile Entwicklung sinnvoll?
Hallo Micha,
pull wäre es nur, wenn ihr immer wieder die selbe unveränderte Software liefern würdet - was ja in der Softwareentwicklung gar keinen Sinn macht. Ihr "pusht" vorn immer neue Anforderungen rein, welche hinten dann zu einem immer komplexeren und anderen Produkt werden - also Push.
Deshalb: ja, agil macht Sinn - Softwareentwicklung kann per Definition nicht "pull" sein.
Gruß David
Was ist wenn man gar keinen Kunden hat? Man entwickelt eine Software für ein Gerät, dass direkt in großen Stückzahlen in den Markt kommt und möglichst fertig und fehlerfrei sein soll. Kann man die Methode dafür adaptieren?
Ich hätte gerne ein Video das SCRUM und Kanban vergleicht. Und Planungssicherheit interessiert mich bei SCRUM. Also was stellst du wann wie dem Kunden in Rechnung?
Danke für das Video! Also wenn ich das richtig verstanden habe ist Agile Softwareentwicklung das Konzept und XP, Scrum und Kanban sind die konkreten Strategien, die das Konzept umsetzen?
sehr gerne, schön dass es dir gefällt :)
ja, genau so sieht es aus!
Gruß David
@@DavidTielke Danke! Das ist das beste Video zu dem Thema, das ich finden konnte. Habs endlich verstanden 😀
Hallo David - Erstklassig beschrieben!
Ich konnte zusätzlich noch etwas davon mitnehmen.
Ich habe noch nie richtig nach Scrum gearbeitet, noch arbeiten können.
Viele machen eher Scrumbaan. Oder ich habe Dailys mit mehr als 3 Stunden Dauer erlebt, gruselig.
In Jeff Southerlands Buch, wird aber auch beschrieben, dass Agile Softwareentwicklung, kein Freifahrtschein für zusätzliche Aufgaben oder generelle Änderungen bedeuten soll.
Wie Du schon sagtest, auf dem Markt, dem Gesetzänderungen reagieren zu können.
Man muss ja auch zu einem Ende kommen. Ein Endziel muss doch definiert sein, um nicht wie der BER zu enden.
Oder bedeutet Scrum, immer Ende offen??
Dem würde es ein Fass ohne Boden entsprechen, oder?
Gruß
Marcus
Hallo Marcus,
schön das es Dir gefällt.
Bei dem Endziel würde ich eher von einer Vision sprechen, als von einem Ziel weil für mich ein Ziel ein genau definierter Endzustand ist. Das erreichen wir mit Iterationen und am Ende ist es das Ziel, aber der Fokus liegt auf dem Weg dorthin immer auf der nächsten Iteration mit der Vision des Ziels im Hinterkopf. Ich habe bis heute noch nie ein Softwareprojekt erlebt, was nach Fertigstellung nicht mehr geändert wurde, also ist das mit dem "zu einem Ende kommen" immer relativ in meinen Augen :)
Gruß David
@@DavidTielke hallo David.
Ja das ist richtig.
Aber es muss doch erst mal ein Punkt erreicht werden, wo z.B. das Projekt als erfolgreich abgenommen wird.
Natürlich wird es in Zukunft Anpassungen geben. Und je nachdem wie das System entwickelt wurde mit mehr oder weniger Aufwand.
Das Problem ist doch häufig dass, das Aufsichtsräte und Co. an Zeiten und Zahlen hangeln. Ist ja auch ihr Job.
Alle die ich erlebt habe, brauchen eine Dauer und ein Endtermin, um kalkulieren zu können, welche Budget einzuplanen ist.
Auch ein BER wird weiter entwickelt werden. Aber es muss ein Ende fixiert werden, wo die Grundvorrausetzungen erfüllt sein müssen, um mit dem Projekt arbeiten zu können.
Sonst wäre es ja auch ein Freifahrtschein, einfach als Team irgendwie weiter zu machen.
Eine Vision ist schön, aber ich glaube Visionen, ist das letzte was der Geldgeber hier hören möchte.
Er will wissen. Wann ist das Projekt fertig, wann ist das alte weg und wann wirft die neue Entwickelte Software Geld für mich ab.
Und wenn es nur verbesserte UseCases sind, die dafür sorgen.
Natürlich hängt das wieder am Gesamtkonzept ab. Aber ich kann ja auch nicht unbedingt erwarten, dass z.B. die interne Abteilung über Jahre mit 2 Softwaresystemen arbeiten muss, dadurch Mehraufwand hat, weil die Entwicklung, es so tut wie sie es dann tut.
Gruß
Soweit ich das verstehe verlagert agile Softwareentwicklung die Erstellung von Pflichten und Lastenheften auf Kundenseite, auch wenn der Umfang iterativ kleiner wird als im klassischen Fall können in der Summe die iterativen Prozesse deutlich länger sein als im klassischen H2OFallmodell.
Was ist wenn Softwareprodukte für Geräte entwickelt werden müssen, die nicht am Kunden sondern an einer nicht näher definierten Marksituation orientiert sind ? Ich bin daher der Meinung, dass ein vernünftiges Mixup aus agil und klassischer Methoden angesagt sind.
Endgültige vollständige Dokumentation bleibt m.E. bei agiler Arbeitsweise fast immer auf der Strecke.
Diese Unterscheidung zwischen Pull und Push Prozess ergibt überhaupt keinen Sinn. Ich kann doch genauso immer die gleichen Inputs pushen und unterschiedliche Outputs pullen... Die Benennung ist nicht sprechend.
Erklärend sehr gut aber Überschrift ist agile und Sie haben die Hälfte über Klassisch verbraucht!