​​​

 

 

Wie fehlerhafte Motivationen Transformationen von Agile zum Scheitern bringen könnenhttps://cleverlance.de/de/blog/Seiten/agile-transformation-agile.aspxWie fehlerhafte Motivationen Transformationen von Agile zum Scheitern bringen können<p>​​Agile Transformation ist zu einem Schlagwort in der Geschäftswelt geworden. Die Unternehmen sind begierig darauf, auf den Zug aufzuspringen und Agile Methoden zu übernehmen. Man glaubt, dass die Agile Transformation die Produktivität, Effizienz und Geschwindigkeit erhöht, alles vereinfacht und beschleunigt. Dies kann zwar der Fall sein, wenn es richtig gemacht wird, aber wenn die einzige Motivation für die Agile Transformation auf diese Ergebnisse ausgerichtet ist und das Unternehmen eine wahnhafte Vorstellung davon hat, wie schwierig es sein wird, diese zu erreichen, wird es schief gehen. Es ist immer viel holpriger als erwartet.</p><p>Dieser Beitrag ist Teil einer Serie über die häufigsten Probleme bei der Agile Transformation, wie ich sie in den Unternehmen um mich herum erlebt habe. Diese Serie konzentriert sich auf die Top-Down-Hindernisse. <br></p><h3>Geschwindigkeit, Effizienz, Transparenz<br></h3><p>Was ist falsch an der oben genannten Motivation? Verkörpern nicht Effizienz, Effektivität, Transparenz, Flexibilität und Geschwindigkeit die Eigenschaften, die die Kultur von Agile verspricht?<br></p><p>Meiner Meinung nach liegt der Grund dafür, dass sie zu kurz greift, darin, dass ein wesentlicher und integraler Aspekt der agilen Methodik fehlt, nämlich das Konzept des schnellen Scheiterns und der sofortigen Identifizierung und Darstellung von Hindernissen und Herausforderungen, die den Fortschritt behindern. Eine echte Bereitschaft, Probleme schneller zu finden und die Zusammenarbeit zu verbessern, muss ebenfalls ein integraler und echter Bestandteil der Motivation sein.<br></p><p>Das von mir erwähnte Missverständnis ist problematisch, weil es unrealistische Erwartungen an das weckt, was Agile erreichen kann. Agile ist keine schnelle Lösung für organisatorische Probleme. Es handelt sich vielmehr um eine grundlegende Veränderung der Arbeitsweise eines Unternehmens. Es handelt sich um eine Arbeitsweise, die Zusammenarbeit und die Bereitschaft zur Anpassung erfordert. Jeder, auch das Senior Management, muss bereit sein, mit den Teams zusammenzuarbeiten, um das Umfeld für Arbeiten mit Agile zu verbessern. Die gesamte Motivation entspringt der Überzeugung, dass Probleme durch die Desorganisation von Teams und falsche Organisationsstrukturen verursacht werden.<br></p><h3>Transformationsprojekt – sein Ende ist erst der Anfang<br></h3><p>Bedauerlicherweise wird die Agile Transformation von Managementteams oft als Patentlösung für die organisatorischen Probleme eines Unternehmens angesehen. Sie sehen sie fälschlicherweise als eine kurze, einmalige Investition, die sofortige und dauerhafte Vorteile bringt. Diese Fehleinschätzung kann zu einer allzu vereinfachten Herangehensweise an die Agile Transformation führen, bei der der kontinuierliche Aufwand, der zur Aufrechterhaltung der Transformation erforderlich ist, nicht berücksichtigt wird. Die Agile Transformation erfordert kontinuierliche Anstrengungen und Engagement sowohl von dem Senior Management als auch von den beteiligten Teams.<br></p><p>Viele Manager glauben fälschlicherweise, dass die Einführung von Agile so einfach ist, wie ein Transformationsprojekt auszurufen, ein Budget bereitzustellen, dem Projekt einen schicken Namen zu geben, Berater zu engagieren und eine Reihe von Schulungen durchzuführen. Sie denken, dass diese Maßnahmen allein ausreichen, um die Transformation zu erreichen, und ihre Aufgabe damit erledigt ist. Man klopft sich selbst auf die Schulter, weil man die Projektmanager in Scrum Master umbenannt und das Transformationsprojekt offiziell abgeschlossen hat. Und dann lehnen sie sich zurück, während sich die Teams selbst organisieren und die Scrum Master auf magische Weise alle Hindernisse beseitigen. Aber so funktioniert es nicht.<br></p><p>Organisationen stehen oft vor strukturellen und systematischen Problemen, die ihre Agilität behindern. Jedes Unternehmen hat welche – nur ihre Intensität variiert. Diese Probleme können sich auf verschiedene Weise manifestieren, zum Beispiel durch zu komplizierte Organisations- und Entscheidungshierarchien, Abhängigkeit von unflexiblen Technologien, verworrene Bereitstellungsverfahren und starre Genehmigungsprozesse, um nur einige typische Beispiele zu nennen.<br></p><p> Ein Unternehmen, das beispielsweise zweimal im Jahr Software-Updates mit zahlreichen Abhängigkeiten, Code-Freezes, zentralisierten Tests und langwierigen Entwicklungs-, Test- und Abnahmeschleifen veröffentlicht, wird bei der Einführung von Agile Methoden wahrscheinlich auf erhebliche Hindernisse stoßen. Die alten Prozesse und Technologien sind möglicherweise nicht mit den Arbeitsabläufen von Agile kompatibel, so dass es eine Herausforderung ist, das gewünschte Maß an Flexibilität und Geschwindigkeit zu erreichen.</p><p>Diese inhärenten Probleme werden während einer Agile Transformation nicht auf magische Weise verschwinden - sie werden nur schmerzhaft offensichtlich und dringlich werden. Die gute Nachricht ist, dass sich die Teams endlich trauen werden, über sie zu sprechen und zu versuchen, sie direkt anzugehen. Probleme werden überall zu finden sein.​<br></p><h3>Hüten Sie sich davor, ein Potemkinsches Dorf zu schaffen</h3><p>Die Kehrseite der Medaille ist, dass die gesamte Transformation nicht funktionieren wird, wenn man nicht damit rechnet, dass dies geschieht. Man muss bereit sein, die schlechten Nachrichten zu hören und proaktive Entscheidungen zu treffen.<br></p><p>Nachdem die Teams jahrelang die Probleme einfach hingenommen haben, werden sie plötzlich anfangen, über diese Probleme zu schimpfen, und das Senior Management muss sich einschalten und mit ihnen zusammenarbeiten, um den Arbeitsplatz agilitätsfreundlicher zu gestalten. Andernfalls werden die Teams in einem starren Umfeld feststecken. Jeder wird sich einfach einen neuen Titel geben, wie Product Owner oder Agile Coach. Diese Umstrukturierung wird wahrscheinlich als eine weitere Geldverschwendung und ein Misserfolg angesehen werden, und viele werden zu dem Schluss kommen, dass Agile nicht funktioniert. Ein Potemkinsches Dorf.<br></p><p>Alle Ebenen einer Organisation müssen bereit sein, sich diesen Herausforderungen zu stellen und gemeinsam an Lösungen zu arbeiten. Die Entscheidung, Agile einzuführen, ist nur der erste Schritt. Auch die Führungskräfte müssen bereit sein, die Ärmel hochzukrempeln und sich an der Identifizierung und Lösung von Problemen zu beteiligen, die während der Transformation auftreten. Es ist eine Teamleistung, und jeder muss eine aktive Rolle spielen. Je komplexer die Unternehmensstruktur ist, desto länger wird die gesamte Transformation wahrscheinlich dauern. Es handelt sich um einen fortlaufenden Prozess, der wahrscheinlich nie zu einem vollständigen Ende kommen wird. Der entscheidende Faktor ist jedoch, ob der Wille vorhanden ist, eine unbequeme Veränderung zu beginnen und durchzuhalten.<br></p><p>Eine überraschende Tatsache bei der Agile Transformation ist, dass sie zu mehr Bürokratie führen kann, wenn sie nicht richtig umgesetzt wird. Nehmen wir zum Beispiel an, ein Unternehmen führt Agile ein, ohne die zugrundeliegenden Probleme wie verworrene Entscheidungsprozesse oder starre Genehmigungsverfahren anzugehen. In diesem Fall kann es ungewollt zu mehr Bürokratie kommen, da der Prozess noch vielschichtiger wird. Denn Agile erfordert ständige Kommunikation und Zusammenarbeit, und wenn diese Prozesse nicht gestrafft werden, kann dies zu noch mehr Verzögerungen und Ineffizienzen führen.<br></p><h3>Wahre Motivation: Ein Gefühl der Sicherheit<br></h3><p>Meiner Erfahrung nach sind gescheiterte Versuche der Agile Transformation oft auf ein gemeinsames Grundproblem zurückzuführen: einen Mangel an Vertrauen. Dies kann sich auf verschiedene Weise äußern, z. B. durch die Tendenz, Teams genau zu überwachen und zu kontrollieren. Nach einer solchen Transformation habe ich erlebt, dass Teams aufgefordert wurden, ihre Sprint Commitments, Burn-Down-Charts und Geschwindigkeiten mitzuteilen, und sich dann rechtfertigen mussten, wenn sie diese Messwerte nicht einhielten. Dies geschah auf der Ebene des Senior Managements.<br></p><p>Diese Art der Berichterstattung vermittelte ein falsches Gefühl der Sicherheit, da das Erscheinungsbild von beeindruckenden Diagrammen und Zahlen auf dem Papier im Vordergrund stand und nicht der tatsächliche Wert der geleisteten Arbeit. Der Schwerpunkt lag auf der Einhaltung von Zusagen, anstatt den Sinn dieser Zusagen und der Gesamtpläne zu hinterfragen. Was natürlich fehlte, war eine kritische Prüfung des tatsächlichen geschäftlichen Wertes der investierten Anstrengungen und des Wertes der entwickelten Dinge. Es war also ziemlich offensichtlich, was die wahre ursprüngliche Motivation für die Einführung von Agile war.<br></p><h3>Wollen Sie wirklich Agile werden?<br></h3><p>Zusammenfassend lässt sich sagen, dass die Transformation von Agile ein leistungsfähiges Instrument für Unternehmen sein kann, die ihre Produktivität, Effizienz und Geschwindigkeit verbessern wollen.  Es ist jedoch wichtig, mit realistischen Erwartungen an die Transformation heranzugehen und die Bereitschaft zu zeigen, die zugrunde liegenden strukturellen und kulturellen Probleme anzugehen. Die Agile Transformation ist keine schnelle Lösung oder eine einmalige Investition, sondern erfordert kontinuierliche Anstrengungen und Engagement auf allen Ebenen des Unternehmens. Auch die Führungskräfte müssen bereit sein, die Ärmel hochzukrempeln und sich an der Identifizierung und Lösung von Problemen zu beteiligen, die während der Transformation auftreten. <br></p><p>Darüber hinaus ist es von entscheidender Bedeutung, sich bei der Transformation auf den geschäftlichen Nutzen zu konzentrieren und nicht nur auf Messwerte und Äußerlichkeiten. Bevor Sie sich also auf die Reise der Agile Transformation begeben, sollten Sie zweimal nachdenken und sicherstellen, dass Sie bereit sind, sich voll und ganz auf den Prozess einzulassen. Bei der Transformation mit Agile geht es darum, flüssiger auf sich ändernde geschäftliche Umstände reagieren zu können, nicht wahr?  Wenn die Bereitschaft gering ist, sich mit den zugrunde liegenden Problemen, die den Fortschritt behindern, auseinanderzusetzen, was nützt es dann, sie überhaupt erst zu identifizieren? Das verhindert per definitionem, dass sich die Dinge ändern.<br></p><p>Wenn es nicht die ehrliche Motivation ist, eine Organisation grundlegend zu verändern, einschließlich ihrer kulturellen, technischen und prozessualen Kernaspekte, dann ist es vielleicht bequemer, den Status quo beizubehalten und sich die Peinlichkeit zu ersparen, die der Versuch einer Agile Transformation unweigerlich mit sich bringen würde.​​<br></p>
Wie das Management Buy-In die agile Transformation beeinflussthttps://cleverlance.de/de/blog/Seiten/agile-transformation.aspxWie das Management Buy-In die agile Transformation beeinflusst<p>​Die agile Transformation kann ein leistungsfähiges Instrument für Unternehmen sein, die ihre Effizienz, Produktivität und Flexibilität verbessern wollen. Der Erfolg einer agilen Transformation hängt jedoch oft von der Zustimmung des Managements ab. Wie ich bereits in einem früheren Beitrag geschrieben habe, liegt die Motivation für eine agile Transformation in vielen Fällen in der Überzeugung, dass die derzeitige Organisationsstruktur falsch ausgerichtet ist und dass agile Methoden das Allheilmittel sind. Möglicherweise hat das Management auch unrealistische Erwartungen an den Transformationsprozess.</p><p>In Wirklichkeit muss das Management eine aktive Rolle im Transformationsprozess spielen und mit den Teams zusammenarbeiten, um Probleme zu identifizieren und zu lösen. Dies erfordert die Bereitschaft, auch schlechte Nachrichten zu hören, schwierige Entscheidungen zu treffen und strukturelle und systematische Probleme anzugehen, die die Agilität behindern können, wie z. B. zu komplexe Organisationshierarchien, starre Technologien und unflexible Genehmigungsverfahren. Ohne diese Zustimmung und aktive Beteiligung können agile Transformationen nur zu einer oberflächlichen Veränderung mit geringen Auswirkungen auf Effizienz und Produktivität werden.</p><h3>Definition von Management und Führung</h3><p>Es gibt mehrere Definitionen dessen, was Management eigentlich ist. Lassen Sie mich die beiden klassischen zitieren:</p><p>Harold Koontz: Management ist die Kunst, Dinge durch und mit Menschen in formell organisierten Gruppen zu erreichen. Es ist die Kunst, ein Umfeld zu schaffen, in dem Menschen als Individuen Leistung erbringen und zur Erreichung von Gruppenzielen zusammenarbeiten können.</p><p>F.W. Taylor: Management ist die Kunst, zu wissen, was zu tun ist, wann es zu tun ist, und dafür zu sorgen, dass es auf die beste und billigste Weise geschieht.</p><p>Wenn es also darum geht, zu einem agilen Ansatz überzugehen, müssen Manager vor allem zwei Dinge beachten: Erstens sind sie dafür verantwortlich, ein Umfeld zu schaffen, in dem Menschen produktiv sein können, und zweitens müssen sie herausfinden, was zu tun ist, wenn andere unsicher sind.</p><p>Darüber hinaus ist es erwähnenswert, dass es zwar Überschneidungen zwischen den Fähigkeiten und Qualitäten eines Managers und einer Führungskraft gibt, sie aber nicht dasselbe sind. Ein Manager beaufsichtigt und leitet ein Team oder eine Organisation, um deren Ziele zu erreichen, während eine Führungskraft Menschen inspiriert und motiviert, auf eine gemeinsame Vision oder ein gemeinsames Ziel hinzuarbeiten. Obwohl es ideal ist, wenn eine Führungskraft auch über ausgeprägte Führungsqualitäten verfügt, ist es nicht immer notwendig, dass eine Führungskraft auch eine Führungspersönlichkeit ist, da sie ein Team auch dann effektiv leiten kann, wenn sie es nicht unbedingt inspiriert oder motiviert. In vielen Fällen können jedoch starke Führungsqualitäten die Fähigkeit einer Führungskraft, ihr Team effektiv zu führen, verbessern.</p><p>Wie lässt sich dies im Zusammenhang mit einer agilen Transformation anwenden?</p><h3>Top-down-Ansatz für die agile Umstellung</h3><p>Meiner Erfahrung nach sind einige Schlüsseleigenschaften für einen erfolgreichen Top-down-Ansatz bei der agilen Umstellung entscheidend. Manager müssen bereit sein, "schlechte Nachrichten" zu hören und aktiv Entscheidungen im besten Interesse des Unternehmens zu treffen. Der Durchschnittsmitarbeiter im Unternehmen muss von den Managern ermutigt werden, Hindernisse zu erkennen und sowohl Umgehungslösungen als auch richtige Lösungen vorzuschlagen.</p><p>Um eine reibungslose und effektive Arbeit zu gewährleisten, müssen die Führungskräfte ihre Visionen und Erwartungen den Teammitgliedern deutlich machen. Obwohl strukturelle Veränderungen den Fortschritt behindern können, ist es wichtig zu erkennen, dass manche Veränderungen Zeit brauchen. Eine gemeinsame Vision kann die Teammitglieder motivieren, in der Zwischenzeit Ausweichmöglichkeiten zu finden, und gleichzeitig den Glauben fördern, dass die höhere Führungsebene aktiv an einer langfristigen Lösung arbeitet.</p><p>Eine klare Orientierung, eine Vision und ein Verständnis für den Kontext auf höherer Ebene können die Motivation, die Produktivität und die Relevanz von Lösungen während einer agilen Transformation erheblich verbessern. Es kann zu effizienteren und effektiveren Lösungen führen, da sie mit dem Blick auf das große Ganze entwickelt werden. Ein Gefühl für die Richtung und eine klare Vision können die Mitarbeiter stark motivieren, in schwierigen Zeiten durchzuhalten. Wie der Blick auf den Horizont in stürmischen Gewässern vermittelt er ein Gefühl von Stabilität und Zielstrebigkeit, das dem Einzelnen helfen kann, konzentriert und produktiv zu bleiben. Es liegt in der Verantwortung der Führungskraft, dafür zu sorgen, dass eine solche Vision existiert und von anderen verstanden wird.</p><h3>Nehmen Sie es nicht persönlich</h3><p>Manager, die sich weigern, Kritik auf strategischer Ebene zu hören, können den Fortschritt der agilen Transformation behindern. Es ist wichtig, sie nicht persönlich zu nehmen. Je umfassender das Problem ist, desto schwieriger ist es zu lösen. Der Versuch, es zu lösen, birgt sowohl Risiken als auch Chancen, weshalb die agile Transformation überhaupt erst eingeleitet wurde.</p><p>Wenn Manager Kritik oder Hindernisse als Deckmantel für die Inkompetenz oder das Versagen von Mitarbeitern betrachten, kann dies zu einem Mangel an Vertrauen führen, der eine effektive Führung behindert. Dies kann zu einer Tendenz zum Mikromanagement und zur übermäßigen Überwachung der Mitarbeiter führen, was letztlich alle Umstellungsbemühungen untergraben kann. Schließlich kann mangelndes Vertrauen dazu führen, dass Mitarbeiter ihre Ideen für sich behalten, um mögliche Konflikte oder Auseinandersetzungen mit ihren Vorgesetzten zu vermeiden. Dies kann Kreativität und Innovation behindern und eine toxische Arbeitsumgebung schaffen, in der offene Kommunikation und Zusammenarbeit nicht erwünscht sind.</p><p>Es ist wichtig, dass Führungskräfte aktiv mit ihren Teams zusammenarbeiten und sie bei der Problemlösung und Entscheidungsfindung unterstützen, anstatt zu erwarten, dass die Teams alles selbst regeln. Einige Hindernisse liegen außerhalb der Kontrolle einzelner Teams und erfordern ein Eingreifen auf höherer Ebene oder die Unterstützung des Unternehmens.</p><h3>Entscheidungen treffen - das ist die Aufgabe von Führungskräften</h3><p>Die Entscheidungsfindung in einem Unternehmen ist eine gemeinsame Aufgabe von Führungskräften und Mitarbeitern der unteren Ebenen. Wirksame Führungskräfte übernehmen die Verantwortung für ihre Entscheidungen, auch wenn sie mit Unsicherheiten konfrontiert sind. Sie suchen aktiv nach den Informationen, die sie benötigen, um fundierte Entscheidungen zu treffen, und erkennen an, dass in manchen Situationen vielleicht nicht genügend Informationen vorliegen, aber dennoch eine Entscheidung getroffen werden muss. Im Gegensatz dazu versuchen manche Manager aus Angst vor dem Scheitern, die Verantwortung auf andere abzuwälzen, anstatt sie sich in solchen Situationen zu eigen zu machen und die Verantwortung für ihre Entscheidungen zu übernehmen. Es ist wichtig, dass Manager verstehen, dass der Umgang mit Ungewissheit ein wichtiger Bestandteil der Entscheidungsfindung ist, und dass sie diese Verantwortung übernehmen. Die Kollegen der unteren Ebenen spielen eine entscheidende Rolle bei der Erleichterung von Entscheidungen, indem sie gültige, präzise, vollständige und vor allem ehrliche Informationen liefern.</p><p>Um mit kritischen Entscheidungen umzugehen, können Unternehmen eine Kultur des Experimentierens und Testens fördern oder einen strukturierten Ansatz zur Sammlung und Analyse von Daten für fundierte Entscheidungen entwickeln. Indem sie verschiedene Szenarien potenzieller Ergebnisse erforschen, ihre Auswirkungen messen und sich proaktiv mit solchen Modellen auseinandersetzen, können sich Unternehmen von diesem Muster lösen.</p><p>Effektive Manager gehen mit einer gesunden Portion Skepsis an die Entscheidungsfindung heran, indem sie Daten validieren und gegenprüfen, bevor sie irgendwelche Verpflichtungen eingehen. Dies gilt auch für die Erstellung von Plänen und Zusagen während des Verkaufsprozesses. Dabei ist zu beachten, dass die Kritik und die Verbesserungsvorschläge der einzelnen Teams nicht nur strukturelle und technische Aspekte, sondern auch Zielpläne betreffen können. Ein häufiger Fallstrick ist, dass Experten nicht in den Verkaufs- und Planungsprozess einbezogen werden, was zu unrealistischen Plänen führt. In solchen Fällen sollte das Team nicht dafür verantwortlich gemacht werden, dass es einen unrealistischen Plan nicht einhalten kann. Die Erstellung eines solchen Plans ist eine risikobehaftete Entscheidung, für deren Bewertung, Verwaltung und Akzeptanz die Manager verantwortlich sind. Die agile Transformation kann solche naiven Pläne schmerzlich entlarven.</p><p>Die Delegation von Kompetenzen und Verantwortung ist ein wesentlicher Aspekt effektiven Managements. Es ist jedoch wichtig zu beachten, dass Manager auch bereit sein sollten, die Konsequenzen der Delegation zu akzeptieren.</p><h3>Überwindung von Angst und mangelndem Vertrauen<br></h3><p>Die Angst vor Veränderungen kann den agilen Transformationsprozess oft behindern, und viele Manager zögern aufgrund verschiedener Ängste, die jedem Menschen eigen sind, Veränderungen vorzunehmen. Zu diesen Ängsten gehören die Angst vor dem Scheitern, die Angst vor dem Unbekannten, die Angst, die Kontrolle zu verlieren, die Angst um die Sicherheit des Arbeitsplatzes, die Angst, als inkompetent entlarvt zu werden, die Angst, Status oder Macht zu verlieren, die Angst vor Konflikten oder Widerständen und die Angst vor den umfangreichen Veränderungen, die der agile Transformationsprozess erfordert. Effektive Manager und Organisationen sind jedoch in der Lage, diese Ängste zu erkennen und zu bewältigen und gleichzeitig die notwendigen Veränderungen voranzutreiben, um die Ergebnisse zu verbessern. Es ist wichtig, diese Ängste nicht persönlich zu nehmen, sondern sie mit einer lösungsorientierten Denkweise anzugehen – denn Lähmung kann die andere Option sein.</p><p>Angst und mangelndes Vertrauen können erhebliche Hindernisse für den Unternehmenserfolg darstellen, insbesondere bei der Umstellung auf eine agile Kultur. Auch wenn diese Gefühle berechtigt sind und berechtigte Gründe haben, können sie letztlich den Fortschritt behindern. Damit eine Organisation vorankommt und effektiver wird, ist es unerlässlich, Vertrauen zu schaffen, Kompetenzen und Verantwortlichkeiten zu delegieren und die Mitarbeiter zu befähigen, Entscheidungen zu treffen. Die meisten Menschen sind von Natur aus durch Veränderungen motiviert, die Zeit und Mühe sparen, und eine Kultur des Vertrauens und der Zusammenarbeit kann diese Motivation zur Erreichung der Unternehmensziele fördern.</p><p>Durch die Förderung einer Kultur des Vertrauens und der Zusammenarbeit können Unternehmen Ängste und Hindernisse bei der agilen Transformation überwinden und die Mitarbeiter befähigen, Maßnahmen zu ergreifen, die Zeit und Aufwand sparen.​<br></p>
Unerwartete schlechte Praktikenhttps://cleverlance.de/de/blog/Seiten/unexpected-bad-practices.aspxUnerwartete schlechte Praktiken<p>​​​Einige Programmierpraktiken sind uns so vertraut, dass wir sie automatisch und ohne großes Nachdenken anwenden. Manchmal sind diese Techniken veraltet, manchmal werden sie im falschen Kontext angewendet. Das Ansprechen solch schlecht eingespielter Gewohnheiten stößt oft auf Ablehnung. Vor allem von denjenigen, die sie nutzen und das Thema als nützlich empfinden, also lasst uns genau das tun!</p><h3>Marks<br></h3><p>Programmier-IDEs erkennen oft bestimmte Arten von Kommentaren, um die Navigation in der Codebasis zu erleichtern. Die <em>FIXME</em>-Funktion von Xcode lässt andere Entwickler wissen, dass ein Teil des Codes mehr Aufmerksamkeit verdient. <em>TODO</em> ist hilfreich, wenn etwas, nun ja, erledigt werden soll. <em>MARK</em> unterscheidet sich von den vorherigen Fällen; es dient der Dokumentation. Die gleiche Funktion wird in IntelliJ IDEA/Android Studio als Region bezeichnet.</p><p>Markierungen unterteilen den Quellcode in mehrere Teile, indem sie Überschriften verwenden. Das kann dazu führen, dass der Code in logische Einheiten unterteilt erscheint. Wenn Sie ein Leser sind, der mit der früheren Objective-C-Ära der iOS-Entwicklung vertraut ist, wissen Sie, dass dies nur eine aktualisierte <em>#pragma mark</em>-Anweisung ist.</p><p>Typisch ist die Verwendung in Dateien mit einer großen Anzahl von Zeilen. Zeichen schaffen die Illusion von Klarheit, indem sie in vermeintlich zusammengehörende Teile zerlegt werden.</p><p>Die Verwendung von Zeichen in solchen Fällen ist eine schlechte Praxis. Entwickler missbrauchen sie oft, um eine zu große Datei zu rechtfertigen. Man sollte sich nicht auf Xcode verlassen, um den Code verständlich und lesbar zu machen. Kleine und gut komponierte Klassen sind ohne IDE-Funktionen einfacher zu verstehen und zu navigieren. Vor allem für die Überprüfer von Pull-Anfragen, die die Weboberfläche benutzen, wo diese Funktionen nicht vorhanden sind.</p><h3>Erweiterungen</h3><p>Moderne Programmiersprachen wie Kotlin oder Swift ermöglichen die Erweiterung von Klassen, Schnittstellen/Protokollen, Structs oder Enums, um eine zusätzliche Implementierung bereitzustellen. Sie können Ihren Code in mehrere Teile aufteilen, indem Sie Erweiterungen verwenden, um festzulegen, was näher zusammengehört. Eine andere Möglichkeit besteht darin, eine Erweiterung für einen anderen Typ zu erstellen, den Sie vielleicht nicht einmal besitzen, um seine Verwendung intuitiver zu gestalten. Die Möglichkeiten sind nahezu grenzenlos. Das ist nicht immer eine gute Sache, aber zunächst ein Blick in die Geschichte. </p><p>Erweiterungen gab es auch schon in Objective-C. Wenn Sie keine Erfahrung mit der Programmierung in einer solchen Sprache haben und den Namen für Erweiterungen erraten müssten, würden Sie wahrscheinlich überrascht sein. Es sind Kategorien! Eine weitere Überraschung ist, dass es auch in Objective-C Erweiterungen gibt, die jedoch anderen Zwecken dienen. Interessant ist der Unterschied zwischen den beiden Sprachen. Kategorien in Objective-C zwangen den Entwickler, sich den Namen auszudenken. Aus diesem Grund werden Dateien mit dem Namen Class+CategoryName.swift oft auch für Swift-Erweiterungen verwendet. Und noch wichtiger: Um Kategorien zu verwenden, mussten sie explizit importiert werden.</p><p>Erweiterungen in Swift sind ein unbenannter Teil des Codes. Ein solcher Code kann für den Leser komplizierter zu verstehen sein. Wenn es mehrere Erweiterungen desselben Typs gibt, kann das Hinzufügen eines Namens zum Code und die Einbettung in einen Typ die Lesbarkeit erheblich verbessern.</p><p>Die unsachgemäße Erweiterung von weit verbreiteten Typen führt zu einer Verschmutzung des Namensraums. Es ist wichtig, sich vor der Erstellung von Erweiterungen zu fragen, ob alle Instanzen des Typs eine solche Fähigkeit haben sollen. Sollten alle UIViews Zugang zu einer Blinkmethode haben? Macht eine bestimmte Unterklasse von UIView mehr Sinn?</p><p>Einige Entwickler verwenden Erweiterungen, um die Implementierung mehrerer Protokolle aufzuschlüsseln, was ebenfalls ein Warnzeichen sein kann. Wenn eine Klasse viele Protokolle implementiert, ist es vielleicht an der Zeit, sie in kleinere Klassen aufzuteilen.</p><p>Für Trolle da draußen: Sie können Ihre Kollegen wütend machen, indem Sie <em>UIView</em> mit <em>translatesAutoresizingMasksIntoConstraints</em> erweitern und beobachten, wie sie es mit <em>translatesAutoresizingMaskIntoConstraints vergleichen.</em></p><p>Aber tun Sie es nicht.</p><h3>Kommentare</h3><p>Die Möglichkeit, Kommentare zu schreiben, könnte undisziplinierte Programmierer dazu verleiten, einen Code von schlechter Qualität zu erstellen. Leider ist es einfacher, eine Variable nicht zu benennen und mit einem komplizierten, aber nicht so klaren Kommentar zu beschreiben, was in meinem Kopf vor sich geht. Leichtigkeit sollte nicht unser Ziel sein. Knappheit und Klarheit sollten es sein.</p><p>Ein guter Kommentar für einen schlecht geschriebenen Code ist immer noch ein Codegeruch. Nehmen Sie nicht nur mich beim Wort. Robert Martin erklärt: „Ein Kommentar ist ein Versäumnis, sich in einem Code auszudrücken. Wenn Sie scheitern, dann schreiben Sie einen Kommentar; aber versuchen Sie nicht zu scheitern.“</p><p>Ein weiterer Grund ist, dass sich das Verhalten des Codes ändern kann, wenn er im Repository lebt, geändert und überarbeitet wird, und dass sein Name dies überall, wo er aufgerufen wird, zum Ausdruck bringen kann. Der Kommentar wird jedoch selten aktualisiert und kann mehr verwirren als helfen.</p><p>Dokumentationskommentare erfüllen ihren Zweck sehr gut, wenn Sie eine API entwerfen, die andere verwenden sollen. Denken Sie daran, dass die API für sich selbst stehen muss, und dass Klarheit Vorrang hat. Benutzen Sie die Kommentare in der Dokumentation nicht als Entschuldigung für ein miserables Design.</p><h3>Struktur</h3><p>Die Struktur eines Projekts ist eines der ersten Dinge, die man sieht, wenn man sich eine Codebasis ansieht, und sie sollte auf den ersten Blick den Zweck der Anwendung umreißen. Es ist jedoch keine Ausnahme, dass einige Projekte Ordnerstrukturen haben, die von den Schichten der Architektur inspiriert sind, z. B. View, ViewModel, Model.</p><p>Eine Projektstruktur auf der Grundlage von Architekturschichten ist eine schlechte Praxis. Dies macht die Wiederverwendbarkeit praktisch unmöglich. Die Navigation durch eine solche Struktur ist unnötig kompliziert und wird mit zunehmendem Umfang immer schwieriger zu pflegen. Sie ist nicht skalierbar. Von der Architektur inspirierte Ordner könnten ihren Platz haben, nicht nur auf der obersten Ebene. Es sollte nicht das erste sein, was Sie sehen.<br></p><p><img src="/de/blog/PublishingImages/Articles/MobileIt/unexpected-bad-practices-01-01.png" data-themekey="#" alt="" style="margin:5px;" /><br></p><p>Überzeugen Sie sich selbst, welche Struktur Ihnen mehr über die Anwendung verrät</p><h3>Abhängigkeiten</h3><p>Open Source bietet viele Bibliotheken, die das Leben vereinfachen, von UI-Komponenten über Netzwerke bis hin zu Lösungen für die Injektion von Abhängigkeiten. Dies kann oft viel Zeit und Mühe sparen. Andererseits birgt dies verschiedene Gefahren und Einschränkungen; die Verwendung von Bibliotheken Dritter erfordert Disziplin, Ordnung und Ausgewogenheit.</p><p>Zufällig verstreute Abhängigkeiten von Dritten verringern die Robustheit erheblich. Die Abschirmung des Kerns der Anwendung und die Verwendung der Bibliotheken von den äußeren Teilen der Architektur helfen, das Risiko zu mindern. Die Abstraktion erleichtert den Prozess des Ersetzens einer Bibliothek durch eine andere.</p><p>Es ist in Ordnung, Abhängigkeiten von Drittanbietern zu verwenden, aber mit Vorsicht. Fragen Sie sich selbst: Wie viel Zeit werde ich dadurch sparen? Wie hoch ist der Aufwand für den Ersatz? Kann ich genügend Schutzmechanismen installieren, um die Anwendung zu schützen? </p><p>Der Königsweg zum Schutz Ihrer Anwendung, auch wenn dies manchmal schwierig oder unpraktisch ist, besteht darin, die Abhängigkeit nur an einer Stelle zu importieren.</p><p>Wir hatten bereits das Vergnügen, mehrere Anwendungen zu übernehmen, die aufgrund dieses Problems nicht mehr zu warten waren. Ohne Abstraktion, nicht mehr unterstützte (oder Closed-Source-) Bibliotheken haben die Codebase zersetzt. Externe Abhängigkeiten sollten Ihr Produkt niemals als Geisel halten.</p><h3>Tests</h3><p>Testgetriebene Entwicklung ist die gute Kinderstube eines Programmierers, eine Disziplin mit vielen Vorteilen. Die technischen Auswirkungen sind ein eigener Blogbeitrag, wenn nicht sogar eine ganze Serie. Nicht-technische Auswirkungen wie etwa die einfache Einarbeitung neuer Teammitglieder und eine ausführbare Dokumentation, die nicht veralten kann, sprechen für sich.</p><p>Dennoch werden sie oft vernachlässigt. Das völlige Fehlen von Tests ist der offensichtlich erste und häufigste Verstoß, gefolgt vom Schreiben von Tests nach dem Produktionscode, was alle Vorteile abschwächt und andere Hindernisse mit sich bringt.</p><p>Sie müssen zuerst Unit-Tests schreiben - vor dem Produktionscode. Wenn Sie zuerst testen, verhindern Sie, dass Sie einen zu komplexen Code erstellen. Er führt Sie durch den Bau von Bauteilen in der richtigen Größe. Die großen Klassen sind schwierig zu testen, und die Tests werden Sie anweisen, sie in kleinere Klassen zu zerlegen.</p><p>Tests, die nach dem Produktionscode geschrieben werden, sind von Natur aus von geringerer Qualität und können sogar irreführend sein. Solange Sie den Produktionscode nicht als Beweis für den ersten fehlgeschlagenen Test schreiben, ist es unmöglich zu sagen, ob die Tests das behaupten, was sie deklarieren. Es ist dann fraglich, wie gut solche Tests das zu prüfende System schützen.</p><p>Wenn Sie Tests erst nach der Implementierung schreiben, kann es sein, dass eine Komponente schwierig zu testen ist, was bei einem Test-first-Ansatz unmöglich ist. Sie können keinen untestbaren Code erstellen!</p><h3>Der Teufel steckt im Detail</h3><p>Selbst das Alltägliche kann schädlich sein, wenn wir etwas zu automatisch und mit weniger Aufmerksamkeit tun. Stellen Sie das Gewöhnliche in Frage und suchen Sie nach schlechten Praktiken, die Sie nicht erwarten würden.​​<br></p>
Apple denkt an die Sicherheit seiner Benutzerhttps://cleverlance.de/de/blog/Seiten/apple-account-deletion.aspxApple denkt an die Sicherheit seiner Benutzer<p>​​Mobile Apps werden bei den Benutzern immer beliebter. Jeden Tag werden von <strong>Google Play</strong> und <strong>Apple App Store</strong> tausende heruntergeladen. Allerdings sind nicht alle Apps für ihre Benutzer völlig sicher und nicht alle verwalten die persönlichen Daten der Benutzer korrekt. Die oben genannten Unternehmen versuchen zu überwachen, dass nur solche Apps in ihre Stores gelangen, die mit den Benutzern "fair spielen".</p><p>Um die Privatsphäre der Benutzer von iOS-Apps zu schützen, hat Apple eine <a href="https://developer.apple.com/support/offering-account-deletion-in-your-app" target="_blank">Verordnung erlassen</a>, dass "ab dem 30. Juni 2022 alle mobilen Apps im App Store, die die Erstellung von Konten unterstützen, den Benutzern auch die Möglichkeit geben müssen, ihre Konten zu löschen".</p><p>Ursprünglich sollte diese Richtlinie bereits ab Ende Januar 2022 gelten, aber die Frist wurde auf Druck von Entwicklern und Gesellschaften, die Applikationen betreiben, um fünf Monate verschoben. Dies ist nämlich nicht immer ein einfaches Verfahren. Apple hat klare Regeln für das Löschen Ihres Kontos: </p><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px;"><p>• Das Verfahren zum Löschen eines Kontos muss klar, intuitiv und transparent und in der Applikation leicht zu finden (z. B. eine Schaltfläche im Benutzerprofil oder in der Kontoverwaltung) sein.</p><p>• Wir müssen anbieten, den gesamten Kontodatensatz, einschließlich der damit verbundenen personenbezogenen Daten, vollständig zu löschen. Das bloße Angebot, das Konto zu deaktivieren (vorübergehend abzuschalten), reicht nicht aus. </p><p>• Wenn Benutzer die Website besuchen müssen, um die Löschung ihres Kontos abzuschließen, sollten wir einen direkten Link zu einer Seite auf der Website hinzufügen, auf der sie den Vorgang abschließen können. </p><p>• Die Benutzer müssen gut informiert sein. Wenn die Bearbeitung des Löschantrags länger dauert, müssen wir sie darüber informieren. </p><p>• Wenn die App Einkäufe in der Applikation unterstützt, müssen wir den Benutzern klar machen, wie spätere Abrechnungen und Auflösungen des Kontos ablaufen werden. </p><p>• Alle Apps müssen einen leicht zugänglichen Link zu den Datenschutzrichtlinien in der Beschreibung auf App Store Connect innerhalb der Applikation enthalten. </p><p>• Und nicht zuletzt sind die geltenden gesetzlichen Anforderungen an die Verarbeitung und Speicherung der personenbezogenen Daten des Kunden einzuhalten. Und auch für das Löschen. Dazu gehört auch die Einhaltung lokaler Gesetze - in unserem Fall der geltenden GDPR-Richtlinie.</p></blockquote><p><a href="/de" target="_blank">Cleverlance</a> als Technologieunternehmen hilft ihren Kunden, diese Anforderungen zu erfüllen. Als Anbieter von mobilen Applikationen haben wir dieses Problem erfolgreich gelöst, zum Beispiel bei der mobilen Applikation <a href="https://apps.apple.com/cz/app/my%c5%a1koda/id1161648654?l=cs" target="_blank">MyŠkoda​</a> der Gesellschaft ŠKODA AUTO a.s. Genau nach der GDPR-Richtlinie kann der Kunde hier in seinem Profil sein Konto vollständig löschen, einschließlich seiner personenbezogenen Daten. Allerdings muss er zunächst seine Fahrzeuge abschalten, die er über die App steuert. </p><p>Im Bankwesen ist die Situation ein wenig anders. Obwohl der Benutzer sein Konto und den Zugang zur mobilen App löschen kann, bleiben seine Produkte in der Bank unberührt. Ebenso wie personenbezogene Daten, die aufgrund des berechtigten Interesses an der Verarbeitung personenbezogener Daten und der Erfüllung einer legislativen Pflicht in den Systemen verbleiben müssen. Der Benutzer kann so sein Konto in der App löschen und somit die Nutzung der App einstellen. Aber er bleibt ein vollwertiger Kunde der Bank.</p><h3>Was sagt Google dazu?</h3><p>Und was sagt ein anderer Gigant, Google, dazu? Die Regeln für die Ausstellung von Apps bei Google Play besagen, dass die App transparent sein und den Benutzer darüber informieren muss, wie sie seine personenbezogenen Daten verarbeitet. Sie verbieten ein offenkundig betrügerisches oder unehrliches Verhalten. Google hat sich jedoch noch nicht dazu durchgerungen, vorzuschreiben, dass jede Applikation, die ein Benutzerkonto einrichtet, auch die Löschung dieses Kontos zulassen muss. </p><p>Dieser Schritt von Apple wird sicherlich die Transparenz und Fairness von Apps gegenüber ihren Benutzern verbessern. Es ist ein positiver Schritt in Richtung einer ehrlicheren elektronischen Welt. </p><h3>Empfehlungen für Entwickler </h3><p>Für die Implementierung der neuen Kontolöschungsfunktion empfehle ich, eine separate Freigabe nach diesem Datum zu planen. Apple wird wahrscheinlich die Funktionalität gründlich überprüfen und es könnte so passieren, dass sich die Veröffentlichung der neuen Version verzögern wird. Dies könnte sich nachteilig auf andere wichtige neue Funktionen der App auswirken, wenn sie gleichzeitig mit dieser Freigabe veröffentlicht würden. Und die Benutzer warten nicht gern.<br></p>
Entwicklung von Multiplattform-Mobil- und Webanwendungenhttps://cleverlance.de/de/blog/Seiten/Multiplatform.aspxEntwicklung von Multiplattform-Mobil- und Webanwendungen<p>​​​​​​Möchten Sie Ihre eigene mobile Anwendung? Es ist jedem klar, dass man sowohl an die Android- als auch an die iOS-Plattform denken muss, eine davon reicht nicht aus. Und oft kommen wir nicht ohne eine Webschnittstelle aus. Praktisch seit dem Aufkommen der mobilen Geräte auf dem Markt hört man jedoch, dass es teuer ist, für jede Plattform separat zu entwickeln. Aus diesem Grund haben verschiedene Unternehmen versucht, Alternativen in Form von Multiplattform-Lösungen anzubieten, aber keine von ihnen hat sich wirklich durchgesetzt. Sie hatten ihre Tücken, waren unnötig komplex und hielten ein Unternehmen, das seine mobilen Anwendungen flexibel entwickeln will, in einem imaginären „Käfig“ begrenzter Möglichkeiten. Aus diesem Grund wird für B2C-Anwendungen oft die native Entwicklung bevorzugt, da sie nicht durch UX, Animationsmöglichkeiten und andere Details eingeschränkt sind, die für diese Zielgruppe sehr wichtig sind</p><p>In den letzten Jahren haben sich jedoch mobile Unternehmensanwendungen herausgebildet, bei denen nicht die perfekte Benutzeroberfläche und das Design im Vordergrund stehen, sondern die Funktionalität, die Benutzerfreundlichkeit und vor allem die Geschwindigkeit der Bereitstellung und die Flexibilität der Anpassung. Und hier zeigte sich Spielraum für den Einsatz ausgewählter Technologien, die eine plattformübergreifende Nutzung ermöglichen. Natürlich unter Einhaltung bestimmter Regeln.<br></p><p>Bei Cleverlance haben sich drei Arten der Implementierung bewährt. Wenn wir es stark vereinfachen, müssen wir gleich zu Beginn entscheiden, wie robust das Back-End mit MOA (Microservice Oriented Architecture) ist oder ob wir es erstellen müssen, und dann, ob die Anwendung nicht zu viel Geschäftslogik haben wird, sondern eher eine reine Präsentationsebene sein wird. In diesem Fall ist es vorteilhaft, Flutter zu verwenden. Wenn wir Warteschlangen für die Synchronisation, Geschäftslogik und die Einführung einer gewissen Komplexität außerhalb von Formularen in unserer Anwendung benötigen, ist Kotlin Multiplatform eine gute Lösung. Oder es gibt einen dritten Player = PWA (Progressive Web Applications), der die starke Basis moderner Browser nutzt.<br></p><h2>Flutter<br>​<br></h2><p>Wir betrachten Flutter als eine echte Multi-Channel-Display-Ebene, mit der wir mobile, Web- und Desktop-Anwendungen erstellen können. Es handelt sich um eine flexible Lösung, mit der sich B2B- und unter bestimmten Voraussetzungen auch B2C-Anwendungen effizient gestalten lassen. Ein Beispiel ist eine mobile Anwendung für BMW. Aber wenn Sie keine Probleme lösen wollen, ist es besser, sich auf das Backend zu verlassen und ihm das „Denken“ zu überlassen.<br></p><h2>Kotlin Multiplattform<br></h2><p>Eine weitere Option ist die Multiplattformsprache Kotlin. Der Vorteil ist, dass Sie eine „native App“ für Android programmieren, von der ein Teil auch für iOS verwendet werden kann. Meistens sprechen wir über die Geschäftslogik und die Integrationsebene, was uns später in der QA-Phase eine Menge Zeit erspart. Die Visualisierungsebene ist nativ für iOS und Android programmiert, so dass es möglich ist, das „Look & Feel“ der jeweiligen Plattform zu erreichen und die „One Code Base“ für die unsichtbaren Teile der App zu übernehmen. Bei einigen Projekten können bis zu 70-80 % des Codes auf diese Weise verwendet werden.<br></p><h2>PWA<br></h2><p>Progressive Web Applications gehören zu einem der neuesten Trends in der Entwicklung von Webanwendungen. Bis zu einem gewissen Grad verwischen sie die Grenzen zwischen webbasierten und nativen mobilen Anwendungen, indem sie Offline-Arbeit, den Zugriff auf die Gerätehardware und die Möglichkeit, Push-Benachrichtigungen zu empfangen, ermöglichen. Sie vereinen das Beste aus beiden Welten, nur begrenzt durch die Einschränkungen des Browsers. Dies eröffnet eine breite Palette von Funktionalitäten, zum Beispiel können bereits eine Kamera oder einen Fingerabdruckleser in der Basis verwendet werden. Das Erfordernis, tiefer gehende Gerätefunktionen zu nutzen, kann mit einer nativen „Hülle“, der sie verfügbar macht, effizient erfüllt werden. PWA-Apps können in allen gängigen App-Stores (Google Play, Apple Store, Huawei AppGallery und Microsoft Store) platziert werden und auf Android-, iOS- und Windows-Geräten laufen.<br></p><h2>Wo funktioniert es?<br></h2><p>Als Anbieter wollen wir natürlich neben den Standard-Entwicklungstechnologien auch „neue“ Technologien anbieten, und es freut uns umso mehr, dass unsere Kunden, die von Anfang an nach Kotlin Multiplatform gefragt haben, zu uns kommen. Als Beispiel sei hier das amerikanische Unternehmen Globstar genannt, für das die Aricoma-Gruppe eine mobile Anwendung für die Konfiguration und Verwaltung von Satellitenmodems für den Internetanschluss liefert. Der Einsatz von Kotlin Multiplatform war in diesem Fall wirklich erfolgreich, da es sich um eine Anwendung handelte, die in Bezug auf Integration und Datentransfer anspruchsvoll war. Darüber hinaus erfolgt die Integration über BLE (Bluetooth Low Energy), das Dutzende von Geräten gleichzeitig bedienen und beispielsweise deren Firmware aktualisieren kann. Die Technologie hat sowohl den Kunden als auch uns als Anbieter überzeugt, und es ist uns gelungen, eine partnerschaftliche Zusammenarbeit bei der Entwicklung der Anwendung aufzubauen.<br></p><p>Wir haben die PWA-Technologie zum Beispiel im Online-Service für SAZKAmobil-Kunden erfolgreich eingesetzt. Ihr Hauptvorteil ist die extrem verkürzte Time-To-Market (die Zeit, die benötigt wird, um neue Funktionen auf den Markt zu bringen) und die große Zahl von Entwicklern, die diese Technologie beherrschen. Darüber hinaus eignen sich PWAs am besten für Anwendungen, bei denen die Nutzung der Komponenten des Geräts selbst wenig im Vordergrund steht, z. B. für interne Unternehmensanwendungen, die von Außendienstmitarbeitern oder Produktionsmitarbeitern genutzt werden.<br></p><p>Wenn Sie an technischen Details interessiert sind, lesen Sie diesen Artikel in unserem Blog mobile it, in dem Sie auch erfahren, worauf Sie bei der Auswahl einer Technologie für die Entwicklung einer mobilen Anwendung achten sollten.<br></p>

​