In the final report of their internship, the students of our school must have one chapter where they "document" the developed work. When using the “waterfall” methodology, they usually have one sub-section for each stage:
What if an agile methodology like XP or SCRUM is used? Every year we have the same problem, as some teachers say it should be done one way, while others say the exact opposite.
Any ideas?
In SCRUM, during the end of each sprint, there is a Sprint Retrospective and Spring Review. Important artifacts from the two should be extracted into this report, as it reflects the "developed work".
I'm not sure the scope of what you require from your students for documenting the work, is it for the whole internship, or just one cycle? In any case, because Agile is done incrementally, they can just write one template per sprint they've completed.
Agile doesn't mean "don't plan", so there should be plenty to talk about.
Have your students developed user stories? Can they talk about these? For example, let's take this example user story:
As a teacher, I want to automatically mark assignments so I'm not spending time checking code that could be done automatically.
It might be worthwhile to encourage your students to consider how and why they wrote their user stories as they did. You can check that they're not developing user stories that are too broad (too many epics rather than stories) as they go along if you want to provide some support and prevent them from being too unrealistic.
As you should probably be estimating the amount of work for each user story, ask them to document that so you can check it. Unrealistic timings—or no timings at all—should be caught early so that you can make sure they finish the project on time.
If you follow the 'planning game' of XP, then you can also look at how the requirements were sorted by risk and value. Yet another point to document and mark if needed.
As mentioned by Kaneki, sprint retrospectives provide time for your students to reflect on their progress. Encourage them to use this wisely in place of a huge specification detailing implementations, tests, etc.
In short, there's loads to document about Agile, but you might not need to write everything on paper. If it's easier for you, consider just being a part of the retrospective meetings and looking at how these go instead of meticulously writing down every detail.
If the system is object-oriented, you can use UML class diagrams to document the design. Eclipse has a plugin called ObjectAid that generates these diagrams from the source code (no additional work required).
Students can generate professional documentation from their source code. There is jsdoc for JavaScript and javadoc for Java. These require specific comments and tags, but it's well worth it. Source code documentation is important for future development.
For all types of diagrams, there's draw.io, Balsamiq, PowerPoint, Visio, and many more. A picture is worth a thousand words.
