myRIO Balancing Robot

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

myRIO Balancing Robot - Development Process

Community Logo.png
This document was created for the myRIO Balancing Robot Project
https://decibel.ni.com/content/groups/myrio-balancing-robot
myBOT.png

Process Description

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

Overview

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:

  1. We're working towards a moving target: At the beginning of the Development Process it's not clear, what the outcome should look like.
  2. The project team is constantly evolving: Student teams from all over the world are joining in, also the NI inside project team is evolving.

Table of Contents

1. Cooperation

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.

2. Process Guidelines

The following process guidelines define best practices that will be used for the development of myRIO Balancing Robot.

Agile Model

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.

Kanban Wall

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.

Sprint

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

Backlog

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

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

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.

Epics

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

Restrictions that a project must fullfill are listed in the backlog.

Restrictions have an unique number following the pattern: R-XXX: Name

3. Conclusion

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.

4. Sources

5. Further Information

A good starting point is the book of "Agile Prozesse" (only available in German) written by Eckhart Hanser.


0 Kudos
Message 1 of 1
(4,969 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.