Workflow automation has a history going back to 1990. For nearly 15 years however most projects failed.
This started to change after BPEL was invented.
The final breakthrough came with BPMN — a graphical notation for specifying workflows which can then be implemented automatically on top of BPEL (or now also any other mechanism — the need to insist on BPEL is gone as long as you use products that are able to import BPMN compatible process specifications created with the help of a wide range of competing products).
But be warned: This is not to say that it has become easy to successfully implement process automation. If you are about to start a corresponding project, it might help first to read The Promise of Workflow Automation: Points of Failure, and how to Realize the Promise (2012).
Quite a good yardstick for what typical tools in 2012 can do for you is certainly BizAgi’s BPM Suite.
Everything software developers and test managers should know about how to monitor test coverage quite effectively — and which metrics not to use — is explained in a two pages document What you need to know about old and new Metrics for Test Coverage Assessment.
There is also a very illuminating example.
Most people — Agile evangelists are no exception — tend to define Agility via a specific way of working (e.g. via SCRUM) or via the Agile Manifesto (which is a set of too easily – and by far too often – misunderstood principles totally ignoring the CIO as one of the most important stakeholders).
But to really understand what it means to become agile as a software developer (or a developer’s client) in some positive manner
- we have to understand Agility as a Necessity to survive in today’s fast changing environment,
- we have to adopt the right Agile Attitude,
- and we have to accept Agile as a Best Practice.
If you don’t believe me, there are others who also say:
- We are tired about reading misinformation about Agile,
- Agile is certainly not SCRUM (or some other specific process), and
- Agile is often used for an excuse not to work professionally enough.
Als jemand der 30 Jahre Erfahrung mit Entwicklung und Test von Software hat, habe ich — für Berufsanfänger (aber auch für Hochschullehrer und für Manager mit wenig praktischer Erfahrung) — in Form von etwa 25 sehr kurzen Aufsätzen zusammengetragen, was ich unter
Best Practice Software Engineering
verstehe.
Einstiegsseite in dieses kleine Handbuch ist Software Engineering: Fakten, Best Practices (und allzu Naives).
Wer mir widersprechen möchte ist eingeladen, hier entsprechende Kommentare zu hinterlassen.
ggreiter 