Differences

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

--- teaching:student-projects [2014/07/23 16:40] – [Internal organization of the student team] tenorth
+++ teaching:student-projects [2021/08/30 14:22] (current) – removed pmania
@@ Line 1: / Line 1: @@
-====== How to organize a student project ======
-This page is intended to collect good practices for organizing student projects. They are based on the lessons learned in the SUTURO project, but will hopefully be extended with experiences made in other projects.
-===== Topic =====
-The SUTURO project was about developing a complete mobile manipulation application on the PR2. On the one hand, the students liked to work on this nice platform and to develop a complete integrated system. On the other hand, it was also a very complex scenario that bound many resources, so something slightly less complex may also be appropriate.
-===== Schedule =====
-We organized the project in the following way:
-  * **Early Spring:** Presentation of the project idea and a first rough schedule on how to proceed
-  * **During the summer semester:** Seminar with presentations by the supervisors on topics required for the project (in our case, knowledge representation, plan-based control, perception, manipulation), as well as tutorials and homework assignments. The pages of this seminar can be found [[teaching/se-kiba|here]]. The assignments aimed at familiarizing the students with the basic techniques and some of the software packages to be used during the project. It wasn't done by most of the students, but most agreed later that it would have been a good preparation.
-  * **Project kick-off:** At the beginning of the semester, we had the initial meeting including a more detailed plan on what was to be implemented and how this could be achieved. As supervisors, we had sketched a plan how we'd approach the task to check whether it appeared feasible and if all required components were available.
-  * The rest of the project was organized in **milestones every 4-8 weeks**. The first two were given by the supervisors, the following ones were defined by the students as part of the report on the previous milestone. This way, they could have influence on the content of the project, but had to commit to a fixed goal beforehand. Each milestone consisted of a live robot demonstration, a presentation of the software architecture and the components that were shown in the demonstration, and a written report.
-  * **Milestone 1:** The first milestone after two weeks was about setting up the project. It involved the software development infrastructure, the project organization (roles, meeting structure, rules for e.g. missed meetings, etc) as well as the detailed definition of the subsequent milestone. The two-week deadline was very tense, but force the students to start working together early in the project.
-  * **Milestone 2, four weeks later:** This largely pre-defined milestone was a maximally stripped-down version of the final goal. In the case of SUTURO, the robot was to touch an object that was considered edible. Achieving this milestone required collaboration of all groups, though each of the groups had to do only slightly more than what was part of the homework assignments. This milestone thus served as a test case for learning to organize joint software development, testing software on the robot, and familiarizing oneself with the software libraries to be used.
-  * **The following milestones** then incrementally increased the complexity until arriving at the final goal.
-===== Grading =====
-The students got intermediate grades after each milestone in order to get feedback on how they developed and how they perform w.r.t. their peers.
-==== Criteria ====
-We graded people based on a) the technical quality of the implemented robot behaviour, b) the contribution to software development (dev. infrastructure, integration of components, testing and debugging on the robot), and c) the contribution to the project management. The approximate weighting was 60%/30%/30%; as the sum was at 120%, students had the chance to set an individual emphasis on some parts, while having to cover all areas. Details can be found in doc/src/teaching/pr-bachpro-ws13/intro.tex
-==== Feedback sheets ====
-At each milestone, each student had to fill out a feedback sheet ({{:teaching:feedbackbogen.pdf|PDF}}, {{:teaching:feedbackbogen.odt|ODT}}). The goals were to get an 'inside-out' view on the self-perception of the group dynamics, the students' own contributions, problems in the group etc. By the brief descriptions of what the others have done, it could be seen who under-performed, but also who had a good grasp on what everyone in the group did.
-==== Intermediate grades ====
-Based on the demonstrated results and the feedback sheets, the students got intermediate grades after each milestone. They were however not simply averaged in the end, but were weighted with the overall project success and therefore lifted. The intermediate grades were mostly intended to give feedback on how the performance and progress were seen.
-===== Plenary sessions =====
-* One plenary session
-===== Internal organization of the student team =====
-  * Atlassian tools (Jira, Confluence)
-  * Four sub-teams: perception, knowledge, planning, manipulation
-  * Project management using Kanban/Scrum
-  * One project owner for each team, changing per milestone
-  * All other roles were also switched regularly