Lade Inhalt...

Using eXtreme Programming in a Student Environment

A Case Study

Masterarbeit 2010 134 Seiten

Informatik - Programmierung

Leseprobe

Contents

1 Introduction

2 Background
2.1 Introduction
2.2 Students Programming Background
2.3 Evaluative Research
2.3.1 Surveys and Interviews
2.3.2 Observation
2.3.3 Tools
2.4 Case Study
2.4.1 History of Case Studies
2.4.2 Description of Case Studies
2.4.3 Qualitative versus Quantitative Methods
2.4.4 The use of Case Study in the Experiment
2.5 eXtreme Programming in a nutshell
2.5.1 An overview of eXtreme Programming
2.5.2 Applying eXtreme Programming in a Student Project Environment
2.6 Review

3 The analysis model
3.1 Introduction
3.2 Hypotheses
3.3 Survey 1
3.3.1 Introduction
3.3.2 Terms of reference for Survey
3.3.3 Items of Survey
3.3.4 Summary
3.4 The tools
3.5 The observation protocol
3.5.1 Introduction
3.5.2 Terms of the observation
3.5.3 The measurement of each observed practice
3.5.4 Summary
3.6 Survey 2
3.6.1 Introduction
3.6.2 The terms of reference of Survey
3.6.3 Items of Survey
3.6.4 Summary
3.7 The sample
3.8 Summary

4 Empirical Study
4.1 Introduction
4.2 Survey 1
4.2.1 Introduction
4.2.2 Evaluation
4.2.3 Conclusion
4.3 The Tools
4.3.1 Introduction
4.3.2 Evaluation
4.3.3 Conclusion
4.4 The observation protocol
4.4.1 Introduction
4.4.2 Evaluation
4.4.3 Conclusion
4.5 Survey 2
4.5.1 Introduction
4.5.2 Evaluation
4.5.3 Conclusion
4.6 Summary

5 Result by practices
5.1 Introduction
5.2 Sit Together
5.3 Informative Workspace
5.4 Energized Work
5.5 Pair Programming
5.6 Stories
5.7 Weekly Cycle
5.8 Slack
5.9 Ten-Minute Build
5.10 Continuous Integration
5.11 Test-First Programming
5.12 Incremental Design
5.13 Shared Code
5.14 Code & Test
5.15 Single Code Base
5.16 Negotiated Scope Contract
5.17 Final Comments

References

A. Appendix List of abbreviations

B. Appendix The project specification

C. Appendix Survey 1

D. Appendix The Observation Protocol

Week 1

Week 2

Week 3

Week 4

Week 5

All 5 weeks

E Appendix Survey

F Appendix The CVS Log Files

Week 1

Week 2

Week 3

Week 4

Week 5

All 5 weeks

G. Appendix Summary of the meeting 050309 16:00-17:45

List of figures

Figure 2.1 The 2004 computer engineering curriculum at the University of Karlstad

Figure 2.2 Six sources of evidence: Strengths and Weaknesses taken from Yin [24 ]

Figure 2.3 Convergence of Evidence taken from Yin [24]

Figure 2.4 Non Convergence of Evidence taken from Yin [24]

Figure 3.1 Project timeline and action events

Figure 3.2 Distribution of the students' age

Figure 4.1 Responses to survey 1 item 2

Figure 4.2 Responses to item 3

Figure 4.3 File count during the project phase

Figure 4.4 Average file sizes during the project phase

Figure 4.5 Anonymous quotas of the students’ add and modify transactions

Figure 4.6 Responses on item 1

Figure 4.7 Responses on item 3

Figure 4.8 Responses on item 4

Figure 4.9 Responses on item 5

Figure 4.10 Responses on item 7

Figure 0.1 Day Commits: Week 1

Figure 0.2 Time Commits: Week 1 average

Figure 0.3 Day Commits: Week 2

Figure 0.4 Time Commits: Week 2 average

Figure 0.5 Day Commits: Week 3

Figure 0.6: Time Commits: Week 3 average

Figure 0.7 Day Commits: Week 4

Figure 0.8 Time Commits: Week 4 average

Figure 0.9 Day Commits: Week 5

Figure 0.10: Time Commits: Week 5 average

