2016/07/12

JIRA Workflows from the Trenches @ NTT DATA EMEA Blog

Just published: JIRA Workflows from the Trenches @ NTT DATA EMEA Blog.

Abstract:
Atlassian’s JIRA (https://de.atlassian.com/software/jira) as a project management tool is actually an industry standard for the software projects. However the initial configuration of many aspect of JIRA leaves areas for improvements. This post focuses on the JIRA workflows, which define states for the issues, such as user stories and bug, and the transformations between them (also known as workflow or state machine).

All that based on my experience as a chief of development with real examples from my current project: quasi directly from the trenches.

Workflows from the Trenches

2016/03/28

Are You a Programmer? Think Twice Before You Say "It Is Just a Trivial 'Hello World'" example!

It is Monday in Germany, and it is Easter Monday 2016.

I had finally chance to take my "pimped" Commodore Amiga 500 out of the shelf (yes "she" is pimped, with 2 MB RAM, with a Workbench-switch between versions 2.0 and 3.1, with a Gotek floppy emulator, and so on). And I had played with it. Hm, you know me, no games, just coding, just assembler, just pure system.

The ASM-One assembler together with a "very" old book "Amiga Assembler Buch" by Peter Wollschlaeger did their job perfectly. I wrote a "Hello World" for the Motorola 68000 and Amiga DOS. I was able to assemble it, to link it and to run it. And here is the result:

Running "Hello Word" written in assembler on Amiga 500
Bildunterschrift hinzuf├╝gen

Wow, what a result! It is tremendous!
I can see the "Hello World" printed on the command line of Amiga's Workbench! Ok, just kidding...

But wait a minute and just look at the code, the pure Motorola 68000 assembler code:

* Hello World using 68000 assembler
* based on example from Peter Wollschlaeger book 1987

SysBase:  equ 4  ;base of exec
LVOOpenLib:  equ -552 ;open lib
LVOCloseLib: equ -414 ;close lib
LVOOutput:  equ -60  ;dos.lib get output-handle
LVOWrite: e qu -48  ;dos.lib write

* open dos.lib

main: move.l #dosname,a1 ;name of dos.lib
  moveq #0,d0  ;version is not relevant
  move.l SysBase,a6 ;set base address of exec
  jsr LVOOpenLib(a6) ;call open lib
  tst.l d0   ;any errors?
  beq finish   ;on error goto finish
  move.l d0,DOSBase ;save pointer to lib

* find output handler

  move.l  DOSBase,a6 ;set base address of dos.lib
  jsr LVOOutput(a6) ;call function
  move.l d0,d4  ;save output handler

* print text
  move.l d4,d1  ;set output handler
  move.l #string,d2 ;set address of text
  moveq #12,d3  ;set length of text
  move.l DOSBase,a6 ;set base address of dos.lib
  jsr LVOWrite(a6) ;call function

* close libs
  move.l DOSBase,a1 ;set lib to close
  move.l SysBase,a6 ;set base address of exec
  jsr LVOCloseLib(a6) ;close the lib

finish:  rts

* data

DOSBase: dc.l 0
  cnop 0,2

dosname: dc.b 'dos.library',0
  cnop 0,2

string:  dc.b 'Hello world',10,0
  cnop 0,2 

To print a "Hello World" on the Amiga 500 using assembler, you have to first find the address of the DOS library, open it, set parameters for the method, call it and and finally close it carefully at the end... It is not a just one or three lines of code you suppose to write...


So think twice before you say "it is just a trivial 'Hello World' example". Our modern machines do pretty much similar stuff as wirten above.

And think again about it when you decide to use a plenty of high sophisticated libraries to access a database, create services or integrate security. Think about what is going on under the hood. Think about this "Hello World" example. Think about complexity you introduce. Just think about it because this is reality.

---

2015/09/01

Agile Architecture from the Trenches at ACE Conference 2015


Agile Architecture from the Trenches from ACE! Conferences on Vimeo.

In my latest ten years, working as an IT consultant in the area of enterprise architecture, I got more and more questions about combination of the agile software engineering (not just only development) and the enterprise architecture which comprises business and software architecture. Especially for the big organizations it is a challenging topic due to their internal culture and structure that doesn't really suit to the values and principles of "being agile" as defined by the Agile Manifesto.

2015/07/04

Don't Think in Dialogs, Interactions and Features! Use Models Instead!

For some days I read an article in ObjectSpektrum by Ralf Westphal about his understanding of an agile architecture. As we know, there is no clear definition for that term, so the interpretation field is quite big, from design process up to continuous delivery. I was interesting what Ralf would like to say about agile architecture as I knew some of his interesting projects before (e.g. http://www.clean-code-developer.de/).

He rightly claims that there is a gap between requirements and, what he calls, logic (understood as implementation). Agile architecture should help to reduce this gap. This requirements are defined with the help of User-Stories, that mostly do not have direct mapping in the software structure. They have to be transformed into containers with logic, called modules. He reasons that these modules exist in various forms, from small functions, throw-out classes and libraries, up to services. This is however a quite technical view on a software system, so Ralf created another model that is defined as follows (with respect to the first one):
  • Software system
  • Applications of a software system (map to services)
  • Dialogs of an application (map to classes)
  • Interactions of a dialog (map to functions)
  • Features of a interaction (map to functions as well)
This second model is used to correlate User-Stories with its "module-oriented increments" which can be in turn, as described above, mapped into modules:

Pic. Correlation between User-Stories and module-oriented increments by Ralf Westphal

I have seen lot of systems built like this, and in my opinion it is not a proper way for designing a software system where an agile architecture is used in context of closing the gap between requirements and logic. 

2015/05/24

2015/04/17

Agile Culture Capability Model at JAX 2015 Conference in Germany



https://jax.de/2015/sessions/agile-culture-capability-model-can-we-all-be-agile-same-way

Offshore, nearshore, outsourcing? “No, I don’t want that, not once again” many IT managers would say… and not without a reason. Plenty of enterprises have already run classical, waterfall projects with the mix of onsite and nearshore or offshore teams. Unfortunately most of them have ended without success. Quite fast a question may arise whether the used methodology was an appropriate one.

2015/03/17

Agile Architecture From the Trenches Slides from ACE 2015

...are now available at Slideshare:



Abstract:

In my latest ten years, working as an IT consultant in the area of enterprise architecture, I got more and more questions about combination of the agile software engineering (not just only development) and the enterprise architecture which comprises business and software architecture. Especially for the big organizations it is a challenging topic due to their internal culture and structure that doesn't really suit to the values and principles of "being agile" as defined by the Agile Manifesto.

2015/03/11

Five Orders of Ignorance and Three Agile Architecture Views

Triggered by Geritts Beine's post and his article in the current Business Technology about black swans and the laws of software process I decided to review my concept of the Agile Architecture against Five Orders of Ignorance as defined by Phillip G. Armour in 2000.
I got a feeling that this concept better suits to the context as my previous one called RQC (risk driven, quality focused, and complexity is the enemy).

In summary Armour defines OIs as follows:
  • 0th Order of Ignorance (0OI)—Lack of Ignorance
  • 1st Order of Ignorance (1OI)—Lack of Knowledge
  • 2nd Order of Ignorance (2OI)—Lack of Awareness
  • 3rd Order of Ignorance (3OI)—Lack of Process
  • 4th Order Ignorance (4OI)—Meta Ignorance

And (what a great feeling) as a matter of fact I was finally able to reason about my Three Views on Agile Architecture as three complementary elements:
  • Design Process View
  • Construction Flavour View
  • System Behavior View


2015/02/26

2x Agile Architecture from the Trenches - Frankfurt/Germany, Krakow/Poland

It gives me great pleasure to announce with my talk about "Agile Architecture from the Trenches" at:
Do you think Agile Architecture is an oxymoron? Do you want to know what RQC abbreviation is an how it relates to the agile architecture? If so just join me at these events.


2015/02/07

Architectural Way of Catching Business Functionality Explained

An agile architecture should be designed in the way it aligns to the business requirements, thus focusing on the software parts that directly amplify business value and enhance adaptation capability (reaction to change).

These requirements have to be documented using semantic that is perfectly understood by all project teams and using syntax that can be afterwards effectively and efficiently used by the developers, who will develop the system. The trivial helper like user stories defined based on the predefined syntax (as a ... I'd like to have etc.) are good but far not enough to catch the core of the business requirements. They focus on the single activity of a system even if cohesive grouped together. To describe business functionality you need a "holistic" instrument. We need business models.