Sieger KMU-Preis Vorarlberg 2024


In der digitalen Produktentwicklung ist ein gut strukturierter Design- und Entwicklungsprozess entscheidend für den Erfolg eines Projekts. Doch oft scheitern Teams an Herausforderungen wie mangelnder Kommunikation, unklaren Vorgaben und fehlender Abstimmung zwischen Designern und Entwicklern. Diese Schwachstellen führen nicht nur zu Missverständnissen und Verzögerungen, sondern auch zu inkonsistenten Ergebnissen, die die Qualität des Endprodukts beeinträchtigen können.

In diesem Blogpost werfen wir einen Blick auf die häufigsten Probleme in traditionellen Design- und Entwicklungsprozessen und stellen im Anschluss einen modernen Ansatz vor, der durch den Einsatz von Tools wie Figma und Storybook nicht nur die Zusammenarbeit verbessert, sondern auch eine konsistente und effiziente Umsetzung garantiert.

#### Der veraltete Design- & Entwicklungsprozess ❌

Der Design- und Entwicklungsprozess ist oft von Herausforderungen geprägt, die sich aus unklarer Kommunikation, unzureichenden Designvorlagen und mangelnder Abstimmung zwischen den Teams ergeben. Angefangen bei der Ideensammlung bis hin zur Entwicklung ohne klare Richtlinien können diese Probleme zu Missverständnissen, unrealistischen Erwartungen und ineffizientem Arbeiten führen.

**1. Brainstorming und Ideensammlung**

Der Prozess beginnt oft mit einer Idee vom Kunden, die dann an eine Designagentur ausgelagert wird. Hier liegt oft das erste Problem: Die Kommunikation zwischen Kunde und Agentur kann unklar sein, was zu Missverständnissen und unrealistischen Erwartungen führt.

**2. Erstellung von Wireframes**

Die Agentur erstellt Wireframes, oft noch in Form von statischen PDFs oder pixelbasierten Entwürfen zum Beispiel für Desktop. Diese können jedoch die dynamischen Aspekte einer Website oder App nicht angemessen erfassen und lassen oft wichtige Details unberücksichtigt und Entscheidungen und Feedback für den Start der Entwicklung fehlen.

**3. Entwicklung ohne klare Richtlinien**

Die Entwicklung beginnt auf Basis der Wireframes und eines möglichen Styleguides. Hier entstehen jedoch oft Probleme:

- **Unvollständige Informationen:** Der Styleguide ist oft unvollständig und lässt Fragen offen, wie die richtige und konsistente Verwendung von Farben und Schriften, optimierte Layouts für unterschiedliche Bildschirmgrößen oder die Darstellung unterschiedlicher Zustände und Interaktionen.
- **Mangelnde Konsistenz:** Da Designentscheidungen durch statische PDFs nicht eindeutig festgelegt sind, treffen Entwickler oft individuelle Entscheidungen. So kann es gut sein, dass ein Entwickler den Abstand zwischen Text und Button etwas größer interpretiert und umsetzt als sein Team-Mitglied. Dies führt zu inkonsistenten Ergebnissen und erhöhtem Zeitaufwand.
- **Fehlende Abstimmung:** Die fehlende Koordination zwischen Design und Entwicklung führt zu ineffizientem Arbeiten und kann zu unerwarteten Problemen im späteren Projektverlauf führen. Der Kunde hat die statischen Mockups in PDF-Form gesehen, hatte jedoch andere Erwartungen an die Interaktion des fertig entwickelten Produkt oder für spezifische Fälle, welche nicht abgebildet werden konnten.

![](/images/blog/optimierter-design-entwicklungsprozess/design-system-processes.png 'Vergleich Prozesse')

#### Ein moderner Prozess ✅

