Overview¶
The following will describe the process used in the 2019 project of the GIRAF project. It was updated at the very end of the project, to include all adaptations of processes, to help the year of 2020 get a headstart on the project. Most decisions will be described to explain the circumstances and arguments that made it the preferable decision at the time. We recommend that the year of 2020 try to replicate this process, and change it to match inevitable changes to your circumstances.
Best of luck.
How to read this guide¶
This guide is intended to be read partly as a cover-to-cover guide of the process that we developed during the semester. The primary focus, however, is for it to be a guide that you can go and look at, every time you are in doubt about the meaning of something. If you are a process group member, you will probably benefit from reading it almost cover-to-cover or keeping it very close to you in the first few weeks. If you are part of a development group, you will benefit greatly from the last sections that describe how the code lifecycle works. Other than that, you might be able to use the rest of the sections for reference in your report.
Introduction for the next process group¶
You have been chosen as the process group of this semester. It might be against your will, but nonetheless it's an important job that needs to be done. If this is at the very beginning of the semester, we recommend that you do of course read the entirety of the process manual, but for a quick-start you might read the following sections:
- General development in Process group information
- Project meetings
- Especially sprint intro and cross-group standups
- How to handle roles in Process group information
- Changing the process
Your responsibility is to define how project groups do everything: from writing proper code to meetings and releasing the code. Just remember: especially in the beginning it's a good idea to just take quick decisions and correct errors later. 30-40 people wait just for you to get started, so any plan is better than no plan. We do of course recommend our plan. That's still better than no plan.
To avoid micromanaging we don't care for how groups do things internally. We only care about things that affect other groups as well. So if one groups wants to work hardcore Scrum, and another don't want any formal process, let them. Just make sure that they participate in the common activities that you define, and make sure that you can reach them in normal work hours (preferably in person.)
Last but not least: Good luck, and remember that agile approaches (especially scrum) is not the answer! Both us and numerous groups before us experienced this!