Unsere Kompetenzen
Während unserer langjährigen Tätigkeit in der Softwareentwicklkung haben wir wertvolle Erfahrungen in verschiedenen Bereichen gesammelt. Nachfolgend präsentieren wir die Kompetenzen, die für uns heute von besonderer Bedeutung in der Projektumsetzung sind.
Unsere Methoden um möglichst effektiv Lösungen zur Verfügung zu stellen.
Scrum ist eine Arbeitsmethodik in der agilen Softwareentwicklung und beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst zu werden. So werden in einem regelmässigen Zyklus (z.B. alle zwei Wochen) kleine Zwischenergebnisse geschaffen, anhand derer sich die fehlenden Anforderungen und Lösungstechniken konkretisieren lassen.
Das Ziel von Kanban ist, schnellere Durchlaufzeiten zu erreichen und Probleme schneller sichtbar zu machen. Dies wird unter Anderem durch Begrenzung von parallelen Arbeiten erreicht. Die ganze Wertschöpfungskette mit ihren verschiedenen Prozessschritten wird in einem sogenannten Kanban-Board für alle Beteiligten visualisiert.
Lean-Methodiken stammen ursprünglich aus der Japanischen Autoindustrie. Sie eignen sich hervorragend um neue Ideen zu testen und herauszufinden ob man damit ein profitables Business aufbauen kann. Die Methodiken umfassen MVP (Minimum Viable Product), Customer Development, Lean Canvas und mehr.
Clean Code macht den Unterschied zwischen Amateur-Software und professioneller Software. Wir arbeiten mit den Clean Code-Prinzipien um robuste und wartbare Software zu schreiben.
Automatisiertes Testing ist ein integraler Bestandteil der Entwicklung. Wir empfehlen den Aufbau einer systematischen Testpyramide um eine optimale Abdeckung zu erhalten. Je nach Verwendungszweck und Lebensdauer einer Software sind ganz unterschiedliche Ansätze erforderlich. Ziel des Testings ist es immer zu einem vernünftigen Preis eine optimale Sicherheit und Qualität zu erreichen.
Mit Continuous Integration (CI) werden die Software-Artefakte mehrmals pro Tag neu gebaut, integriert und getestet. Mit Continuous Delivery (CD) kommt noch die Auslieferung auf einen Produktivserver hinzu. Ein zuverlässiges automatisiertes Testing wird vorausgesetzt. Nach unseren Erfahrungen führt CI/CD zu mehr Lieferzuverlässigkeit, Flexibilität und schnellerer Time-To-Market.
Im Gegensatz zum technologiezentrierten Vorgehen steht beim anwenderzentrierten Design (UCD) der Mensch im Zentrum. Das System wird dabei von der Benutzerschnittstelle abgeleitet. Der Fokus bezüglich Qualität geht von Stabilität und Performance hin zum Nutzen und Benutzbarkeit (Usability). Für ein anwenderzentriertes Vorgehen ist es deshalb nötig als erstes die Anwender:innen mit ihren Zielen, Tätigkeiten und Verhalten zu verstehen.
Beim Story Mapping erstellen alle an einem Projekt Beteiligten zusammen eine Landkarte ihres Vorhabens. Dabei entsteht ein gemeinsames Verständnis, was für die Umsetzung enorm wertvoll ist. Die Story Map visualisiert den Umfang und die Grösse eines Vorhabens. Zusätzlich lassen sich damit einzelne Releases definieren um beim Umsetzen den Fokus nicht zu verlieren.
Bei all unseren Lösungen stehen die Anwender:innen im Fokus. Entsprechend ist bei uns Usability nicht bloss ein Lippenbekenntnis sondern Teil jeder Entwicklung.
Auch Contextual Inquiry genannt. Dabei werden zukünftige Anwender:innen in ihrem natürlichen Umfeld beobachtet und zu Tätigkeiten, Gewohnheiten und Bedürfnissen befragt.
Beobachtungen und Erkenntnisse werden in einem Persona-Modell festgehalten. Eine Persona unterstützt bei der Fokussierung, Ausrichtung und Kommunikation einer zukünftigen Lösung.
Kontext Szenarios beschreiben zukünftige Lösungen als Geschichte der Personas. Kontext Szenarios unterstützen die Kreativität und machen die zukünftige Lösung fassbarer.
Sketches sind mit Stift auf Papier gezeichnete User Interfaces der zukünftigen Lösung. Diese fördern die Kreativität und eignen sich um sehr schnell viele mögliche Varianten einer Lösung zu entwickeln.
Wireframes sind wie Sketches Zeichnungen eines zukünftigen User Interfaces. Im Gegensatz zu Sketches werden diese am PC ausgearbeitet und eignen sich um eine Idee zu verfeinern.
Prototypen verhalten sich wie Teile der zukünftigen Lösung. Da sie innerhalb von Stunden erstellt werden können, erlauben diese sehr schnell Feedback von den zukünftigen Anwender:innen zu erhalten.
Designprinzipien sind ein Satz von Regeln, die als Richtschnur für die Produktentwicklung dienen. Sie sorgen nicht bloss für Konsistenz, sondern machen Entscheidungen und schlussendlich die eigentliche Benutzererfahrung messbar.
Bei der heuristischen Evaluation werden mit der Hilfe von Designprinzipien Lösungen evaluiert. Eine solche Evaluation gibt schnell einen Überblick über die Mängel und Potentiale einer Lösung.
Bei Usability Tests werden den Anwender:innen Aufgaben gestellt, welche in der Lösung oder einem Prototypen selbständig gelöst werden müssen. Dies gibt Aufschluss über die Verständlichkeit und Einfachheit einer Lösung.
Die Architektur spielt eine entscheidende Rolle, um die technischen Bedürfnisse zu erfüllen wie z.B. Sicherheit, Zuverlässigkeit, Verfügbarkeit usw.
Üblicherweise werden Anforderungen an ein System in Form von Anwendungsfällen oder User Stories beschrieben. Diese definieren was das System fachlich können soll. Darüber hinaus gibt es jedoch auch Anforderungen, die über reine Funktionalität hinausgehen. Sie beschreiben wie sich das System verhalten soll und haben grossen Einfluss auf die Entstehung der Architektur. Qulitätsziele und -szenarien sind hervorragende Werkzeuge um die Architektur laufend zu überprüfen.
Bei der Architekturarbeit werden viele Entscheidungen getroffen, die im Nachhinein nur mit grossem Aufwand geändert werden können. Falsch getroffene Entscheidungen können ein Projekt zum Scheitern bringen. Darum ist es wichtig, solche Entscheidungen sorgsam und nachvollziehbar zu fällen. Relevante Einflussfaktoren sind zum Beispiel die Rahmenbedingungen und die Qualitätsziele. Nicht jede Entscheidung ist von grosser Bedeutung. So raten wir zwischen einer Mikro- und Makroarchitektur zu unterscheiden. Hier wird definiert, was übergreifend festgelegt wird, und wo Teams Freiheit in der Entscheidung haben.
Dokumentation wird in vielen Softwareprojekten stark vernachlässigt. Später wundert man sich, warum gewisse Teile der Architektur so entstanden sind. „Historisch gewachsen“ sind Antworten die hellhörig machen sollten. Dies muss nicht sein, denn architekturrelevante Einflussfaktoren von Softwarelösungen lassen sich angemessen und ohne Ballast festhalten und kommunizieren.
Die Organisation einer Unternehmung hat grossen Einfluss auf die Entstehung einer Softwarelösung. Es ist entscheidend, dass Teams von Anfang an passend aufgestellt sind. Die Kommunikationsstruktur wird von den Teams getrieben und wenn nötig angepasst. Eine mögliche Lösung dafür sind Gilden (organisationsübergreifende Interessengruppen, z.B. für Testing oder UI-Gestaltung).
Mit der passenden Technologie gelingen besser Lösungen.
Kein Problem! Melde dich bei mir, ich spreche auch deine Sprache.
