Categorie Archief Artikelen

Search query Enterprise Architect for searching element by Id

One of the hidden features of the EAValidator is copying the EA Id into the clipboard. When you double-click on a validationerror in Id of the element is copied into to clipboard.

In Enterprise Architect you can easily search for the element by creating a new search (only once) with the following query:

SELECT
ea_guid AS CLASSGUID, Object_Type AS CLASSTYPE,Name AS Object, Object_Type AS [Type], Stereotype, CreatedDate, ModifiedDate
FROM
t_object
WHERE
ea_guid = '<Search Term>'

Search Find by Id

What every Product Owner should know

When I’m participating in an agile team or when I’m doing some agile coaching stuff I often have conversations with the product owner about roles, activities and expectations of his/her job? And during this conversation I advice to read the ‘Product Owner Manual’ from ScrumSense. I don’t think every product owner can or will agree to this manual but it is the first home work I’ll advice.

Product-Owners-Manual

More info: http://www.scrumsense.com/resources/product-owner-manual/

How to split a user story (or slice or use case story or ..)

I found a nice flowchart for splitting a user story. Naturally the same flowchart is applicable for slices or use case stories if you are using Use Case 2.0 techniques.

For more info: http://www.agileforall.com/splitting-user-stories/

 

Mijn stijl van activity diagrams

Al vaak heb ik UML trainingen mogen geven. Waaronder ook de training Pragmatisch Modelleren op basis van het boek van Sander Hoogendoorn. Vele activity diagrams in verschillende kleuren, smaken en varianten heb ik langs zien komen . Van hele duidelijke diagrammen tot aan super ingewikkelde (maar wel helemaal volgens de UML regels)  diagrammen.

Ik vind het belangrijk dat men dezelfde soort diagrammen maakt. Het belangrijkste doel van zo’n diagram is namelijk de communicatie tussen de verschillende betrokkenen en een eenvoudig en eenduidig diagram helpt daar heel erg mee. De officiele UML regels staan toe om veel verschillende stijlen van modelleren toe te passen. De term ‘stijl’ gebruik ik vaak. Het geeft aan dat het niet goed of fout is om op andere manieren te modelleren. Toch vind ik het belangrijk dat de betrokkene zoveel mogelijk dezelfde stijl gebruiken. Dat verhoogd de leesbaarheid en eenduidigheid en maakt de communicatie dus makkelijker. Een leuke bijkomstigheid is dat hierdoor wellicht automatisch validaties van modellen eenvoudig wordt.

Een stijl is net zoals de stijl van kleding. Sommige stijlen passen je en sommige stijlen passen je niet. Het is waar je van houd. Voor het maken van activity diagrams gebruik ik zelf de onderstaande richtlijnen. Een deel van de richtlijnen is afkomstig van het boek Pragmatisch Modelleren met UML 2.0. Alle richtlijnen gebruik ik zelf in de praktijk.

Mijn richtlijnen

 

1. In een activity diagram gebruiken we alleen de volgende symbolen. We gebruiken géén andere symbolen.

  • Activity node – Een activity is de eenheid om het gedrag (stap) in een aktiviteiten diagram te modelleren.
  • Initial node – De flow start in een Initial node.
  • Final node – De flow eindigt in 1 of meerdere Final nodes
  • Decision node – Een decision node markeert een beslismoment. Er vindt dan een splitsing splitsing plaats in meerdere stromen.
  • Merge node – In een merge node komen verschillende stromen samen.
  • Loop node – Een loopnode modelleert een herhaald uitvoeren van een aantal activity nodes.
  • Fork/Join node – Fork en Join nodes worden gebruikt als eenheid om gelijktijdige (parallele) uitvoering van activity nodes te modelleren.
  • Control flow – Het modelleren van gedrag wordt gemodelleerd dmv de control flow tussen de verschillende nodes.

2. Plaats één enkele initial node in het activity diagram.

3. Modelleer een activity voor iedere stap in het stappenplan.

4. Modelleer één enkele transitie vanaf de initial node naar de eerste activity node.

5. Modelleer het gewenste scenario recht van boven naar beneden. Als je het gewenste scenario recht van boven naar beneden modelleert is het diagram makkelijker en sneller te begrijpen. Het gewenste doel zal dan altijd onderaan staan.

6. Geef ieder beslismoment in het activity diagram weer als een decision node. Geef de decision node geen naam.

7. Noteer guards bij de transities vanuit een decision node. Deze guards zijn volledig en sluiten elkaar uit.

8. Breng beslismomenten in het stappenplan die na elkaar dezelfde conditie testen samen in één enkele decision node in het activity diagram.

9. Maak gebruik van merge nodes. Laat dus nooit meerdere transities naar dezelfde activity lopen

10. Modelleer een herhaling in een stappenplan als een loop node in het activity diagram.

11. Sluit iedere herhaling aan op een merge node.

12. Doorbreek iedere herhaling met minimaal één decision node.

13. Formuleer een guard als een stelling met een onderwerp, werkwoord en zelfstandig naamwoord die met ja of nee beantwoord kan worden.

14. Geef een activity die een (sub function level) use case uitvoert de naam van deze use case. Voorzie de activity van het stereotype <<use case>>. Als je in de flow een ‘uitstap’ maakt naar een andere use case dan geeft ik de activity het stereotype <<use case>>. Als je ook nog automatisch de kleur kunt wijzigen in de modelleer tool dan kun is het direct zichtbaar.

