Requirements Don’t Solve the Real Problems

An interesting read here.

The concept is not new – Customer Collaboration is one of the core principles of the Agile Manifesto – but this article provides a nice focus on why traditional requirements are flawed.

Advertisements

Workflow Considerations

While evaluating ClearQuest to JIRA migration, I noticed there are some major differences in their default defect tracking workflows. They have different approach to even the most basic issues such as assigning or reopening a defect. In this post I would like to focus on some of the key differences, and suggest my opinion about them.

Before I start, you may ask why do I care about the default workflows? Every modern issue tracking tool is very customizable, after all. But the way I see it, the default workflow say something about the tool developers and their vision of defect tracking, so it may be something interesting to look at.

Continue reading

Set field requiredness in JIRA based on another field

I am new to JIRA, currently evaluating if we could use it as a replacement for ClearQuest.

One of the early challenges I encountered was to perform the task mentioned in the title. Specifically, when the other field is a checkbox. Let’s say we have a checkbox called ‘Related Document’ and a textbox called ‘Document name’. If the checkbox is ticked, then the user must supply the document name, and if the checkbox is cleared, then the text field should be read-only.

In ClearQuest it’s quite straightforward:

  1. Create a perl script as the ‘Value Changed’ event of the ‘Related Document’ field.
  2. Add the following code to the script:
 my $value = $entity->GetFieldValue($fieldname)->GetValue();
 if ($value)
 {
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_MANDATORY);
 }
 else
 {
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_READONLY);
   $entity->SetFieldValue("DocumentName","");
 }

In JIRA, it’s a bit more involved:

  • In ClearQuest, you define a field, and then attach it to a widget. In JIRA, the field type is also the widget, and usually it’s impossible to change it once set. So I need to use a checkbox-type field.
    There is no ‘single checkbox’ field type in JIRA, so I created a multi-checkbox field called “Documentation” with a single option, “Related Document”.
  • There isn’t an easy way to add ‘Value Changed’ events to fields in JIRA itself; I installed a plugin, called ‘JIRA Behaviours Plugin‘, which adds a lot of customization abilities.
So here’s what I did after creating the relevant fields and installing the plug-in (This took a bit of trial-and-error until I got it right…)
  1. Add a new Behavior (Administration > Plugins > Behaviors)
  2. Add the checkbox field to this behavior, and within it, add the following server-side validation script:
FormField relDoc = getFieldByName("Documentation")
String val = relDoc.getValue()
FormField docName = getFieldByName("Document Name")
if (val == "Related Document") {
 docName.setReadOnly(false)
 docName.setRequired(true)
} else {
 docName.setReadOnly(true)
 docName.setRequired(false)
 docName.setFormValue("")
}

It all seemed to work, except that when you initially open the form, the text field is enabled even though the checkbox is not marked. So, I edited the behavior, added the text field, and set it as ‘read only’.

Configuring JIRA is a very different experience than ClearQuest, both in concept and implementation; I’ll post more general CQ vs. JIRA thoughts later this month.