ICL Services
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.
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.
Share:

Related news

    Contact us

    Contact Press Service
    Phone +7 (499) 239-92-69

    pr@icl-services.com

    Stay informed

    Subscribe to our newsletter and keep up with our latest news

    Subscribe to newsletter
    Ok
    icl-services.com uses cookies, and by continuing browsing the website you give your consent to the use of cookies by us. Otherwise you should leave our website after reading this.

    Ask a question

    Name*
    Email*
    Company*
    Position*
    Phone*
    Message*
    Please see the Privacy Notice further information regarding your rights.

    I have read the Privacy Notice and consent to the processing of my personal data

    Request a call

    Name*
    Phone*
    Email
    Company*
    Please see the Privacy Notice further information regarding your rights.

    I have read the Privacy Notice and consent to the processing of my personal data

    Up