Following this observation we prefer using the term ‘artefacts’ in the remainder of this article this also allows us to overcome the perceived ravine between agile and old-fashioned documentation. This definition equates (minimum) documentation and simple artefacts, opposing the both to the comprehensive documentation of the Agile Manifesto. 2009) in their description of the connection between documentation and artefacts in ASD as “ Documentation is kept to a minimum, in favour of close collaboration, and simple artefacts”. 2009), but allows in fact for a much broader spectre of artefacts. This definition certainly includes physical artefacts, such as story cards and the Wall (Sharp et al. We define an artefact, in line with previous research, as a tangible deliverable produced during software development, including materials in both physical and electronic format (Wagenaar et al. More in particular not only traditional and agile software development processes are blended, but also elements from them, especially artefacts. ( 2016) describe a reference model for hybrid traditional-agile software development methodologies. Bustamante and Rincón ( 2017) developed the WYDIWYN (What You Define, Is What You Need) model to define agile and traditional methodologies oriented to what a company needs, simplifying the identification, correlation and selection of phases, roles, tasks and work products among different frameworks Gill et al. Models have emerged to describe combinations of traditional and agile methodologies. This result is further supported by a survey outcome, where approximately 75% of the participants answered that they (intentionally) combine different development approaches (Kuhrmann et al. Instead developers find documentation important but at the same time observe that too little of it is available in their projects.ĭespite the fact that documentation usage in agile software development (ASD) has a somewhat ‘old-fashioned’ connotation, recent research has shown that traditional software development approaches and ASD are being blended in a hybrid approach among the different combinations, Scrum, the classic Waterfall model, and V-shaped processes account for the majority (Kuhrmann et al. However, Stettina and Heijstek ( 2011) concluded: “ Agile practitioners do not seem to agree with this agile principle” ( p. The Agile manifesto itself values “ working software over comprehensive documentation” and emphasizes “ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Research thus continued, but five years later a research gap with regard to the implications of agile information system development on the coordination, collaboration and communication mechanisms within agile teams was still noted (Hummel, 2014). Yet at the same time “ exciting research areas that can further our understanding of the effectiveness of agile methods and practices” ( p.1219) were still identified, among which not the least one: the ‘core’ of agile. After half of this period, some 7½ years after its inception, the research community had lavished attention on issues related to agile software development (Dybå & Dingsøyr, 2008). Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation.įifteen years have passed since the Agile Manifesto (Beck et al. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) team-internal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. However, explicit rationales for using them remain unclear. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. Still, recent research has shown agile teams to use quite a number of artefacts. Agile software development (ASD) promotes working software over comprehensive documentation.
0 Comments
Leave a Reply. |