In einem modernen Design- und Entwicklungsprozess bildet ein **Design System** die Basis für effizientes Arbeiten und eine konsistente Umsetzung. Der Prozess wird durch den Einsatz von Tools wie [Figma](https://www.figma.com/de-de/design/) zum Erstellen von interaktiven Klick-Prototypen oder [Storybook](https://storybook.js.org/) zur Erstellung einer Komponenten-Bibliothek unterstützt.

**1. Erfassen der Anforderungen und Wireframing**

Die Anforderungen werden erfasst und erste Entwürfe/Wireframes werden erstellt. Dabei findet eine kontinuierliche Rücksprache mit dem Kunden statt, um Basiskonzepte und Grundlagen des Design-Systems wie Farben, Schriften, Layouts und Interaktionen zu definieren. In diesem Prozess ist es wichtig, auch die Abläufe und Funktionen aus Kunden- und Anwendersicht zu verstehen.

![© Figma](/images/blog/optimierter-design-entwicklungsprozess/figma-design-system.png 'Design System')

**2. Design System als Diskussionsplattform**

Basierend auf den umfangreich erfassten Anforderungen und Konzepten wird von der Agentur das Designsystem und die Applikation in einem modernen Tool wie Figma in mehreren Sprints umgesetzt und anhand von Klickprototypen interaktiv gemacht. Das Design System dient als zentrale Plattform für Diskussionen und liefert viele Informationen sowie Antworten auf Design- und Entwicklungsfragen. Durch den Einsatz interaktiver Prototypen in Figma können UX-Fragen frühzeitig geklärt und Feedback eingeholt werden.

- **Interaktive Prototypen:** Durch interaktive Prototypen werden Designentscheidungen besser verstanden und können erlebt werden. Der Kunde kann die Basis-Interaktionen schon vor der Entwicklung sehen und präzises Feedback geben.
- **Figma als Tool mit DEV Mode:** Entwickler erhalten frühzeitig relevante Informationen auch aus technischer Sicht und können spezifische Fragen stellen und ihre Erfahrung einbringen, was den Entwicklungsprozess optimiert.
- **Konsistenz und Effizienz:** Alle Entwickler arbeiten auf der gleichen, vollständigen Grundlage, was zu einer konsistenten und effizienten Umsetzung führt.

![© Figma](/images/blog/optimierter-design-entwicklungsprozess/dev-mode-copyright-figma.png 'DEV Mode ©Figma')

<Card className="p-4 sm:p-4 md:p-6 my-8">
**Figma Dev Mode**

Figma bietet mit seinem [Dev Mode](https://www.figma.com/de-de/blog/introducing-dev-mode/) einen Playground für Entwickler, der den gesamten Prozess der Entwicklung unterstützt.

<ul>
  <li>**Inspizieren von Komponenten:** Entwickler können Komponenten im Detail untersuchen, einschließlich Zuständen und Interaktionen.</li>
  <li>
    **Output für Entwickler:** Figma generiert automatisch CSS-Stile, Rem-Größen und verwendet Tokens, was Entwicklern die Entscheidungsfindung
    erleichtert.
  </li>
  <li>
    **Markieren von Komponenten/Screens als "Bereit für die Entwicklung":** Diese Funktion ermöglicht eine klare Kommunikation zwischen Design und
    Entwicklung. Durch direkte Notizen für Entwickler und die Einsicht in Änderungen am Design seit der Freigabe werden Produktbesitzer und Entwickler
    dabei unterstützt, nachträgliche Änderungen besser zu verstehen und zu verwalten. Diese Funktionen tragen dazu bei, die Zusammenarbeit zwischen
    Design und Entwicklung zu verbessern und die Effizienz des gesamten Prozesses zu steigern.
  </li>
</ul>

  </Card>

**3. Entwicklung von Komponenten**

Basierend auf dem grafischen und interaktiven Komponentenkatalog in Figma kann mit der Entwicklung gestartet werden. Oft wird hier bereits mit der Implementierung von Basis-Komponenten gestartet. Diese werden unabhängig von der Applikationslogik (Backend, Authentifizierung, ...) implementiert und können somit ohne Abhängigkeiten entwickelt und getestet werden. Die isoliert entwickelten Komponenten, wie beispielsweise Buttons, Popups oder die Toolbar, können dadurch auch in anderen Projekten des Unternehmens eingesetzt werden.

- **Eigene Style- und Component-Library:** Isolierte Frontend-Komponenten können in einer eigenen Component-Library entwickelt werden, die in verschiedenen Projekten wiederverwendet werden kann.
- **Unabhängige Konzeption und Implementierung:** Durch die Entwicklung und automatisierten Tests der isolierten Komponenten, ohne Abhängigkeiten zu spezifischen Applikationen, ist eine schnelle und unabhängige Entwicklung möglich.
- **Storybook als Tool:** Mit Tools wie zum Beispiel Storybook kann eine Art [Katalog für alle implementierten Basis-Komponenten](https://react.ui.audi/?path=/story/components-accordion--properties) erstellt werden. Dies ermöglicht es allen Teilnehmern die generische Komponenten-Bibliothek anzusehen, auszuprobieren und für weitere Projekte einzusetzen.

Durch diesen modernen Prozess wird eine effiziente und konsistente Umsetzung von Design und Entwicklung gewährleistet, was zu qualitativ hochwertigen Produkten führt.

![© Storybook](/images/blog/optimierter-design-entwicklungsprozess/storybook-example.png 'Storybook Example ©Storybook')

![© Atlassian](/images/blog/optimierter-design-entwicklungsprozess/style-library-copyright-atlassian.png 'Library / Tokens ©Atlassian')

#### Fazit

Ein moderner Design- und Entwicklungsprozess zeichnet sich im besten Fall durch die Nutzung eines Design Systems aus, das als Grundlage für alle Arbeitsschritte dient. Durch die klare Definition anhand des Design Systems wird eine konsistente Umsetzung gewährleistet.

Die verschiedenen Bereiche wie Design und Entwicklung rücken näher zusammen, da jeder Bereich nur seine spezifischen Fähigkeiten einbringt. Entwickler müssen keine Designentscheidungen treffen, sondern können sich auf ihre Expertise konzentrieren. Gleichzeitig ermöglicht dies eine bessere Verknüpfung von Know-how und Inputs aus verschiedenen Bereichen. Entwickler und Produktbesitzer können frühzeitig ihr Wissen und ihre Erfahrungen in den Designprozess einbringen und so wertvolles Feedback liefern.

Durch dieses nahtlose Zusammenarbeit wird eine effiziente und konsistente Umsetzung von Projekten erreicht. Die klare Kommunikation und das gemeinsame Verständnis für die Anforderungen führen zu qualitativ hochwertigen Endprodukten, die den Bedürfnissen der Nutzer gerecht werden.

![](/images/blog/optimierter-design-entwicklungsprozess/design-system-processes.png 'Vergleich Prozesse')

#### Links

- [Figma für Design Systeme](https://www.figma.com/de-de/design-systems/)
- [Figma Dev Mode](https://www.figma.com/de-de/blog/introducing-dev-mode/)
- [Figma Introduction to design systems ](https://help.figma.com/hc/en-us/articles/14552901442839-Overview-Introduction-to-design-systems)
- [Design Tokens](https://atlassian.design/tokens/design-tokens)
- [Storybook](https://storybook.js.org/)
- [Storybook Figma integration](https://storybook.js.org/docs/sharing/design-integrations)


Konsistenz und Effizienz: So verbesserst du den Design- und Entwicklungsprozess


Spätestens seit dem Release von Version 17 ist klar, dass das Angular Team eine neue Richtung einschlagen will. Im Mittelpunkt davon: Angular Signals. Diese sollen den Einstieg in die Angular Welt erleichtern, die Change Detection optimieren und das kontroverse RxJS zu einem optionalen, allerdings immer noch mächtigen, Werkzeug anstatt integralen Bestandteil des Frameworks machen.

Das NgRx Team hat zeitgleich mit dem Angular 17 Release die erste Version der @ngrx/signals Library veröffentlich und bietet damit direkt eine flexible und einfache Möglichkeit zum signal-based State Management an. Der darin enthaltene lightweight Signal State und etwas umfangreichere Signal Store sind dabei komplett abgekapselt zum bereits etablierten RxJS-based NgRx Store und Component Store zu betrachten.

Doch inwieweit unterscheidet sich der Signal Store von bisherigen State Management Lösungen, welche Features kommen out-of-the-box mit und ist eine zusätzliche externe Library überhaupt notwendig für das State Management von Signals? Wir haben den NgRx Signal Store bereits seit einem halben Jahr im Einsatz und ziehen Fazit.

#### Signal State

Wie bereits erwähnt gibt es zwei verschiedene Ausprägungen der NgRx Signals Library. Der Signal State ist eine lightweight und minimalistische Utility zum Verwalten von signal-based State. Dieser eignet sich beispielsweise besonders gut für abgekapselte States auf Komponenten Ebene. Dazu wird einfach die signalState Funktion aus dem Package eingebunden und mit dem initialen State initialisiert.

```jsx
import { signalState } from '@ngrx/signals';

const userState =
  signalState <
  UserState >
  {
    firstName: 'John',
    lastName: 'Doe',
    address: {
      street: 'Street 1',
      zip: 1234,
    },
  };
```

Sieht auf den ersten Blick nicht viel anders aus als ein gewöhnliches Angular Signal, unterscheidet sich aber folgendermaßen:

- **Deep Signal:** Der Signal State erzeugt im Hintergrund nicht nur für das userState Objekt ein readonly Signal, sondern zusätzlich auch für jedes verschachtelte Property. Somit kann beispielsweise die address Property mit userState().address und userState.address() ausgelesen werden und erlaubt für “fine-grained reactivity”. Konsumenten des Signals können den State also auf Property Ebene auslesen und werden bei anderen Änderungen des States nicht benachrichtigt und unnötige Change Detection Cycles bleiben erspart.
- **Immutable State Updates:** Um unerwartete Side Effects zu verhindern, bietet die patchState Funktion die Möglichkeit an den State auf eine kontrollierte Art und Weise zu aktualisieren.

```jsx
import { patchState } from '@ngrx/signals';

patchState(userState, { firstName: 'Jane' });
patchState(userState, (state) => ({ address: { ...state.address, zip: 5678 } }));
```

Zusätzlich dazu können auch wiederverwendbare State Updaters erstellt werden.

```jsx
import { PartialStateUpdater } from '@ngrx/signals';

function setZip(zip: number): PartialStateUpdater<{ address: Address }> {
  return (state) => ({ address: { ...state.address, zip } });
}

patchState(userState, setZip(5678));
```

Dieser funktionelle Ansatz zum State Management ermöglicht hohe Flexibilität und deckt wahrscheinlich die Anforderungen der meisten Use Cases ab.

#### Signal Store

Mit dem Signal Store hat NgRx die Basis Funktionalität des Signal States um einige Features erweitert und ist in der Lage komplexeren Anforderungen gerecht zu werden. Der Store wird mit der signalStore Funktion erstellt und liefert ein Injectable Service zurück. Der generierte Service kann entweder in root provided werden und als Singleton einen applikationsweiten State verwalten oder direkt in Komponenten provided werden und als Component Store eingesetzt werden. Der Signal Store umfasst folgende Konzepte:

- `withState`: Analog zum signalState kann mit der withState Funktion der initiale State des Stores gesetzt werden.
- `withComputed`: Basierend auf den initial erstellten Signals können direkt im Store berechnete Werte (Computed Values) definiert werden. Damit kann featurespezifische Logik von der Komponente in den Store ausgelagert werden und hilft dabei die Komponenten schlank zu halten.
- `withMethods`: Um zu vermeiden, dass der State von überall in der Applikation aktualisiert werden kann, werden mit der withMethods Funktion die State Update Logik bereit gestellt und führt mögliche asynchrone Side Effects entweder mit Promises aus oder wie bisher mit RxJS mithilfe der rxMethod Funktion.
- `rxMethod`: Wer nicht komplett auf die Stärken der RxJS Operators verzichten will, kann ganz einfach mit rxMethod Funktionalität ausgehend von einem Observable Stream ausführen. Entweder durch manuelle Trigger oder als Reaktion auf einen Signal Change emitted das Source Observable einen neuen Wert und macht es so möglich komplexere Side Effects zu handhaben.
- Lifecycle Hooks: Die mitgelieferten onInit und onDestroy Hooks machen den Store noch unabhängiger und in sich konsistent. Man sieht beispielsweise auf einen Blick, wie sich der initiale State zusammensetzt, ohne die gesamte Applikation für Methodenaufrufe durchsuchen zu müssen.
- Custom Features: Das auf den ersten Blick vielleicht unscheinbarste Feature ist womöglich das Mächtigste. Der Signal Store ermöglicht es wiederkehrende State Logik in eigene Features zu kapseln, die je nach Bedarf in den Store eingebunden werden. So kann man beispielsweise eine Loading/Error State Logik (inklusive State Properties, Computed Properties, Methods, etc.) auslagern und jeder Store der dieses Features aktiviert kann mit nur einer Code Zeile auf diese Logik aufbauen. Die perfekte Ausgangssituation für eine flexible Softwarearchitektur.

Ein Beispiel für einen simplen Signal Store könnte folgendermaßen aussehen.

```jsx
import { patchState, signalStore, withComputed, withMethods, withState} from '@ngrx/signals';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { withLoadingState } from '../loading-state-feature';
[...]

const initialState: UsersState = {
  users: [],
  filter: ''
};

@Injectable({ providedIn: 'root' })
export class UserStore extends signalStore(
  withState(initialState),
  withLoadingState(), // <- Activate Custom Feature to access isLoading property
  withComputed(({ users, filter }) => ({
    usersCount: computed(() => users().length),
  })),
  withMethods((store, usersService = inject(UsersService)) => ({
    updateFilter(filter: string): void {
      patchState(store, { filter });
    },
    connectFilter: rxMethod<string>(
      pipe(
        debounceTime(300),
        distinctUntilChanged(),
        tap(() => patchState(store, { isLoading: true })),
        switchMap((query) => {
          return usersService.getByFilter(filter).pipe(
            tapResponse({
              next: (users) => patchState(store, { users }),
              finalize: () => patchState(store, { isLoading: false }),
            })
          );
        })
      )
    ),
  })),
  withHooks({
    onInit(store) {
      store.connectFilter(store.filter);
    },
  })
);
```

#### Fazit

Durch den funktionellen Ansatz und der flexiblen Anwendung bringt der Einsatz der Library viele Vorteile und wenige bis keine Nachteile mit. Das State Management verleiht der Applikation ausreichend Struktur und eine einheitliche Architektur bei geringem Overhead und gleichzeitig minimaler Vergrößerung der Bundle Size.

Unsere wichtigsten Erkenntnisse:

- **Flexibilität:** Je nach Feature oder Komponente kann der Store als Component Store oder globaler App Store eingesetzt werden. Sollte unklar sein, an welcher Stelle der App Struktur der Store erstellt und eingebunden wird, gilt als Faustregel den Store so spezifisch wie möglich zu integrieren. Sollte es notwendig sein, den Store globaler zu machen, ist das mit wenig Aufwand möglich. Somit können unnötige Abhängigkeiten einfach vermieden werden.
- **Schlanke Komponenten:** Mit der withComputed Methode lässt sich Komponentenlogik einfach und an einer Stelle im Store definieren und sorgt dafür, dass die Komponenten möglichst klein und wartbar bleiben. Der Einsatz von Computed State Properties versichert stabile und berechenbare Change Detection Cycles.
- **Custom Features:** Generische und wiederkehrende Logik lässt sich unkompliziert in eigene Files auslagern und fördert eine flexible Architektur.

Gerade in Projekten mit begrenztem vorhandenen RxJS Know How erleichtert der Signal Store die initiale Implementierung des State Managements und das Onboarding neuer Entwickler. Die Architektur des klassischen NgRx State Management mit strikter Trennung von Actions, Effects, Reducers und Selectors hat natürlich Vorteile in größeren Projekten, ist die etabliertere Lösung und ist von vielen Teams möglicherweise noch die präferierte Option. Dennoch sehe ich die den Signal State/Store als die flexiblere und einfachere State Management Lösung an, vor allem aufgrund des Shifts in Richtung Signals im Angular Framework.


NgRx Signal Store – worth the hype?


Trotz guten Entwicklern und einem erfahrenen Projektteam ist der Erfolg eines Software Produktes nicht immer automatisch gewährleistet. Jahrelang eingespielte Entwicklerteams, ausreichend vorhandenes Know-How sowohl in Domäne als auch Tech-Stack gepaart mit genügend zeitlicher Flexibilität bleiben oft das Wunschszenario. Kurz gesagt, die Ressourcen sind knapp, die gesetzten Ziele hoch. Es gilt also mit diesen Rahmenbedingungen umzugehen, die Produktivität zu maximieren und die internen Voraussetzungen für einen effizienten Entwicklungsprozess zu schaffen.

Und dennoch ist in vielen Fällen genau hier noch Luft nach oben. Unklare Strukturen und Prozesse, mangelnder Fokus auf das Kernprodukt, unproduktive Meetings und teils ausbaufähige Architekturentscheidungen sind nur einige der Hürden, mit denen sich Produkt- und Entwicklerteams auseinandersetzen müssen. Gerade wenn Ressourcen nicht immer ausreichen und die Zeit drängt, können die richtigen internen Handgriffe dem Team die notwendige Struktur, Effizienz und Motivation verleihen.

#### Produktmanagement: Die Richtung festlegen und halten

Die Basis für einen optimalen Produktentwicklungsprozess entsteht bereits bei der Ausarbeitung der Produkt Strategie. Im Mittelpunkt, eine klar definierte Product Roadmap. Diese Roadmap sollte nicht nur kurzfristige Ziele festlegen, sondern auch eine klare Mission für das Produkt definieren. Ein gemeinsames Verständnis der Mission schafft Identifikation im Team, fördert die Zusammenarbeit und hilft dabei, die Entwicklung auf das Wesentliche zu konzentrieren. Dabei sollten ständige Richtungsänderungen und Insellösungen vermieden werden, da diese die Entwicklung verlangsamen und das Team demotivieren. Natürlich ist klar, dass auf gewisse Dynamiken im Markt reagiert werden muss und diese die Strategie beeinflussen können, allerdings haltet sich die Agilität an dieser Stelle idealerweise noch etwas in Grenzen.

#### Strukturierte Abläufe und klare Rollenverteilungen

Es hat gute Gründe, wieso Scrum der Grundstein für nahezu alle modernen Software Projekte ist. Es verteilt eindeutige Aufgabenbereiche, gibt einen transparenten und einheitlichen Arbeitsablauf vor und erlaubt somit für Flexibilität, Reaktionsschnelligkeit und Effizienz. Obwohl es nicht in allen Fällen notwendig ist einen Scrum-Prozess laut Lehrbuch einzuführen, sollte man sich den Vorteilen der Grundprinzipien von Scrum bewusst sein und bei Bedarf einen adaptierten Prozess implementieren. Das Ziel muss sein:

- Gut vorbereitete PI- und Sprintplanungen, welche durchdachte und ausführlich definierte Arbeitspakete verabschiedet und die Arbeitsbelastung ideal priorisiert
- Kompakte und regelmäßige Standup Meetings während des Sprints um den Informationsaustausch hochzuhalten und unnötige Meetings zu vermeiden
- Klare Rollenverteilung für direkte Kommunikation und kurze Entscheidungswege
- Gezieltes Dokumentieren von kritischen Informationen als Kriterium für Definition of Done
- Ständige Reflexion des Arbeitsprozesses und Team Dynamik durch regelmäßige Retrospective Meetings

Diese Grundprinzipien erlauben dem Entwicklungsteam vollen Fokus und Stabilität. Zusätzlich dazu wird es für neue Teammitglieder leichter sich schnell in das Projekt zu integrieren und Schritt für Schritt durch strukturierte Planung und direkte, regelmäßige Kommunikation den gewünschten Output zu produzieren.

#### Saubere Anforderungen und eine effektive Teststrategie

Viele haben es wahrscheinlich schon mitgemacht: Das Planungsmeeting geht wiedermal länger als geplant, Grundsatzdiskussionen nehmen die eigentlich wertvoll eingeplante Zeit für die Definition der Akzeptanzkriterien ein und jeder ist froh, wenn man das mühselige Meeting hinter sich lassen und mit der Umsetzung starten kann. Das Problem dabei, die geplanten Stories wurden nicht mehr im notwendigen Detail besprochen, Anforderungen wurden schlampig definiert und es herrscht zu viel Interpretationsspielraum. Dementsprechende Unsicherheit, Fehlinterpretationen und Missverständnisse während der Implementierung führen nun zu möglichen ungewünschten Outcomes und kostspieligen Verzögerungen.

Man sieht, die beiden oben angesprochenen Themen sind auch die Basis für ein sauberes Anforderungsmanagement. Aufbauend darauf ist es ausschlaggebend, die Lösungsspezifikation der Arbeitspakete nicht nur zu diskutieren, sondern auch vollständig und verständlich zu verschriftlichen. Somit wissen sowohl Entwickler und Product Owner genau was definiert wurde, das Risiko für Missverständnisse und zeitaufwendige Abstimmungsmeetings wird minimiert, und die Voraussetzungen für einen effizienten Review und Testing Prozess sind geschaffen.

Werden die Features nun on-time abgeschlossen und präsentiert, kann parallel direkt mit dem Testing angefangen werden während der nächste Sprint bereits in Entwicklung ist. Ergänzend zum bestehenden automatisierten Testing werden somit durch _Continuous Testing_ potenzielle Fehler frühzeitig erkannt und behoben. Dies ermöglicht nicht nur eine höhere Produktqualität, sondern reduziert auch das Risiko von teuren Nacharbeiten und langwierigen Testphasen vor dem Release.

#### Modularisierung von Architekturen für Flexibilität und Skalierbarkeit

Gerade in größeren Softwareprojekten mit einer Vielzahl an Entwicklern, oftmals sogar organisiert in mehreren Teams, kann eine suboptimale Architektur schnell mal zum Bottleneck werden. Je länger das Projekt andauert und die Applikation wächst, desto anspruchsvoller ist in der Regel die Entwicklung jedes einzelnen neuen Features und umso wichtiger ist der Fokus auf einen hoch-qualitativen und vor allem wartbaren Code.

Durch die Aufteilung eines komplexen Systems in unabhängige Module (z.B. bei Domain-Driven-Design) wird die Architektur klar strukturiert und getrennt, was die Flexibilität und Erweiterbarkeit erheblich verbessert. Modularisierung ermöglicht es, Änderungen in einem Teil des Systems vorzunehmen, ohne den gesamten Code zu berühren. Dies trägt zur Fehlerreduzierung bei und erleichtert es, neue Funktionen hinzuzufügen oder bestehende zu optimieren, ohne das gesamte System zu gefährden. Darüber hinaus fördert die Modularisierung die Zusammenarbeit in großen Entwicklerteams, da diese unabhängig voneinander an verschiedenen Teilen der Applikation arbeiten können.

#### Fazit

Um das volle Potenzial eines Entwicklungsteams auszuschöpfen benötigt es angefangen vom Produktmanagement bis hin zur Softwarearchitektur genügend Struktur, solide Planung, klare Rollenverteilung und gezielte Kommunikation. Auch wenn ein funktionierender Prozess gefunden wurde und die Produktivität stimmt, darf man sich nicht darauf ausruhen und muss sich laufend an die sich verändernden Situationen anpassen.

Ganz nach unserem Motto “Good people, good projects” kann natürlich der Entwicklungsprozess noch so feinjustiert sein, es braucht am Ende immer das richtige Team um den Projekterfolg sicherzustellen.


Erfolgsfaktoren für einen effizienten Entwicklungsprozess


#### Jakob’s Law

###### “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Benutzer sind an bestimmte Designelemente und Interaktionen gewöhnt, die sie beim Verwenden verschiedener Websites und Anwendungen erleben. Durch die Verwendung vertrauter Design Patterns können Sie eine intuitivere und benutzerfreundlichere Erfahrung für Ihre Zielgruppe schaffen.

![Youtube Redesign 2017: Etablierte Navigation bleibt](/images/blog/laws-of-software-development/jakobs-law-youtube.jpg)

#### Hofstadter’s Law

###### “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

"Wie lange wird es dauern?“ ist eine der gefürchtetsten Fragen in der Softwareentwicklung. Hofstadters Gesetz beschreibt die Tendenz, dass Projekte und Aufgaben häufig mehr Zeit in Anspruch nehmen als ursprünglich angenommen. Sogar wenn bereits Verzögerungen und Puffer für Unvorhersehbarkeiten eingeplant wurden.

In Software-Projekte gibt es zahlreiche Gründe für Verzögerungen: Unseriöse Angebote und Aufwandschätzungen, falsche Annahmen, unklare Spezifikationen, Fokus auf unwesentliche Dinge, Legay Code, permanente Change-Requests, Angst Entscheidungen zu treffen, etc.

#### The 90-90 Rule

###### “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Die 90-90-Regel spiegelt (etwas überspitzt) wider, dass Softwareprojekte oft länger dauern als erwartet. Die ursprünglich geplante Entwicklungsdauer wird aus diversen Gründen (siehe Hofstadter’s Law) überschritten. Auch wenn man zu Beginn große Schritte macht und die Entwicklung wie geplant voranschreitet, kann es – je näher der Go-Live Termin kommt – zu Verzögerungen kommen.

#### Brooks’s law

###### “Adding manpower to a late project makes it later.”

Das Gesetz stammt aus Fred Brooks' Buch "The Mythical Man Month" von 1975. Es befasst sich mit der Annahme, dass Teammitglieder und benötigte Monate austauschbar sind. Dies ist jedoch insbesondere in der Softwareentwicklung nicht zwingend der Fall. Warum? Aufgrund der Zeit, die benötigt wird, um Personen über den aktuellen Stand des Projekts auf dem Laufenden zu halten und sie in den Prozess zu integrieren. Zudem gibt es nicht immer die Aufgaben, die in kleinere Subtasks aufgeteilt werden können und gleichzeitig abgearbeitet werden.

![“You cannot have a baby in one month by getting nine women pregnant.”](/images/blog/laws-of-software-development/brooks-law.png)

#### Murphy's Law

###### “If there is a wrong way to do something, then someone will do it.”

Dies ist das bekannteste und universellste Gesetz auf dieser Liste. Murphys Gesetz ist in allen Bereichen des Projektmanagements, der Softwareentwicklung und des Lebens im Allgemeinen sichtbar.

#### Pareto Principle

###### "80% of the effects come from 20% of the causes."

Ein Klassiker! Das Paretoprinzip kann auf viele Bereiche der Arbeit und des Lebens angewandt werden. In der Softwareentwicklung können bedeutende Verbesserungen erzielt werden, indem man den Fokus auf die Funktionen legt, die dem User einen Mehrwert liefern. Zu früh und zu oft verliert man sich im Detail.

Sollte das Paretoprinzip immer berücksichtigt werden. Nein! Es gibt Fälle, in denen es von Vorteil ist, wenn man frühzeitig alle Eventualität berücksichtigt.

#### Dunning–Kruger Effect

###### "Low performers often struggle to recognize the skills and competence of others, leading them to consistently view themselves as better, more capable, and more knowledgeable than others."

Der Dunning-Kruger-Effekt besagt, dass Menschen mit geringen Fähigkeiten oft ihre eigenen Fähigkeiten überschätzen und die Tiefe des benötigten Fachwissens nicht erkennen. Weniger kompetente Personen halten sich oft für sehr kompetent, während kompetentere Personen ihre Fähigkeiten realistischer einschätzen können. In der Softwareentwicklung trifft man häufig auf dieses Phänomen.

![Zu Beginn ist die Lernkurve steil...](/images/blog/laws-of-software-development/dunning-kruger-effect.png)

#### Segal’s Law

###### “A man with a watch knows what time it is. A man with two watches is never sure.”

Hier geht es um die Daten und die Datenqualität – genauer gesagt das Konzept „Single source of truth“ (SSOT). Ein Unternehmen sammelt alle Daten an einem Ort. Dieser allgemeingültige Datenbestand liefert korrekte und verlässliche Daten.

Mehrere Datenquellen ohne SSOT können u.a. zu Verwirrung und Inkonsistenzen führen.

#### DRY (Don't Repeat Yourself)

###### "Every piece of knowledge must have a single, unambiguous representation within a system."

Das DRY-Prinzip besagt, dass in einem Softwareprojekt dieselbe Information oder Logik nicht an mehreren Stellen dupliziert werden sollte. Stattdessen sollte sie an einer einzigen Stelle verwaltet werden. Dies fördert die Wartbarkeit, reduziert das Risiko von Fehlern und vereinfacht Änderungen, da Aktualisierungen nur an einer Stelle vorgenommen werden müssen.

#### Gall’s law

###### “A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”

Wenn man ein neues System entwickelt, sollte man schrittweise vorgehen. Galls Gesetz liefert einen guten Grund, die Entwicklung von Softwareprodukten in unterschiedliche Etappen zu unterteilen. In der Praxis setzt man dabei auf Werkzeuge wie Prototyping, PoCs und MVPs. Wenn alles funktioniert, kann man schrittweise weiterentwickeln und neue Funktionen hinzufügen.

![Step-by-Step zum Ziel mit Prototyping und MVPS](/images/blog/laws-of-software-development/galls-law.png)

#### KISS (Keep it Simple, Stupid)

###### "Simplicity is the ultimate sophistication."

Dieses Prinzip rät dazu, Software so einfach wie möglich zu halten, um unnötige Komplexität zu vermeiden. Einfache Lösungen sind oft leichter zu verstehen, zu warten und zu debuggen. Klingt simple oder?

#### Eagleson’s law

###### “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Mit sechs Monaten zählt Eagleson zu den Optimisten. Wie dem auch sei. Sein Gesetz unterstreicht die Notwendigkeit von Clean-Code, Standards und Kommentaren. Nach einer Weile kann selbst der ursprüngliche Programmierer seinen Code nicht mehr entwirren. Ich spreche da aus eigener Erfahrung…

#### Lubarsky’s law

###### “There’s always one more bug.”

Trotzt aller Bemühung und einhalten von Best-Practice-Ansätzen: Man wird immer noch einen Bug oder eine vermeintliche Optimierung finden. Die Arbeit ist nie abgeschlossen. Was lehrt uns das Gesetz: Nimm dich in Acht vor Perfektionismus! Es kann Zeit, Geld und Nerven kosten.

#### Knuth’s Optimization Principle

###### “Premature optimization is the root of all evil.”

Meiner Meinung nach trifft das nicht immer zu. Beispiel: Wenn wir wissen, dass ein bestimmter Teil eines Systems entscheidend für die Leistung ist und es einen besseren Ansatz als die aktuelle Implementierung gibt, sollte man zumindest über die Alternative diskutieren.

So oder so, in etwa 90 % der Fälle trifft dieses Prinzip zu: Wenn wir zu früh und zu stark optimieren, besteht die Gefahr, dass man das große Ganze aus den Augen verliert und wertvolle Zeit verschwendet.

#### YAGNI (You Aren't Gonna Need It)

###### "Always implement things when you actually need them, never when you just foresee that you need them."

“Nur für den Fall, dass wir sie brauchen” oder “irgendwann wird uns das Helfen”. Stop! YAGNI rät davon ab, Funktionalität oder Features vorzeitig hinzuzufügen. Stattdessen sollte man sich auf die aktuellen Prioritäten fokussieren.

#### Sayre’s Law

###### “In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

Intensive Diskussionen sind wichtig. Manchmal wird zu viel Zeit für Nebenschauplätze verschwendet. Wenn man stundenlang über Dinge debattiert, die keinen Mehrwert bringen, ist das Zeitverschwendung. Daher gilt die Faustregel: Die Diskussionszeit sollte proportional zur Wichtigkeit des Problems sein.

![Fokus auf die wichtigen Themen](/images/blog/laws-of-software-development/sayres-law.png)

#### Parkinson’s Law of Triviality

###### "The time spent on any agenda item will be in inverse proportion to the sum involved."

Ähnlicher Ansatz wie Sayre’s Law. Das Gesetz besagt, dass Menschen tendenziell mehr Zeit und Energie für unwichtige Angelegenheiten verschwenden. In der Softwareentwicklung kann es zu ausgeschweiften Diskussionen über Details wie Formatierungen kommen, während bei tiefgreifende Architektur- oder Designentscheidungen wenig Input geliefert wird.

![Das berühmte Beispiel von Parkinson: Bikesheeding](/images/blog/laws-of-software-development/parkinsons-law.png)

#### Fazit

Wenn einem diese Gesetze und Prinzipien geläufig sind, wird man in der Praxis immer wieder auf sie stoßen. Sie bieten nicht nur Einsichten, sondern auch bewährte Leitfäden für erfolgreiche Projekte. Ob Reduktion der Komplexität, kluge Entscheidungen oder Fokussierung auf das Wesentliche – diese Regeln können als Anhaltspunkte dienen.

Trotz ihrer scheinbaren Strenge sollten wir im Hinterkopf behalten, dass ihre Anwendung oft flexibel ist. Ob und wie sehr man sich an diese Regeln hält, hängt von der jeweiligen Situation ab.

Fakt ist, diese Prinzipien sind ausgezeichnete Orientierungshilfen. Nutzen wir die Weisheiten, für unsere Softwareprojekte und heben diese auf das nächste Level – Code für Code.


Von Murphy bis Knuth: Die Gebote der Softwareentwicklung


Visual Studio Code ist schon lange eine der führenden IDEs für Webentwickler. Das liegt zweiffellos daran, dass VSCode
schlank und mit einer Vielzahl von Extensions erweitert werden kann. In diesem Post werde ich meine bevorzugten Add-ons vorstellen,
die ich täglich als Angular Entwickler im Einsatz habe.

### [Angular Language Server](https://marketplace.visualstudio.com/items?itemName=Angular.ng-template)

![](/gifs/blog/vscode-extensions/angular-language-server.gif 'Angular Language Server')

Ein absolutes MUSS in der Angular-Entwicklung. Dieses Tool hilft beim Erstellen von Angular Templates mit Autocomplete.
Ohne diese Erweiterung ist es fast unmöglich, fehlerfreie Angular Templates zu schreiben.

### [Angular Schematics](https://marketplace.visualstudio.com/items?itemName=cyrilletuzi.angular-schematics)

![](/gifs/blog/vscode-extensions/angular-schematics.gif 'Angular Schematics')

Das Angular Schematics Plugin erleichtert dir den Aufbau deiner Components. Mit einem Rechtsklick auf den
gewünschten Ordner kann ganz leicht eine neue Komponente hinzugefügt werden. Weitere Eingaben im folgenden Wizard
konfigurieren die neue Komponente, so wird das Erstellen von
[Smart und Dumb Components](https://fortix.io/blog/angular-smart-and-dumb-components) ein Kinderspiel!

### [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner)

![](/gifs/blog/vscode-extensions/vscode-jest.gif 'Jest Runner')

Mit dieser Extension erspart ihr euch eine Menge Zeit beim Schreiben von neuen Unit Tests.
Im Vergleich zu der bekannteren [vscode-jest](https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest)
Erweiterung, kann Jest Runner einen einzelnen spezifischen Test ausführen. Dazu wird einfach über jedem
Test auf "Run" geklickt, und schon wird der Test im Terminal ausgeführt.

### [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)

![](/images/blog/vscode-extensions/nx-console-ui-light.png 'Nx Console')

Nx Monorepos kommen bei FORTIX Projekten oft zum Einsatz. In großen Angular Apps wird dazu auch NgRx verwendet. Mit Nx Console
können ganz leicht Libraries, Components, Services uvm. über eine UI generiert werden. Grundsätzlich ist es möglich, jedes Nx CLI Command
mit dieser Console auszuführen. Sobald ihr dieses Tool installiert habt, müsst ihr nie wieder nach einem Nx Command suchen.

### [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)

![](/images/blog/vscode-extensions/prettier.png 'Prettier - Code formatter')

Der wahrscheinlich meistgenutzte Formatter in VSCode. Prettier arbeitet mit einem eigenen [Configuration File](https://prettier.io/docs/en/configuration.html)
mit dem die wichtigsten Formatierungsoptionen festgelegt werden können.

### [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)

![](/images/blog/vscode-extensions/eslint.png 'ESLint')

[ESLint](https://eslint.org/) ist ein Tool für statische Codeanalyse. Mit ESLint können mögliche Probleme und Bugs
noch während der Entwicklung gefunden und behandelt werden. Eigene Regeln und individuelle Konfigurationen für den Code sind ebenfalls möglich.

### [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss)

![](/images/blog/vscode-extensions/tailwind.png 'Tailwind CSS')

Tailwind ist ein CSS Framework welches gerade einen regelrechten Hype erfährt.
Hunderte vordefinierte CSS Klassen werden durch diese Extension leicht auffindbar. Das Arbeiten mit Tailwind wurde für mich durch diese Hilfe erleichtert.

### [Color Highlight](https://marketplace.visualstudio.com/items?itemName=naumovs.color-highlight)

![](/images/blog/vscode-extensions/color-highlight.png 'Color Highlight')

Eine sehr simple Erweiterung die aber einen großen Nutzen hat. Es werden alle CSS/Web Farben im Code farblich hinterlegt.
Zum Beispiel wird dann <span style={{backgroundColor: "#6699cc"}}>#6699cc</span> blau eingefärbt.

Ich hoffe, dass all diese Erweiterungen es euch ermöglichen Zeit zu sparen und produktiver mit Angular zu arbeiten. Wenn
ihr noch weitere VSCode-Erweiterungen kennt die ihr täglich benützt, zögert nicht und meldet euch bei uns über Social Media oder schreibt mir eine [Mail](mailto:adrian.natter@fortix.io).


Die wichtigsten VSCode Extensions für Angular Developers


Flutter-Programme bestehen aus vielen verschiedenen Widgets. Ein Widget bündelt die Logik, Interaktion und die Darstellung eines Objekts. Flutter bringt eine Reihe von vordefinierten Widgets mit. Dadurch kann schnell ein MVP entwickelt und veröffentlicht werden.

Ein weiteres Feature, das die Entwicklungszeit stark verringert, ist Flutter’s Hot Reload . Mithilfe des Hot Reloads lassen sich Änderungen im UI oder in der Business Logik in Sekundenschnelle auf das Smartphone übertragen. Dabei wird der neue Sourcecode in eine virtuelle Dart Umgebung geladen, die auf dem Gerät läuft. Das Entwickeln und Testing wird dadurch stark vereinfacht.

![Flutter logo](/images/flutter.png 'Flutter Logo')

Der Dart Code wird je nach Plattform unterschiedlich kompiliert. Auf Mobilen, Desktop und Servergeräten wird der Code nativ in Maschinencode übersetzt. Dies lässt die Applikation performant mit mindestens 60 Hz pro Sekunde auf dem Gerät laufen. Wenn die Anwendung für das Web veröffentlicht wird, wird der Code mit dem Dart-to-JavaScript Compiler ([dart2js](https://dart.dev/tools/dart2js)) kompiliert. Die Anwendung kann dann ganz einfach im Browser ausgeführt werden.

Mit Flutter ist es also möglich mit einer einzigen Codebasis für mehrere Betriebssysteme bzw. Plattformen zu entwickeln. Derzeit wird Web, Android, iOS, Windows, Linux, macOS und das neue Betriebssystem von Google – [Fuchsia OS](https://de.wikipedia.org/wiki/Google_Fuchsia) unterstützt. Das Framework ist schon bei vielen großen Softwareprojekten im Einsatz, unter anderem wird Flutter bei Google Ads eingesetzt. Es bleibt spannend wie sich das Framework weiterentwickelt. Zurzeit ist Flutter das einzige Framework, das so eine große Anzahl von Plattformen nativ unterstützt.

Google und die stetig wachsende Community entwickeln Flutter rasant weiter. Wir bei FORTIX setzen speziell bei der Entwicklung von Mobile Apps auf Flutter. Durch die sogenannte Single-Codebase ist es möglich, eine App zu entwickeln, die sowohl auf Android als auch auf iOS nativ dargestellt wird. Man erspart sich daher viel Aufwand in der Entwicklung und Wartung einer App, was wiederum in geringeren Projektkosten resultiert. Auch deshalb ist Flutter nicht nur für die Entwickler eine sehr spannende Option, sondern auch für diejenigen, die mit dem Gedanken spielen, eine App entwickeln zu lassen.

Bei Fragen bezüglich App-Entwicklung, Flutter und alternativen Technologien stehen wir gerne zur Verfügung!


Allgemein

Sieger KMU-Preis Vorarlberg 2024

Ein großes Dankeschön

Der KMU-Preis Vorarlberg

Weitere Links:

Share this post

Weitere Blogs

Eine Auswahl unserer letzten Blogs

Konsistenz und Effizienz: So verbesserst du den Design- und Entwicklungsprozess

NgRx Signal Store – worth the hype?

Erfolgsfaktoren für einen effizienten Entwicklungsprozess

Von Murphy bis Knuth: Die Gebote der Softwareentwicklung

Die wichtigsten VSCode Extensions für Angular Developers

Flutter – Das Werkzeug für native Apps in Rekordzeit