Dirk Riehle's Industry and Research Publications

Category: 2. Building Products

  • The QDAcity-RE method for structural domain modeling using qualitative data analysis [RE Journal]

    The QDAcity-RE method for structural domain modeling using qualitative data analysis [RE Journal]

    Abstract: The creation of domain models from qualitative input relies heavily on experience. An uncodified ad-hoc modeling process is still common and leads to poor documentation of the analysis. In this article we present a new method for domain analysis based on qualitative data analysis. The method helps identify inconsistencies, ensures a high degree of…

  • Code of conduct for code reviews

    Code of conduct for code reviews

    On Twitter, @arkwrite suggested that a code review should always say something nice and @chaos_monster commented that we need a code of conduct for code reviews. All of this makes sense to me, however, I suggest that we first have a general code of conduct of productive discussions (and most companies have something like it).…

  • Who writes and prioritizes user stories?

    Who writes and prioritizes user stories?

    I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well. In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is: Who…

  • Product manager vs. product owner

    Product manager vs. product owner

    Alistair Cockburn pointed us to an excellent article by Melissa Perri about the differences between a product manager and (Scrum) product owner. The article clarifies some confusion. I’d like to repeat and emphasize some points that have been omitted (and where I also disagree). Foremost, a product manager works on products for a market (i.e.…

  • But what if someone steals my inner source code?

    But what if someone steals my inner source code?

    During my talk at the inner source summit, I was asked about the following worry with establishing inner source at a company: But if we lay all source code open within the company, don’t we run the risk that a disgruntled employee has it too easy to steal all code and publish it on the…

  • The patch-flow method for measuring inner source collaboration [MSR 2018]

    The patch-flow method for measuring inner source collaboration [MSR 2018]

    Abstract: Inner source (IS) is the use of open source software development (SD) practices and the establishment of an open source-like culture within an organization. IS enables and requires developers to collaborate more than traditional SD methods such as plan-driven or agile development. To better understand IS, researchers and practitioners need to measure IS collaboration.…