Blog

Als je met Stash/Git werkt kun je op twee manieren authenticeren:

  1. HTTP
  2. SSH

Het is normaal om voor de eerste connectie HTTP te gebruiken, het heeft echter twee beperkingen:

  1. De push wordt over HTTP vertaalt naar een POST en de POST-body-grootte is gelimiteerd, daarnaast kan er een HTTP-timeout optreden als een push teveel content bevat.
  2. Als je in Jenkins een connectie naar je Git repository wilt hebben moet je daar je eigen credentials achter laten.

Het is dus raadzaam om SSH te gebruiken zodat je geen last hebt van de HTTP-limiet en niet je eigen username/wachtwoord in Jenkins hoeft te stoppen.

Maak een RSA-key aan (twee delen: public en private key, dat doe je met ssh-keygen of PuTTYgen) en bewaar je private key in een .ssh map die je in je profiel-folder zet. Zorg dat je map en je private key alleen leesbaar zijn voor jouw user, dat doe je in linux, mac of git-bash:

SSH maakt gebruik van het public/private-key systeem waarbij je je private key zelf houdt - vandaar die permissies - en je public key registreert bij je persoonlijke profiel in Stash (zie de Stash documentatie en voor Windows gebruikers eventueel Installing Git on Windows of Configuring Git SSH on Windows).

Daarmee lossen we beperking 1 op maar dan moet je nog je eigen key-set aan Jenkins geven, gelukkig is dat niet nodig: Jenkins heeft een key waarmee automatische leestoegang is tot alle OOSE-repositories, je vindt deze in Jenkins terug onder de naam "mdkr" (toegegeven, die had beter gekund):

Je gebruikt in Jenkins dus elke keer dezelfde key, in je project gebruik je je eigen key om snel en veilig te kunnen werken. 

 

 

Inleiding

Je hebt je product backlog netjes gevuld met use cases/taken en gebruikt subtaken om in detail werk te kunnen plannen en schatten. Je hebt gebruik gemaakt van planning poker en story points aan de (sub)taken gehangen maar hoe krijg je nu een nette burndown?

Story points vs uren

Het inschatten van story points is handig omdat je zo een relatieve schaal hebt. Uitgaande van de meest eenvoudige taak / use case relateer je de overige werkzaamheden die vervolgens 1, 2, 3, 5, 8 of 13 punten waard zijn (ik adviseer teams om de overige kaarten niet te gebruiken of in elk geval als je een 20 of groter hebt deze taak op te splitsen naar kleinere taakjes). In eerste instantie gebruik je je "gut feeling" om een set van taken te pakken die haalbaar lijkt in een sprint, je gaat aan de slag en tijdens de stand-ups en de retrospective merk je wel of je goed zat of niet. 

Belangrijk om te weten: JIRA ondersteunt geen cumulatieve story points, dus de hoofdtaak krijgt niet automatisch de som van de story points van de deeltaken.

Nog belangrijker: je verbrandt eigenlijk niet direct punten (pas als de gehele taak af is, maar wat log je als je nog niet klaar bent?), dat is een handig schattingsmiddel; je verbrandt uren (elke dag netjes bijhouden, log work).

Zorg er dus voor dat elke subtaak een original estimate (voor de betekenis zie o.a. https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-issues/estimating-an-issue) heeft, JIRA is wel in staat om deze voor subtaken bij elkaar op te tellen. Zet deze original estimate op alle (sub)taken en start dan pas je sprint, dan is je sprint backlog gevuld.

Burndown

Standaard staat de burndown van JIRA in story points, maar zoals gezegd: pas als een taak helemaal af is zou je die "verbranden", dat geeft een vreemde burndown met veel flatlines (druk aan het werk .....) en dan ineens een dal (klaar). Door de burndown in uren te zetten krijg je een fijnmaziger overzicht, je gaat hiervoor in de configuratie van het planningboard naar Estimation:

Configuratie van planningboard, meten in uren

Deze configuratie heeft meerdere voordelen:

  • de burndown is fijnmaziger
  • de schatting van subtaken wordt meegenomen (gaat in story points niet)
  • het is passend bij wat je verbrandt: uren (smile)

De burndown kan er dan als volgt uit zien:

De groene lijn loopt omhoog, deze toont het aantal gemaakt uren. De rode lijn loopt (als het goed is (wink)) naar beneden, dat zijn de uren die je opgemaakt hebt. Soms gaat de rode lijn omhoog: als je tussentijds merkt dat je schatting te laag is, pas je de remaining estimate (voor de betekenis zie o.a. https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-issues/estimating-an-issue) aan, hierdoor krijg je er dus eigenlijk meer werk bij, vandaar de piek. 

Zelf oefenen voor je het in project toepast? Volg dan de JIRA workshop.

 

 

