Process
Agile
The term agile was coined in 2001 to describe a bottom-up approach to software project management based on very short iterations and frequent feedback from both developers and customers. [Masood2018] and many others have found it to be effective for student projects; we will look at one form called Scrum.
Right place, right time
Agile development practices are almost as old as programming, but they came into their own with the rise of the web in the late 1990s. First, the web made it possible to release software weekly, daily, or even hourly, since updating a server is a lot faster, and a lot less expensive, than shipping CDs to thousands of people. Second, during the 1990s and early 2000s it seemed as if web programming tools were changing every single day. Multi-year development plans didn't make a lot of sense when everything they depended on would be obsolete by the time work started, much less by the time it finished.
Third, the growth of the web was aided by, and fuelled, the growth of the open source movement. People couldn't help noticing that most open source projects didn't have long-range plans, but nevertheless produced high-quality software faster than many closed-source commercial projects.
...
Scrum and other agile processes work best when:
- Requirements are constantly changing, i.e., long-range planning simply isn't possible. This is often true of student projects, since the people on the team may not have worked in this domain or with these tools before.
- Developers and users can communicate continuously, or at worst daily or weekly. This varies widely from one student project to another: if you are your own customers it's not a problem, but if you have a real external client, you may only be able to meet with them every few weeks.
- The team is small, so that everyone can take part in a single stand-up meeting. This is usually true for student projects, though getting everyone to show up for a morning meeting can be a challenge.
- Team members are disciplined enough not to use "agile" as an excuse for chaotic coding.
- Everyone on the team can make some progress every day.
The last two points are the most important. Most developers don't like writing plans before they code, or documentation when they're done. Coincidentally, agile doesn't require them to do much of either. It's therefore all too common for developers to say "we're agile" when what they mean is "we're not going to bother doing anything we don't want to". In reality, agile requires more discipline, not less, just as improvising well requires even more musical talent than playing a score exactly.
...
Cutting Corners
A schedule's primary purpose is not to tell you what you're supposed to be doing on any given day, but to tell you when you should start cutting corners. Suppose that you have ten weeks in order to accomplish some task. Five weeks after you start, you've only done the first four weeks' worth of work. You have several options:
Denial.
This is very popular but doesn't actually solve the problem.
Start working evenings and weekends.
This is also very popular, but is quickly self-defeating. As Chapter 2 explained, the quality of your work goes down when you're tired, so any ground you gain by working until three a.m. you lose to extra debugging and rewriting.
Ask for more time.
Groups working in industry often do this (often in combination with the previous solution), but it usually isn't an option in an academic setting. Instructors have to submit marks at the end of the term; as far as the university is concerned, whatever hasn't been done by then might as well not be done at all.
Do less work.
You can either do less testing (which is quickly self-defeating) or update the schedule to reflect the rate at which you're actually working and drop features if it now shows that you won't be able to finish in time.
Let's return to our example. At the start of the project you believed it would take ten weeks. You're now at week five through, but you've done only the first four weeks' worth of work. Looking at it another way, your estimates for how long tasks would take were too optimistic by about 25%. You should therefore go back to your schedule and add 25% to each task's estimate.
...