Is anyone managing Tasks and TaskQueues on Wiki instead of on IndexCards or Whiteboards?
Instead of a
TaskCard on
IndexCards, we use
WikiPages with a reference to
CategoryProjectName,
TopicTask, and
TopicIterationN at the bottom of the page. The rest of the page looks just like a typical
TaskCard except that it may also reference that
UserStory page that it was derrived from.
While not as convenient as
IndexCards, it does have its own set of advantages. If we want to see a list of all tasks in a project, we simply go to the
TopicTask page and press its title. To see all the tasks in the 2nd iteration, we go to the
TopicIteration2 page and click on its title. To see all work in
all iterations we just go to the
TopicIteration page since pressing its title will match the pattern Topic
Iteration[*]. When a Task is completed, the person who
claimed the task changes its reference from
TopicTask to
TopicTaskDone. Going to this page and pressing its title shows all completed tasks. Its great to be able to go to a Completed Task Page such as Make
Response
Schedulable and add a reference to Refactor
Make
Response
Schedulable to create a new page for a Task that improves on the original task.
Tasks start out with out any owner. When you are done with your current task, you can
claim a new task. This is done by creating a reference to their
WikiName in the text of the Task they want to perform. This process is called
claiming the task. This also allows one to list all tasks a particular engineer is working on by searching on their
WikiName and the Topic
Task.
While I'm not completely happy with this method, it does seem to work very well, encourage collaboration, and provide project status visibility to all stakeholders. We also make all our
UserStories WikiPages. Instead of
TopicTask, the
UserStory pages reference
TopicStory. We then create the tasks for each story
in the story page by creating a new
WikiName for the task (anywhere in the story page) and then pressing its question mark to make the
WikiName a Topic
Task
WikiPage. This way, each story references all the tasks it has produced. These new pages are only created as the tasks are thought of.
--RobertDiFalco
I am doing something similar. The problem we faced was having to arrange the cards at meetings, and the fact that only one person can
hold the actual cards (we are not doing true XP, and are not all at the same location, except for meetings). By having them on our Wiki, we all have easy access, and we pull up the actual pages during our meetings (we have networked computers connected to projectors in certain meeting rooms). During the meetings we move things around, add text, and assign action items. It is not as fluid as paper, but at the end of the meeting, the Wiki is up to date. --
RichardBash
We started out using Wiki for project relevant information, e.g. stakeholder
contact details, Todos, software information, tips and tricks .... all the kind
of information that would normally be gotten from the
TruckNumber-person, i.e.
TruckPerson.
Having gotten a rough idea what was to be done, we did a series of scenarios [our terminology for
UserStories] on index cards. Once we had a first version,
we typed them into Wiki. What we did next was to identify components and sequences which corresponded with the scenarios. Components where described
using CRC principles but, for reasons of understanding, the term Object was
avoided. The next step was the design of an architecture, this was then also
stored in Wiki.
Unfortunately what has now happened is that the stakeholder wants a document .... a Word document -- what we have is a series of HTML pages! But that isn't a
problem -- a couple of AWK scripts later -- one large HTML document built out
of the various pieces lying around in Wiki, plus the advantage of being able
to modify the parts and being able to generate a whole. But ofcourse this document does not match with the company document standard. This problem remains
open .....
--
GerritRiessen
ChangeTheStandard.
CategoryCard