Voor alle OOSE groepen staat een nightly klaar in Jenkins die gekoppeld is aan het Maven project dat meegeleverd is in de git repository. Maar krijg je nu je codekwaliteit zichtbaar in Sonar? Het antwoord is deels afhankelijk van het platform en de build-tool die je gebruikt.

Java projecten die gebouwd worden met Maven

  1. Zet testcode in src/test/java en broncode in src/main/java.
  2. Check of de jacoco-plugin is opgenomen in de pom.xml (zit er standaard in bij het leveren van de git repository maar wellicht is deze verwijderd):

  3. Pas de Jenkins job aan, standaard doet deze

    maak hiervan

  4. Run de job een keer handmatig. Als deze job groen is, voeg dan een "Build step" toe die heet: Execute SonarQube Scanner
  5. Vul het veld "Analysis Properties". Kies ook de juiste SonarQube versie (Windows als je geen slave gebruikt, Linux als je wel een slave/label gebruikt). Hieronder een voorbeeld-inhoud, pas in elk geval de key en de naam van je project aan:

  6. Run de job nog een keer handmatig. Als deze job groen is je naar Sonar en bekijk je het resultaat. 

Java projecten die gebouwd worden met Gradle

  1. Zet testcode in src/test/java en broncode in src/main/java.
  2. Check of de jacoco-plugin is opgenomen in de build.gradle, zie o.a. deze voorbeelden hoe je dit aan kunt pakken.
  3. Pas de Jenkins job aan: verwijder de Maven build step en voeg een Invoke Gradle Script toe. Run de task jacocoTestReport.

  4. Run de job een keer handmatig. Als deze job groen is, voeg dan een "Build step" toe die heet: Invoke Standalone SonarQube Analysis
  5. Maak gebruik van het zelfde .properties bestand als bij Maven hierboven. 
  6. Run de job nog een keer handmatig. Als deze job groen is je naar Sonar en bekijk je het resultaat. 

Niet-Java projecten die gebouwd worden met iets anders dan Maven of Gradle

  1. Zet testcode en broncode is een eigen mappenstructuur, bijvoorbeeld src en test
  2. Pas de Jenkins job aan: verwijder de Maven build step en voeg een aanroep naar je build-tool toe (bijv. MSBuild, phpcomposer, npm, cmake, etc.)
  3. Run de job een keer handmatig. Als deze job groen is, voeg dan een "Build step" toe die heet: Invoke Standalone SonarQube Analysis
  4. Zorg dat je in de root van je project een bestand zet dat sonar-project.properties heet en vermeld hier o.a. de taal waarin je werkt, de plaats van de broncode staat (src) en de plaats waar de tests (test) staan. Voeg indien beschikbaar ook toe op welke locaties rapporten te vinden zijn van bijvoorbeeld cppcheck, cpptest, phpdepend, phpunit en vermeld dat in dit .properties bestand. Voor voorbeelden zie de github van sonar. Een voorbeeld voor hoe dat met C++ kan vind je op Jenkins: http://ci.icaprojecten.nl/jenkins/job/OOSE-R_RobotWorld_test/

 

 

 

Het ligt erg voor de hand: je maakt user stories of use cases in JIRA en hangt vervolgens subtaken aan deze taken en deze subtaken schat je in uren. Wat is dan de estimation van de hoofdtaak? In JIRA is dat helaas 0.

Ik heb gekeken in JIRA en “by design” is het niet mogelijk om de estimation van de hoofdtaak de som van de deeltaken te laten zijn: https://jira.atlassian.com/browse/GHS-10597. Er zijn meerdere mensen die deze wens hebben, maar het zit er dus niet in.

Mijn workaround: 

  • converteer (of creëer) de huidige hoofdtaken van het type "use cases" naar Epics
  • converteer (of creëer) alle subtaken naar gewone taken (“tasks” of “user stories”) en link deze aan de betreffende epic 

Op deze manier kun je ze op Epic groeperen en klopt de burndown en het planningboard. 

You may have noticed that you can use the Scrum Board in JIRA. It actually has two faces: the Classical View and the Default View. Both faces come from GreenHopper, formerly a separate product but today a first class citizen in JIRA. However, with the integration of GreenHopper with JIRA the development team also started to develop new features, resulting in two different versions of the same plugin in JIRA. 

Classic View

The Classic View is tied to the concept of versions in JIRA, you should create a version for every release/sprint and set the correct start date and end date. The default configuration of the Task Board contains three statuses: To Do, In Progress and Done. Using the Task Board Mapping you can create extra statuses, however most state changes trigger screens you need to complete, the Default View does not have this restriction. One advantage of the Classic View is that is has widgets that you can add on your own dashboard. 

Default View (or Board)