Figure 0.11 Day Commits: Average for all weeks

Figure 0.12 Time Commits: Average for all weeks

List of tables

Table 2-1 Primary practices, the aspect of the practice and whether applied or not

Table 2-2 Corollary practices, the aspect of the practice and whether applied or not

Table 3-1 Weighted Average Example

Table 3-2 Three Category Scale

Table 3-3 Evaluated practices and their evaluation method

Table 4-1Weighted mean values for survey 1 item 2

Table 4-2 Weighted mean values for item 3

Table 4-3 Comparing the understand & the applicable mean values

Table 4-4 Responses on item 5

Table 4-5 CVS transactions

Table 4-6 File types in the CVS

Table 4-7 Practices applied per week in words and numerical values

Table 4-8 Survey 1 item 2 compared to the protocol of the observation and the tools

Table 4-9 Mean value of item 1

Table 4-10 Mean value of item 3

Table 4-11 Comparison of Survey 2 Item 4 and, the observation and tools

Table 4-12 The mean value of item 5

Table 4-13 Responses on item 7

Table 4-14 Comparing Survey 1 with Survey 2

Table 0-1 Responses to Survey 1

Table 0-2 Recommended practices, used or not: Week 1

Table 0-3 Average hrs/day: Week 1

Table 0-4 Recommended practices, used or not: Week 2

Table 0-5 Average hrs/day: Week 2

Table 0-6 Recommended practices, used or not: Week 3

Table 0-7 Average hrs/day: Week 3

Table 0-8 Recommended practices, used or not: Week 4

Table 0-9 Average hrs/day: Week 4

Table 0-10 Recommended practices, used or not: Week 5

Table 0-11 Average hrs/day: Week 5

Table 0-12 Recommended practices, used or not: All Weeks

Table 0-13 Average hrs/day: All Weeks

Table 0-14 Responses on Survey 2

1 Introduction

This project is the result of a case study as to whether or not the ideas of eXtreme Programming may be taught in the undergraduate curriculum. The increasing adoption of agile methods [80] and eXtreme Programming [20] in industry means that these methods should be introduced to students as part of their education. The question is how best to achieve this.

It is a point of discussion as to how eXtreme Programming may be taught to students in a University. This thesis addresses this question by analyzing a student lab exercise for the Software Engineering course in the Department of Computer Science at Karlstad University by means of a case study. The main goal of this case study was to measure certain (15) eXtreme Programming practices realizable in a student environment [appendix G] by means of surveys, analysis of archival information from programming tools and direct observations of the students. However, this thesis aims further by analyzing the success or failure in teaching the 15 eXtreme Programming practices and in giving ideas to improve this process.

This thesis consists of 4 chapters. Chapter 2 presents the background information such as the external circumstances of the course, basics about evaluative research and case studies as well as eXtreme Programming. Thereupon, chapter 3 defines the analysis model used in the empirical study in chapter 4 and introduces the items set up for the study and allocates them to the different data sources. Chapter 4 shows the students’ responses to the surveys, evaluates all data sources and combines these results for an interpretation of this learning process. Finally, chapter 5 compares these results with the 15 eXtreme Programming practices and to related work in order to give recommendations for future courses in this area.

2 Background

2.1 Introduction

This chapter introduces topics and methods that are required to read and understand this thesis.

In the first section the students’ background on programming skills is introduced. This is followed by an introduction on evaluative research. The tools from the toolbox of evaluative research which have been applied in this project are introduced. The procedure model used is then presented. To complete the procedural overview the next section is about case studies. The case study methods used in this dissertation are briefly introduced. Furthermore it is explained how the evaluation tools fit into the case study research methodology. The last section of this chapter introduces eXtreme Programming to the reader. The reader is required to know some key facts about eXtreme Programming to be able to understand the analysis of the course performed in this dissertation. Finally as a complement to the first section of his chapter follows an introduction to how eXtreme Programming is taught at Karlstad University and what the level of the students’ knowledge about eXtreme Programming was before they attended the course.

2.2 Students Programming Background

The programming background of those students who attended the course which was evaluated in this dissertation is introduced. This information is given in the form of the programming courses that the students had already taken. The curriculum of the students’ first two years is presented in Figure 2.1. This curriculum is of interest since the course evaluated in this project is a second year course.

