Spring literature by Scott Stanlick

Currently I am preparing myself for my upcoming Spring core course.

Already long time ago I was facing Spring and so I decided to prepare myself by some literature. First of all I found the „Beginning Spring“, which I already mentioned.

My ebook-provider suggested me another series for Spring: „Spring next generation“. I started with „Core Container„, which is already Volume 2. Scott Stanlick suggested for newbies also to read Volume 1 „Thinking in objects“. As the books are quite easy to read and even cheap I decided to study Volume 1 afterwards.

Scott has a very simple and direct way to focus on the main intention of Spring:

  1. Elminating new().
  2. Bring together, what fits best for the context.

He describes every chapter with pictures from the real world and the one I keep in mind is how he made me first of all understand this:

Imagine you go into a restaurant and order from the carte. Spring is the chef who brings together the ingredients from the restaurant with your desires. And this is called „Dependency Injection“. Brilliant!

For everyone even interested in good literature with very simple and clean code examples I recommend Scott Stanlicks series. Next I will try the „AOP“-Thing, as I have never done it before.

So I hope in some weeks I will give you a NICE Review of my core exam…

Have you ever done the Big Jump?

Big-Jump-Picture

During the last weeks I have learned to use a new tool: JMeter!

I am running Load tests in a new software environment for our customer. The old environment was quite simple: One application server, one Database server, aged database management system, aged application server, aged server and operating system…

We planned a new environment with failover instances for application and database servers, upgraded application- and database management system, docker containers to improve and simplify „up-to-dateness“, bi-directional replication.

Everything implemented we had a little integration and manuel testing. Everything seemed alright. So we did the migration of the old system.

Next morning the system had gone. No more connections possible to the database.

We have thought about definite problems and had one day of try and error…

Resolution: Nothing!

Our manager decided to break the system back down. We have installed the containers with the old setup and brought in some load tests for penetrating the system for a while automatically.

Every successful test session (of at least 12 hours) lead to the next level. We are still in the process but have already found interesting insights…

Have you ever had similar jumps?

What have you done different?

Coding Kata: Café XY

Lets say you would like to do some Coding Kata. You have already found a lot of practices to do with your team but everything without functional reference.

Last weeks I did some Coaching with a team who want to do Progress in Pair Programming. They already did some technical stuff like the „String Kata“. My idea was now to give them a little Vision and some kind of User Story Backlog. After that we would have some sprints with changing pairs.

The vision

The idea is that your company plans to create a café for the employees. Currently they plan to hire no more employees, and so the customers to be served by an app.

The first Storys

According to the motivation bringing every sprint a shippable product here are my example Storys:

  • As a customer I want to order something.
  • As the barman I need a list of all orders to prepare them.
  • As a customer I want to get my order to consume together at my table.

Do you already see the acceptance criterias? They are not really necessary in this cata. Depending to what you put your focus on you can strengthen this or other parts.

Starting the first sprint

First of all we want to commit on the first storys. Acceptance criteria for our planning:

  • We can place order by order
  • All orders can be output in an ordered list.
  • Optional: We can add amount.
  • Optional II: We can add a table number.

Sprint duration is 30 minutes. Go ahead!

My insights

Depending on the lead in the Pair we found different solutions. Some of them started by doing object design and planing tables, orders and so on. Some of them really concentrated on test first. In my opinion you find each strength in the upcoming next sprints when you try to commit on the rest of the User Storys.

No insight without review

Absolutely obligatory is the review after the sprint to face each team the different perspectives.

Whats your opinion on this approach?

Have you tried already something comparable?

2015 – Mein Review

Das war 2015:

Ich habe mich dieses Jahr in vielerlei Hinsicht weiterbilden können. Als Coach konnte ich meine ersten Erfahrungen sammeln und sehr viel Sicherheit als Facilitator sammeln.

Mit bikablo habe ich das Medium Flipchart für mich entdeckt und zu schätzen gelernt. Wenn man erstmal etwas ausprobiert hat fällt es einem immer leichter in Sessions auch mal spontan eine Visualisierung aufs Papier zu bringen. Meine Kollegen konnten auch davon partizipieren: Wir haben zur Übung in einem öffentlichen Raum jeden Tag ein neues Bild zu Agilen Methoden erstellt. Es entstand im Laufe eines Tages angefangen mit einer Überschrift oder einer Figur / einem Symbol… .

