Development Procedure

Roles:

• Designer: responsible to create prototype as per Design Guidelines
• Test Engineer: responsible to create end-to-end tests
• Developer: responsible to create a branch with code that implements the task as per the prototype according to Coding Guidelines
• Mike: responsible to oversee process, set code guidelines/requirements overall and for tasks, conduct final code review.

Triage

Scope of work development

Prerequisites:

• None

Output:

• Task card that is essentially a scope of work for the feature on Github. Task labelled ReadyForPrototype on Github.

What	Who	Timeframe
User story on Github in the format of “As a (user type) I want (feature) so that (benefit).	Anyone with a feature idea.	Ongoing
List of tasks that users must be able to accomplish (e.g. teacher or admin can enable shared school device mode, teacher or admin can disable school device mode, teacher or admin can see list of shared school devices)	Anyone with idea, reviewed by Mike and Designer	Before prototype development

Prototype (design) development

Prerequisites

• Task card with user story and list of tasks users must be able to accomplish

Output:

• Clickable (Figma) prototype with unambiguous screen designs for all screens that are going to be newly added or modified for this task. Task labelled ReadyForDevelopment on Github

What	Who	Timeframe
Prototype version 1: Figma prototype as above: ready for development as per Design Guidelines. Can include getting comments from within/outside the team, sharing draft ideas/concepts, teachers/educators/parents, focus group as needed as determined by the designer	Designer	1-5 working days
Comments	Mike, Test Engineer, Developer (optional)	1-3 working days
Prototype version 2: Figma prototype as above with comments actioned as required	Designer	1-2 working days
Live finalization call: if there are any issues with the prototype that make it unsuitable for development as per Design Guidelines: call where all blocker issues are resolved live on call	Designer, Mike, Test Engineer	10:00 UAE time / 11:30 India time working day after internal comments time is closed.
Live finalization call: if there are any issues with the prototype that make it unsuitable for release as ready for development: call where all blocker issues are resolved live on call	Designer, CEO (Mike), Test Engineer	10:00 UAE time / 11:30 India time Second working day after external comments closed.

• When designer is requesting comments on a design and when reviewers have completed a review they must add a comment to the Github task card for the record. When comments are open add Github label OpenForComment.
• Before the start of each iteration (sprint) there should be at least 1-2 tasks ready per developer.

Software development (two week sprint cycles)

Every two weeks tasks will be selected for development from those that are in the backlog with the status/label ReadyForDevelopment.

Prerequisites (criteria for task selection):

• Software development must not have any not yet published dependency (e.g. anything that would require Mike or anyone else to do further development for the task to be completed).
• Completed prototype

What	Who	Timeframe
Sprint kick-off call: reviewing previous sprint, assigning tasks to each developer, estimation (set dates on task card), prioritization	All	Sprint day 1
Task kickoff call/guidance	CEO (Mike), Designer, Test Engineer, Developer	Sprint day 1
End to end automated (Maestro) test development based on prototype (included in development branch). Task labelled E2ETestReady on GitHub.	Test Engineer	As per story/estimate: should be within the first half of the time available for the software development itself.
Software developed as per coding guidelines to pass end-to-end automated test.	Developer	As per estimate
Code review	Mike	Within 1-2 working days of software passing end-to-end test.
Merge to main branch	Mike	Upon completion of review and implementation of comments/tidyup as required.
Publish to Google Play	Mike	Monthly

• When the developer believes their task is done: they must request a pull request review on Github from the senior developer who will review the code. The reviewer must use Github's pull request review to either request changes or approve.

Once a task has been labeled ReadyForDevelopment and assigned the prototype should not be change unless something unforeseen makes that essential and unavoidable (in which case a comment must be made on the task card about what was changed and why). Making a new small task is preferred to modifying the existing task card after development has started.