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

More documents

Recommendations

Info

community, however, Ethan always convincingly represented the team and their work. Third, illustrating the previous point, no one in the team but Ethan actually took any initiative towards the PLENTI community. It was not until the lead programmers decided that something must be done about the lack of PLENTI skills and usage in the project, that effective interaction happened. In our case, it took a programmer not only to undertake the role as broker, but also to understand that someone needed to take that role. 6.1.3 The credibility gained through OSS participation Being acknowledged as a participant in a developer community is likely to add to the self consciousness of the participant. When a contribution is met by a response in a forum, the community membership of the contributor is acknowledged. When a contribution is openly praised in the forum, the skills of the participant are implicitly valued, and his credibility in the forum is maintained or strengthened. If the participant is relatively inexperienced and do not already participate actively on several related arenas, the newly earned credibility is likely to be a source of pride and increased self confidence. Also, the credibility won can be demonstrated to others outside the community, adding to credibility and strengthening authority there as well. From our case, we draw some illustrative points: In Exhibit 4, the last response from Bernhard to Ethan includes the following: “Wonderful! Several people have asked for it in the past, it would be a very welcome contribution to the project.” The contribution of Ethan and the team is thus publicly acknowledged as something relevant and welcome. The positive response was referred to by Ethan on later occasions, e.g. in customer meetings. In team-internal conversation, Ethan on some occasions talked of Bernhard almost as if he was a buddy, using his first name. Ethan also pointed out to the team how quick Bernard was at providing them with response, and often outside of normal work hours. Ethan’s pride in the engagement of the team with the PLENTI developer community was very visible whenever the project was accounted for in meetings with supervisor or customer in the last part of the project. On one hand, referring to ongoing successful interaction with the PLENTI community served as a way of ensuring project stakeholders that the project was in fact progressing. On the other hand, it may be seen as a way of assuring the stakeholders that the team were competent, doing development work of a standard acceptable to the framework developer community. Finally, whereas the fourth phase of OSS interaction, contributing to the framework, might not have been strictly necessary for the team’s development task, it might have benefited the development task indirectly: Ethan’s positive attitude towards contributing to the PLENTI development might have inspired Bernhard to give better, faster or more elaborate response. 6.2 OSS community participation aided by a broker: Benefits and pitfalls for SE projects Turning focus to what we see as benefits and pitfalls of having student SE teams acquire knowledge from OSS communities, we give a final account of the impact of OSS community involvement on the Anniva team, looking at their project more broadly. The team succeeded with their development task, producing a working system by active use of advice received from the OSS community. On the other hand, the project report suffered from a lack of attention from the programmers. The poor quality of the report was a main reason for the project receiving a B and not an A, according to course staff in the grading meeting. It is only a guess that the team in our case would have been no more concerned about the project report if they did not have to interact with an OSS community. The focus on programming (at the cost e.g. of developing models and documentation) might be seen as a consequence of a lack of experience and maturity in terms of project management, or as a legal choice of prioritizing what was to the team the essence of the project. In respect of the team postponing the work with design and architecture modeling, it is worth noting that the PLENTI framework can be seen as an example of a third party software component, unfamiliar to the team and poorly documented, which implies a realistic SE challenge of determining when to attempt to develop an overall design and when to start using the component [6]. Communicating in the OSS forum appeared to be a gratifying experience for the broker. The team was vulnerable to his absence, but that problem never occurred. Also, our observations indicate that the broker shared his knowledge from the OSS forum with the rest of the team in an open and effective way. It is difficult to say if he spent too much of the project time in the forum, or if the team spent too much time on programming tasks based on the results of the interaction. The fact that the interaction took place only in the last part of the project, indicates a limited use of project time. Also, the team’s interaction with the OSS community having to do with changes to PLENTI constituted only a small part of the interaction. Finally, these discussions were closely related to pertinent development tasks in the project. The fact that Ethan did not mention in the individual reflection note his role in the communication with the PLENTI community, might indicate that he did not consider it as something requiring a substantial part of his time or being very important to the project, but there may be other reasons why he did not mention his brokering role. As for the power of the broker, Owen (on reading a draft of this paper) expresses uncertainty about how much power Ethan gained through his gatekeeping role. Owen had not until now reflected much on the importance of the interaction with the PLENTI community. It may be the case that Owen and Ethan take their successful OSS community interaction for granted, underestimating the communication skills actually required. Finally, balancing our previous focus on the significance of OSS participation to the team, we should note that communicating with the PLENTI community was one out of several activities important to the project. The power structures in the team may be seen to have mirrored the complementary skills and interests of the two lead programmers, which ensured a certain balance in power between the two. Nevertheless, given our findings, our interpretation is that the team, and the broker in particular, were both challenged and inspired by the fact that they were participants in, and contributors to the PLENTI OSS community and considered it an essential part of their project experience. Leaving the story of the auctioning system project, we now turn to what we see as more general benefits and pitfalls – in terms of a good project result - for student SE teams in need of interacting with OSS communities as part of their development work. 798 116
6.2.1 Benefits for SE student projects interacting with OSS communities In line with arguments from others’ research, we hold that OSS community participation is a realistic aspect of modern SE work. The management of such interaction should be regarded as highly relevant industry SE experience. If the team interacts with an OSS community, part of the experience is shared by the whole team. The broker in particular may learn a lot about how to achieve successful communication and acquire relevant knowledge in an OSS community. A broker whose authority and importance in the team is acknowledged by the team is likely to take pride in his position as a knowledge provider and thus be strongly motivated to contribute to the project result. If the broker further experiences that he earns credibility on the OSS arena, being recognized as a proper participant there, he might want to make his contribution more substantial and visible, which may again benefit his team. 6.2.2 Pitfalls for SE student projects interacting with OSS communities Student SE teams may hesitate to embark on interaction over technically challenging issues in a type of community unknown to them, the students being in doubt about their own skills and credibility. This may cause problematic project delays. Also, attempts to interact with an OSS community may turn out to be nonsuccessful if the team does not manage to convince the community that they represent ‘real’ users and development issues and thus qualify as potential contributors. To a team inexperienced in project management, interaction in an OSS community may pose great challenges because it involves an extra external stakeholder and may be perceived as even more out of control than other programming related activity. OSS community participation can be used as an excuse to spend time on the wrong tasks from a project management point of view. Having an alternative arena for gratifying response and acknowledged participation might lead a programmer to focus too narrowly on certain programming tasks related to that arena. Brokering may be performed in an inadequate way: A broker unable or unwilling to share relevant knowledge with the team, or mainly representing other interests than those of the team in the OSS community, stands in the way of a good project result and everyone’s learning. Further, there is a risk associated with having only one broker – both in case of inadequate brokering and in the case of sudden absence of the one broker. 6.3 Implications for the pedagogy of SE project courses An implication of the work presented in this paper is that course staff responsible for SE project courses should pay particular heed to SE student projects requiring interaction with OSS communities for development-related knowledge acquisition. These projects hold a potential for industry-relevant experience but at the same time hold some challenges. Course staff should be aware of benefits and pitfalls inherent to this type of project. Further, awareness of the mechanism of brokering and the potentially influential role of the broker(s) in the projects may aid a supervisor in determining what advice to provide on project management and process issues. Part of the charm of industry projects is that they are very diverse. Having used our in-depth single case study to derive issues we believe to be generally relevant to student projects interacting with OSS communities as a resource in their development work, we would like to stress that the particular challenges of OSS participation in one project may be very different from those in another. Considerations over project management and supervision must always be made in the light of the particular characteristics of the specific project. In this respect, the project supervisor will always benefit from having experience with the approaches and domains relevant to the project. In the type of project of our current focus, some background within OSS development or research is likely to be an advantage to the supervisor. In a situation in which many of the projects in a course include OSS community participation, the overall organization of the course may be designed to reflect this particular focus. For instance, lectures may be given on how OSS communities work. Each project’s interaction with the OSS community may be more explicitly used as a learning resource, e.g. by being examined and discussed within and across teams. Further, the OSS community interaction of a team should be considered as a learning result (or documented part of the project process) and assessed and credited by course staff, e.g. in the grading of the projects. 6.4 Limitations to the study Drawing on a single case, our findings may be seen as closely related to its particular characteristics. Still, we believe findings from our study on the role of the broker have general relevance to SE student projects interacting with OSS communities. An important characteristic of the OSS community of our case is its small size, which may be seen as a condition for the rapid entry of the student team into OSS development contribution. Arguments about the empowerment of the broker however apply even if OSS community participation is restricted to the user role. Finally, our research explored a student team. Our findings may have some relevance to teams of SE professionals, but differences between these categories of SE teams should be considered. These include the level of competence in project management in the team, and the formalized learning goals of a project course which are not found in industry and which impact on how we wish to guide the SE student teams through project supervision. 7. CONCLUSION In this study, we set out to gain insights on mechanisms enabling a SE student team to successfully interact with an open source community and on possible pitfalls and benefits of the engagement in terms of project success. We have done so by pointing to the role of the broker and how this role implies increased authority and influence in the team for several reasons and with several possible consequences, positive and negative. We hope that our contribution will inspire SE course staff and others involved with SE student projects to build on our work with reference to their own experience. Continued focus on work and learning in SE student projects involving OSS community participation should result in empirically based research contributions for us all to share, with the aim of improving current pedagogical practices. Further work may look at the implications of the type and sizes of the OSS communities for student teams’ involvement there. Also, the relevance of OSS participation in student SE projects to similar 799 117
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: Getting from the second to the thir
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 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?