| || |
Documenting SDLC in Agile/Scrum
I was hoping to discuss or have anyone share their experiences in this scenario.
I work for a company that builds its own hardware and creates software for that hardware, everyone is in house and we use an Agile/Scrum methodology for all of the software work. The company is rather small and the software team of about 7 takes on the responsibility for most of the planning, requirements etc. of the software with some input from business and marketing departments for direction.
Managements new thing this year is that they want a SDLC document to define the software creation process (we sometimes take on government contracts where such a document would be helpful).
This task has fallen on me to atleast start the document. I am stuggling however, SDLC documents tend to be for waterfall or iterative models traditionally so I am not seeing a clear way to create this document for our Agile/Scrum workflow.
We do have several standard operating procedure documents already such as SW development process, bug entry, QA process etc. and it seems creating an SDLC document would be duplicating a lot of this information already in these documents.
So I have narrowed this down to a few possibilities...Should I create a very high level, general document for the SDLC with references to the existing SOPs and call it a day, should I just create a sort of index listing out the SOPs that cover this process (some new ones may need created to fill gaps) or should just create a mammoth document that covers everything and following something like the Disciplined Agile Delivery model?
Looking for any examples through google or anywhere else only really turns up SDLC documents based on waterfall so its hard to really use any as a guideline so any ideas, suggestions or experiences appreciated.
I hate documents and would rather just be testing
Many Agile shops have taken the approach of collapsing their documentation into tests. Frameworks like cucumber, that forces the dev team to describe their product in a Domain Driven Language such as Gherkin.
Originally Posted by Resputan
In Gherkin, users write their tests in the form of statements in the form Given... When... Then... format.
Using that, the automated test serves as the internal documentation for the product.