Specifications process

This page describes all aspects related to the specification of new features for the imeji software developed by the MPDL.

Team

The imeji specifications are done by MPDL service manager:

• Inga: https://outbox.mpdl.mpg.de/
• Jalal: Caesar
• Kristina: http://edmond.mpdl.mpg.de/
• Lu: http://labcam.mpdl.mpg.de/
• Tomas: https://gluons.mpdl.mpg.de/

... together with MPDL imeji developers!

Weekly

• The service manager team meets every Wednesday from 11:30 to 12:30 (timeboxed) in room 204
• Topics are managed in a backlog in room 204
• If backlog is empty, meeting is cancelled

Release

• A release is defined as 4 weeks development period (2 weeks development, 2 weeks testing).
• At least one feature must be achieved during this period
• Features are chosen from the Ready column (see feature management) according to priorities
• At the beginning of the release, the highest prioritized feature in Ready is chosen and put in Dev
• If a feature is not ready for testing after 2 weeks, it will be postponed to the next release
• Priorities of features in Ready can be changed by the service manager team anytime

Features management

• New Features are managed in a Kanban Backlog in room 204
• Only members of the service manager team can add features to the backlog
• The backlog contains the following columns:

1. New: Features still not introduced to the service manager team
2. Todo: All features not already specified, ordered by importance/value and urgency. The position of a Todo feature determines its priority for the development and can be changed by the service manager team anytime
3. Specs: Features being specified (Max 2 Features at once)
4. Ready: Features with enough specification (agreed by service managers and developers). Features are ordered from 1 to 5 by priority (Max 5 features at once)
5. Dev: Features which are currently in development. (Max 1 feature at once)
6. Test: Features which are currently in testing
7. Done: Features which have been successfully tested and accepted by the service managers

• Features specifications are documented in Github issues
• Specifications can be done via text or picture

Enhancement management

• Enhancements are system improvements which require only few efforts and can be implemented along the way:
• Technical limit: 0.5 day of implementation
• They are reported by the service managers or other involved parties as Github issues
• Enhancements which are required soon should be tagged as "important"
• Prioritization and assignment to a specific release are done by the development team
• About one week before the release planning, the development team sends an e-mail to the service managers to check the pending enhacements. Question/remarks can be then discuss on next imeji meeting
• Ahead of implementation, the development team provides a list of planned enhancements to the project managers (e.g. per email) to give them a chance to "veto" individual enhancements or the complete selection.