Als Scrum Master und Entwickler in 2 Festpreisprojekten habe ich Erkenntnisse gewonnen, wie man bei festgelegtem Budget und Zeitrahmen ein Produkt mit den geforderten Ergebnissen erstellt. Hier haben uns die regelmäßigen Reviews mit den Stakeholdern geholfen, aber erst Recht die Festlegung auf das „Wofür“, um die User Storys mit einem erträglichen Aufwand zu realisieren.

Im Bereich Web-Entwicklung konnte ich mit apache wicket einen ganz alten Bekannten mal etwas näher kennenlernen. Meine erste Erkenntnis: Es ist schon ziemlich xxx sich manuell Komponente und Markup synchron zu halten und in unserer Architektur dann auch noch für jede kleine Änderung am Styling komplett zu deployen.

Bevor ich noch meine private Literatur liste möchte ich noch gerne fragen, was Eure Highlights 2015 waren? Schreibt mir Kommentare, Mails oder ruft mich an:)

Einen guten Rutsch und bis 2016 dann mit hoffentlich weiteren Themen!

Zu guter letzt noch meine Literatur:

Magic Estimation – customized

I like to present you an alternate activity for estimating large backlogs in little time. The acitivity isn’t new at all but when i first tried it during the past days I felt so impressed that I like to share this.
Another reason for me is that I also added one feature which made it easier for the product owner to track discrepancy.
But first of all let us habe a Lok at the rules that i captured in German

20151112_105550

  1. The product owner will distribute all the Storys as cards to the developers. Storys Schuld bei Mixer and not Onlay one Eric to one developer.
  2. Every participant / developer estimates each Story without conversation by comparing each other according its „size of functionality“.
  3. After estimating the Story is pinned to the Slot with the corresponding „fibunacci count“.
  4. Each Story gets a „post-it“ with the current estimate.
  5. After all the Storys are estimated take a short break . Then go on and let each other estimate silently on the estimated Storys.
  6. Make sure every moved story card received a new post with the current estimate. So even after finishing the product owner can always recognise Storys that have to be debated.
  7. Bad written or unclear Storys are estimated to 100.
  8. Second round is over when every one starts reestimating effort or all developers talk about other stuff. Second round is really hard, so don’t be that dogged.

Our insights

100 user Storys were estimated by 4 developers in the first round in 15 minutes. Second round took another 20 minutes. I prepared a chart to keep in mind the relation of the „fibunacci counts“ which helped very well.

20151112_100011

Another point is the estimating unit „complexity of function“. In my opinion next time I will have an introducing round with estimating housewares as described by Boris Gloger.

See some more impressions of the activity…

Review Beginning Spring

Recently i just finished studying „Beginning Spring“ (amazon).

My impression is great for really learning about the framework. You have very good descriptions (also about technical implementations) „Try it out“ – sections for all necessary topics. Excercices finish a chapter.

The structure of each chapter is as follows.

A Table of contents gives a listed overview with links to all topics of the chapter.

First a quick Introduction of at least 3 pages describes the theme from the specification to implementations and the differenciation by Spring.

A basic implementation is described shortly followed directly by a „Try it out“-section.

The „Try-it-out„-section has a step by step guide starting on creation of a maven project, doing configuration, implementing code until finally executing test applications. A „How it works“ part describes all the steps afterwards. „Try -it-out„-sections are written for all necessary topics in a chapter.

A Summary gives a resumé of all explained features of a chapter.

Following some Excercises on the treated theme can be executed. The solutions are found well described in the Appendix.

A Vocabulary table repeats all learned technical phrases or annotation learned from the chapter with a short description. This is the only fault of the e-book: The description column can never be fully read.

The book covers all the necessary themes for a first start with spring core elements (DI, JDBC, JPA, Security, MVC…).

Bosch ixo Super Soaker 2015

image

