08-08-2013 09:47 AM
This document was created for the myRIO Balancing Robot Project https://decibel.ni.com/content/groups/myrio-balancing-robot |
Continuous improvement of the process
“The process description should not being misinterpreted as a command. The process itself shall be agile and continuously improved by the team.”
Quote: Eckhart Hanser, Agile Prozesse, Chapter 7: http://www.amazon.de/Agile-Prozesse-eXamen-press-German-Edition/dp/3642123120
This document describes the Development Process that will be used by the myRIO Balancing Robot project team. The Process Model is a blend of different Agile Process Models. If you're all new to Agile Software Models: http://en.wikipedia.org/wiki/Agile_software_development gives a good overview and introduction.
The agile model was chosen because of two important reasons:
This document is not ment to be dead. If you think something is wrong, not explained well or missing: please comment. Also if you think there are good things in it: please comment!
Please link additional sources that you think are useful for a better understanding of the process.
And: Cooperation is one of the main ideas in agile software development. All team members take responsibility for the outcome of the whole project. Everybody is invited to actively participate in the Community, to contribute his ideas.
The following process guidelines define best practices that will be used for the development of myRIO Balancing Robot.
The development process is agile. The requirements for the product are constantly evolving. They build a moving target.
Quote: Hanser - Agile Prozesse, Kapitel 1: http://www.amazon.de/Agile-Prozesse-eXamen-press-German-Edition/dp/3642123120
Also the project team is constantly evolving.
In order to meet this demands, an agile model is best suited.
One of the most used Agile models nowadays is Scrum. Also NI internally Scrum is widely used. See this NI talk resource for further information: http://nitalk.natinst.com/people/scot/blog/2011/03/14/scrum-in-5-minutes
Scrum provides some great technics, on the other handside Scrum is quite restricted concerning the roles in the team. For the myRIO Balancing Robot a pure Scrum process is not feasible due to limitations in the project team (triple role of Adrian Schmid).
Therefore an adapted Scrum with some additions shall be used for the development of myRIO Balancing Robot.
In the following the process shall be described.
The Kanban Wall is the heart of the process.
See: http://en.wikipedia.org/wiki/Kanban_(development) for an overview on Kanban.
The Kanban Wall for myRIO Balancing Robot is hosted on: https://www.symphonical.com/wall/swmaX
Every project member has an account on that wall. If not ask adrian.schmid@ni.com to create you one.
A Sprint is one interation in the Agile Development Process. In the myRIO Balancing Robot project, a Sprint is one week long.
At the beginning of a Week a short Meeting is held in which the involved project members define what should be implemented the next week. All this items form the Sprint Backlog.
At the end of the Week, a Sprint Summary is being written, which describes what has been released, what problems occured etc.
For example Sprint 3 Summary can be found here: https://decibel.ni.com/content/docs/DOC-30570
The backlog is the “Requirements Specification” pendant in an agile process. The backlog is filled with user stories that must, should, could or won’t be implemented over the whole process.
User Stories are used to describe What needs to be developed.
http://en.wikipedia.org/wiki/User_story
The user stories shall be written on the base of a template.
User Stories have an unique number following the pattern: U-XXX: Name
Story Points are used to estimate the workload of a user story.
Description:
http://ksimons.de/2011/06/story-points-verstandlich-erklart/
The following scale shall be used: 1, 2, 3, 5, 8, 13, 20, 40, 100.
The assumption is, that a developer is able to develop 3 Points per day.
Whenever a user story gets too big, or is too vage to be developed without further information, the user story shall be split up in different parts. The overall user story is then called an epic.
See: http://www.allaboutagile.com/thats-not-a-user-story-thats-an-epic/ for more information about epics.
Epics have an unique number following the pattern: E-XXX: Name
Restrictions that a project must fullfill are listed in the backlog.
Restrictions have an unique number following the pattern: R-XXX: Name
This document covers some of the Methods and Ideas that are used for the development of myRIO Balancing Robot.
If you have any questions or comments please let me know.
A good starting point is the book of "Agile Prozesse" (only available in German) written by Eckhart Hanser.