Comments for Doing better

Comment on Things left unsaid… by Austin Hastings

Austin Hastings — Mon, 29 Jun 2009 00:35:46 +0000

It’s not how well the bear dances…

Comment on Things left unsaid… by Bill Mattocks

Bill Mattocks — Mon, 29 Jun 2009 00:09:12 +0000

Nice! Writing compilers, eh? Amazing.

Comment on Dimension: Requirements or Business Demands by Doing better » Dimension: Requirements or Business Demands « Peter Bakker’s Sketches

Sun, 27 Jul 2008 08:38:17 +0000

[...] Tags: Governance, RM, Stakeholders On the “Doing better” is an article posted about Dimension: Requirements or Business Demands: Changing or unknown requirements can be a huge source of problems for a development team. [...]

Comment on Microsoft's take on database change management by Jim

Jim — Tue, 27 May 2008 15:33:32 +0000

Hi! Glad you enjoyed the session. The DB edition has a data comparision tool (similar to the schema compare), which would detect the new “IQ” entry. Currently only MS SQL Server databases are supported.

Comment on Dimension: Requirements or Business Demands by Peter Bakker

Peter Bakker — Mon, 17 Mar 2008 20:09:38 +0000

Austin,
For me the biggest requirements challenge is that the stakeholders should be responsible for managing their own requirements and they shouldn’t trust a temporarily project team to do it for them. A project team by nature will focus on the design and build stages of the system lifecycle and put other requirements important to the other lifecycle stages on a lower priority to meet their own deadlines. When a project team starts building there is too little time to keep managing new or changing requirements and redesign or rebuild stuff…
In theory most projects do have some external (outside the project) steering committee or governance body but in practice they most of the times do not take their responsibility but they do trust the project team fully as long as the team meets its deadlines. Stakeholders must and should be able to validate their requirements continuously and not only just before and after the design and building stages.

On my site I ended the post with the reference to this article with:
When do the stakeholders see that they must take responsibility to manage their own requirements during the total lifecycle of a system and they must do that from an outside-in view (looking to the system from its context)? And that if they need tools for requirements management it must be community-enabling social networking tools….

Comment on Dimension: Requirements or Business Demands by Austin Hastings

Austin Hastings — Mon, 17 Mar 2008 17:59:21 +0000

Peter,

It has never occurred to me to think of understanding requirements as a challenge. I think in general that whenever I have seen requirements being managed, the team “just knew” what the requirements were and were not. Maybe that was because of good training, or because they hired a SME for the requirements gathering phase.

On the other hand, all those RQM tool vendors offer training, so it’s probably not totally intuitive. So how can we characterize the “amount” or “intensity” of the requirements challenge? Is it worse to not know what you want to manage, or if the stakeholders don’t agree on priority?

Are there other characteristics of requirements challenges? What about social identifiers?

Comment on Dimension: Requirements or Business Demands by Agile Cases

Agile Cases — Mon, 17 Mar 2008 11:57:33 +0000

Doing better » Dimension: Requirements or Business Demands

On the “Doing better” is an article posted about Dimension: Requirements or Business Demands:
Changing or unknown requirements can be a huge source of problems for a development team. Fortunately, configuration management is designed to su…

Comment on Dimension: Requirements or Business Demands by Peter Bakker

Peter Bakker — Mon, 17 Mar 2008 11:30:47 +0000

The most confusing part about requirements and requirements management is the unclear definition of the term “requirement”. Some people are saying everything that constraints a system is a requirement other do use smaller scopes, like stating that requirements only should be in the problem space or that requirements are the implementation of rules (whatever they mean by rules).
So how can you manage if it is not clear what you want or should manage?

Managing stuff like rules, principles, interests and requirements in order to make a success of projects is a social issue and not a technical one. If the stakeholders are not willing to pursue the same goals and don’t have empathy for each others concerns then no process, method or tool will help to solve the problem of the failing projects…

Comment on Antipattern Repository by Austin Hastings

Austin Hastings — Thu, 09 Mar 2006 11:53:54 +0000

Think for a moment about what you just said: you want all your stuff using a common repository.

Thing is, all your stuff doesn't even share a common approach to storage. Blogs and Plogs and Forums are storing their info in databases, source code goes in files, AutoCAD is writing single giant entities (either a megafile or a custom database, your cal).

I think what you really want, and this is probably worth money, is a common repository interface. And I don't mean WebDAV.

I think it's some common mechanism for specifying release/branch/time configspecs that gets shared across everywhere.

Part of that almost certainly translates into something implemented at the OS level, for performance. But the rest of it I think has to be worked in to applications. Are you familiar with OS9's backup mechanism? A virtual directory of datestamps that can be traversed to find a version of a file at some arbitrary timepoint.

That mechanism, or something like it, probably needs to be generalized.

The right place to start, I think, is with a journaling filesystem. After all, that's how the big storage is implemented, so it's certainly where implementation will have to go. Beyond that, there's some kind of mixin technology that permits identifying branches.

I think I'll post on this, if you don't beat me to it. Maybe a CMJ article...

Comment on Defining: Baseline by Austin Hastings

Austin Hastings — Thu, 09 Mar 2006 11:21:05 +0000

Robert is right about surveys in the UK. But they were “triangulations” and apparently nobody used the term “baseline.” I think that was because baselines were only needed when allocating property that the government was going to hold and sell off. The UK, of course, qualifies as one of those ancient civilizations where every deed was describe using the “10 paces past the frog pond to the tree stump” mechanism.