The work-reflection-learning cycle - Department of Computer and ...

More documents

Recommendations

Info

Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 perspectives, team-customer relationship, development of requirements.) Again, team participation in the tagging of contents, whether in the there-and-then work situation or in reflective hindsight, would help ensuring that information considered important by those involved is given priority. 6. The wiki walkthrough tool: reviewing selected aspects of project history In Section 5 we have argued that user-defined tagging of wiki page revisions combined with the possibility to review the set of tagged revisions, could make a project wiki even more useful for postmortem reviews. In this section, we demonstrate how a wiki can be extended in this way. Our wiki walkthrough tool (WWT) has been implemented as a prototype extension of DokuWiki. An elaborate presentation of the tool is beyond the scope of the paper, but we provide a brief use scenario and a description of the tool functionality. 6.1. A scenario for the use of a wiki walkthrough tool The following scenario is intended to show in a compact way how a project wiki can be used for postmortem reflection, aided by some extended wiki functionality. The context for the scenario is as follows: There is a SE student project team with five members doing development work for a customer. The team has a project wiki in which they include or link in artifacts related to the project process and product. The wiki is actively used in project management: Various to-do-lists are updated by all team members, and there is a news bulletin mainly updated by the project manager. The chapters in the project report are included in the wiki and converted to a coherent, printable report at need. In addition to the wiki, the team makes use of development tools, including a versioning system, and collaboration technology such as a shared calendar and instant messaging. The postmortem review scenario: Throughout the project every team member tags elements in the project wiki reflecting what she considers to be important events. The team member decides if the tag is to be visible to other team members. The following postmortem review takes place twice: just before the delivery of a preliminary project report, and before delivery of the final report: Each team member spends an hour going through her tagged wiki contents, modifying the trajectory made up of those elements by visiting wiki pages and adding or removing tags. In a common workshop supervised by a project-external facilitator, each team member gets 15 minutes to present her trajectory, using a projector in the meeting room. The team next discusses the project and how their respective understandings differ. After the mid-term postmortem review, results of the discussion (e.g. conflicting viewpoints, new insights) are documented and actively used in project planning (e.g. changed priorities, changed roles) After the final postmortem review, the team decides on some elements in the wiki that should be included in their common documentation of the project process. The postmortem review in the scenario is designed to reflect acknowledged practice [23], e.g. encouraging individual recall and reflection followed by plenary presentation and discussion, and the creation of a project management report which is later actively used to achieve improvement in the project. The scenario has been evaluated by two expert groups experienced in the supervisor and customer roles in the projects of the course described in Section 3. Here, we only report the main conclusions from the evaluation: The expert groups were positive about the potential of wiki history to be utilized in postmortem reflection on the project process. They were also positive about the potential of the WWT to help a team achieve a more focused review. 6.2. The wiki walkthrough tool functionality A prototype of the WWT was developed during spring 2008. In providing a brief description of the tool functionality in what follows, we take two screenshots as our starting point. Figure 3. Tagging a content page with an existing tag ('todo_historikk') Figure 3 shows a page from a project wiki. This is a DokuWiki into which the WWT functionality has been integrated. The user is browsing the wiki and decides that she wants to tag the particular page revision. She has clicked the Add tags button at the top of the page. In the pop-up window appearing in the middle of the page, the user gets the option of using an existing tag or creating a new one. She picks an existing one, todo_historikk, from the list. When she clicks Save, 8 Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 09:00 from IEEE Xplore. Restrictions apply. 158
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 the page revision will be tagged with todo_historikk. While in the example it is the current revision of the page being tagged, the procedure would have been the same if the user was viewing an older revision of the page and wanted to tag it. When the user chooses All tags or Tag search at the upper right of a contents page like the one in Figure 3, she can proceed to choose a tag and get a report showing the page revisions tagged by it. In Figure 4, the report shows contents tagged with todo_historikk In the report view, for each page, tagged revisions are shown together chronologically. The user may view one or more of the revisions. In Figure 4, three wiki pages have been tagged with todo_historikk. Start has three revisions tagged, but the user has chosen to view only the last one. For the page TODO, the user has chosen to view two of the tagged revisions. In the small window on top of the upper TODO revision, visibility of the revisions can be changed. The third page displayed in this report is the presentasjon_final page revision tagged in Figure 3. Figure 4. Report view showing wiki contents tagged with 'todo_historikk' In the report view there is an option of expanded or compact views of the pages. The user may go directly from to a page revision to explore it further, e.g. follow one of its links. She may later return to the report view. Also, from the report view, the report may be printed. The tool has not yet been subject to evaluation through full-fledged use in a real project. 6.3. Related work on wiki tagging Tagging wiki contents is not a new idea as such. Many existing wiki extensions allow users to impose extra structure on a wiki in order to make it useful in new ways. The use of semantic web enabled technologies to improve navigation and search in a wiki, so called social tagging, has been implemented in SweetWiki [24] and Semantic MediaWiki [25]. Gnowsis [26], a semantic desktop including a wiki, implements the idea of collecting relevant information to reflect a personalized view. The use of structured tagging, including free, personal tagging, to provide personalized access to wiki information for purposes of document management, is discussed in [27]. History or chronology is not in particular focus in the aforementioned systems. However, whereas the opportunities to tag earlier page revisions are only partially addressed in the associated literature, we assume that some existing tagging tools largely cover the functionality proposed for the WWT. Accordingly, from a technical point of view, some existing tool could be used for our purposes, maybe after some minor tailoring. From a usability perspective, we hold that alternative usage of a tool, perhaps involving only a subset of the available functionality and requiring substantial adjustments, might introduce too much noise to meet our high-level requirement for minimal intrusiveness into the work process in which tagging should be a background feature. A tool that deserves particular consideration for its related functionality is WikiTrails [28], designed to help build context and structure around existing wiki contents in an educational setting. The tool makes it possible for a wiki user to leave a trail while browsing the wiki, enabling other users to follow that trail later on. The aim is thus related to ours: building and sharing a story through a sequence of wiki pages. A manual mode is provided, in which pages for a trail may be picked and added by the user, e.g. from a list. Two aspects of WikiTrails make it inadequate for the intended use of the WWT. First, WikiTrails is not designed to support the marking of potentially interesting information element during work activity for possible later incorporation in a trail. Second, WikiTrails provides no support for the generation of a chronological sequence; focus is on generating a trail that will amount to a pedagogically sound presentation of existing wiki contents. A third and minor objection to WikiTrails in our context is that is seems to lack functionality for the tagging of sections within a page, a drawback it shares with the WWT prototype. However, in WikiTrails the opportunity to annotate might compensate for this fairly coarse granularity. In sum, while acknowledging the potential of existing tools to aid the structuring and traversal of wiki contents, we advocate the use of a designated tool for the reconstruction of a project trajectory. 9 Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 09:00 from IEEE Xplore. Restrictions apply. 159
Page 1 and 2:
Birgit Rognebakke Krogstie The work
Page 3 and 4:
Figure 1: Most used terms in the th
Page 5 and 6:
Abstract In project based learning,
Page 7 and 8:
Preface This thesis is submitted to
Page 9 and 10:
Acknowledgements I would like to th
Page 11 and 12:
Contents 1 Introduction ...........
Page 13 and 14:
Research paper P4 135 Research pape
Page 15 and 16:
Figure 17: Support for learning in
Page 17:
Abbreviations CSCL CSCW IS NITH NTN
Page 20 and 21:
The work-reflection-learning cycle
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 37 and 38:
3 Software Engineering student proj
Page 39 and 40:
Software Engineering student projec
Page 41 and 42:
Page 43 and 44:
Page 45:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
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:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
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 and 96:
8 Conclusion and further work This
Page 97 and 98:
Conclusion and recommendations for
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
Page 147 and 148: Example 3. Excerpt from an IM log s
Page 149 and 150: immediate feedback in the heated di
Page 151 and 152: Acknowledgements Thanks to Monica D
Page 153 and 154: Research paper P4 Title: The wiki a
Page 155 and 156: The wiki as an integrative tool in
Page 157 and 158: type of use can be seen as an examp
Page 159 and 160: ecome integration, and we identifie
Page 161 and 162: project. Typically, a clean-up was
Page 163 and 164: 5.1 The wiki as a knowledge reposit
Page 165 and 166: 6. Conclusion We have shown how pro
Page 167 and 168: Research paper P5 Title: Using Proj
Page 169 and 170: Proceedings of the 42nd Hawaii Inte
Page 175: Proceedings of the 42nd Hawaii Inte
Page 179 and 180: Research paper P6 Title: Shared tim
Page 181 and 182: Shared timeline and individual expe
Page 183 and 184: presentation. In 2008, there were 1
Page 185 and 186: congruent’ to sets that seem to o
Page 187 and 188: team members and the co-constructiv
Page 189 and 190: Research paper P7 Title: A Model of
Page 191 and 192: A Model of Retrospective Reflection
Page 193 and 194: 420 B.R. Krogstie Fig. 1. Shared ti
Page 195 and 196: 422 B.R. Krogstie information about
Page 197 and 198: 424 B.R. Krogstie and to express ho
Page 199 and 200: 426 B.R. Krogstie 4.2 The Temporal
Page 201 and 202: 428 B.R. Krogstie in combining them
Page 203 and 204: 430 B.R. Krogstie Fig. 3. A model o
Page 205 and 206: 432 B.R. Krogstie 20. Hutchins, E.:
Page 207 and 208: Research paper P8 Title: Supporting
Page 209 and 210: Supporting Reflection in Software D
Page 211 and 212: 2 Background In this section we bri
Page 213 and 214: There are 3-5 students in the teams
Page 215 and 216: 4 Research Method The research repo
Page 217 and 218: 5 Findings In this section we draw
Page 219 and 220: As a consequence, ‘startup coding
Page 221 and 222: The type of data involved included
Page 223 and 224: potentially negative effects is if
Page 225 and 226: unfolded may shed light on the proc
Page 227 and 228:
5. Lyytinen, K. and D. Robey, Learn
Page 229 and 230:
Appendix B: Other research publicat
show all

The work-reflection-learning cycle - Department of Computer and ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?