From ImageWeb

Contents 1 Introduction 2 Project Management and Administration 3 Community engagement 4 Technical 5 Agile modelling and development

Introduction

This page captures the elements of agile processes used for running this project. It is subject to continuous review, and this page exists to record the current state of that review process. The aim is to capture those process elements that work for us, or that we believe we will be of benefit in due course.

The process-revision outcomes of sprint reviews should be reflected here.

Project Management and Administration

• Daily stand-up meeting each morning, about 9:45AM.
• Iterations (sprints): aim for 2 weeks, with 10-15 working days, and allowing some flexibility to accommodate circumstances and other commitments. Re-evaluate and reschedule tasks for each sprint.
• During sprint planning, create a visual calendar of events for the coming sprint.
• Sprint plans recorded in the project wiki, together with progress and review notes.
• Create an online summary, in one place, of achievements and deliverables delivered. E.g. in the overall project plan, near the project roadmap. Update from sprint reviews.
• Allow 10-15% overall effort for sprint planning, review, recoding and routine reporting. For project manager, allow 20-25%.
• Daily activities recorded in personal calendar and sprint plan; these underpin and supplement daily stand-ups.
• Use the project wiki for administrative notes and plans
• Outline project plan, milestones and sprint schedule recorded in project wiki.
• Review process each iteration, update this document as appropriate.
• Responding to technical barriers. When facing unexpected technical barriers, try to timebox the task according to the sprint plan, achieve what can be achieved, and as part of the sprint review decide if more needs to be done. Don't allow a single task to run away with the overall schedule.
• User stories (TODO)
• Release plan (TODO)

Community engagement

• Develop an open source sustainability plan, which underlines need to be aware of wider community issues when making technical and other decisions. (TODO)
• Aim to develop functionality requested by users, but the early stages will develop an initial system to elicit user requirements, using data audit and our original project proposal for guidance.
• Meet users, identify current data curation practices, elicit further requirements/desiderata, develop user stories, implement. Later, use running prototype to help elicit requirements.
• Disemmination plan (TODO)
• Generate summary diagrams (e.g. user interactions, project management artifacts) for internal and external visualization of project (TODO)
• Iteratively create data flow models for each of our test users. Use regular meetings to refine these. (TODO) (Select tooling?)

Technical

• Try to use existing code / libraries where possible. But allow interim home-grown elements if learning time is likely to be a factor.
• Spike code to understand how to do something or use new libraries.
• Test-led development for production code; test cases at unit and interface level (Windmill / selenium)
• To explore user-facing features, it's sometimes easier to implement first, then wrap code in test cases when the desired functionality has been worked out.
• Continuous refactoring; adopt patterns to maximize unit test coverage (e.g. MVC per FlyWeb)
• Continuous integration (TODO)
• Pair programming or review for all production code.

Agile modelling and development

In the early stages of a project , it is sometimes necessary to spend some time on high-level design activities activities, and creating technical infrastructure, that of themselves do not directly contribute to a user story.

This essay, Agile Model Driven Development (AMDD)¹, suggests that even for agile development it can be appropriate to take some time (but not too much!) to perform "requirements envisioning" and "initial architecture envisioning", to "get a good gut feel what the project is all about" and to "identify an architecture that has a good chance of working". As always with agile development, the goal is "to get something that is just barely good enough so that your team can get going".

This essay also says "For your architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough" - it seems to me that the important bit here, very much to be emphasized, is "end-to-end".

1. Agile Model Driven Development (AMDD), by Scott Ambler. http://www.agilemodeling.com/essays/amdd.htm