In several issues we encountered an ambiguous usage of project management terminology within the Storm module. For example, a "Storm Ticket" has several categories, including "Task". Also there is a own content type for tasks (Storm Task), but it should be either a ticket or a task, not an ambiguous mixture of both. Also, a Storm Ticket can be assigned the category "Task", but it can't be resolved with a Storm Task.
To resolve issues like this, I'm suggesting to develop documentation for the terminology used in Storm, especially definitions what the different content types are, how they relate to each other, and what they are supposed to be used for. This might help to clean up terminological confusion like in this issue #1178720: Allow to resolve Storm tickets with a Storm task.
Comments
Comment #1
asb CreditAttribution: asb commentedFor starters: Wikipedia definitions.
Project, http://en.wikipedia.org/wiki/Project
Or, more general, from Oxford English Dictionary:
The key elements from those definitions are: "temporary endeavor" - "collaborative" - "carefully planned" - wants to "achieve a particular aim" (= product, service or result).
Task (project management), http://en.wikipedia.org/wiki/Task_(project_management)
The key elements from those definition are: "activity" - "defined period of time" - can have "assignments" and "dependencies".
In Storm's terminology, an "assignment" probably matches more or less a "Storm Ticket" (at this point, Storm seems to move away from project management and switch to Bugtracking terminology).
Ticket (in an Issue tracking system), http://en.wikipedia.org/wiki/Issue_tracking_system
This terminology is interesting since it matches the usage in Storm (tickets are created not by the end user, but "in a help desk or call center environment"). However, we'd still have no way for users to report an incident within Storm.
In this definition the connection between "Issue" or "Case" and "Ticket" isn't clear to me. Wikipedia continues:
Issue (in an Issue tracking system), http://en.wikipedia.org/wiki/Issue_tracking_system
So there seems to be a difference between an "Issue" or a "Case" and a Ticket". If we actually had a way for users to post Issues in Storm, we'd get a Issue tracking system ;)
Comment #2
juliangb CreditAttribution: juliangb commentedI'm not convinced that there is a major difference between a ticket and an issue - and hence don't see the need to have issues as well. Some systems will use issues, some tickets.
On the definitions of task and ticket, IMO the Storm types seem to match fairly well.
How can we progress this to a solution?
Comment #3
asb CreditAttribution: asb commentedProbably there is no quick solution. Maybe we should wait for comments of other users.
If we say (Storm) Ticket := Issue, we run into this again:
Issue management, http://en.wikipedia.org/wiki/Issue_management:
That's the definition I'm familiar with, and this leads us again to the dead end since there is no way to address Storm Tickets since they're the end point of the content type hierarchy. Thusly, we'd need to say: (Storm) Task := Issue.
Process Flow in the Issues Management Process from Source: http://www.pmhut.com/issues-management-process:
A typical issue workflow in product or software development, according to http://en.wikipedia.org/wiki/Issue_management:
Where the [in test] and [in work] phases often loop, and none of this would imho work in Storm, unless all phases occur on the same Storm Task node (which would mean to lose the phases' history, and it wouldn't allow for proper loops). Indeed this is complicated :-(
Comment #4
juliangb CreditAttribution: juliangb commentedI'm not convinced that we need to define Tasks / Tickets more specifically.
Please reopen if there is specific action we can take to help.
Comment #5
kaizerking CreditAttribution: kaizerking commentedHi juliangb,asb
For your benefit of understanding The a project will be as follows
1. Project is a structural plan frame to execute a work/job
2. Job is broken in to chunks/pieces of work We call WBS element(Work break down Structure) according the requirement/feasibility. granularity/accountability.Some call this as Task some as WBS Element in MS Projects it is called "Task"
3.Each WBS element may have or may not have Activities i.e the actual execution such as digging a trench where the value addition happens to the work, The WBS element may/can have one more WBS element in parallel or Hierarchical tree structure the levels can be un limted.
4.These Activities may or may not be linked/related to each other
5. An activity will have a start time and Finish time
6. When a relation exists between the activities then we define relations as SF or SS or FS or FF
Start to Finish ,Start-to Start, Finish to Start, Finish to Finish
7 if there is time gap between two activities then we call the deference as "Float"
8.The activities as a group is called Activity Net work or simply "network"
9.Where there is not enough float and deadlines or very strict and narrow the work path of activities is called Critical path.
10 A Project Typically have stages
a) Plan -> Schedule->release->Execute->Report(confirm the work done in quantities) ->Close
All the stages can revert to previous stage if wished how ever all the changes have to be logged to record to report and see the variations in plan change to attribute the changes in result. This is normally viewed in graphs, bar charts, pie charts S curve apart from normal tabulated sheets etc..
11.Every time you plan or change plan you need to extrapolate ->schedule or re-schedule
12. Scheduling means declaring the start date and end date and the flow of activity network.
13.Planning is done for various resource This is known as Multi Resource Planning (MRP)
1.Cost planning (plan the costs estimates for various WBS Tasks or Acivities)
2.Financial planing(Budgeting)
3.Material Planning (included in cost Planning)
4.Work Force Planning
14.Same way Scheduling is also done for Multiple Resources it is called Multi Resource Scheduling
it determines what is required, where is required when is required .How much is required is the "plan"
It may be a good idea to call the task as WBS task to make it is easy for all
Now coming to the point of Issue:
A issue is the mother of task , it is only a point of concern or a requirement raised by the client or team member, which will be converted in to a task or Activity and a resource allocated (plan) give time lines and Schedule,the resource will execute/solve the problem and report(confirm it is done and enter the times) Sometimes there is a client acceptance for the work and then the times will be approved -Close
hope that clarifies.
Just yesterday only i happen to stumble on this STORM while i was searching for Project management module.downloaded the D7 version, read the document provided in the documents, it seems the document is for D6 needs work for D7.
I did not get how it works can some one put the steps please