''Is anyone managing Tasks and TaskQueues on Wiki instead of on IndexCard''''''s or Whiteboards?''


Instead of a TaskCard on IndexCard''''''s, we use WikiPage''''''s with a reference to '''Category''''''''Project''''''Name''''', '''Topic''''''Task''', and '''Topic''''''Iteration''N''''' 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 IndexCard''''''s, 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 '''Topic''''''Task''' page and press its title. To see all the tasks in the 2nd iteration, we go to the '''Topic''''''Iteration2''' page and click on its title. To see all work in ''all'' iterations we just go to the '''Topic''''''Iteration''' 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 '''Topic''''''Task''' to '''Topic''''''Task''''''Done'''. 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''' WikiPage''''''s. Instead of '''Topic''''''Task''', the UserStory pages reference '''Topic''''''Story'''. 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