Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
teaching:labs:xp:2008b:evaluation [2008/11/25 17:49]
Daniel Speicher
teaching:labs:xp:2008b:evaluation [2018/05/09 01:59] (current)
Line 1: Line 1:
 +====== Evaluation ======
 +<​note>​We asked the participants for they feedback. On this page you find their comments. We also have quite some numbers that we hope to add soon. The comments are unfiltered. Only obvious spelling errors were corrected for better readability. There is another evaluation following the standards of the Fachschaft, that we also hope to get published soon.</​note>​
 +===== Comments [on elements of the practical course] =====
 +  * <​html><​font color=green></​html>​Most of the things were pretty useful<​html></​font><​font color=red></​html>​ 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.<​html></​font></​html>​
 +  * <​html><​font color=orange></​html>​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.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​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.<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​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.<​html></​font></​html>​
 +===== Comments on satisfaction?​ =====
 +  * <​html><​font color=red></​html>​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. <​html></​font><​font color=green></​html>​At the end I really fell to have something accomplished.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​I really enjoyed the atmosphere. Despite <​html></​font><​font color=red></​html>​some minor issues and the protocol discussion - which was unnecessary bloated - <​html></​font><​font color=green></​html>​this was until now the most fun part of my studies.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​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. =)<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​I'​m pretty much satisfied - my skills have obviously improved throughout the lab. The team spirit also grew stronger, <​html></​font><​font color=red></​html>​and the only regret I have that there is still a (long) way to go in terms of having a stable and predictable application.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​Awesome!<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​I'​m really satisfied. My expectations were highly exceeded!<​html></​font></​html>​
 +===== Comments about steering & control? =====
 +  * <​html><​font color=green></​html>​Like in 3.6 [Reference to be explained] the level of control rose with the level of confidence in the programming languages.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​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.<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​Sometimes the discussions lost focus.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​The feedback about where we stood in the development process was always good and honest. The burndown charts encouraged our estimation efforts. <​html></​font><​font color=red></​html>​The overall design decisions, especially the long-term decisions might improve by a better steering.<​html></​font></​html>​
 +===== What was the most important thing you learned in the preparation seminar? =====
 +  * 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.
 +===== What else would you have liked to learn? =====
 +  * 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
 +===== Concrete suggestion how to organize code reviews? =====
 +  * 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.
 +===== Is there something we should have made different? Do you have any tips for future teachers and students? Do you have any other final remark? =====
 +  * <​html><​font color=red></​html>​Concerning question 4.3 [Reference to be explained]: There were too many programmers for the project, <​html></​font><​font color=green></​html>​but I don't think there were too many students for everybody to learn a lot.<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​Either do not plan everything with the whole group, or be OK with spending more time. <​html></​font><​font color=orange></​html>​Splitting up helps.<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​Sometimes the English skills were an obstacle.<​html></​font><​font color=orange></​html>​ 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."<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​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. <​html></​font></​html>​
 +  * <​html><​font color=orange></​html>​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.<​html></​font></​html>​
 +  * <​html><​font color=orange></​html>​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. <​html></​font><​font color=green></​html>​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!<​html></​font></​html>​
 +  * <​html><​font color=red></​html>​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. <​html></​font><​font color=green></​html>​Apart from that your performance as tutors where exemplary. Good job guys.<​html></​font></​html>​
 +  * <​html><​font color=green></​html>​Good job!<​html></​font></​html>​
 +===== Kommentare aus den Antworten auf den Fachschaftsfragebogen =====
 +  * <​html><​font color=green></​html>​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. ​ \\ <​html></​font><​font color=red></​html>​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. <​html></​font><​font color=green></​html>​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. \\ <​html></​font><​font color=red></​html>​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.<​html></​font></​html> ​
 +  * <​html><​font color=green></​html>​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.<​html></​font></​html> ​
 +  * <​html><​font color=orange></​html>​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. <​html></​font></​html>​
teaching/labs/xp/2008b/evaluation.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019