Scrumday 2015. Tag 1

Ankunft zum Workshop. Keiner weiß, was ihn erwartet, Titel des Workshop ist „Bosch IXO Challenge – die Scrum Simulation für Tüftler und Bastler„.
Zunächst wollen die Coaches ein Bild über die Erfahrungen mit Scrum, Entwicklung und Basteln erhalten. Dazu werden wir gebeten uns entsprechend unserer Einschatzung auf einer imaginären Linie im Raum zu verteilen.
Anschließend erhalten wir eine Kurzeinführung in Scrum – nicht länger als 10 Minuten.

image

Nun sind alle heiß auf die Vision. Die Coaches stellen uns die Bosch IXO vor- ein Kleiner Akkuschrauber,der sich gerade durch seine vielseitigen Erweiterungen großer Beliebtheit erfreut. Hier nur ein Beispiel: eine BBQ Erweiterung
Viele Kundensegmente seien bereits erschlossen. Nun solle aber ein grosses folgen:Die Kinder. Die Vision ist eine Erweiterung mit der die IXO zu einer Wasserpistole wird.

Die User Storys sind bereits fertig geschrieben, Akzeptanzkriterien festgelegt und in einem Backlog priorisiert. Der Kunde ist auch da.

Nun finden sich die Teams zusammen und gemeinsam starten wir in die erste Planung. Für den ersten Sprint gibt es Unsicherheit und kein Team möchte sich über eine Story commiten. In den den folgenden Sprints finden sich dann die Teams und die Commitments werden immer sicherer. Am Ende des dirtten Sprints stehen bereits bei allen 4 Teams erste Prototypen zur Verfügung, die mobil von einer Person bedient und aufgefüllt werden können.
image

image

Mein Fazit:

Ein guter Workshop mit tollen Coaches und einem ansprechenden Thema. Hardware-Prototyping ist in so einem Rahmen durchaus möglich und alle hatten sehr viel Spaß.

Regelmäßig liefern – alles was zählt

Mein erster Beitrag in diesem Blog soll etwas mit meinen Erfahrungen und Erkenntnissen in agiler Softwareentwicklung zu tun haben.

Ich programmiere seit 2002. Und ich programmiere seit 2002 Java.

Soviel schon mal vorweg. 2010 kam ich in meiner Tätigkeit als Berater das erste Mal mit Agilen Entwicklungsmethoden in Kontakt. Ich bekam die Chance ein Entwicklerteam zu unterstützen, das aus dem Büro für einen Kunden entwickelte. Die Methodik entsprach nicht Scrum, aber es ging schwer in die Richtung: Pair Programming, Iterationen, Retrospektiven. Der Kern der Entwickler hatte bereits an der Hochschule gemeinsam in Projekten gearbeitet und daher lief die Abstimmung sehr reibungslos.

Was mir jedoch bereits nach der ersten Iteration auffiel war, dass der Moment der Auslieferung nicht zelebriert wurde. Der letzte Tag der Iteration war festgelegt, aber die Auslieferung erfolgte meist später und auch nicht von den Entwicklern selbst. Im Team herrschte Ungewissheit, was die fachliche Qualität Ihrer Lösungen angeht und auch die Richtung des Produktverantwortlichen war nicht eindeutig. Allerdings ließ sich der Kunde leider auch nicht auf einen regelmäßigen Termin zur Präsentation ein. Termingründe…

In zukünftigen Projekten wollte ich möglichst viel Agile Methoden anwenden und stellte immer häufiger fest, daß jedes Team / Projekt seine eigenen individuellen Bedürfnisse hat.

Allerdings stellte sich heraus, daß eines immer ankam sowohl beim Kunden als auch bei den Entwicklern: Das Regelmäßige Liefern eines Inkrements und die Präsentation durch die Verantwortlichen! Man könnte auch sagen, dass Feedback ganz entscheidend ist.

Die Begründung lasse ich erstmal aus, da wahrscheinlich jeder seine eigene Erkenntnis gesammelt hat.

Wie seht ihr die Wichtigkeit dieses Artefakts ?

Regelmäßige Lieferung von Software