15. Modeleer niet de annuleer flow. Het komt vaak voor dat bij een scherm een annuleer knop heeft. Als je wilt modelleren dat je op elke gewenst moment kunt annuleren kun je een spaghetti krijgen van lijnen. Ik modelleer deze flow nooit als je op elk moment in de flow kunt annuleren én dat er geen extra acties nog plaatsvinden na het drukken op de annuleer knop. Wel modelleer ik vaak een losse notitie om deze flow niet te vergeten.

Nieuw EAValidator

 

validation-protocol-execution-tipsMaak jij weleens fouten bij het modelleren in Enterprise Architect? Ben je weleens vergeten om elementen uit je projectbrowser te verwijderen als je het element hebt verwijderd van je diagram? Ben je ooit eens vergeten om een omschrijving vast te leggen bij je use case?

Ik wel! En ik merkte dat, met al de ‘vergeten’ dingen, het Enterprise Architect model steeds minder betrouwbaar werd als single-source-of-truth. Geïnspireerd door de code analyse mechanisme van Microsoft Visual Studio. Heb ik de tool EAValidator ontwikkeld. EAValidator valideert uw model tegen uw eigen validatieregels en informeert u onmiddellijk over fouten in uw model. De EAValidator zal niet voorkomen dat u fouten maakt. De visie van bij de EAValidator is om niet te beperken maar wel snel te signaleren! Je zult dus heel snel je fouten zien zodat je deze ook snel kunt herstellen.

De EAValidator is in ontwikkeling. Voor het laatste nieuws ga naar http://www.fflowing.nl/model-validation-for-enterprise-architect/

 

Visualize progress with charts

A burn-down (or burn-up, or cumulative flow) chart is a graphical representation of outstanding work versus time. The outstanding work is often on the vertical axis, with time along the horizontal. The chart is used in agile software development methodologies like Scrum. With this very simple chart, and in my opinion the only one you need for the team, it is so easy to:

  • predict when all of the work will be completed;
  • see if we are on track;
  • use for early steering;
  • not be surprised at the end of the sprint;
  • stop answering questions about progress;
  • learn for better estimating;
  • start focusing on burning (a.k.a. delivering);
  • create energy in the team.

I also noticed that is very easy to misuse the charts so not the real progress is shown. With that discussion I could fill several other articles. In this article I’ll explain different types of charts with the benefits and concerns of that type, also in this article I will not discuss why measuring progress of work instead of measuring progress of added value.

For now I see three types of charts:

  • Burn-down charts displays the amount of outstanding work;
  • Burn-up chart displays the amount of work done;
  • Cumulative flow chart displays the amount outstanding work and work done (and more).

How to measure outstanding work?

The vertical axis displays often the amount of outstanding work or the work still to do. This can be the

  • time remaining;
  • number of stories still remaining;
  • number of tasks still remaining;
  • amount of user points still remaining.

 

Chart with the time remaining

image

This chart shows every day the time remaining of all work in the sprint. For a correct chart the teams needs to update the remaining time for all items and also continuously re estimate the remaining time. When you only calculate the initially estimated hours minus the hours spent minus the chart will not be accurate. It is possible the chart sais 0 hours remaining and the work is still not done!

Benefits

  • If used with the correct estimated time remaining this chart is the most precise chart. Project managers loves these type of charts
  • A lot of project management tools are supporting this type of chart

Concerns

  • How many stories are finished? You can’t answer this important question from the chart. It looks not that bad – but it could be that no story at all will be finished at the end of the sprint.
  • To draw the chart line daily – you need to re estimate all the work remaining each day. This counting is time consuming and I never met developers who like doing things with hours…
  • When the chart say zero hours left it is still possible no story is finished…
  • Counting hours spent is different form re estimating hours every day.
  • Updating this chart is difficult and so it’s almost impossible to embed it in your the daily standup.

 

Chart with the number of stories remaining

image

This chart shows every day the number of remaining stories. The chart only drops when the story is done.

Benefits

  • To draw the chart daily it’s very easy by counting the stories not done.
  • The charts show the progress of the items the team committed to.
  • It stimulates the team to completely finish the stories.
  • It stimulates the team to finish the story one by one and to eliminate too much work in progress.
  • It is easy to embed it in your daily standup.

Concerns

  • Differences in sizes of the stories is not shown.
  • Law of large numbers doesn’t apply with small number of stories.
  • When all stories are finished at the end of the sprint the chart doesn’t show progress during the sprint.
  • It stimulates the team to complete the small stories first and ignore the priorities.

Chart with number of tasks remaining

Instead of counting stories it is possible to count the remaining tasks.

Benefits

  • To draw the chart daily it’s very easy to count the tasks not done.
  • Chart is displaying growing and shrinking of amount of work.
  • Law of large numbers applies.
  • You can embed it in your daily standup.

Concerns

  • Tasks needs to be the same size (sort of) for a useful chart. (It’s common to split the tasks to same sizes approx half day work).

Chart with amount of story points remaining

image

In my opinion is the chart which is showing the story points remaining my favorite burndown chart. This chart shows the amount of story points remaining for each day.

Benefits

  • To draw the chart daily it’s very easy to count the points not done
  • The charts show the progress of the items the team committed to.
  • Difference in size of the stories is shown.
  • It stimulates the team to completely finish the stories
  • It stimulates the team to finish the story one by one and to eliminate too much work in progress.
  • You can embed it in your daily standup.

Concerns

  • When stories are finished at the end of the sprint the chart doesn’t visualize progress. It’s difficult to see you are on track or predict completion date. With focusing on finishing stories one by one this problem