Author Archives: Zampano

Essential Agile

When you observe the history of “Agile”, hear of the experiences from others documented in countless blog posts, study all the literature and wisdom about it, practise it on your own in different teams, setups and environments, perform a root cause analysis on impediments and problems you’ve encountered when applying agile methods, do an inverse impact mapping and when you discuss it with people who have gone through it all too – then it comes down that two principal things define its success or failure:

  1. Fast feedback on activities

  2. Ability to react on change

That’s all what you should really care about.
And I mean care really, really hard about.
In fact so hard that you never should compromise any of these two.

Everything else is less important, interchangeable, subject to personal or corporate taste – or simply waste.

Continuous Delivery – We Always Did It

Introducing Continuos Delivery (CD) to software teams often leaves them either sceptic or at least with many question marks in their heads.
It may be surprising for some that we all knew and used it already for a long time. Somehow.

Read More →

Scrum or Agile? No, the Product!

Scrum? Agil? Egal

Erstaunlich, wie unklar das Verständnis und die Definitionen von Scrum und agiler Methoden noch sind. Scrum ist für viele (die meisten?) ein Synonym für agiles Vorgehen und agile Methoden. Daher werden die Begriffe Scrum und Agil immer wieder in einen Topf geworfen. Und ebenso Projekt- und Produktmanagement, was aber ein noch viel gewichtigerer Unterschied ist.

Read More →

Teile und Herrsche! – CQRS, Pt. 2

CQRS must be SOLID

Es sei angemerkt, dass man mit den Vorteilen der SOLID Prinzipien [1] vertraut sein sollte, um den ganzen Sinn von CQRS zu verstehen. Es entstanden im letzten Artikel viele Diskussionen über grundsätzliche Aspekte wie SRP oder OCL, weil diese Prinzipien nicht angewandt oder verstanden werden. Ebenso sollte man schon mal etwas über den Sinn von Layering und Modularität von Software gehört haben.

Teile und Herrsche! – CQRS, Pt. 1

Im Leben eines Entwicklers gibt es immer wieder „Aha“- oder sog. „Breakthrough“-Momente, in denen man entweder etwas entdeckt, dass die eigenen Fähigkeiten beträchtlich erweitert oder lange bestehende Probleme löst.

Hier geht es um ein solches, (noch) kaum bekanntes und bisher selten angewendetes Prinzip für das Design von objektorientierter Software.  Meines Erachtens ist es sehr einfach  zu verstehen und auch sehr einfach anwendbar. Aber noch größer sind die Vorteile die es bietet.

Read More →

Agile Kultur

 

Alle reden von agilen Prozessen, agilem Projektmanagement und agiler Softwareentwicklung.
Es existieren massenhaft Einführungen, Bücher, Blogeinträge und die Prozesse und Tools
sind auch hinreichend bekannt.

Doch Informationen zum wichtigsten “Detail” finden sich fast kaum, obwohl es die Grundlage ist, mit der agile Prozesse überhaupt erst möglich sind: der Mensch!
Maschinen brauchen keine Agilität, es ist für Menschen die miteinander arbeiten und kommunizieren da.

Read More →

No Model No Cry

Das Zend Framework hat es richtig gemacht: ein MVC-Framework, das kein M(odel) zur Verfügung stellt.

Wie kann ein MVC-Framework ohne ein M(odel) vollständig sein?

Read More →

Was ist DDD nun eigentlich?

Jemandem DDD (Domain-driven Design) zu erklären, scheint nicht immer ganz einfach zu sein. Entweder ist es zu technologielastig oder aber zu abstrakt, je nachdem mit welcher Zielgruppe man es zu tun hat.

Ist DDD …
–          ein Pattern?
–          eine Philosophie?
–          eine Architektur?
–          ein Entwicklungsansatz?
–          ein Prinzip?
–          eine Modeerscheinung?
–          Nichts (oder alles) davon.

Read More →

Context Is King

Abgesehen von der trivialsten Software bewegen sich die meisten Anwendungen in einem mehr oder weniger komplexen Problemumfeld (Domäne). Bevor man nicht weiß, welche Bereiche mit welchen Verantwortlichkeiten existieren, in welchen Umgebungen man sich bewegt und welches Problem sie eigentlich lösen sollen, macht es keinen Sinn über Architekturen, Datenformate, Datenstrukturen, Frameworks oder Lösungsansätze nachzudenken.

Read More →