The work-reflection-learning cycle - Department of Computer and ...
The work-reflection-learning cycle - Department of Computer and ... The work-reflection-learning cycle - Department of Computer and ...
The work-reflection-learning cycle in SE student projects: Use of collaboration tools in the typical challenges of SE and collaborative project work. Some initial ideas for how this could be achieved include: training course staff to provide advice on this topic; conducting introductory lectures; arranging workshops where students from different groups compare their experiences, and addressing the topic of collaboration tool use in retrospective reflection workshops during the semester. How the topic of collaboration tool use may be more consciously addressed in SE project courses deserves systematic and empirical research by SE education practitioners. The thesis shows some cases of collaboration tool use in which cross-community collaboration entails a relatively high degree of participation in the other community, for example when a project customer gets his own page in a project team‟s wiki, or in the case of OSS participation by a project team, through an internet developer forum. In the context of SE student projects, further research could address the questions of when such participation in the other community is appropriate and what it takes for it to succeed, specifically addressing the role of collaboration tools. The concepts of CoP, brokering and boundary objects might be useful in the analysis. The research could be done within SE education, TEL or CSCW. Another task for further research in SE education is to adapt the retrospective reflection workshop approach outlined in the thesis, with or without the use of historical data in collaboration tools, to the needs of specific courses. This should be considered and conducted as design research and not merely „use‟ of research results. The outcomes should be improvement of the specific project courses as well as guidelines and templates for the organizing of retrospective reflection workshops in SE student projects. The more systematic use of issue trackers in retrospective reflection in a larger number of teams should be explored. An important aspect of adapting the approaches to specific courses is the integration of reflection into the development processes (e.g. as done in SCRUM and other agile development methodologies). This implies making reflection part of a process improvement effort and conducting reflection workshops several times during the project. In each workshop, not only should the teams collaboratively determine what are main lessons learned, they should define a set of action items to be implemented in their subsequent work. Accordingly, empirical research on reflection in the projects should investigate the teams‟ actual use of, and benefit from, the outcomes of reflection. Comparing data from several reflection workshops in a project might provide useful data in this respect. This could be supplemented by longitudinal observation of work in the team with a focus on the follow-up of action items. In PBL in other domains of education, a similar way of organizing retrospective reflection can be adapted and tried out. The results of such studies should be best 78
Conclusion and recommendations for further work practices and guidelines for PBL in the particular domains, and should also contribute to the development of these work domains beyond educational settings. The insights from this thesis about the potential of historical data in collaboration tools to aid retrospective reflection should be developed into a contribution to the software engineering community, as the rationale for the proposed use of historical data originates in SE research and the needs of SE professionals. The empirical data on the use of Trac in retrospective reflection, as well as new studies in which a similar approach is introduced in a larger number of student projects, should result in publications directed at the SE community with a focus on how the proposed approach meets the needs of Software Engineering. Exposing the research to the software engineering community (and not just SE education) would help ensure that the use of historical data to aid retrospective reflection in SE student projects become not only an improvement of education practices but, in line with the PBL core idea of doing „real work‟, an improvement of SE practice. The thesis outlined the first steps of an investigation of the connection between day-today use of lightweight collaboration tools, tool features and the potential of the tools to aid retrospective reflection. Further CSCW research along this line should aim for the development of a framework that can be used by project teams and organizers as well as designers of collaboration tools to consider the role of collaboration tools in retrospective reflection. The development of the framework would require a survey of state-of-the-art research on day-to-day tool use in teams combined with empirical studies addressing the connection between day-to-day tool use and the use of the same tools in retrospective reflection. Again, SE student projects may be used as test beds. The reflection model proposed in the thesis can be used to inform further research on reflective learning and the role of collaboration tools in supporting day-to-day collaborative work and reflection on that work. Based on the results of such research, the model can be further developed and refined. I propose three research directions that can be pursued independently or in combination: Firstly, the model can be used as a basis for exploring and comparing various types of use of historical data in day-to-day work, including retrospective reflection. This research should identify how current approaches and solutions to the gathering and use of data for one purpose (e.g. coordination) – or the gathered data themselves - could be applied for another purpose (e.g. reflection) within the work practice. The research should draw on state-of-the-art research within SE and CSCW and result in contributions (to the same communities) with practical applicability for the organization of, and tool support for, collaborative project work. Also, the research should lead to a 79
- Page 45: Software Engineering student projec
- Page 48 and 49: The work-reflection-learning cycle
- Page 50 and 51: The work-reflection-learning cycle
- Page 52 and 53: The work-reflection-learning cycle
- Page 55 and 56: 5 Results This chapter presents an
- Page 57 and 58: Results The background of P2 is a l
- Page 59 and 60: Results project management and coll
- Page 61 and 62: Results proposed in P5 was to allow
- Page 63 and 64: Results Analysis of the results sho
- Page 65 and 66: Results archives are found to conta
- Page 67 and 68: Results (SVN). Trac provides lightw
- Page 69: Results Figure 15: A model outlinin
- Page 72 and 73: The work-reflection-learning cycle
- Page 74 and 75: The work-reflection-learning cycle
- Page 76 and 77: The work-reflection-learning cycle
- Page 78 and 79: The work-reflection-learning cycle
- Page 81 and 82: 7 Evaluation In this chapter, I eva
- Page 83 and 84: Evaluation adds to the CSCW literat
- Page 85 and 86: Evaluation 7.3 Evaluation of the re
- Page 87 and 88: Evaluation In the longitudinal stud
- Page 89 and 90: Evaluation According to the princip
- Page 91 and 92: Evaluation However, only some of th
- Page 93 and 94: Evaluation to design is problematic
- Page 95: 8 Conclusion and further work This
- Page 99 and 100: 9 References Abran, A., Moore, J. W
- Page 101 and 102: References Cobb, P. (1994). "Where
- Page 103 and 104: References Herbsleb, J. D., Mockus,
- Page 105 and 106: References Leont'ev, A. N. (1981).
- Page 107 and 108: References Stahl, G. (2002). "Build
- Page 109 and 110: Glossary B Boundary object - artifa
- Page 111 and 112: Glossary maintaining the system aft
- Page 113 and 114: Appendix A: Research papers P1 P2 P
- Page 115 and 116: Research paper P1 Title: Cross-Comm
- Page 117 and 118: Cross-Community Collaboration and L
- Page 119 and 120: the course staff may improve the co
- Page 121 and 122: 4: Case findings: students’ view
- Page 123 and 124: own account of why each artifact is
- Page 125 and 126: Research paper P2 Title: Power Thro
- Page 127 and 128: Power Through Brokering: Open Sourc
- Page 129 and 130: Due to the openness of OSS communit
- Page 131 and 132: 5.1.2 Second phase (February-May):
- Page 133 and 134: Getting from the second to the thir
- Page 135 and 136: 6.2.1 Benefits for SE student proje
- Page 137 and 138: Research paper P3 Title: Do’s and
- Page 139 and 140: DO‟S AND DON‟TS OF INSTANT MESS
- Page 141 and 142: a chat window is opened. As soon as
- Page 143 and 144: three examples in the form of excer
- Page 145 and 146: Example 2. Excerpt from an IM log s
<strong>The</strong> <strong>work</strong>-<strong>reflection</strong>-<strong>learning</strong> <strong>cycle</strong> in SE student projects: Use <strong>of</strong> collaboration tools<br />
in the typical challenges <strong>of</strong> SE <strong>and</strong> collaborative project <strong>work</strong>. Some initial ideas for<br />
how this could be achieved include: training course staff to provide advice on this topic;<br />
conducting introductory lectures; arranging <strong>work</strong>shops where students from different<br />
groups compare their experiences, <strong>and</strong> addressing the topic <strong>of</strong> collaboration tool use in<br />
retrospective <strong>reflection</strong> <strong>work</strong>shops during the semester. How the topic <strong>of</strong> collaboration<br />
tool use may be more consciously addressed in SE project courses deserves systematic<br />
<strong>and</strong> empirical research by SE education practitioners.<br />
<strong>The</strong> thesis shows some cases <strong>of</strong> collaboration tool use in which cross-community<br />
collaboration entails a relatively high degree <strong>of</strong> participation in the other community,<br />
for example when a project customer gets his own page in a project team‟s wiki, or in<br />
the case <strong>of</strong> OSS participation by a project team, through an internet developer forum. In<br />
the context <strong>of</strong> SE student projects, further research could address the questions <strong>of</strong> when<br />
such participation in the other community is appropriate <strong>and</strong> what it takes for it to<br />
succeed, specifically addressing the role <strong>of</strong> collaboration tools. <strong>The</strong> concepts <strong>of</strong> CoP,<br />
brokering <strong>and</strong> boundary objects might be useful in the analysis. <strong>The</strong> research could be<br />
done within SE education, TEL or CSCW.<br />
Another task for further research in SE education is to adapt the retrospective <strong>reflection</strong><br />
<strong>work</strong>shop approach outlined in the thesis, with or without the use <strong>of</strong> historical data in<br />
collaboration tools, to the needs <strong>of</strong> specific courses. This should be considered <strong>and</strong><br />
conducted as design research <strong>and</strong> not merely „use‟ <strong>of</strong> research results. <strong>The</strong> outcomes<br />
should be improvement <strong>of</strong> the specific project courses as well as guidelines <strong>and</strong><br />
templates for the organizing <strong>of</strong> retrospective <strong>reflection</strong> <strong>work</strong>shops in SE student<br />
projects. <strong>The</strong> more systematic use <strong>of</strong> issue trackers in retrospective <strong>reflection</strong> in a larger<br />
number <strong>of</strong> teams should be explored. An important aspect <strong>of</strong> adapting the approaches to<br />
specific courses is the integration <strong>of</strong> <strong>reflection</strong> into the development processes (e.g. as<br />
done in SCRUM <strong>and</strong> other agile development methodologies). This implies making<br />
<strong>reflection</strong> part <strong>of</strong> a process improvement effort <strong>and</strong> conducting <strong>reflection</strong> <strong>work</strong>shops<br />
several times during the project. In each <strong>work</strong>shop, not only should the teams<br />
collaboratively determine what are main lessons learned, they should define a set <strong>of</strong><br />
action items to be implemented in their subsequent <strong>work</strong>. Accordingly, empirical<br />
research on <strong>reflection</strong> in the projects should investigate the teams‟ actual use <strong>of</strong>, <strong>and</strong><br />
benefit from, the outcomes <strong>of</strong> <strong>reflection</strong>. Comparing data from several <strong>reflection</strong><br />
<strong>work</strong>shops in a project might provide useful data in this respect. This could be<br />
supplemented by longitudinal observation <strong>of</strong> <strong>work</strong> in the team with a focus on the<br />
follow-up <strong>of</strong> action items.<br />
In PBL in other domains <strong>of</strong> education, a similar way <strong>of</strong> organizing retrospective<br />
<strong>reflection</strong> can be adapted <strong>and</strong> tried out. <strong>The</strong> results <strong>of</strong> such studies should be best<br />
78