Our team have started on Scrum to move forward with our projects. So far, so staggering steps but, hey, we are new to it. We will learn by falling / failing and then learning from where we went wrong and fixing it.
One of the things that I have been looking at, partially because, as Joel on Software’s article, Painless Functional Specifications – Part 1: Why Bother?, puts it,
When you force yourself to write a good, complete spec … you notice all these things and you either fix them or at least you mark them with a big red flag.
The last company that I worked for never wrote specs. Documentation, pah. Not here. Not until my last three weeks where I wrote up the documentation on thirty odd projects. In theory, great, but I was describing the existing system, rather than having a system to check my programmes against spec. Projects were late and needed patching because there was no description of what was being planned to communicate.
I am currently working on a project which I am writing documentation for. Again I have sort of started in the wrong way. The spec has not been written at the beginning and writing it up now, I can see issues with the existing systems. I can see where they are and can fix them. No spec, not entirely clear what the issues are. It also means that other team members working on systems which interface with mine or managers need to report on progress. It takes pressure off me, the developer, to be on hand to describe how the system works or to diagnose issues before they arise (well try to anyhow).
So where to now? Well. I need to do some writing and create both functional and technical specs. I will learn, and possibly fail at some point only to pick myself up again. A starting point, apart from trying, is to read the other Joel on Software articles, keep researching and writing.
No Comments