Applying Agile Project Management to a Customized Moodle Implementation

Transcription

1 Applying Agile Project Management to a Customized Moodle Implementation November 6, 2013 Presented by: Curtis Fornadley, PMP UCLA CCLE Coordinator

2 Applying Agile Project Management to a Customized Moodle Implementation Agenda What is CCLE? What is Agile? Overview of Scrum Moodle HQ and Scrum CCLE and Scrum CCLE Agile Retrospective Next steps - Automated Testing Questions Goals: A basic understanding of Agile and Scrum How UCLA has applied Agile principals Get you thinking on how you can use these tools

3 What is CCLE? Common Collaboration and Learning Environment Common LMS for the Campus (Moodle 2.5.1) Supports: Instruction, Collaboration and Research Users: Faculty, Students and Staff. First successful, large scale, project that pulls together many different campus departments to host a single service.

4 Growth of CCLE 3000 Total Course Sites Fall Winter Spring Summer 0 Logins per Day Total Users Spring ,309 29, 812 Spring ,341 26,497 Spring ,113 23,854

5 LMS on Campus 2013 Anderson CCLE Statistics - CCLE Arts and Architecture - CCLE Public Affairs - CCLE Social Sciences - CCLE Engineering CCLE (2014) Humanities - CCLE Mathematics CCLE Physical Sciences - CCLE GSEIS - CCLE Life Sciences CCLE Nursing - CCLE Public Health - CCLE

6 Shared Governance Model Oversight CCLE Home Governance Faculty Group Academic Leadership, Deans, CIOs CCLE Coordinator Lead Developer Support Coordinator Standards and Practices Group System Administrator Shared System Programmer/Back-up Sys Admin Student Group Operations CCLE Home Shared Campus Operations Common Code base in GIT Common Interest Group (CIG) CCLE Subgroups Autonomous Department System Autonomous Department System Autonomous Department System

7 CCLE: Customized Moodle A primary driver for selecting Moodle: The Ability to Customize

8 Managing Code Divergence Technical Debt: Moodle is constantly changing Rework is a constant. Moodle.org 6 month release cycle. Code Divergence CCLE Moodle Moodle.org Core Time

9 Project Management Developing and Evolving a customized Moodle instance amounts to a series of projects - some large, some small. What is a Project? A temporary group activity designed to produce a unique product, service or result. A project is unique; it is not a routine operation Project management is the application of knowledge, skills and techniques to execute projects effectively and efficiently.

10 Basic Project Management Triple Constraint: Scope: Improvements, fixes, new functionality Schedule: Often dictated by academic calendar Resources: Existing staff, matrix staff, contractors One cannot change without affecting the others Two Methodologies to consider: Waterfall and Agile

11 Compare Methodologies S T A R T Waterfall Development Design Requirements You know the least about a project at the start Sprint 1 Highest Priority Features REQUIREMENTS Design Test Test Develop Integrate Test Agile DEMO & FEEDBACK Sprint 2 Highest Priority Features REQUIREMENTS Design Test Test Develop Integrate Test DEMO & FEEDBACK Deploy Testing Sprint n Highest Priority Features REQUIREMENTS Design Test Test Develop Integrate Test DEMO & FEEDBACK R E L E A S E

12 Waterfall vs. Agile Agile projects are 3 times more successful than non-agile projects. The Standish Group defines project success as: On Time, On Budget, and with All Planned Features.

13 What is Agile? Agile: umbrella term for Iterative, Incremental Software Development Methodologies. Agile methodologies include: Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean, and Feature-Driven Development (FDD). Agile methodologies emphasize: small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.

14 Key Attributes of Agile Promotes Sustainable Development Design Constant Feedback Test Customer Collaboration Integrate Iterative Development Co-located Dedicated Team(s) Daily Communication Resolve Defects Early Self Organizing Teams - Team Members Take Ownership REQUIREMENTS Test Test Develop DEMO & FEEDBACK Responding to Change Over Following a Plan Primary Measure of Progress: Delivering Working Software Frequently

15 Scrum = An Agile Framework Scrum is the most widely recognized Agile Framework for the iterative development of software Note: Sometimes the term Scrum is used interchangeably with the term Agile, this is incorrect Scrum is comprised of a series of short iterations called Sprints. Each Sprint ends with the delivery of an increment of working software. The term Scrum is derived from the game of Rugby, where it refers to a team that moves down the field as one body.

16 Scrum Roles Product Owner Stakeholder Representative - priority setting, business side, controls $$, sets strategy and direction, Accepts/Rejects the work from the Sprint. Could have a PO proxy, more on this later Development Team (7 +-2) Product Creators: programmers, UI experts, testers, etc. Cross functional skill sets, self organizing and self managing, ideally full time and co-located. Scrum Master Project Facilitator. Supports the team as a servant-leader, removes obstacles, has intuitional knowledge, helps to build consensus. Process Coach - keeps the team true to Agile principles

17 Scrum Teams Project Team Scrum Team Scrum Master Development Team Product Owner Stakeholders

18 Scrum Artifacts Product Road Map - overall view of Product requirements Themes, epic user stories, tentative release time lines Product Backlog - list of all User Stories associated with the project main source for project requirements Sprint Backlog - list of Users Stories associated with the current Sprint, includes estimates in hours to complete tasks (max time should be one day per task) Increment - the sum of all the Product Backlog Items completed during a Sprint and all previous Sprints Burn Down Chart - a publicly displayed chart showing remaining work in the Sprint Backlog