illustration not visible in this excerpt

Figure 2.1 The 2004 computer engineering curriculum at the University of Karlstad

All courses on programming are indentified by an orange rectangle. As Figure 2.1 shows the students had 4 courses on programming before they attended the course on eXtreme Programming (CIT B02 red rectangle on the bottom right of Figure 2.1). From this, the students may be classified as intermediate programmers In addition to their current knowledge, the students were required to learn an entire new infrastructure (tools the students have not used before) as well as the ideas behind eXtreme Programming.

2.3 Evaluative Research

The main methods used in this dissertation are taken from the area of evaluative research. According to Bortz & Döring [24], Rossi & Freeman [34], Weiss [35], Wittmann [36] and Thierau & Wottawa [37] evaluative research is a variation on empirical research methods, applied to a particular group of questions. Modern evaluative research has its roots in the 1930s in the USA where it was applied to analyze programs, interventions and arrangements in the health care and the education system[1].

Since evaluative research is a very wide topic, this section is only about those parts, used in the research for this thesis. During this research, some tools out of the toolbox of evaluative research have been used. These tools were:

a) Survey; two surveys that have been filled in by the student group.
b) Observation; an observation on the student group.
c) Analysis of log files; The log files of the tools the students used in their project

Due to the fact, that these tools have the purpose to gather data they can be understood – following Yin [23] - as data sources or, as Yin [23] calls them sources of evidence. The strengths and weaknesses of the different data sources, according to Yin [23], can be found in Figure 2.2 In the following sections all applied data sources are explained in detail.

illustration not visible in this excerpt

Figure 2.2 Six sources of evidence: Strengths and Weaknesses taken from Yin [24 ]

illustration not visible in this excerpt

Figure 2.3 Convergence of Evidence taken from Yin [24]

illustration not visible in this excerpt

Figure 2.4 Non Convergence of Evidence taken from Yin [24]

Figure 2.3 & Figure 2.4 show that, according to Yin [23], there exist 2 different ways of interpreting data sources that have been analysed during research. The first one – in this case convergence of evidence – builds the evidence based on different data sources whereas the second one derives a conclusion from every single data source. In this thesis, the way described in Figure 2.3 has been applied. All sources of evidence – described in the next sub sections – are used to find one fact about an item. The detailed procedure can be found in chapter 3 where the analysis model is introduced in detail.

2.3.1 Surveys and Interviews

The Survey in this dissertation is regarded as a special kind of interview. An advantage of the survey is that surveys are performed without interviewer control. This can be understood as an advantage since any influence by the interviewer can be minimised. Another relevant advantage, in the context of this thesis, is that it is an economical way to perform an interview. All disadvantages mentioned in Bortz & Döring [24] may be neglected. These disadvantages are:

- Influence by the appearance of the interviewer (who)
- Influence due to different point of time of the interview of each respondents (when)
- Influence by different surroundings of the interview of each and every respondent (where)

These disadvantages may appear if the respondents do not answer the survey under the same circumstances. This means the respondents have to answer the survey at the same time in the same room to avoid influence from other respondents and other outside influences.

The survey as a method has been chosen since surveys are meant to gather data about the students’ state of mind regarding their knowledge about eXtreme Programming, its practices and their interest in applying eXtreme programming during the students’ practical project. Details about how the surveys have been set up can be found later in this document in Chapter 3 where the whole analysis model is introduced.

2.3.2 Observation

In this research the observation method was chosen as instrument with the goal of evaluating whether the students did apply a certain practice or not. This means - according to Bortz & Döring [24] the qualitative approach has been chosen. This corresponds to the following criteria presented in Adler & Adler [41]

- Observation in the natural surrounding (in this case the classroom)
- Active interaction of the observer
- Focusing on larger units, systems and behaviour patterns instead of focusing on small variables
- Open for new input and not focused on an observation schema

The last point might sometimes be hard to follow since the observers in this project had to fill in an observation template which focused on the 15 practices used in the project. More about these practices can be found in the section 2.5. Regarding the last point it needs to be mentioned that not only the fixed observation schema is evaluated since the observers wrote a small diary for every day and analysed this diary with focus on the questions, defined in chapter 3 where the whole analysis model is introduced.

