What do do with the Tasks?

  • Well I had some other ideas lined up to kick this tutorials forum off, but I believe it will be more useful and effective for me to figure these things out within the forum. That way, the tutorials don't get backed up waiting for me to write them. Plus I get the added bonus of thinking through writing. Always try to incorporate data entry into a task, if it is left for later you'll never be able to keep up.

    So here goes. I finally figured out that we are going to use the Tasks area to maintain the project schedules. After looking at the data items, it finally became clear that is exactly what they are meant to contain. I mean task time estimate and dependencies, hello!

    Here is the problem. I think it was great to decide to keep the project milestones in Tasks. It keeps them alive and in our faces. They can also become the audit trail we will need to create the quarterly reports for Pridco.

    The Tasks are also an excellent location to keep the SNAP Agile Process development schedules. Per UP, there will be two types of schedules: coarse and detailed. The coarse grain schedule containing the phases and the major development iterations. The detailed or fine grain schedules will provide the individual activities within each development iteration. Our three primary development efforts are: the SNAP Platform, the SNAP Eclipse Plug-in, and the SNAP Development Community. So up to this point I have these types of schedule information:
    Milestones (Quarterly)
    SNAP Platform Coarse Grain
    SNAP Platform Fine Grain
    SNAP Eclipse Plug-in Coarse Grain
    SNAP Eclipse Plug-in Fine Grain
    SNAP Development Community
    SNAP Development Community

    However, it occurs to me that these milestones will need a nitty gritty schedule of activities that are useful for keeping the quarter in perspective. It seems like the milestones are the coarse grain goals, and the weekly schedule are the fine grained goals. Sounds good because it brings everything together similarity-wise.

    The big question is how do I create all of the schedule items with out creating an administrative nightmare? It sure would be nice for SourceForge.net to have satellite tools that allow easier maintenance of this information. I mean clearly the tracker and task (probably everything) is maintained in a database somewhere, why can't they open up the database so that a project can access their own data using external tools. SourceForge.net remains the central repository, but now you have client-server based tools to maintain the data. Hmm..... sounds like a few new open source tools.

    Anyway, back to the problem. How do I represent all of these items. Let's take a look at SourceForge.net Tasks area in SNAP. First we have the subprojects, which I already flew off the handle and added Milestones, Brand, Ideas, Imagination, Execution, Delivery. If I want to browse, my options are subproject, user and status. Not much help there. The only other option is to examine the data items once again. Gee, you'd think I have them burned into my mind by now. Not much help there either. I was looking for some way to relate the two different grains for a specific effort.

    Since I'm not having any luck finding what I'm looking for, it occurs to me that I'm not quite sure what I am looking for, or at least what I need out of my solution. So let's start with the basics:
    I got two different types of schedule information relating to the same coarse grain goals.
    I need to create a relationship between the  grains.
    The major data item is subproject.
    I will probably maintain this same information outside of SourceForge.net in GanttProject, although no exchange of information will be possible. However, I will at least be able to see the schedule graphically.
    Need to be able to see relationships.
    Need to be able to find the task I need to maintain.

    Well that was helpful. It moved me to try a quick test. I saw that the column headings were links which led me to believe that the browse listing could be sorted.
    I can use dependencies to create relationships. Also since a task can have more than one dependency, the coarse grained tasks will be dependent on each of the individual related tasks.
    I can use the task times to gain more control over finding tasks. The browse screen allows sorting by: Task ID, Summary, Start Date, End Date, and Percent Complete.
    Finally, I can use the Summary to alphabetically sort the coarse grain and fine grain tasks, then I can use the dependencies to form the relationships.

    Were getting there, just a couple last questions to answer. What naming convention should I use for the tasks and how to support the iterations within the phases. Let's see if by solving the first, whether I solve the second. The summary naming convention should be:

    Level    Phase

    Where the level is either coarse grain (CG) or fine grain (FG). The phase is one of the SNAP Agile Process phases: Idea (ID), Imagination (IM), Execution (EX), or Delivery (DE). The milestone subproject will not use the phase portion of the naming convention. As an example, the following are some probable tasks for the upcoming idea phase of the SNAP Platform.

    CG-ID-Idea Phase
    FG-ID-Create Vision Document
    FG-ID-Create Risk List
    FG-ID-Software Development Plan
    FG-ID-Create Initial Use Cases

    From this sample, I realize that the tasks will still not sort correctly. The tasks can not be sorted by more than one column, therefore, in order to keep the tasks in relative order I need to add a numbering ordering scheme. The scheme must account for the fact that the sorting is alphabetical. It is also clear to me, that in order to keep the iterations separate, then I need to add an iteration number to the convention. Note: the iteration task itself will use iteration level 0, order 000. The revised naming convention is:

    Level    Phase        Iter Order

    So the sample becomes:

    CG-ID-0-000-Idea Phase
    FG-ID-1-001-Create Vision Document
    FG-ID-1-002-Create Risk List
    FG-ID-1-003-Software Development Plan
    FG-ID-1-004-Create Initial Use Cases

    Well only time and use will tell whether this will meet our needs. Two quick tips to take away from this tutorial. When in doubt, revisit your assumptions and objectives for the task. And always use an example to work through the details, and to safely test your assumption.

    • PJ Cabrera
      PJ Cabrera

      Hi Kevin,

      I like the task numbering scheme. It is a very clever way to use the tracker for phase and iteration scheduling. Well done!

      As a bit of an improvement, I would suggest that when tasks are first entered in a particular order, that you count task order in tens, like this:

      CG-ID-0-000-Idea Phase
      FG-ID-1-010-Create Vision Document
      FG-ID-1-020-Create Risk List
      FG-ID-1-030-Software Development Plan
      FG-ID-1-040-Create Initial Use Cases

      Why? Because there are often times the schedule needs to be modified by inserting tasks in between already existing tasks. With this scheme, you can do something like:

      CG-ID-0-000-Idea Phase
      FG-ID-1-010-Create Vision Document
      FG-ID-1-020-Create Risk List
      FG-ID-1-025-Create Business Case
      FG-ID-1-030-Software Development Plan
      FG-ID-1-040-Create Initial Use Cases

      Let me know what you think.

    • I LIKE IT!. You are absolutely correct. Wow, like major falshback. Probably before your time, but I remember that we always had to do that with ... what was it COBOL, maybe FORTRAN too. Hey gimme break it has only been about 20 years since I studied that. Don't even get me started on typing up Assembly programs on punch cards. You always knew who the Comp. Sci. geeks were, the dorks walking around campus with boxes of punch cards gingerly protecting our valuable cargo.