19 Scrum User Stories User Story: A simple description of a product requirement Title <a name for the user story> As a <User or persona> I want to <take this action> So that <I get this benefit> When I <take this action>, this happens <description of action> Outlines the test case(s) for developers Can form that basis of Automated Testing. Stakeholders have direct input Customer Collaboration

20 Scrum Meetings Sprint - a consistent iteration of time (1-4 weeks) At the end the Development team deliveries of an increment of working software. Sprint Planning - beginning of the cycle, select the work to be done Turn User Stories into Tasks - detail time and work estimates. Daily Scrum - ~15 min Coordination - Not Problem Solving What did you do yesterday? What are you planning to do today? Any impediments/stumbling blocks? Sprint Review Demonstrate the working product Sprint Retrospect Post mortem done after ever Sprint. What went well? What would we like to change? How can we make the change?

21 Moodle HQ and Scrum Moodle HQ s move to Scrum Martin Dougiamas announcement December 10, Moodle Tracker = Product Road Map : bugs and new features Major releases happening every 6 months (starting June 2012). Scrum Roles: Product Owner - Martin Dougiamas Representing the voice of all Moodle users Scrum Master - Michael de Raadt Two Development Teams: FRONTEND and BACKEND Most Moodle HQ developers are in Perth Some work remotely - Working towards co-location.

22 Moodle HQ and Scrum Since 2.5 release both stable and dev work is achieved using Scrum. Prior to 2.5 just stable Backlog for FRONTEND and BACKEND teams ranked by Product Owner Three week Sprints - teams select issues from their relevant Product Backlogs. Retrospective held at the end of each Sprint Two Sprints are followed by a project week Developers are free to work on their own Moodle-related projects. Daily Scrum meetings (remote people via Google Hangouts) Currently refining initial planning period specs writing and prototypes

23 UCLA and Agile Product Owner CCLE is highly collaborative and consensus driven Two Product Owner Proxies represent the group. Development Team (7 +-2) Just short of 7 CCLE Home Team: 1 lead developer, 1 programmer/ui expert, 1 tester application expert, ~4 part time student developers/testers,.5 FTE matrix assigned programmer ~.5 FTE Contributed testing resources Scrum Master CCLE Coordinator (me): servant-leader, removes obstacles, has intuitional knowledge, helps to build consensus. Process Coach : CCLE Coordinator and Lead Developer

24 UCLA Scrum Artifacts Product Road Map Features and Functionality Matrix (FFM) Captures input from stakeholders Reviewed and updated monthly 1-2 years of work Product Backlog Prioritized items from the FFM User Stories captured in Jira Sprint Backlog Entered and edited in Jira, Kanban board Increment - Captured in FFM and Jira Burn Down Chart - Not used

25 UCLA Scrum Meetings Sprints weeks, varies Sprint Planning Turn User Stories into Tasks Consistent and Useful. Sprints include Bug Fixes and New Features Daily Scrum Done virtually with Jabber Varied schedules and not all co-located Sprint Review Released to stakeholders on Test and Stage environments Weekly meetings of key stakeholders Sprint Retrospect Not held consistently; mostly discussion after major releases Not much time between Sprints

26 Requirements and Priorities CIG and SPG F&F Matrix Faculty Survey Student Survey Faculty Advisory Group CCLE F&F Matrix Product Road Map Reviewed Monthly Student Advisory Group CCLE Product Backlog Reviewed Weekly CCLE Development Team and Product Owners New Functionality and Improvement Projects

27 Prioritizing Feature Requests Features and Functionality Matrix (H, M, L) Feature Types: System Operations CCLE Archival User Interface Functionality Improv. Integration with Campus Systems Other CCLE sites Staffing Resources Admin/Support Tools Mobile Copyright Documentation Merge Code to Moodle.org Contribute to Moodle.org Governance Other Value Technical Difficulty

28 Sprint Planning and Execution

29 UCLA Agile Retrospective FFM created for Moodle 2 migration Waterfall Fall move to Agile approach June 2012 launched Moodle 2.0 with all critical functions working less important items iterated over summer and fall An Agile approach was key to the smooth transition Focus and Re-focus on the top priorities Remember and Communicate the Triple Constraint Nothing is perfect on day one Make sure the most important things are

30 UCLA Agile Retrospective Lessons Learned and Things to Work On Staffing falls short for true Scrum Product Owner Proxies are really representatives and have limited power Some aspects of Scrum have not been implemented (Burn down chart, rigorous Scrum estimation techniques) Scrum is a skill - you get better as you do it. Testing is our Achilles heal It happened again moving to 2.5 Common Agile Pitfall : Lack of Automated Testing

31 Automated Testing Behavior Driven Development (BBD) Test Driven Dev. Behat is a behavior driven testing framework Behat scripts are human readable stories that describe the behavior of your application. Behat scripts are called features Each feature contains a scenario Scenarios are basically Agile User Stories Code may change over time, but the expected behavior should not. If the expected behavior has changed during a test, your code probably broke something.

32 Automated Testing Moodle.org supplies Automated Testing scripts in 2.5 A custom Behat environment built to work with Moodle. Functions that generate data (like courses and students) A large set of predefined step definitions Example: And I turn editing mode on. Challenge for UCLA - heavily customized version of Moodle Edit Moodle supplied scripts Write our own

33 Agile References Agile Project Management for Dummies, Mark C. Layton Platinum Edge Agile Training platinumedge.com Project Management Institute

34 Questions? Curtis Fornadley, PMP CCLE Coordinator