2.3.3 Tools

Tools are source of evidence for every case study. According to Yin [23] the tools themselves are not to be seen as source of evidence. The tools deliver artefacts – in this case called archival records – that can be seen as evidence for the evaluation. According to Yin [23] examples for archival records include:

- “Service records, such as those showing the number of clients served over a given period of time
- Organizational records, such as organizational charts and budgets over a period of time
- Map sand charts of the geographical characteristics or layouts of a place
- Lists of names and other relevant items”

Yin [23] states that archival records do show one criterion that is relevant for case studies, namely that the archival records will never be similar if you run a project twice.

2.4 Case Study

Numerous definitions of a case study may be found but for this research the definition according to Yin [23] has been applied. According to Yin [23] a case study is one of several methods developed in social science research. Another definition according to Merriam [6] is that a case study is an “investigation of a specific occurrence, e.g. a program, an event, a person, an institution or a social group.” This section is giving an overview over the history of case studies, what a case study can be, what different characteristics a case study can have.

2.4.1 History of Case Studies

Case study research is historically marked by periods of intense use and periods of disuse. According to Tellis [7] the earliest use of this form of research can be traced to Europe, predominantly to France. The fields of sociology and anthropology are credited with the primary shaping of the case study concept as we know it today (see Barnes, Conrad, Demont-Heinrich, Graziano, Kowalski, Neufeld, Zamora, and Palmquist [9]). However; case study research has drawn from a number of other areas as well, such as:

- the clinical methods of doctors
- the casework technique being developed by social workers
- the methods of historians and anthropologists
- the qualitative descriptions provided by quantitative researchers
- the techniques of newspaper reporters and novelists.

2.4.2 Description of Case Studies

Apart from the definition at the beginning of this chapter, a case study can also be described in terms of its special properties. The properties that are relevant to this research project are, taken from Merriam [6]:

- Particularistic: Means that a case study “focuses on a certain situation, event, occurrence or person.” This reflects the definition of case study mentioned earlier.
- Heuristic: Means that it “can improve the readers understanding of the occurrence that is being studied”

In contrast to other designs of experiments, surveys and history research, case studies do not have any special methods for collecting or analyzing information (data). All types of methods for collecting scientific data, from observation to interview and survey, can be used in a case study.

2.4.3 Qualitative versus Quantitative Methods

According to Barnes et al. [9] qualitative and quantitative methods are usually used in conjunction with each other. Typically qualitative data uses words and pictures while quantitative data uses numbers to describe what the researcher has extracted from what the researcher studied. Another major difference between the 2 is that qualitative research is inductive, i.e. it evolves abstractions, concepts, hypotheses and theories, while quantitative research is deductive, i.e. reaches to test already existing theories. In qualitative research, a hypothesis is not needed to begin research. However (according to Barnes et al., [9]), “all quantitative research requires a hypothesis before research can begin.”

2.4.4 The use of Case Study in the Experiment

It was decided to perform this experiment as a case study since this research did not require control of behavioural events but focused on contemporary events. These characteristics are, according to Yin [23], typical for a case study as research method. As can be seen in section 2.4.3, the boundaries between qualitative and quantitative case studies are clear, and in this experiment both will be used.

The following data gathering methods have been used:

- Observation is used here as a qualitative method. Due to the typical characteristics of observation this makes the case study particularistic and heuristic. Particularistic due to the investigation of the students group and heuristic due to the analysis of the students’ understanding and acceptance of the eXtreme Programming practices. More details about the definition of particularistic and heuristic can be found in section 2.4.2
- Surveys: the survey is used here as a quantitative research method. It asks the same questions of the different people in a group and delivers a variety of impressions under the same circumstance. For instance if you ask a group of people using a 5 category response scale (++/+/0/-/--) the same question, the answers are still liable to be different based on individual impressions.
- Archival records are used here as a qualitative research method. This is a analysis of historical data that has been collected during the experiment. It is, according to Bortz & Döring [24], very important to exclude interpretations as much as possible, to ensure that only hard facts have been taken into consideration.

2.5 eXtreme Programming in a nutshell