As an alternative to the Classic View you can use the Board, it comes with two templates: Scrum and Kanban. OOSE/DDOA uses the Scrum view, so let's focus on that. The Scrum Board is not tied to the concept op versions and the UI is more intuitive than the Classic View. In OOSE/DDOA the JIRA project is created first, so when you look the Scrum Board it strongly resembled the Classic View and the Task statuses are tied to JIRA statuses. The last fact is troublesome when adding columns, which is a nice way to see in which state your task is.  

Planning tasks and subtasks

I will briefly describe two ways of handling tasks within a Scrum project:

  • Use subtasks (preferred way of working in OOSE/DDOA-projects)
  • Use statuses

Subtasks

  • Create a task of type use case or user story and add your estimate from the planning poker
  • For every task that is tied to the use case, e.g. writing use cases, writing operation contracts, designing sequence- and classdiagrams, writing code, etc. you create a subtask
  • For every task that is not tied to a specific use case you create a task
  • You might want to add one or two extra columns to your dashboard, like "To Review" or "Testing". You need a simplified workflow for that, ask your administrator to perform this action for you. 

Statuses

You're supposed to choose which exact activities you need to call the use case / feature done, not all of the use cases need to be fully written, designed, built and tested (the last two are required though). So in some cases you don't need to write the use cases or write operation contracts, isn't it dull to create subtasks that you don't need? An alternative is to create extra statuses in your Scrum Board:

  • First, configure your board and simplify your workflow (ask your administrator to perform this action) so it can be managed by GreenHopper

  • Create extra statuses using Add Column, it creates extra statuses automatically.

  • Create a task of type use case or user story and add your estimate from the planning poker
  • Drag the task from left to right through the statuses to let everyone know what status of your use case is. Is it being written? Is it being designed? Coded? Unittested? Tested in combination with the rest of the app?

Pick your weapon of choice for planning tasks, but don't try to switch within your sprint. All new development from Atlassian will be done on the Scrum Boards so I'd pick Scrum Board over the Classic View, the only disadvantage is the lack of widgets on your dashboard. 

  1. Zorg ervoor dat je code vanaf dag 1 gebouwd en getest kan worden met Maven, of alternatief met Ant of Gradle. Voor enkele groepen is het al ingericht, mail Rody als je project Maven-ready is.
  2. Doe je planningpokersessie op de eerste dag van de sprint of een dag ervoor en neem er minimaal een dagdeel voor (ochtend en/of middag).  
  3. Zorg voor een geverifieerd (door docent en opdrachtgever) use case model en gebruik de use cases om schattingen in punten (niet in uren) te maken. 
  4. Bespreek in je team wat je exact onder de use case verstaat, maak eventueel schetsen op het bord en/of papier en voeg de use cases als hoofdtaken toe in JIRA; maak voor elke use case subtaken aan zoals use case uitschrijven, SSD maken, operatie contracten maken, sequencediagram(men) maken, classdiagram maken/aanpassen, unittests maken en code schrijven. 
  5. Maak een taak in JIRA genaamd Scrumproces waar je stand-ups, sprint-reviews, retrospectives, (gast)lessen, vergaderingen etc. op boekt. Maak voor use-case overstijgende taken (bepaalde technologie uitzoeken, deploymentdiagram of een lagenmodel maken etc.) aparte taken aan.
  6. Verdeel taken die aan een use case niet over teveel verschillende mensen, maximaal 2. Je kunt hier natuurlijk ook pair-designing of pair-programming doen.
  7. Beloof de opdrachtgever geen dingen die je niet waar kunt maken, wees voorzichtig met toezeggingen "oh, dat doen we wel even".
  8. Ben je klaar met een geslaagde sprint vier het dan goed met alle betrokkenen.  
  9. Ben je eerder klaar met een sprint voeg dan geen nieuwe features meer toe, klaar is klaar maar check heel goed de definition of done!
  10. Werk elke dag je uren in JIRA bij, alleen dan krijg je als team, scrummaster, docent en/of opdrachtgever een correct beeld van de werkzaamheden.

Mocht je zelf nog goede suggesties hebben voor de andere teams voeg dan comments toe. Happy coding!

Starting today you can draw UML diagrams in Astah (Community) and display the diagrams in Confluence. This way you have a good alternative for the built-in Gliffy editor that uses Flash and works in your browser. Create your UML diagram in Astah, and attach your Astah diagram to the page:

Then modify the page in Confluence and start editing the page. Using the Macro Browser (Insert->Other Macro's, or start typing a { ) you can insert your diagram and your diagram is on the wiki.

Using the macro you don't need to export the diagram to PNG/JPEG!

Prev Next

JIRA Greenhopper Basics. Meer info op: http://quickstart.atlassian.com/download/jira/get-started/agile-planning/set-up.

JIRA Greenhopper Details.