by DAN CALLOWAY
Published 7 March 2010

WEAVERVILLE, NC – Dean Sanders, the Computer Science and Information Systems chair at Northwest Missouri State University in Maryville, Missouri asked the students to evaluate the use of Extreme Programming for a project that was to be conducted in the undergraduate computer science curriculum and to write opinion papers on the subject (Sanders, 2002). The majority of the students were opposed to the use of XP as the preferred life-cycle model for the project, but did support the introduction of some of the practices of XP for selected courses. Among these acceptable practices were unit testing and coding standards for introductory classes. The students, however, felt that other practices should be deferred to project-specific courses.

As a means of corroborating the opinions of the students, Sanders (2002) conducted two pilot studies: one on pair programming and one on Extreme Programming. The reasons for these pilot studies were to develop substantiative experience to support the opinions of the students and to evaluate the literature on pair programming and agile methods to see where they fit into a typical undergraduate computer science curriculum.

The Pair Programming pilot study (Sanders, 2002) was conducted in the Summer semester of 2001. The course selected for the study was a Data and File Structures course consisting of a small group of individuals with mixed ethnicity and diversity among family obligations, gender, age, job schedules, and grade point averages who were felt to be ideal for the study. In general, the results of this pilot study revealed that most of the students were enthusiastic about the concept of pair programming and felt that they had learned quite a bit about working in pairs, communicating with one another on the project, and felt that this experience had been a rewarding one. One surprising result of the study, however, was that early on in the course, the majority of the students felt that the introduction of pair programming in the Data and File Structures course was very useful, but by the end of the course, most students had changed their minds as a result of the stronger students constantly having to explain concepts to the weaker ones, and felt that this practice should be delayed to a later course rather than being an introductory one.

The Extreme Programming pilot study (Sanders, 2002) was conducted in the Fall semester of 2001 where one project was selected as an XP pilot project to develop a teaching/learning environment for students in an introductory programming course. This particular project was selected for three reasons: (1) the instructor would be playing the role of the client, (2) the project was large enough to instill interest among students, and (3) the project could tolerate a lack of progress. The project, codenamed Jeroo, when completed, would allow students to control the movements of an animated character by writing programs in a Java-like language. The completed project would include a GUI, an animation plane, a source-code editor, a graphical environment editor, a lexical analyzer, a parser, a compiler, an interpretor, and a run-time module. A team consisting of six students all of whom had a demonstrated history of producing excellent work, were asked to conduct further research into XP practices and were asked how they would adapt those practices to the Jeroo project. Releases of the software client were developed about every three weeks. The team reported they attempted to follow the principles of simple design but time constraints made refactoring extremely difficult. Testing during the project did occur, but did not follow the prescribed practice of Extreme Programming. Students reported the most successful aspects regarding the use of pair programming and XP were the stand-up meetings, the variation on pair programming, and the use of CVS. The majority of the students felt that XP kept their morale high, but they did not deem XP suitable for all teams or projects, recommending that a subset of XP be used in future projects.

As a result of the student evaluations and pilot studies, Sanders (2002) made six recommendations for the use of pair programming and XP in an undergraduate curriculum: (1) ensure the introduction of XP does not conflict with broader educational objectives; (2) teach XP or agile methods in an introductory computer science course but be cautious about using either in introductory course projects; (3) an appropriately modified version of XP practices can be used on some projects and some teams; (4) a topics course is the most appropriate place to practice agile methods; (5) some of the practices of XP can be distributed among selected courses as enhancements or revisions of current practices; and (6) pair programming is most effective when students have developed individual skills, when members of team pairs have equitable skill levels, and the course includes regularly scheduled lab sessions.

The results of Sanders (2002) are consistent with the findings of (Kobayashi, Kawabata, Sakai, & Parkinson, 2006) in the use of the whole team concept in which all the players involved in XP projects are gathered together to work as a team, the planning game and short releases concept in which developers and customers make plans for short releases and iterations of software development, clearly identifying the role each plays, and the pair programming concept where teams work in pairs at a single computer when developing the software. Kobayashi, et al., recommends the introduction of selected practices of XP in projects, which is also consistent with the findings and recommendations of Sanders (2002) in the XP pilot study.

—————–

References
Kobayashi, O., Kawabata, M., Sakai, M., & Parkinson, E. (2006). Analysis of the interaction between practices for introducing XP effectively. In Proceedings of the 28th international conference on software engineering (pp. 544-550). Presented at the Far eas experience papers: development technique, Shanghai, China: ACM. Retrieved March 3, 2010, from http://portal.acm.org.library.capella.edu/citation.cfm?doid=1134285.1134361.

Sanders, D. (2002). Extreme Programming: The student view. Computer Science Education, 12(3), 235-250.

by DAN CALLOWAY
Published 3 March 2010

THE UNITED STATES – Offshore outsourcing (or offshoring) is defined as the relocation of business functions and structures to third-parties in lower-wage countries outside of the United States for the purposes of taking advantage of cost savings that can be realized (Sauer, 2005). Although the primary motivation for outsourcing programming projects is to take advantage of cost savings realized through lower-cost labor, another motivator for doing so is the flexibility and concentration on a corporation’s core business through the employment of skilled programmers where the talent available offshore is not as readily available domestically (Sauer). Therefore, to summarize, offshore outsourcing of programming work is typically accomplished for two reasons: (1) To reduce the cost of the programming project by hiring programmers in foreign countries, such as India, who are willing to work for less money, and (2) To acquire programming skills available in bigger job markets by including those countries outside the United States for specific skills that may not be available within the boundaries of the United States (Sauer).