The purpose of this section is to present a quick introduction of eXtreme Programming to the reader. This starts with the history of the origin of eXtreme Programming, followed by an introduction on the basic idea behind eXtreme Programming. There then follows a description which shows the relevance of eXtreme Programming to student programming and industry applications

The section is completed by a short walk through the points of interest of eXtreme Programming to this research.

2.5.1 An overview of eXtreme Programming

eXtreme Programming is a lightweight programming methodology that, according to [75], supports a team by writing software that contains fewer bugs and therefore takes shorter time. This methodology consists of several values, principles and practices to be considered. Some of these must be applied by the whole company, some by the team and most by each and every member of the team. The 2 essential aspects of eXtreme Programming are

1. short term and very specific programming goals
2. an awareness of the social aspects of programming

The first edition of Beck [1] was published in October 1999. In effect, eXtreme Programming originated in this first edition. Over the years eXtreme Programming has been applied by a number of programming teams and several books have been written on the subject. Many companies (see [20]) applied the process given by Beck and realized that in their experience eXtreme Programming is a very good and efficient way to create software. eXtreme Programming is a process and has a number of practices that are used to reach a project goal. The eXtreme Programming process also includes a philosophy of software development which is based on 5 values, namely; communication, feedback, simplicity, courage and respect. To integrate these values into eXtreme Programming, Beck received help from a psychologist, Cynthia Andres. This was in order to show that eXtreme Programming is not only a new style of programming or a new idea, but also a process that deals with the social behaviour of the whole team and more or less of the whole company. Beside the 5 values, eXtreme Programming uses 24 practices and 13 principles. A detailed explanation of these values, principles and practices can be found in Beck [2]. In the second edition of eXtreme Programming Beck [2] published in 2004 some minor and some major modifications in the process. One major modification was that the developing team should select the practices they really need for the project and exclude the remaining practices. This approach was new, since in the first edition of eXtreme Programming Beck [1] Beck’s opinion was that the team has to apply all practices. To offer the practices in a different way Beck divided the practices into primary and corollary practices where the primary practices are independent of the corollary practices. The corollary practices are, according to Beck, difficult to use without first mastering the primary practices. This might be caused by the enormous change of behaviour the corollary practices require from the whole team and in some cases even from the whole company. Beck is not trying to give one defined way to apply eXtreme Programming into a team; rather he wants to give some directives to the team from which the developer is able to take what he requires to become a better team member and developer.

2.5.2 Applying eXtreme Programming in a Student Project Environment

This research shall bring up whether eXtreme Programming can be taught in a project like the applied system construction project or not. Therefore it needs to be analysed if the teaching that took place in advance to the project was sufficient so that the students felt prepared enough to apply certain practices of eXtreme Programming during the project.

The teaching took place in a course called “Tillampad systemkonstruktion” (Eng. Applied System Construction) where the students were taught the basic ideas of eXtreme Programming. As can be found in Figure 2.1 this course took place exactly before the applied system construction project was started. For further information about the applied system construction project see Figure 2.1

Table 2-1 and Table 2-2 all eXtreme Programming practices are listed. All these practices where taught at the projects preparation course. The students have been asked to apply only the practices that show a “yes” in the column named applied. That seems not to be a problem since Beck says in [2] that there is no need to apply all given practices. The decision what practice the students were asked to apply and what practices the students were not asked to apply was taken by the teachers of the course. The teachers justified their decision by the circumstances given, by a simulated project.

illustration not visible in this excerpt

Table 2-1 Primary practices, the aspect of the practice and whether applied or not

The numbers in the column called “Aspect” are to be understood as follows:

1. short term and very specific programming goals
2. an awareness of the social aspects of programming

illustration not visible in this excerpt

Table 2-2 Corollary practices, the aspect of the practice and whether applied or not

