Anmelden
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Mehr Infos zu den heutigen Themen:
Fachkräftemangel: https://heise.de/-4156285
Mobilfunkversorgung: https://heise.de/-4157205
British Airways: https://heise.de/-4157167
Rechtspopulist Jones: https://heise.de/-4156983
Vor kurzem hat mich bei Twitter jemand nach Tipps gefragt, um ein besserer Software-Entwickler zu werden. Dieser Blog-Post soll dafür sorgen, dass nicht nur einer von den Ideen profitiert. Der Beitrag erhebt nicht den Anspruch vollständig zu sein. Wer also weitere Ideen hat: Ich freue mich über Kommentare!
Software-Entwickler definieren sich oft über die Programmiersprache oder das Framework, das sie nutzen. Ich finde das eigentlich schade, denn beides sind nur Werkzeuge. Eigentlich sollte ein guter Entwickler mehrere beherrschen. Alle Tipps, wie man eine Programmiersprache oder ein Framework lernt, würden den Umfang des Blog-Beitrags sprengen.
Dennoch ist das Erlernen neuer Sprachen sicherlich sinnvoll. Das führt mich zu meinem Buch-Tipp "The Pragmatic Programmer [1]" beziehungsweise "Der pragmatische Programmierer [2]". Es ist eine solche Sammlung von Tipps – und damit genau das richtige für diesen Blog-Beitrag. Das Buch ist zwar fast zwanzig Jahre alt, aber das zeigt gerade, wie grundlegend die Tipps sind. Einer der Tipps ist übrigens, jedes Jahr eine neue Programmiersprache zu erlernen.
Sicherlich gibt es weitere wichtige Bücher, aber der Austausch zwischen Entwicklern ist meiner Meinung nach noch wichtiger. Eine Möglichkeit, ganz praktisch voneinander zu lernen, sind Coderetreats [3]. Dabei üben die Teilnehmer ganz praktisch Techniken wie Refactoring, Pair Programming oder testgetriebene Entwicklung. Am 17. November ist der Global Day of Coderetreat, an dem Coderetreats weltweit [4] stattfinden. Vielleicht ist einer in der Nähe. Wenn nicht: Es gibt eine Anleitung [5], wie man einen eigenen Event auszurichten kann. Ähnliche praktische Lern-Events sind Code Katas [6], bei denen Entwickler gemeinsam Probleme lösen und so voneinander lernen und unterschiedliche Ansätze ausprobieren können. Beim Mob Programming [7] hingegen arbeitet das ganze Team gemeinsam an einem Problem im Code. Auch das stärkt den Austausch.
Solche Aktivitäten können Entwickler mit anderen Interessierten in der eigenen Firma umsetzen. Eine andere Möglichkeit sind die Softwerkskammern [8], in denen sich Gleichgesinnte treffen. Überhaupt findet man mittlerweile in vielen Städten Meetups [9] zu verschiedenen Themen aus der Software-Entwicklung. Und natürlich eine Vielzahl an Konferenzen.
Fehlen darf natürlich auch nicht der Hinweis auf einen älteren Blog-Post [10], der Fortbildungsmöglichkeiten im Bereich Software-Entwicklung nicht nur für Kinder und unterrepräsentierte Gruppen aufgelistet hat.
Soweit die kurze Übersicht – über Ergänzungen und Kommentare freue ich mich!
Entwickler lernen am besten voneinander. Dazu gibt es verschiedene Möglichkeiten.
URL dieses Artikels:http://www.heise.de/-4156718
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/The_Pragmatic_Programmer[2] https://www.hanser-fachbuch.de/buch/Der+Pragmatische+Programmierer/9783446223097[3] https://www.coderetreat.org/[4] https://www.coderetreat.org/events/[5] https://www.coderetreat.org/pages/hosting/hosts/[6] http://codekata.com/[7] https://en.wikipedia.org/wiki/Mob_programming[8] https://www.softwerkskammer.org/[9] https://www.meetup.com/[10] https://www.heise.de/developer/artikel/Mit-Code-und-Bildung-die-Welt-verbessern-3663044.html
Copyright © 2018 Heise Medien
Auf der IFA waren wieder viele c't-Kollegen unterwegs. Zwei von ihnen erzählen uns, was sie entdeckt haben und was auf uns zukommt.
Mehr Infos zu den heutigen Themen:
Dieselverbot in Frankfurt: https://heise.de/-4156155
Digitalsteuer?: https://heise.de/-4156027
KI vs. Weltwirtschaft: https://heise.de/-4155988
Abmahnung für Sony: https://heise.de/-4156240
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Weltweit werden immer mehr SSDs verkauft, der Absatz von Festplatten geht gleichzeitig zurück. Ob das Ende der Magnetspeicher naht, besprechen wir.
Mehr zu:Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Free2Play und sonst nichts? Parallel zur Gamescom sprechen wir darüber, auf welche Spiele wir uns freuen können und welche Trends die Branche bewegen.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Ein c't uplink außer der Reihe: Gemeinsam mit den Kollegen von t3n haben wir über Technik-Trends von Machine Learning bis Blockchain gesprochen. Die Folge ist nur als Audio-Datei verfügbar.
In dieser Sonderfolge c't uplink geht's um Trends, Hypes und IT-Journalismus. Gemeinsam mit den t3n-Chefredakteuren Luca Caracciolo und Stephan Dörner diskutieren Achim Barczok und Jan-Keno Janssen vom c't-uplink-Team darüber, wie man in Redaktionen mit Technik-Hypes und Buzzword-Bingo umgeht. Wie entscheiden t3n und c't, welche Themen man bei Heft- und Webseitenplanung nach vorne zieht?
Im zweiten Teil nehmen wir uns konkrete Trends vor: künstliche Intelligenz, Blockchain, Virtual und Augmented Reality, smarte Assistenten und Quantencomputer. Welche davon werden in den nächsten fünf Jahren besonders wichtig - da gibt's durchaus unterschiedliche Meinungen in der Runde.
Entstanden ist die Folge am 14. August 2018 auf der Up-date-Konferenz des Ideenboulevards in Hannover. Vor Ort gab es nur Audio-Technik, deshalb gibt's dieses Mal kein Video.
Hier könnt ihr die Folge anhören (47 min):
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Alle früheren Episoden unseres Podcasts gibt es unter www.ct.de/uplink [9].
()
URL dieses Artikels:http://www.heise.de/-4144186
Links in diesem Artikel:[1] http://blog.ct.de/ctuplink[2] http://blog.ct.de/ctuplink/ctuplink.rss[3] http://blog.ct.de/ctuplink/ctuplinkvideohd.rss[4] https://itunes.apple.com/de/podcast/ct-uplink/id835717958[5] https://itunes.apple.com/de/podcast/ct-uplink-video/id927435923?mt=2[6] http://www.heise.de/video/thema/c%27t-uplink[7] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[8] https://www.facebook.com/ctuplink[9] https://www.ct.de/uplink[10] mailto:acb@ct.de
Copyright © 2018 Heise Medien
Vor über zwanzig Jahren konnte man bereits iterativ-inkrementelle Entwicklungsprozesse beobachten. Sie sind ein Vorläufer agiler Prozesse, die es mittlerweile auch seit mehr als fünfzehn Jahren gibt. Obwohl es Agilität bereits geraume Zeit gibt, ist bis heute die agile Transformation ein Thema. Oft klappt die Transformation auch nicht. Warum?
Agile Verfahren zielen darauf ab, ein erfolgreiches Produkt zu entwickeln. Sie gehen in Iterationen vor. Nach jeder Iteration können Kunden den aktuellen Stand des Produkts nutzen. So bekommt das Team Feedback, welche Features beliebt sind und wie man das Produkt weiterentwickeln kann. Auch das Risiko ist geringer als ohne Iterationen: Es ist jederzeit klar, welche Features in Produktion funktionieren und welche nicht. Ein minimales Produkt kann sehr schnell nach Projektstart live gehen, was das Risiko des Scheiterns und einer Fehlentwicklung weiter reduziert. Auf Basis der bisherigen Geschwindigkeit lässt sich abschätzen, wie viel geschafft ist und wie lange das Team für die weiteren Features brauchen wird. Dabei ist das Team zusammen erfolgreich. Nicht eine einzelne Person trägt die Verantwortung für das Projekt, sondern das gesamte Team.
Agile Methoden reduzieren also das Risiko, führen zu schnellen Erfolgen, ermöglichen eine realistische Planbarkeit und entsprechen einer modernen Teamorganisation. Bei so viel Vorteilen sollte Agilität sich eigentlich von selbst durchsetzen. Aber in der Praxis sind agile Transformationen leider eine Herausforderung.
Tatsächlich gab es ein Projekt, an dem der Autor beteiligt war, bei dem die Vorteile der Agilität plötzlich zu Problemen wurden. Agilität hätte durch die frühe Produktivstellung der Software und die Abschätzungen für den weiteren Aufwand frühzeitig offensichtlich gemacht, dass das Projekt deutlich länger brauchen würde als geplant. Eigentlich ist es gut, wenn dieses Risiko frühzeitig offensichtlich geworden wäre. Aber in dieser Organisation hätte das Risiko vermutlich zum Abbruch des Projekts geführt, weil das Team offensichtlich ja der Aufgabe nicht gewachsen ist. Ohne Agilität hat das Projekt zwar die ursprünglichen Ziele nicht erreicht, aber es ist mit einigen politischen Tricks dem Abbruch entgangen und hat zumindest Software in Produktion geliefert.
Das Problem ist nicht der agile Prozess, sondern der Umgang mit dem Feedback, das agile Prozesse liefern. Werden bei Problemen personelle Konsequenzen gezogen oder Projekte abgebrochen, statt das Problem zu analysieren und konstruktiv zu lösen, wie es eine agile Kultur fordert, dann kann es leider sein, dass Verschleiern von Risiken und Verzögerungen sowie politische Spiele die einzige Möglichkeit sind, um ein risikoreiches Projekt durchzuführen.
Ebenfalls hätte Agilität in diesem Projekt für die Karriere des Projektleiters zu Problemen geführt. Um weiterzukommen, müssen Projektleiter Projekte erfolgreich abschließen. Aber in einem agilen Projekt gibt es keinen Projektleiter. Niemand außer dem gesamten Team ist für den Erfolg oder Misserfolg verantwortlich. Das widerspricht klassischen Organisationen, bei denen Manager oder Projektleiter für den Erfolg der Teams verantwortlich sind und dafür auch belohnt oder bestraft werden. Dieses Verständnis muss sich für agile Prozesse grundlegend ändern. Agilität predigt die Verantwortung des Teams – und das auch völlig zurecht. Aber dieser an sich richtige Ansatz ist eben in einigen Organisationen nicht so einfach umsetzbar.
In einem anderen Projekt stieß eine agile Projektorganisation auf ein klassisches Produktdesign. Letzteres hat in Quartalsreleases gedacht, während die Projektorganisation alle vierzehn Tage neue Software bereitstellen konnte. Das Feedback der Nutzer zu den 14-tägigen Releases konnte nicht in die Produktplanung einbezogen werden. Oft wäre es möglich gewesen, zunächst ein Feature in einer einfachen Art zu implementieren und erst später das Feature vollständig umzusetzen. So hätten Nutzer das Feature frühzeitig ausprobieren können. Wenn es nicht erfolgreich gewesen wäre, hätte man die Investition in das Feature beenden können. Das ist wichtig, weil die Literatur ("Online Experimentation at Microsoft") [1] zeigt, dass Produktdesigner nur bei höchstens 30 Prozent der Fälle die Beliebtheit eines Features richtig einschätzen. Agilität erlaubt es, statt des Schätzens auf das Feedback der Nutzer zu setzen. Dazu muss sich aber das Produktdesign seiner schlechten Trefferquote klar sein und dann Feedback aufnehmen und einarbeiten.
Und schließlich sind die Motive der an einem Projekt Beteiligten unterschiedlich. Dienstleister wollen sicher den Erfolg des Projekts, aber sie müssen auch Geld verdienen, während Auftraggeber Geld sparen wollen. Die entgegengesetzten Ziele führen zu Konfliktpotenzial. Techniker sind oft mehr an Technologien als am Projekterfolg interessiert. Dazu gibt es auch einen Blog-Beitrag auf heise Developer [2]. Am Ende sind an einem Projekt eine Vielzahl an Personen beteiligt, die ganz eigene Motive haben. Ihnen kann der Projekterfolg sehr wichtig oder eher egal sein. Und manchmal sind einige Beteiligte am Misserfolg des Projekts interessiert, um die eigene Karriere weiterzubringen.
Agilität setzt dem ein Menschenbild entgegen, bei dem alle Teammitglieder am Erfolg interessiert sind. Das ist auch sinnvoll, denn wenn die Motive der Projektbeteiligten nicht stimmen, kann man wenig tun, um das Projekt dennoch zum Erfolg zu führen.
Die oben angesprochenen Probleme liegen in Kultur und Management. Organisationen müssten mit Problemen konstruktiv umgehen, die Rolle von Projektleitern überdenken, das Produktdesign agilisieren und ein positives und konstruktives Menschenbild fördern. Anders gesagt: Agile Prozesse funktionieren nur, wenn Umgebung und Kultur dazu passen. Wenn diese Bedingungen nicht passen, muss man sie ändern. Aber können Softwarearchitekten, Entwickler oder Projektleiter eine Organisation so grundlegend ändern? Auch für Manager sind Änderungen in der Kultur schwierig, denn die Kultur ist fundamental für ein Unternehmen als soziales Gefüge. Die Unternehmen sind mit ihren alten Vorgehensmodellen und ihrer Kultur meistens am Markt gut positioniert, sodass gar kein Druck zum Wandel besteht – schon gar nicht zu einem radikalen Kulturwandel, wenn es doch "nur" um ein Software-Entwicklungsprojekt geht.
Das Problem ist nicht auf Agilität beschränkt. Continuous Delivery treibt die häufige Produktivstellung von Software weiter. Microservices unterstützen Agilität und selbstorganisierte Teams. Wenn Agilität wegen der Kultur nur begrenzte positive Auswirkungen hat, dann gilt das auch für Continuous Delivery und Microservices. Und daher wäre es so wichtig, Agilität zum Erfolg zu machen und die Kultur zu ändern.
Lösung?
Wenn die Unternehmen den grundlegenden agilen Wandel in der Kultur nicht mitmachen, wird das Ergebnis ein mehr oder minder halbherziger agiler Prozess sein. Der Autor sieht jedenfalls keine Möglichkeit, Agilität auf diese Kulturen anzupassen. "Echte" Agilität ist aber leider die Ausnahme. Mit anderen Worten: Agilität funktioniert in der Mehrheit der Fälle nicht, und der Grund ist das Problem in der Kultur.
Und dann wird Agilität auch einfach zu oft falsch verstanden. Teilweise ist Agilität sogar zu "noch mehr Druck" geworden, wie zum Beispiel dieser Artikel auf Spiegel Online [3] zeigt. Das hat mit eigenverantwortlichem Team und konstruktivem Umgang mit Feedback nichts mehr zu tun.
Agile Transition wird auch in den nächsten zwanzig Jahren noch ein Thema bleiben und es wird weiterhin viele "agile" Projekte geben, die in Wirklichkeit eben nicht agil sind.
Vielen Dank an meine Kollegen Björn Behrens, Martin Eigenbrodt, Lutz Hühnken, Martin Kühl, Andreas Krüger, Michael Schürig, Stefan Tilkov, Benjamin Wolf und Oliver Wolf für die Kommentare zu einer früheren Version des Artikels.
Agile Transformation ist seit zwanzig Jahren ein Thema. Weil Agilität zu der Kultur vieler Unternehmen nicht passt, wird es ein Thema bleiben. Auch weiterhin werden die meisten agile Projekte nur halbherzig Agilität umsetzen können.
URL dieses Artikels:http://www.heise.de/-4140080
Links in diesem Artikel:[1] http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf[2] https://www.heise.de/developer/artikel/Wir-brauchen-technikfeindliche-Techniker-4044291.html[3] http://spiegel.de/karriere/karriereberatung-ich-kann-beim-arbeitstempo-nicht-mehr-mithalten-a-1204711.html
Copyright © 2018 Heise Medien
[unable to retrieve full-text content]
In der Softwarearchitektur gibt es traditionelle Grundsätze, die oft zu Problemen führen. Sich dieser Herausforderungen klar zu werden, ist der erste Schritt, um sie zu beseitigen oder sogar von Anfang an zu vermeiden.
FreshRSS