fix a problem or find a new one... Wiki or svn....
Does it really matter. We are using svn to store the narratives in our current project. But after some iterations we had some problems. With some stories spanning multiple iterations (inspite of our efforts to aviod it) we had about 3 to 4 copies of the same story. So there we were, two distributed teams updating the same narrative in different versions in different iteration folders. Then there was the comments and questions that were being added on to the cards, owing to the fact that our two teams were working at two different time zones... All this lead to us having multilple versions of the same card being updated at different times in different versions. Huh... what a mess.
Thats exactly what we thought and we decided we could try and solve this problem by updating these cards on to a wiki page. This way we could atleast have only one copy of the story narrative, never mind the pain we had to go through to update the wiki page and not being able to link supporting documents (it may be possible, but we didnt have the required expertise in the team. May be we should hire a wiki expert for this).
But then, if we managed to maintain multiple copies of a story narrative in svn what would stop us from doing this in wiki. After all there was nothing stopping us from creating two pages for the same narrative and having it in different iterations. Also there was the problem of not having versioning for the story narratives.
Any way my intension is not to weigh the pros and cons of the wiki and svn and then decide which is the one which should be retained and which one goes out of the window. After some discussion with our home team during our Pre-IPM we came to a conclusion that it was too much of an effort to try and maintain the entire story narrative and the supporting documents in wiki (compare it to word and excel and i dont see much of a dilemma deciding on which to go for). But at the same time we had a tough time maintaining all the comments and questions on word documents. We decided we could use wiki for this. I dont see much of duplication here, since we use wiki for the common IPMs we have across both teams. I think the problem would be better solved by trying to be better desciplined in maintaining the documents than trying to come up with a new way of doing it which may have worked for some one. All problems need not have the same solutions and the same tools to solve it.
Thats exactly what we thought and we decided we could try and solve this problem by updating these cards on to a wiki page. This way we could atleast have only one copy of the story narrative, never mind the pain we had to go through to update the wiki page and not being able to link supporting documents (it may be possible, but we didnt have the required expertise in the team. May be we should hire a wiki expert for this).
But then, if we managed to maintain multiple copies of a story narrative in svn what would stop us from doing this in wiki. After all there was nothing stopping us from creating two pages for the same narrative and having it in different iterations. Also there was the problem of not having versioning for the story narratives.
Any way my intension is not to weigh the pros and cons of the wiki and svn and then decide which is the one which should be retained and which one goes out of the window. After some discussion with our home team during our Pre-IPM we came to a conclusion that it was too much of an effort to try and maintain the entire story narrative and the supporting documents in wiki (compare it to word and excel and i dont see much of a dilemma deciding on which to go for). But at the same time we had a tough time maintaining all the comments and questions on word documents. We decided we could use wiki for this. I dont see much of duplication here, since we use wiki for the common IPMs we have across both teams. I think the problem would be better solved by trying to be better desciplined in maintaining the documents than trying to come up with a new way of doing it which may have worked for some one. All problems need not have the same solutions and the same tools to solve it.