-
Notifications
You must be signed in to change notification settings - Fork 3
02 Development process manifest
This document is to declare development and communication policy on Iguana project for all development team members.
==The team== The team is extremely distributed, multinational, members involvement grade varies. So this manifest is to optimise and streamline the development process and to reduce lags and breakups in communication, thus deliver smoothly and fast an excellent product.
==Requirements specification== The specification document contains feature description and functional requirements, which is helpful to consult in case you have questions regarding any feature described in a user story, or task, or misunderstand how the technology operates for a specified use case or in general.
The specification is supported by the app architecture scheme and app workflow scheme.
This set of papers are not finally fixed, they are to be developed, changed and updated depending on goals and new requirements for the product.
https://goo.gl/UoeJtd https://db.tt/84q5waKz https://drive.google.com/open?id=0B_RBrIySIgwTbDhxVlhDRk9WSzQ
==Prototype== http://goo.gl/Ww9boU is a clickable html file, which can show the right app flow in action. It is constantly being updated. You can find the latest version of it **http://goo.gl/Ww9boU **
==Working board== We use Phabricator as our project management tool. This is to plan, distribute, control and analyse the development process and how the team is progressing over time.
It is open to public to view, but only the team is allowed to practically use it.
==Workflow==
We will try to eliminate to the maximum any kind of useless stand-ups and retrospectives and streamline communication on releases, tasks and issues with good workflow. We apply ScrumBan artifacts and methods to the project, though it is not dogma and the workflow will be constantly analysed and improved, so we can deliver the best kick-ass product in the market and faster then Musks's rockets.
The workflow now is the following:
Once a team member is assigned a task and the task requirements are clear to him, he must give it an estimation in hours (use comments entry form) and pull it to the next appropriate column on https://phabricator.supernet.org/tag/iguana_app/. Time estimation is required to provide and stakeholders right data for the strategic goals planning, next backlog loads and milestones.
Backlog presents a list of features and tasks to be implemented in the future or soon product releases. It is compiled by project management (PM) on the project goals and its stakeholders priorities and vision. The list of features and task in the Backlog is not finite, hence it is periodically groomed and cleaned.
Epics is a list of complex features or groups of tasks collected together and related by common subject or goal.It is compiled by PM)and prioritized due the next release demand having from top to bottom priority principle.
To Do column is task to carry out by the team within the next agreed and stated release. They are prioritized from top to bottom assuming the highest card must be taken and pulled into development first. From this step all tasks can be distributed and assigned by PM or tech team lead (TL) among the team.
In Design - all tasks in design phase.
Designed\Ready For Approval - approved designs. All resource files https://drive.google.com/drive/u/0/folders/0B_RBrIySIgwTTDBDSjJsQmNBbHM
In Development - all tasks in programming\coding phase. Code review is done on that step. Before an engineer pulls a card to the testing phase, he must get a review from 1-2 colleague's who work on the same project, but other functionality or module.
In Code Review - code review is done before an engineer pulls a card to the testing phase, he must get a review from 1-2 colleague's who work on the same project, but busy coding other functionality or module. This will help to prevent some bugs before testing, enrich the architecture and let each team member b on the same wavelength.
Code reviews are processed and managed through https://github.com/blog/2123-more-code-review-tools
In Testing - once a developer pulls a card to the QA column, a testing specialist steps in. The types and the number of tests are to be discussed and agreed with the right team member.
Tested\Ready For Deployment - tasks compiling a new feature or a set of new features or\and older features debugged for a fresh release and ready to be merged to a master brunch.
Released - all tasks completed and implemented into a working and stable version of the product.
//N.B.: The list, the order and the names for phases (columns) is not finite, it might be either changed or updated.//
==Releases and release notes==
This is the repo all the developers are to contribute to https://github.com/SuperNETorg/iguana
As we go ScrumBan, we will deliver features on release-to-release. We go small releases and deliver more often. Each of the release will be related to a milestone https://github.com/SuperNETorg/iguana. Each milestone will contain release notes describing new features or bugs fixed wrapped into a release. Release notes can be used for information and PR matters.
==Testings==
The look of the files must meet 100% mockups. Desktop view in Firefox, Chrome, Safari and IE. Mobile view - Safari, Mobile Chrome
I would suggest a feature branch, do your development on feature branch some unit testing, once the tests are passed successfully and then merge back your code to development branch and do integration testing. once the build seem stable merge it back release branch(when ready for system testing). once all the regression testing is done and QA pass the build then merge it back to master branch for end user. This would significantly reduce bugs for end-to-end testing and most of the bugs will be caught initially would save time and cost.
==Commits==
Commit as often as possible