News
15 December 2021
News
Готово!
Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook
Ok
How to use DDD and BDD in system implementation
Hey everyone! For several years now, I have been working in process design and ITSM system implementation. In system implementation projects, I aim to employ the principles of BDD (Behavior Driven Development) and DDD (Documentation Driven Development), as well as a little of KCS due to my own laziness (the engine of progress, as they say) and a strong unwillingness to go over things multiple times.
It is no secret that many people hate to write documentation, especially user manuals, and I am no exception. Before, when I used to work in the operating unit of the internal IT department, I had to be asked to write a manual multiple times before I would finally sit down and do it — and when I was not asked to, I would not write it.
It is no secret that many people hate to write documentation, especially user manuals, and I am no exception. Before, when I used to work in the operating unit of the internal IT department, I had to be asked to write a manual multiple times before I would finally sit down and do it — and when I was not asked to, I would not write it.
In a systems integrator, things do not work this way — first of all, here you always put the documentation into writing as you are implementing the associated system. Secondly, a few years ago, I realized why I disliked writing documentation: this is not something that should be done after one has already completed their work on the project. When you sit down to produce a user manual after you have fully set up the system, demonstrated it to key users, conducted several Q&A sessions, and made adjustments, your train of thought goes something like this:
I have already explained everything to everyone a hundred times — what else is there to write about?
I saw these settings a week ago, and now I have to go back to the same settings, this is so annoying!
And what did we mean to say here? Now I need to reread the documents and comments again…
Essentially, the sentiments usually boil down to "I am doing the same thing all over again." This is when I stumbled upon the KCS methodology, which helped me take the first steps towards adopting the principle "document first, do second."
For large projects, we have a team of technical writers who can be entrusted with this task, especially if there are requirements to the style, process notation, and so on. However, if the project is small, the involvement of technical writers can greatly slow down its implementation and increase the cost for the customer, all while having little to no effect on the quality of the documentation produced.
But what does all of this have to do with the practices mentioned in the title? Let's have a closer look.
EXAMPLE
For a small Jira implementation project, we write:
– Terms of reference;
– System settings documentation (transition logic in processes, security settings, automation, etc.);
– API description for developers of related systems (optional);
– User manual;
– Administrator's manual.
To learn more about each item on the list and read the author's conclusions, see the full Habr article.
I have already explained everything to everyone a hundred times — what else is there to write about?
I saw these settings a week ago, and now I have to go back to the same settings, this is so annoying!
And what did we mean to say here? Now I need to reread the documents and comments again…
Essentially, the sentiments usually boil down to "I am doing the same thing all over again." This is when I stumbled upon the KCS methodology, which helped me take the first steps towards adopting the principle "document first, do second."
For large projects, we have a team of technical writers who can be entrusted with this task, especially if there are requirements to the style, process notation, and so on. However, if the project is small, the involvement of technical writers can greatly slow down its implementation and increase the cost for the customer, all while having little to no effect on the quality of the documentation produced.
But what does all of this have to do with the practices mentioned in the title? Let's have a closer look.
EXAMPLE
For a small Jira implementation project, we write:
– Terms of reference;
– System settings documentation (transition logic in processes, security settings, automation, etc.);
– API description for developers of related systems (optional);
– User manual;
– Administrator's manual.
To learn more about each item on the list and read the author's conclusions, see the full Habr article.
Related news
- 14 August
ICL Services and TMAXSOFT signed partnrship agreement
Under the agreement our company will be using the TMAXSOFT solutions in its own projects.
- 24 March
ICL Services Expands Red Hat Product Service
ICL Services runs a subscription service to Red Hat products technical support.
- 22 June
ICL Services Entered Top100 Best Outsourcing Companies
ICL Services is one of the largest providers of IT support services in Russia.
- 11 March
ICL Services delivers digital transformation of Service Desk
The customers now can receive support on the first line using digital service channels.
Contact us
Leave information about yourself and your company to get a detailed presentation.