Technical Development - An iterative approach - Kim Edgar, Blackboard
1 like213 views
The document outlines the iterative approach taken by Blackboard in developing Moodlerooms Enterprise, focusing on customization and client collaboration. It details the workflow from issue triage to client testing, highlighting stages such as development, peer review, and deployment. Additionally, it distinguishes between traditional and iterative project management methods, emphasizing the importance of client feedback throughout the development process.
Technical Development - An iterative approach - Kim Edgar, Blackboard
- 2. Welcome 2 Kim Edgar Open source lead, International Consulting Moodlerooms Enterprise, Product Manager • PMP, MBA • Based in Adelaide • Managed educational technology projects since 2005 • Manage a Private RTO
- 3. What is Moodlerooms Enterprise (formerly Enterprise Moodle) 3 Moodle Customisations & Special sauce Moodlerooms features • Universities and large organisations • Large user numbers • Flexible release cycle • On demand customisations
- 4. Sharing 4 Client layer • Client customisation • Client configuration ME Base • ME Customisations • ME Features Moodle Core • Moodle core features
- 5. Blackboard support Moodlerooms Enterprise Customer Application support Consulting Service Delivery Manager 5
- 6. 6
- 7. Moodlerooms Enterprise Environments / releases Test (UAT) •Iterative •Less controlled Stage •Controlled •Same as production Production •Live •Highly controlled 7
- 10. Special Projects Traditional • Client provides: Business requirements, use cases, desired outcomes etc • Blackboard provides: Initial scope statement, and initial estimate • Client signs off • Blackboard provides: Wire frames, test cases and detailed scope statement, final estimate • Client signs off • Development begins • Blackboard completes testing and hands back to client once all test cases are satisfied. 10 Iterative • Client provides: Business requirements, use cases, desired outcomes etc • Blackboard provides: Initial scope statement, and estimate • Client signs off • Development begins • Blackboard provides client with first version • Client provides feedback • Blackboard fixes (there could be several rounds of fixes and client testing) • Client signs off
- 11. Use Case 11 • Challenge / Problem / issue: • Business need: • Outcome: Request raised
- 12. Ticket triage 12 • Application support team review the ticket – Decide it is a large development project – Pass to Client Development team – Mat picks up the ticket – Reviews if there is any current functionality that would satisfy the need – Reviews if there is any work via Moodle HQ tracker – Provides a high level estimate for the work Client approval of estimate
- 13. Development 13 • Development is undertaken on Mat’s local machine • Then passed to the automated testing tool, once passed • Queued for Peer review • Marcus picks up the development and conduct peer review • Once passed he applies the code to the client environment Client testing starts
- 14. Client testing 14 • Running pre-defined test cases testing of the specific functionality • Regression testing, to ensure the custom development hasn’t had an unexpected result on other functionality Client provides feedback
- 15. Fixes 15 • Mat, as the original developer, picks up the issues and develops to the clients requirements • This could involve straight development of a fix or meetings / calls to clarify what’s needed • If the fixes are new functionality, which doesn’t “fit” within the initial high level estimate a quote is provided • Further automated testing. • Marcus Peer reviews Client re-tests
- 16. Questions / thoughts / experiences 16