The last question to think about is why might eXtreme Programming be interesting to students? The authors opinion regarding this question is that there are 2 answers. The first is to improve the quality of the students’ programming. Secondly, there is another reason why attending such courses like the one about eXtreme Programming is interesting to students. It is the need within industry for employees that are skilled with new methodologies and philosophies. Usually it takes some years until a new software development philosophy enters companies. This is caused by some kind of approval process so that the companies are able to filter the useful innovations from non-useful methods. Whenever a company decides to start working following new principles the whole company spirit needs to be adapted and with this all business processes need to be changed. This is very expensive and it becomes even more expensive when it comes to the employee training. All this is much cheaper and easier when a company is able to speed this process up by bringing in new employees who already know the new methodology and have some relevant experience. So the new employees become experienced employees and are able to help the company not to make mistakes which may occur while a methodology like eXtreme Programming is introduced.

2.6 Review

The purpose of chapter 2 was to let the reader aware of the necessary background to the methods and principles of the research and of what has been researched. Transferring this declaration to the concrete thesis the reader should now know the relevant ideas of:

- The students background on programming
- Evaluative research
- The tools (survey, observation, archival records) that have been applied in the research
- Case Studies
- Qualitative and quantitative methods
- eXtreme Programming
- The students background on eXtreme Programming

3 The analysis model

3.1 Introduction

The student project course was as follows. A lecture on eXtreme Programming was held in the first place. The author attended this lecture to receive an impression about the content of the student project course. Following this lecture, Survey 1 was filled in by the student group. This first survey represents the first data source gathered for evaluating the student project course. After the survey was filled in and in correlation to the lectures, the student project started. The student project lasted 5 weeks and the students’ only task was to apply eXtreme Programming. During these 5 weeks a permanent observation was carried out and recorded as a protocol. This protocol represents the second data source analyzed for the evaluation of the course.

illustration not visible in this excerpt

Figure 3.1 Project timeline and action events

At the end of the student project, the students had to fill in the second survey. For the evaluation, the analysis phase started. The second survey represents the third data source that exposed the students’ view on the observation performed by the author. The last phase in this dissertation study was the analysis of the log files generated by the tools used by the students during the student project. These log files serve as last data source. Figure 3.1 illustrates the data sources (orange items: surveys 1 and 2, the observations and the log analysis) and other relevant parts on the timeline.

In Chapter 3 the data sources are explained in detail with special attention to their content and the significance. Furthermore, chapter 3 highlights how the data sources are evaluated and how the results may be interpreted. In addition, chapter 3 introduces the hypothesis that supports the evaluation of the course. The data analysis is presented in chapter 4.

3.2 Hypotheses

The goal of the thesis is too great to be proven by one data source. As a result of this aspect small milestones have been developed to prove small parts and at the end put together to create a high level view. According to that assumption, for each main data source, a hypothesis has been derived. These hypotheses are proven by not proving the corresponding null hypotheses. The following hypotheses and their null hypotheses have been set up:

(1) Survey 1: Hypothesis H S1

Hypothesis HS11: A student group that has attended the theoretical sessions on eXtreme Programming understands the practices well.

Null hypothesis HS10: A student group that has attended the theoretical sessions in eXtreme Programming does not understand the practices well.

This hypothesis reflects one of the key issues in Survey 1 and is tested in the evaluation of Survey 1.

(2) Observation: Hypothesis H O1

Hypothesis HO1: The attitude a student has towards an eXtreme Programming practice has an influence on how eXtreme Programming will be applied during the practical project.

Null hypothesis HO0: The attitude a student has towards an eXtreme Programming practice has no influence on how it will be applied during the practical project.

This hypothesis – derived from the content of the project – is tested by evaluating the observation as it is possible to see how a student applied the practices.

(3) Survey 2: Hypothesis H S21

Hypothesis HS21: The student groups’ self evaluation about the level of application of an eXtreme Programming practice will match the groups’ real behaviour.

Null hypothesis HS20: The student groups’ self evaluation about the level of application of an eXtreme Programming practice will not match the groups’ real behaviour.

This hypothesis proves whether the students’ self evaluation matches their observed behaviour or not. Survey 2 serves in testing this last hypothesis.

3.3 Survey 1

3.3.1 Introduction