Two methods of programming are the agile methods of XP (Extreme Programming) and ASD (Agile Software Development) (Kobayashi, Kawabata, Sakai, & Parkinson, 2006; Lindstrom & Jeffries, 2004). Kobayashi, et al. primarily discussed the agile method of XP through two case studies they introduced involving a selection from 13 XP practices gathered from interviews with developers. The goal of these practices was to define how to select the correct practices based on the programming scenario the reader might encounter. On the other hand, Lindstrom, et al. introduced the principles of the agile manifesto and tabulated several agile methodologies, including the agile method of XP but also included in his discussion the agile method known as ASD. Lindstrom, et al. sees especially XP as a means of solving many of the problems—in larger software development projects—that seem to haunt those projects, and offers an evaluation of the approaches used in XP as well as the underlying values of XP.

Using the agile practices of XP and of ASD constitute a means, especially with XP, to solve many of the software development issues encountered in offshoring because agile practices avoid upfront design, emphasize flexibility, a concentration on rules and documentation, and developing voluminous documentation found in other software development methods (Sauer, 2005). If offshoring, in this instance, could be accomplished, then it would be able to take advantage of cost savings (outsourcing) and the advantage of flexibility (agility) found in a larger market outside of the U.S. However, some issues with offshoring are found in the very principles of agile practices, which rely heavily on communication and feedback, and which requires a team of programmers who are collocated with one another and who have the ability to collaborate with the customer (Sauer).

Sauer (2005) has taken the initiative to analyze published experiences of AO – agile offshoring (agile practices applied to offshore projects), AGSD – agile global software development (agile practices used in globally dispersed software development), and DEP – distributed extreme programming (XP is used as the core agile process model). AO emphasizes the relationship and communication between unequally ranked teams and remote customers, AGSD emphasizes the geographical aspects of cultural and ideological differences, and DEP emphasizes the dispersement of teams, which have a direct effect on communications and coordination (Sauer).

Organizations should expect offshore firms to have competencies in ASD. However, the challenges that Sauer (2005) determined in their analysis of software offshoring that might adversely impact the effective use of ASD can be classified into four categories: (1) Individuals and interactions, (2) Working software, (3) Customer collaboration, and (4) Responding to change. Within the first category, communication is the main issue with offshoring since offshoring does not allow team members to sit together, collaborate with other team members, and resolve issues on a timely basis when they arise. Hindrances in communication often lead to the spreading of informal news, the lowering of team spirit, lack of common knowledge, and a departure from the shared vision of the team. As for the second category, offshoring has increased demands in the infrastructure and invariably this offshoring will lead to integration issues, issues with the testing of software, problems in quality assurance conformity, and issues with software configuration where something that works on one platform in the US may not work on another platform outside of the US. Customer collaboration is a necessity in agile software development where the programming team interacts with the customer quite frequently on requirements engineering and iterations of software development. Offshoring makes this next to impossible since the customer is often geographically distant from the team and the customer is unwilling or unable to send representatives to the offshore location. And, finally, a distributed team, as would be found when offshoring, can lead to problems with a host of project management issues. Among these are: (1) Progress estimation, where the project status is less visible and controllable; (2) Estimating efforts, where the developers not managers should be making these decisions but often the developers are not able to attend planning meetings, or on-site and offshore developers create diverging opinions about the amount of time and effort needed; and (3) Division of work is hampered in a geographically dispersed setting since offshore developers are typically less experienced in the application domain, especially in the beginning of the project, and must be constantly updated to continually involve them in the project so more and more tasks can be transferred offshore where cost savings can be realized.

Therefore, the agile practices of pair-programming, customer on-site, and planning game for extreme programming are directly impacted by offshoring (Sauer, 2005). Although these agile practices are adversely affected, Sauer suggests that if properly adapted and enhanced, they will continue to work in offshoring environments. The main issue with offshoring is the restricted communication between on-site and offshore teams and between offshore developers and the customer, and this is extremely important since communication and regular feedback form the basis for agility. The solutions to these issues are found in the substitution of communication through the technical means of video conferencing, telephone calls, and instant messaging, further supplemented by an occasional exchange of team members. Sauer has performed a case study which they believe will show that although technical substitution may be a solution at a higher cost, and, thus, may indicate that it is only affordable in larger projects, smaller teams can take advantage of offshoring in agile ways by avoiding the initial and running costs, and overhead by employing established practices and tools of software engineering to formalize and structure agile offshoring without losing the flexibility of agile practices.


References:

Kobayashi, O., Kawabata, M., Sakai, M., & Parkinson, E. (2006). Analysis of the interaction between practices for introducing XP effectively. In Proceedings of the 28th international conference on software engineering (pp. 544-550). Presented at the Far east experience papers: development technique, Shanghai, China: ACM. Retrieved March 3, 2010, from http://portal.acm.org.library.capella.edu/citation.cfm?doid=1134285.1134361.

Lindstrom, L., & Jeffries, R. (2004). Extreme Programming and Agile Software Development Methodologies. Information Systems Management, 21(3), 41-60.

Sauer, J. (2005). Agile Practices in Offshore Outsourcing – An Analysis of Published Experiences. ECSCW 2005 Instructions. Retrieved March 3, 2010, from http://74.125.155.132/scholar?q=cache:_lkLfiz5n7cJ:scholar.google.com/+offshore+outsourcing+of+programming+and+agile+practices&hl=en&as_sdt=40000000001.

Tagged with:
 
Get Adobe Flash playerPlugin by wpburn.com wordpress themes

SEO Powered by Platinum SEO from Techblissonline