Jordi Bodera from ISDD Projects Office joins our team as scrum master ; his task is to help us
implementing the scrum methodology within our team.
We will designate a Product Owner ; then, starting from 21th of August stories and things to do
from the Product Owner will be decomposed in smaller issues.
At the moment we do not have a physical board to put our backlog and tasks etc ; we thought we
could just use the gitlab Board feature (from gitlab issues).
The question of the social aspect of the physical board arise, maybe we will install a physical board,
it depends on how it goes with scrum in the following weeks.
The proposed duration for a sprint is two weeks. We will see if it needs to be adapted.
We plan to have daily meetings, very short in time, to keep everyone up-to-date and in sync.
Proposed time : 9:30 am.
Again, we will see if it is something we can do, or if we have to change.
So, the first Scrum sprint will start on the 28th of August.
Concern about operations vs BLISS project tasks
It has been said Scrum can only work if the developers can really focus on their development
tasks for BLISS. That is, effectively implementing the new BCU organisation. The biggest
fear is to have to face angry scientists.
I will meet Andy when back from holidays, in order to see how to make sure beamlines are aware their
current contacts will be busy for BLISS, and thus that developers are relieved from operation tasks
(at least, 80% of those). An official communication is required.
It seems the biggest problem is with ID16 at the moment.
We didn't have time to continue the documentation effort since last meeting. However we
all agree it is something we have to push forward.
We will put all documentation at one place, with the code in the same git repository. This
includes what is currently in wikis (ESRF-specific recipes, existing documentation). The goal
is to make sure everything is coherent and easily findable and editable by everybody in the
Documentation will be stored in Markdown files. Then, Continuous Integration will build
the Sphinx doc automatically.
We made a review of pending issues ; things to be done until end of August.
We would like to establish which coding convention to follow ; then, we need to update
existing files to obey the coding convention. Finally we won't accept merge requests
violating the coding convention.
It has been proposed to use PyFlake8 as a base. Some rules can be adapted (like line length,