Hmmmm, ok. Sounds like you are really looking for suggestions related to work-tracking tools?
Github’s Issues feature (both issues and milestones) is what we use in software-land on 1736.
We tie one branch in git to each issue.
Issues are entered as work is discovered or requirements are defined.
Issues get assigned to people to work based on who’s available and who’s got the right skillset.
Milestones help group related issues by delivery timelines.
We rely on the review/comment/closure process inside issues.
We in turn ensure testing happens prior to closure, and (usually) merging/releasing only happens on reviewed issues.
It’s a fairly loose correlation so far, but with a small team you can get by with some sloppiness.
It’s fairly simple to pull up all current or closed issues to see who’s working on what, who’s accomplished what, and how close we are to delivery of known requirements.
Jira and Trello both can help serve similar purposes, but have different focuses.
On the topic of people: If the team is dead-set on one particular method of tracking work (ex: In a certain excel document) and is willing to be consistent on how they enter the data… You could consider creating some bespoke script to extract information from the teams tracker, and report out summaries in the formats customers are expecting.
Now, most of the tools I’ve seen tend to talk about how they support “Agile” as a marketing tactic, because Agile=modern(ish) in 2020. That’s not to say you couldn’t use waterfall strategies to deliver your software, and still document the workflow in the tools… I can’t think of any reason that wouldn’t be possible.
How big is your team? Small teams do not need agile or waterfall. If your team is big enough that you’re creating new projects so that students have stuff to do, you could adopt some process to make sure their projects are on track.
You should be writing unit tests regardless of your processes.
Our team is using Scrum based on Agile, with a tool called zentao. We think it’s ok to implement some frameworks that could improve work productivity and transparency, but the team itself matters even more as always if you get me:). For our testing job, we do it like this.
Once product backlog items (story list in zentao)have been listed,
1. Write cases based on story 2. Create a test request based on the build of a sprint 3. Link cases to the test request and run cases, if any case fails, report a bug immediately to dev 4. Get a report of this request 5. Submit next test request 6. The sprint is done, switch to next