isecon 2003 san diego, california integrating agile methodologies into the project capstone...
TRANSCRIPT
ISECON 2003 San Diego, California
Integrating Agile Methodologies into the
Project Capstone
Christopher G. Jones, CPA/PhDUtah Valley State College
ISECON 2003 San Diego, California
The Setting Large U.S. Intermountain West university with
18,500 students I.S. program in AACSB School of Economics and
Business Two undergraduate concentrations
• Systems Development
• Information Security Senior Project Capstone required for both tracks
• Team-based end-to-end production of a new system for a real client
ISECON 2003 San Diego, California
The Challenge (1)
Mixed development backgrounds• SA/SD in Systems Analysis & Design
• OOAD in Advanced Programming course
Uneven preparation levels • Two different program concentrations
• Traditional Systems Development
• Information Security
• Students substitute security/computer forensics for advanced development coursework
ISECON 2003 San Diego, California
The Challenge (2)
Little experience with heavy-weight methodologies• Full-blown SA/SD
• OOAD a la UML/RUP
Project artifacts a drag on project momentum rather impetus
ISECON 2003 San Diego, California
The Experiment (1) Intervention
• Use of an ultra-lightweight methodology framework to drive the development process in the capstone• Crystal Clear – “the lightest of the light”• Minor modification to documentation requirements
Subjects• Two sections of Senior Project, Spring 2003
• Day • 7 Students -- 2 project teams
• Evening • 18 students -- 5 project teams
ISECON 2003 San Diego, California
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice
ISECON 2003 San Diego, California
Crystal: Goals
“Software development is viewed as cooperative game of intervention and communication, with a primary goal of delivering useful, working software and setting up the next game.”
--Cockburn, 2001
ISECON 2003 San Diego, California
Crystal: Core Values
Strong on communications. Light on deliverables. Keep the communications paths
short, rich and informal. Deliver frequently. Reduce overhead.
ISECON 2003 San Diego, California
ISECON 2003 San Diego, California
What’s Crystal Clear?
Development methodology for a 2 to 6 person team
Project criticality, low to medium• Failure would not
hurt the bottom line Minimal set of work
products
Crystal ClearCrystal Clear
ISECON 2003 San Diego, California
Crystal Clear Work Products (1)
Mission Statement Team Structure Development
Methodology Release Sequence Viewing & Release
Schedule
Risk List Project Status Actor-goal List Annotated Use
Cases Requirements File System Design
ISECON 2003 San Diego, California
Crystal Clear Work Products (2)
Design Sketches Common Object
model Screen Drafts Source Code Packaged System
Migration Code Test Cases Defect Reports User Manual
ISECON 2003 San Diego, California
Design Sketches Common Object
Domain model Screen Drafts Source Code Packaged System
Crystal Work Products (2) Revised
Migration Code Test Cases Defect Reports User Manual
Assistance
××
ISECON 2003 San Diego, California
The Essence of Crystal Clear
“The lead developer and two to five other developers in a large room or adjacent rooms, with whiteboards (preferably printing whiteboards), access to key users, distractions kept away, delivering running, tested, usable code to the users every month or two, periodically reflecting and adjusting their working conventions” (CC, p. 7).
ISECON 2003 San Diego, California
ISECON 2003 San Diego, California
The Experiment (2)
Treatment• Project Management Body of Knowledge
• Agile Development Exercise
• Crystal Clear Overview
• Work Product Tutorials
• Milestone Presentations
• Reflection Workshops• Analysis/Design/Implementation Retrospectives
• Methodology Retrospective
ISECON 2003 San Diego, California
Agile Development Exercise
Based on the eXtreme Planning Game Working in teams, students design and
“build” a hot drink maker to the client’s specification
High-level Use Cases to capture system requirements
Client available to help prioritize functionality and validate prototypes
ISECON 2003 San Diego, California
Reflection Workshops
“Periodically reflecting and adjusting their working conventions” (CC, p.7)
On-going evaluation of • Team structure
• Team process
• Working conventions One page retrospective following each milestone
• What would you like to keep?
• Where are you having problems?
• What will you do differently in the next phase?
ISECON 2003 San Diego, California
Analysis Phase Retrospective Keepers
• Team roles• Communication channels
Problems• Scope creep• Shared access to work products• Divergent views/Personality differences• Insufficient time to master new technology• Burdensome documentation levels
Adaptations for Design Phase• Increase team meeting frequency• Clarify team member assignments• Establish a team repository• Increase team communication frequency from weekly to daily
ISECON 2003 San Diego, California
Design Phase Retrospective Keepers
• Reworked team roles• Development process• Increased communication levels• Regular team meetings
Problems• Getting all team members to meetings• Occasional communication lapses• Tendency to over-”tech” the project
Adaptations for Implementation Phase• Realign roles to focus on coding/testing• Meet more often/Communicate even more• Emphasize project management to ensure assignment deadlines
met• Focus on functionality over “look and feel”• Meet with client/sponsor more frequently
ISECON 2003 San Diego, California
Implementation Phase Retrospective Keepers
• Team dynamics/balanced team• Team commitment• Regular meetings• High communication levels• Adaptive development process
Problems• Sense of insufficient time to deliver primary functionality• Struggles with technology, whether new or familiar• Synchronizing team meetings as meeting frequency
increased
ISECON 2003 San Diego, California
Results of Experiment
All 7 project teams deployed working code• Met or exceeded client expectations
• Highest priority functionality delivered
Use of agile methodology allowed students to adapt process midstream as necessary
ISECON 2003 San Diego, California
Lessons Learned (1)
Agile methodologies though often targeted to the OO community support traditional development approaches as well
Even with a reduced artifact set, students still perceive any form of documentation (other than uncommented source code) as excessive
ISECON 2003 San Diego, California
Lesson Learned (2)
Adopting Use Cases as the underlying mechanism for functional requirements specifications requires more than a 2-hour in-class tutorial
Students appreciate the adaptiveness and flexibility of the agile approach
ISECON 2003 San Diego, California
Should You Go Light? (1)
These factors suggest a traditional predictive process:• A team over fifty
• Fixed price, or more correctly a fixed scope, contract
• Regional development preferences for heavy-weight methodologies
ISECON 2003 San Diego, California
Should You Go Light? (2)
The following factors suggest an adaptive process:• Uncertain or volatile requirements
• Responsible and motivated developers
• Client/User who understands and will get involved
• Students with mixed development backgrounds
• Teams under fifty
ISECON 2003 San Diego, California
Questions?