openpyxl-redmine workflow tasks and relationships

Overview

Redmine has two ways of associating tasks:

  • sub-tasking which establishes parent-child associations between tasks, whereby a parent can have many children (1:N) and children can have only a single parent (1:1)
  • relationships which establish task sequencing, one task follows or precedes another, or whether a task can be closed before another, etc.

Warning

It’s very important to observe the difference between sub-tasking and relationships. In this chapter sub-tasking should not be confused with relationship!

Sub-tasking and relationships allow us to define a logically consistent way of defining a work project:

  • the work steps (tasks) required (who does, what, when, for how long…)
  • how steps (tasks) are sequenced w.r.t. each other (order, synchronization)
  • how steps (tasks) are grouped into different views (responsibility partitions)

Each project handling procedure (PMO, ERD…) has a top-level Redmine-project, however the purpose of the top-level task representation area may satisfy different requirements.

The PTC PMO projects redmine-project representation aims at provide a view of the work required to complete a PMO project which contains sufficient information to:

    1. identify the total FTE days required and which DATA teams are involved
    1. show the expected start and end dates of the project

The first is required by the PMO project cost estimate procedure. The tasks defined in the cost estimate and seen in the top-level Gantt chart are chosen to be understandable activities without showing the fine-grain task details which they represent. They also allow the chart to mark off regions of delay (examples: EEE-EET Beckhoff documentation preparation is needed before many other EEE activities can start, there is a delay for EEE-EDS module delivery after documentation preparation, and so on). The total FTE count for a PMO project is arrived at by summing the FTEdays column in the spreadsheet (or adding the days of the tasks in the top-level) and the responsible DATA team is identified in the Service column (Responsible DATA team).

The second is needed to show and track work scheduling of the work required, and in the ideal case aligns with the expectations of management and the PM (Project Manager) concerned. It is driven by cost-estimate spreadsheet columns:

  • FTEdays - the duration in days of a task,
  • Delay - the delay in days before a task starts w.r.t. a proceding task,
  • Type - Task are tasks, Group(N) are parents of 1 or more Tasks, Anchor is the topmost task of a PMO project,
  • RelatedIssue(s) - task(s) (or Groups) which need to complete before a Task (or Group)
  • Relationship(s) - the relationship type of the task association

and is seen in the Gantt chart top-level task view. The (s) in RelatedIssue(s) and Relationship(s) mean that multiple tasks can be specified.

Currently the only relationsionship type used is follows and all precedes are converted into follows.

The columns are shown below

cost-estimate columns

Cost-estimate spreadsheet columns

Inserting fine-grain information into the top-level

The mechanism foreseen uses the HoldingTicket(s) and HoldingRelationship(s) columns shown above, where

  • HoldingTicket(s) - are non-top-level Redmine-project task tickets, and
  • HoldingRelationship(s) - are the relationship type.

Currently the only relationship type foreseen is blocks which is being interpreted as the non-top-level task has to be closed before the associated top-level task can be closed.

An example of setting a blocking relationship is:

etest-enquire $API_key set_relationship 95925 82992 'blocked' 0
Holding ticket set

Holding ticket set on task

Guinea-pig tests

The guinea-pig tests of allowing non-DATA people to add to the top-level have shown the following two clause aim, problem results:

  • sub-tasks are added into the top-level, which breaks the simplicity concept of the top-level view.
  • sub-tasks are added with the purpose of the scheduling, but they fail because insufficient knowledge is available. The PM is not aware of HoldingTickets (it’s not documented) and PTC has not finalised this requirement with the DATA groups.

Thanks are still deserved by the guinea-pigs!

Conclusions from tests

  • Adding sub-tasks in the top-level should not be allowed
  • HoldingTickets should be used to mark out-of-top-level tickets
  • Extra sub-structure, if needed, should be inserted into a PMO project specific sub-project only.
  • Extra sub-structure should be added only when the need cannot be provided by HoldingTickets
  • The PTC python interface should flag scheduling changes resulting from the tickets associated through HoldingTicket changes. Longterm the interface should modify the top-level schedule automatically.

Adding a PMO project specific sub-project

An initial view of how the sub-project is added is shown below

PMO Redmine-projects, -sub-projects & -foreign-projects

PMO project Redmine-projects, -sub-projects & -foreign-projects

An initial set of rules to allow the Python interface to work

  • Assertion: parent and children are in the same Redmine-project
  • Simplification: follows (precedes) relationships exists only between tasks in the same Redmin-project
  • Simplification: Only blocking relationship(s) between tasks in different Redmine-projects are allowed.

Open w.r.t. initial set

  • Simplification: blocks must be 1:1 between task hierachies

Questions for out 13:00 zoom

  • General: What do you see as the pros-and-cons of HoldingTickets and sub-projects ?
  • Currently I see most of need for HoldingTickets coming from scheduling of tasks.
  • DATA should avoid extra work, i.e. David producing sub-tasks in the sub-project Redmine-project area.
  • I want to avoid milestones in Redmine and use the the Python interface to provide this functioanlity.
  • Who is allowed to define HoldingTickets ?
  • We should test the next steps with DP005. Let’s list the next steps.