Communications of the ACM
Home/Magazine Archive/December 2007 (Vol. 50, No. 12)/Training Future Software Developers to Acquire Agile.../Full Text
Technical opinion
Training Future Software Developers to Acquire Agile Development Skills
Agile techniques are fast becoming the adopted development methodology commercially. Central to the approach is that a project team can be effective in responding to the changing environment and user requirements if it capitalizes on its members' skills, stresses collaboration among members and users, emphasizes functional modularity, mandates short iteration cycles to enable fast verifications of user requirements, removes all unnecessary activities (such as redundant documentation), provides more system releases with smaller changes between each release, and focuses on developing functions up to the point of adequacy. This column reports the experience of imparting agile techniques to students by guiding them toward delivering large-scale systems.
Information Systems Development Project (ISDP) is an advanced course offered to students in their third year of study who have satisfied prerequisites that are related to software engineering, database systems, operating systems, and Java programming. Through ISDP, students experience, for the first time, a simulated but realistic software development environment that puts sufficiently high time pressure on them to deliver the system and injects the element of uncertainty in functional requirements.
The agile principles incorporated into the course structure are listed in the table here. Students form teams of five or six members each. Several milestones and system releases are stipulated to provide students with the opportunity to learn to pay attention to technical excellence and design agility and to review and revise system deliveries. An element of "shock" that disrupts system development is explicitly introduced: Students are not informed of the second set of functional requirements until the ninth week. This is to develop their ability to respond to the ever-changing real-world system requirements. Expecting the students to deliver working systems within 13 weeks also forces them to only code sufficiently for each function (the principle of simplicity).
We compare the difference in system quality delivered before and after the agile techniques were adopted in the course. We observe, for two consecutive semesters, the use of agile techniques has positive impact on development progress and system quality based on students' feedback and external examiners' evaluations. Ten additional recommendations are derived, and are described in more detail here:
Mandate function list: This provides students with an introduction to project planning and system requirement documentation. The planning process encourages students to think about issues related to their capacity in delivering system functions and meeting user priorities.
Be pragmatic: Encourage students to develop a system to the point of adequacy rather than excessiveness to cater to future uncertain needs. Releasing detailed system evaluation criteria breakdown early (for example, user interface, breath and depth of system delivered, and so forth) induces students to be more inclined to "satisfice" on individual functions and focus more on delivering a working system as a whole.
Conceptualize unit testing before coding: Developing unit testing cases early and prior to code implementation could ferret out misconceptualization and misinterpretation in system requirements.
Multitiered software development platform: With a multitiered software development platform, such as J2EE, students are able to develop the system modularly and isolate bugs in specific tiers.
Continuous integration of the system: Demand functions to be integrated for each system release. Students are coached to integrate system components and perform integration testing for each release.
Demand multiple releases: Students are provided with an opportunity to reflect on the system just released and identify areas for improvement. Such reflection allows them to identify flaws in system design and function delivered early.
Introduce "shock": Additional functions or requirement changes could be introduced. In our experience, to effectively introduce "shocks," you need to first customize the degree of changes to be made and additional function complexity according to students' programming ability. Second, "shocks" could be framed as "challenges" to minimize resentments, and advisors should encourage students to incorporate the changes into their systems.
Teach conflict resolution: We observe many teams have a tendency to divide the work without much knowledge of the assigned members' capabilities. When they could not deliver, conflict arises. Conflict management should be delivered in the lecture.
Perform post-mortem audit after each release: Main goals are to find the core causes for software flaws and provide recommendations so similar flaws do not occur in future release(s). Opportunities for improvement should also be identified.
Reflect on members' roles and responsibilities: Each team member needs to understand his or her role in the project. Understanding strengths and identifying ways to address weaknesses of each member could be beneficial to the distribution of work. We recommend having a peer review session after each system release to highlight any team conflict early.
©2007 ACM 0001-0782/07/1200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.
No entries found