Survey 1 collects information about the students’ standard of knowledge regarding the 15 eXtreme Programming practices after the students had attended the theoretical sessions. It asks the students to self verify their knowledge about eXtreme Programming. This verification has to be done in the 5 categories explained later. Survey 1 also asks the students how well they think the certain practice is applicable in the student project and if the students are willing to embrace eXtreme Programming in this project. These questions aim to evaluate the students’ attitude towards eXtreme Programming and its practices. Moreover, Survey 1 takes a snapshot of the students’ attitude towards the structure of the course. The question regarding the structure of the course is repeated in Survey 2 to see whether the students’ attitude towards the structure of the course changed after performing the student project.

3.3.2 Terms of reference for Survey 1

Since eXtreme Programming is a process that needs to be experienced by the whole project team. The focus has been moved from the individual to the group. Keeping that in mind, Survey 1 has been planned and executed on the assumption that the group will be analyzed as a whole. For that reason, the group response to each of the questions is taken to be the weighted mean [81] of the individual student responses.

In the survey, there are 2 types of response scales. The first one has 5 respective labels: Very Well (1); Well (2); Neutral (3); Not Well (4); Not Well At All (5). The scale is based on the Likert-Scale [31], [82] were the most equidistant style according to Rohrmann [30] and Wyatt & Meyers [29] is chosen.

For the first scale, the 5 point scale, the weights for each category are given in parentheses - Very Well (1); Well (2); Neutral (3); Not Well (4); Not Well At All (5). For question 1 of survey 1 this leads to a weighted mean value of 2.3. I.e. ((1*0) + (2*7) + (3*3) + (4*0) + (5*0))/10 where 10 is the number of responses. This value is interpreted as being a single point value for the student group response. These values for the group response may then be interpreted within the 5 categories by defining a range for each category as shown in Table 3-1

illustration not visible in this excerpt

Table 3-1 Weighted Average Example

The group response to the question “How well did you understand all practices” was thus “Well”. Note that the lower the value of the weighted average, the better the response.

The second response scale consists of the options Yes (1) and No (2). This is according to Grosse & Wright [32] objectively analyzable if the answer is in the categories Yes or No. This approach has been chosen according to Bortz & Döring [24], to force the students to make an either or decision.

Survey 1 was written in English together with a native English speaker and a native Swedish speaker in order to minimize the possibility of misunderstandings caused by differences in culture and language. Therefore, no language or cultural support like Haeberlin [28] mentioned in Bortz & Döring [24] was required.

3.3.3 Items of Survey 1

The items listed in this section and their purpose is presented in order to be able to explain the relationship of the items to the experiment as a whole. The word item is chosen since some items consist of several questions. The aim of the survey was to get a snapshot of the of the student’s self-evaluation about their awareness of eXtreme Programming at the start of the student project. The students’ attitude towards this project is very important to its success. The survey contains questions to prove or not to prove the hypothesis. Question 33 in Survey 1 is repeated in Survey 2 (as Question 25) to see whether or not the students’ point of view changed during the course of the project. The survey consisted of 32 questions which have been consolidated into the following 5 items.

Item 1 How well did you understand all practices?

The formula to calculate the mean (illustration not visible in this excerpt) is illustration not visible in this excerpt. As shown above, the value is 2.3 indicating that the group thought that it understood the practice well. This value may be used as an indicator together with the mean of the weighted means in item 3 i.e. the mean value of the group understanding for all the practices.

Item 2 How well do you think the practice "XY" is applicable during the project?

This question has been asked each time for each of the 15 practices. For the sake of brevity, it is just listed once. This item supports the process of proving or not proving hypothesis (H O1) as explained in section 3.5. This item directly asks the students how well they think a certain practice is applicable in the practical project. It has been asked since it can be checked against the observation that shows if the students applied the practice or not. This item shows whether some students thought that a certain practice was not applicable and then changed their point of view because the group as a whole applied it.

Three categories have been created, namely “Applicable”, “Undecided” and “Not Applicable” to be able to evaluate this item properly. The ranges for the categories are defined as follows:

[...]

Details

Seiten
134
Jahr
2010
ISBN (eBook)
9783640719969
ISBN (Buch)
9783640720040
Dateigröße
1.6 MB
Sprache
Englisch
Katalognummer
v152736
Institution / Hochschule
Karlstads Universitet
Note
Schlagworte
extreme programming case study agile methods university classroom coputer science

Autor

Teilen

Zurück

Titel: Using eXtreme Programming in a Student Environment