Du bist nicht mit dem Internet verbunden.
Firmenneuigkeiten

Nur die Paranoiden überleben

Selbstbewusstsein und Überheblichkeit fühlen sich gut an. Doch der Träge verpasst ganz schnell den letzten Zug. Und Zug um Zug nähert er sich dem letzten Atemzug. Somit gilt für uns und auch für dich die Regel, dass man durch Reflexion und Feedback besser wird: Teil 2 unseres Engineering-Manifests: Umarme Unsicherheit!

Vielleicht kennen einige von euch das Märchen Des Kaisers neue Kleider. Der Kaiser liebt Kleider. In der Geschichte verkaufen die Gauner dem Kaiser ein besonderes Kleid, welches genau auf ihn zugeschnitten sei. Es hiess, das Kleid habe die Eigenschaft, unsichtbar zu werden für diejenigen, die nicht in ihr Amt passen oder einfach zu dumm sind. Niemand wollte dem Kaiser sagen, dass er nackt herumspaziert. Auch der Kaiser selbst wollte es nicht wahrhaben. Denn das würde bedeuten, dass er sich von den Gaunern für dumm verkaufen liess. Eines Tages schreit ein Kind aus der Menschenmenge "Aber er hat ja gar nichts an!". Und als das Wort gesprochen ward, so getrauten sich plötzlich alle, die unbequeme Wahrheit zu sagen. Lasst uns daher Mut haben, Fragen zu stellen, auch wenn wir vor der Menge negativ auffallen könnten.

Gute Vorbereitung ist die halbe Miete (Sprichwort)

  • User Storys werden vorgängig durch den Komponentenverantwortlichen sorgfältig vorbereitet.
  • Es kann vorkommen, dass ein Team Änderung an einer alten, nicht einfach zu durchschauenden Logik vornehmen muss. In diesem Fall ist es ideal, vorgängig eine Research-Story einzuplanen. So können bei Bedarf auch Prozessvisualisierungen erstellt werden, um das gemeinsame Verständnis über die Logik zu fördern. Die Wissenserarbeitung bildet eine gute Grundlage für Diskussionen im Team. Und sie hilft Probleme frühzeitig zu erkennen und bessere Schätzung abzugeben.

Ganze Sachen sind immer einfach wie die Wahrheit selbst. Nur die halben Sachen sind kompliziert. (Heimito von Doderer) Divide et impera (Redewendung)

Eigentlich gibt es wirklich nichts auf der Welt, was kompliziert wäre. Denn alle komplizierten Dinge bestehen aus einfachen Dingen. Wenn wir beginnen die Informationen auf einfach verständlich Art und Weise zu vermitteln, mit UML-Diagrammen, NDepend Graphen, Auswertungen, Entwurfsmustern, Tabellen etc. Dann sehen wir alle das Gesamtbild und plötzlich sind die Dinge einfach zu verstehen und umzusetzen.

Wenn wir Lösungen entwickeln, so ist es wesentlich, dass diese so einfach wie möglich sind. Je klarer und einfacher eine Lösung ist, desto besser. Damit reduziert sich der Aufwand in der Kommunikation, in der Bedienung und in der Wartung.

Jeder Mensch hat ein Brett vor dem Kopf – es kommt nur auf die Entfernung an." (Marie Freifrau von Ebner-Eschenbach)

Teamswitch-Storys und Bugs aus anderen Komponenten sind eine gute Möglichkeit, etwas Neues zu lernen. Es kann nicht schaden, sich mit einer anderen Komponente auseinanderzusetzen. Man versteht das Gesamtbild besser und die Distanz zum Brett wird wieder etwas grösser ;)

Eisen schärft Eisen; ebenso schärft ein Mann den anderen (Bibel, Sprüche 27,17)

Niemand ist perfekt. Gemeinsam können wir einander darin unterstützen, besser zu werden. Ein anderer sieht den Fehler, welcher für unser Auge unsichtbar ist. Deshalb sind Code-Reviews und Feedbacks wertvoll, weil wir uns gemeinsam weiterentwickeln und verbessern können. Die Fehler können gelöst werden, bevor diese in der produktiven Umgebung entstehen.

Nachfolgend einige Anregungen zum Thema «Umarme die Unsicherheit»

  • Ich habe den Mut, Unklarheiten anzusprechen, auch wenn daraus eine peinliche Situation entstehen könnte.
  • Bei Unsicherheiten in Komponenten plane ich Research-Storys ein.
  • Komplizierte Problemstellungen teile ich auf in mehrere, einfachere Teilaufgaben. Dazu nutze ich methodische und technische Werkzeuge wie Story Mapping, BPMN-Diagramme, NDepend, SonarQube etc.
  • Ich sehe Teamswitch-Storys als Horizonterweiterung an und verschaffe mir Kenntnisse in anderen Komponenten
  • Ich minimiere Unsicherheit durch Peer-Reviews und Feedback durch alle Stakeholder
  • Ich treffe kritische Entscheidungen möglichst spät, damit ich möglichst viele Details für die Entscheidung nutzen kann, welche bei der Umsetzung erarbeitet werden

Auch hier, weitere anschauliche Beispiele, wie das zweite Motto des Manifests gelebt werden kann, sind willkommen. Wir freuen uns über jedes Feedback.

Unser Manifest

baixe-aqui-do-livro-ldquo21.jpeg
Firmenneuigkeiten
Tim Csitkovics
Tim Csitkovics
Tim Csitkovics
Junior Software Engineer
  • 1Artikel geschrieben
  • 0Fragen gestellt
  • 0Fragen beantwortet
  • 0Bewertungen geschrieben
  • 0Bewertungen kommentiert
  • 0Diskussionen gestartet
  • 0Beiträge geschrieben
Mehr Infos...
  • 29 7

Warum die Macht nicht immer mit dir sein sollte

Unser Manifest überzeugt dich?

Oder es überzeugt dich nicht, aber du möchtest trotzdem bei uns entwickeln? Wir haben folgende Stellenangebote in der Softwareentwicklung:

User

Robert Rajakone

1 Kommentar

User Anonymous

Ein wichtiger Unterschied zwischen komplex und kompliziert: blog.kmto.de/beratung/kompl...

Wusste ich auch lange Zeit nicht :-)

15.09.2016
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

Du musst angemeldet sein, um auf einen Kommentar zu antworten.


Bitte melde dich an.

Du musst angemeldet sein, um einen neuen Kommentar zu erfassen.

Corporate logo