Most of the things were pretty useful just sometime I would like to see them a little more efficient. We often had long discussions with results that I think didn't need that long time.

I think burn-down charts are harder to understand than just color mapping of the tasks on the whiteboard. One quick look at which color prevails gives you a better overview than the charts.

It was a great experience and I learned a lot. It was good that it was no artificial atmosphere without any problems to solve, because I also learned a lot from the drawbacks.

We needed to have more discipline in deciding when the product development should stop. The reason why the demo was not so successful was because new versions of the client application were still being deployed just 10 minutes before the presentation.

The first two weeks were a little bit frustrating because I was not very comfortable in the new technologies and my personal progress was slow. At the end I really fell to have something accomplished.

I really enjoyed the atmosphere. Despite some minor issues and the protocol discussion - which was unnecessary bloated - this was until now the most fun part of my studies.

The lab was very satisfying, the atmosphere was excellent and the lab made real benefit from the knowledge and experience of the team leaders and tutors.

I'm pretty much satisfied - my skills have obviously improved throughout the lab. The team spirit also grew stronger, and the only regret I have that there is still a (long) way to go in terms of having a stable and predictable application.

Awesome!

I'm really satisfied. My expectations were highly exceeded!

Like in 3.6 [Reference to be explained] the level of control rose with the level of confidence in the programming languages.

Very good team leading and expert advice. In terms of tradeoff between learning and having a running product it was a difficult decision for organizers I guess. But I still feel it was right.

Sometimes the discussions lost focus.

The feedback about where we stood in the development process was always good and honest. The burndown charts encouraged our estimation efforts. The overall design decisions, especially the long-term decisions might improve by a better steering.

It was very helpful to get a general overview. Ruby is in my opinion no easy concept to grasp. The seminars are a must-have.

To see some Ruby code and get a basic idea of it. As well as getting to know the people. It was just too much time until the actual lab started.

Respect the Ruby conventions!

Rails testing frameworks, migrations and REST.

That one should be really aware of the properties of a framework and that one should develop a clear concept of a task before starting to work on it.

It was first opportunity to meet other teammates and also to be exposed to Ruby on Rails.

Hard to imagine. I cannot think of something right now.

Objective-C

More on Ruby-side, after the first iteration, I worked only with Objective-C.

Objective-C and the Cocoa Touch API.

A preparation seminar on the client programming language [Objective-C] would have been very useful.

In fact Objective-C

Code review is a time consuming activity and it's hard to be clear enough about the reasons of why you consider this particular piece of code “bad” or “good”. So it could be a good idea to review critical pieces of code only, and pay a close look to test coverage and functional/integration tests especially.

I think it would be helpful but on the other hand it is quite some effort for the tutors. Getting feedback of the quality of the code would be helpful.

A very important point of this lecture was in my opinion that the participants see for themselves the longtime benefits of good code design. If the tutors would clean up all code there would be no learning experience. Or even worse: the participants would only write good code because the tutors want it that way and not because it's a useful thing to do.

Given the actual course as an example, the fast written product with his non-extendable protocol. The tutors might examine such key-functionality and encourage to rewrite/change them in a certain way. Task-breakdowns should lead to such key functionalities, as far as the experts are certain that such should exist and be written in a certain way. So each review will then lead not only to better understanding of the code/framework/design but as well lead to better reusability in terms of long-term decisions.

I'm not sure about the benefit of this. It would cost a lot of time. The tutors should supervise the progress anyway, while it forms.

Concerning question 4.3 [Reference to be explained]: There were too many programmers for the project, but I don't think there were too many students for everybody to learn a lot.

Either do not plan everything with the whole group, or be OK with spending more time. Splitting up helps.

Sometimes the English skills were an obstacle. Maybe pay closer attention to the language skills of the applicants. The discussions need to be more effective. Maybe to take more things offline or to just say “That is not of importance right now. It does not help.”

The integration of students that live far from Bonn (e.g. Aachen) might be improved by a slightly better information or help about finding a place to stay in the vicinity of the b-it during the lab.

To distinguish between the roles, that are embodied by the team leaders and the customer there might be some space for improvement during the sessions (like the meta-role and so on). I think this is difficult but may lead to a better start in the lab and a better understanding of the processes.

While collective code ownership looks OK, it couldn't work to the full extent when you have two new technologies, as we had Ruby on Rails and Objective-C. The informal separation of the team to server guys and client guys was the result of this learning. Perhaps this should be avoided, since none has a full picture then. Other than that, this lab is a great experience and I was happy to participate in it. Good luck and thanks for all your work!

Never ever again let arguments run circles for more than an hour (protocol discussion). Cut it and continue on another day. Your renown as good tutors took heavy damage that day amongst the participants. Apart from that your performance as tutors where exemplary. Good job guys.

Good job!

Die Methodik des XP-Programming / Agile Development wurde sehr konsequent und gut vermittelt. Ich denke, dass ich einen guten Eindruck darüber gewonnen habe, wie mit Hilfe der verschiedenen angewendeten Methodiken die Evaluierung, die Planung, das Finden von Kompromissen, die Motivation des Teams und einzelner Teilnehmer, sowie die zielgerichtete Abarbeitung der gestellten Aufgaben angegangen wurde und so Probleme auf eine effiziente Art und Weise gelöst wurden.
Jedoch hätte meines Erachtens die Nutzung der gewonnenen Erfahrungen aus den vorherigen Labs die Entwicklung des Produktes entscheidend fördern können. Eine klarere Vorgabe von gewünschten Architekturen und Protokollen nach der ersten Iteration wäre sehr hilfreich gewesen, auch wenn wir uns dann evtl. nicht mehr so in den Entscheidungsprozess involviert sähen. Das gewählte Vorgehen bot trotz einiger Frustrationsmomente jedoch auch eine gute Gelegenheit um die Stärken der oben genannten Methodiken des XP-Programming in eben solchen problematischeren Situationen aufzuzeigen.
Die mangelnde Einarbeitung in die Programmiersprache Objective-C war wohl im Vorfeld nicht zu umgehen, da Ihr wohl keinen Einfluss auf die dazu führenden Faktoren hattet. Generell wäre aber natürlich eine Einarbeitung in beide Sprachen wünschenswert gewesen.

Das Praktikum war einer der besten Kurse, die ich bis jetzt gemacht habe. Ich kann es nur jedem empfehlen. Es ist vielleicht etwas zeitaufwendig, aber man lernt viel und hat dabei eine Menge Spass.

Die Vorbereitungsphase war wohl gut strukturiert aber sie deckte nicht alle Erfordernisse ab. Eine Frage, welche die Abdeckung der erforderlichen Vorkenntnisse hinterfragt würde darüber entsprechenden Aufschluss bieten.