Choosing a method

The design of the PCB has been sent to Alexis Polti and we are now moving from the hardware part of the project to the software part of it. Of course we will have to come back to hardware, as soon as the PCB and components arrive.

Today the group met to talk about the methods we are going to use during software developments of RoseRolls. Luckily for us, both Loik and Quentin have had experiences with the Agile methods in the companies they work or worked for. More specifically, they gave Charles and I a quick update about the Scrum method.

First they explained the different roles that are defined by this method: project owner, scrum master, systems integrator, developer. We all agree that assigning one role to each person would not really fit the context of our project. Nevertheless, defining these role will help us to adopt the right state of mind when performing certain task.

We will also have to manage the various task to implement the users’ stories. We will have four state for a task: to do (it has not been started yet), in progress (one of us is currently working on it), resolved (the developer considers it done but it has not yet been intergrated), done (it has been integrated).So far we have decided to use both the functionalities offered by Github and a paper version based on Post-it because it has a more visual aspect. After one week we will decide whether we want to keep only one of the two or the two according to what work best for us.

We will organize our git repository as following:- each developer has its own branch titled with his name
– developers branches are merged with the Dev branch each time that a task is resolved.
– master is merged with Dev once Dev is stable.

We plan of doing a “scrum”(meeting) of about 15min. Right after we will integrate jointly what has be done the day before. We are trying to avoid the possibility for two person to integrate at the same time on the Dev branch (that’s the problem when developers are integrators as well).

We also plan on doing peer programming as much as possible. However, we forecast that it will not always be possible due to each member personal schedule.




Commentaires fermés.