User Story管理工具

找一个User Story管理工具，用来在线编写User Story，对User Story进行搜索、跟踪。

ThoughtWorks的Mingle是一个，不过Mingle太复杂，而且要收费。

这里还有一个Story Server：http://storyserver.sourceforge.net

还有别的吗？

用来用去,还是卡片顺手.

http://xplanner.org/

Rally
http://www.rallydev.com
老外的，要钱的，敏捷的，全方位的。

xplanner不错

转一些XPlanner相关的文档。

http://nettrace.blogspirit.com/archive/2005/05/30/xplanner_%E4%BD%BF%E7%94%A8%E5%BF%83%E5%BE%97.html
页面被GFWed了，内容贴在下面。

愛德華日誌
XPlanner 使用心得

JeffHung 在他的 Blog 裡問我有關 XPlanner 的使用心得。老實講心得都是斷斷續續的，沒經過通盤的思考，而且有些都是一些自己使用上的旁門左道，不見得是標準用法。不論如何，還是把它整理出來，供有心人參考。
XPlanner 的基本觀念

* XPlanner 是一套支援 XP(Extreme Programming; 終極製程) 的規劃及追蹤軟體
* 在 XPlanner 中，你可以建立許多的使用者與專案，每個使用者在每個專案中可以有不同的權限
* 一個專案可以視為一套產品的開發過程，當然也可以對應到與顧客合作進行的軟體客製化專案
* XPlanner 在專案層級下設有迭代 (Iteration)，基本上一個專案應該要有許多 features 或 requirements。透過迭代，你可以安排要將哪些 features 放在哪個迭代，而將另一些 feature 放在另一個迭代。開發時間越早的迭代，應該包含專案越核心的功能，或是較為重要的功能。而後面的迭代則放入選擇性的功能。
* 迭代層級裡面放置使用者故事 (user stories)。使用者故事用來代表一個使用者可了解的需求，應該是一組獨立，且不可分割的功能。使用者故事同時也用來作為工時估算的單位。決定一個迭代裡要有哪些使用者故事、要把哪個使用者故事放在哪個迭代的過程，就是發行規劃 (release planning)
* 使用者故事層級裡放置作業項目(Tasks)。如果把使用者故事看作是需求，那作業項目就是完成某需求所需進行的工作。作業項目由開發人員撰寫，它同時也可用來較為精細的估計工時。
* 在 XPlanner 裡面你不用怕故事放錯迭代，也不同怕作業項目放錯故事，因為它們都是可以在不同的容器中移動或接續的。

使用 XPlanner 規劃及追蹤軟體開發專案
這部份有些內容參考自 XPlanner 網站：Planning and Tracking

XP (Extreme Programming; 終極製程) 是極富彈性，且還在進化中的軟體開發流程。在實務上有許多的 XP 規劃方法。我們在此說明 XPlanner 所支援的流程。規劃流程的特性及步驟包含：
由顧客及開發人員定義發行計畫 (release plan)

XPlanner 目前還沒有直接支援發行規劃 (release planning)。不過 XPlanner 倒是可以讓你定義許多迭代，並在其中放入適當的故事 (stories)。你可以把這種功能當作是發行規劃的一種方式。實務上，我們還會定義虛擬迭代 (pseudo-iterations) 來容納那些還未排入正式迭代的故事。這樣就可以讓顧各定義他們想看到的產品特性，並為接續的迭代規劃存留原始題材。
使用虛擬的迭代 (pseudo-iteration) 儲存尚未納入排程的故事 (stories)

XPlanner 目前常未直接提供未規劃故事 (unplanned story) 的容器。然而，許多團隊會建立一個稱做是 "backlog"(註: 應該是起源於 Scrum 開發方法學，用來代表 feature repository) 或 "unplanned stories" 的虛擬的迭代，並將迭代啟始時間設定為很久之後，來當作 未規劃故事的容器。將未規劃故事先放在這個虛擬迭代中，之後在概念規劃 (planning game) 時再把適當的故事移到適當的迭代中。
由顧客定義使用者故事 (user stories)

你可以在規劃某一迭代時直接建立使用者故事，或將別的迭代裡的使用者故事移到某迭代中。故事的優先權必須協同顧客敲定。
由開發人員估計實作故事的代價

XPlanner 可以在為故事定義作業項目 (tasks) 之前，就先預估工時。這對一開始時粗估是否能在時間、資源限制內，實作出顧客所要求的故事集是非常有用的。觀察員 (tracker; 追蹤者) 將會參與這個階段，來幫助顧客開發故事。觀察員通常會是故事的開發人員之一，但這並非必要。

一旦選定了一組可行的故事集之後，開發人員將會定義實作故事所需進行的作業項目 (tasks)。這個時候，由開發者為某一故事的工作項目所進行的工時估計，將會取代原始故事的工時粗估。每一個工作項目，都會有一個受理的開發人員 (acceptor)。當開發工作正式進行時，受理人將會 (或可能會) 與另一個配對程式師 (paired programmer) 一同進行開發工作。

開發者以過去迭代的指標來決定其可用預算 (budget, 這裡偏向時間上的預算，而不是指經費上的)。而預算決定了某開發人員在此迭代中可接受的工作。在 XPlanner 中，迭代中每個開發人員的所花費的工時可透過 iteration metrics 頁面呈現。一般來說，將工時除以二 (假如是採用配對程式設計方式) 就是當前迭代可用的預算。
實作故事

如果透過作業項目重新估計的工時仍然在此迭代可接受的預算之內，就可以開始進行作業項目了。
進度追蹤

作業項目開始進行後，就可以追蹤其工時。XPlanner 會在迭代、故事，以及作業項目層級的網頁，以進度列的方式來展示進度。

進度列可用來 (例如，讓相當忙碌及時間有限的顧客) 快速檢視整個團隊的進度。進度列已經過正規化 (normalized) 以減少視覺雜訊的顯示。正規化的缺點是故事的相對大小沒有顯現出來。這樣的資訊是以數值化的方式顯示在迭代表 (iteration table) 及其他頁面中。如果一個作業項目還沒有記錄任何工時，則整條進度列都會是灰色的。

而當作業項目開始進行後，進度列上會以藍色表示已進行的工時。

如果某個作業項目的實際工時已經超出了之前的估計，則 XPlanner 會強制你更新估計工時，才肯讓你儲存輸入工時。之所以這麼做的原因是，XPlanner 不可能在你超出預估工時後，還能幫你估算剩餘工時。而原本的預估並不會喪失，因此還是可以產生 "預估正確性指標 (estimation accuracy metrics)"。

迭代頁面所示的故事層級 (story-level) 進度列，則是作業項目層級進度的整合。

http://www.xxeq.com/supersite/?action-viewthread-tid-563
安装部分就不转了，已经过时了，只适合老版本。

一、 XPlanner简介
XPlanner 是一个基于Web的XP团队计划和跟踪工具。XP的开发概念如iteration、user stories等，XPlanner都提供了相对应的的管理工具，XPlanner支持XP开发流程，并解决利用XP思想来开发项目所碰到的问题。
XPlanner特点包括：简单的模型规划，虚拟笔记卡(Virtual note cards),iterations、user stories与工作记录的追踪，未完成stories将自动迭代，工作时间追踪，生成团队效率，个人工时报表，SOAP界面支持。

三、 公司研发类项目XPlanner初始设定要求

1． 根据项目类型不同分为两种类型对项目在XPlanner上进行初始设定：
对于定制开发类项目，以实际项目名称作为XPlanner的项目名称。在项目下建立首次迭代，制定迭代起止时间。根据公司目前项目情况，建议每次迭代过程不要超过一个月。在制定首次迭代后制定至少一个User Story；在User Story中至少制定一个任务。
对于短期实施类项目，以实际项目名称作为XPlanner的项目名称。一般一次迭代应该完成此项目。
2． 在XPlanner内建立人员列表包括：
公司研发部人员（项目经理设为管理员权限、其他开发人员为编辑者权限）
公司其他部门项目人员，包括项目助理或可以作为项目跟踪者的市场部门人员或者公司管理者
客户：可以作为项目客户或跟踪者
其他访问者：可看到该项目进展情况的访客。设为访客

四、 项目组各成员使用过程及要求
1．项目负责人：鉴于目前XPlanner仅适用于软件研发类项目适用，所以定为研发部项目负责人为XPlanner项目管理员。项目负责人主要负责 XPlanner中项目、迭代、User Story、任务的设置、编辑、删除。项目管理员也可后续由项目助理担任作为执行人和跟踪者。对于项目负责人应该：
在启动新项目前依据《软件项目开发计划》在XPlanner上加入新项目，要对本项目目标加以简要说明。将《软件项目开发计划》附加入"备注/附件"
按照《软件项目开发计划》细分出本次迭代，订立迭代目标、迭代周期、完成的User Story、涉及人员、迭代完成评定标准。形成《软件项目迭代计划》（格式附后）提交审批。要求可度量的明确的迭代目标是《软件项目迭代计划》的重要内容之一。
按照迭代目标、迭代周期、涉及人员制定任务草稿，提交《迭代会议》讨论。
招集相关人员召开《迭代会议》通告《软件项目迭代计划》即迭代目标、迭代周期、完成的User Story、迭代完成评定标准。并对任务草稿进行讨论，制定出确定的任务列表。填入《软件项目迭代计划》。
按照《软件项目迭代计划》在XPlanner上添加相应的迭代、完成的User Story、任务。正式启动本次迭代
如果项目负责人是跟踪者角色，需随时在"我的资料"界面跟踪迭代执行情况。
迭代时间要求不允许调整。User Story可以变更、增加、编辑、删除或调整、延续到后续迭代中去，任务也可以变更、增加、编辑、删除或调整、延续到其他User Story中去，但需要开会讨论决定。任务里的评估工时是XP开发方式的重点控制内容。一般不允许调整（通过对评估工时和实际工时的比对可以统计精确度）。
要及时督促项目研发人员添加、更新XPlanner上各角色负责的内容，做到每日下班前打开XPlanner监控项目进行情况。
本次迭代完成后按照《利用XPlanner对项目进行持续进度跟踪管理》的要求作出简要的《软件项目迭代总结》
2． 编辑者：定为本项目的研发人员、软件测试人员。要求对于本项目的研发人员应该：
参加《迭代会议》，充分了解《软件项目迭代计划》即迭代目标、迭代周期、完成的User Story、迭代完成评定标准。并对任务草稿进行讨论。
接受自己部份的任务列表，对任务内涵要求有清晰明确的认识。
要求每日在"我的资料"界面相应的任务列表内的"操作"表型图标上进入"编辑任务时间"界面，填写本日此任务工时。在"编辑任务时间"页面中的操作应实时进行，要填写开始时间和结束时间。要求格式为时间格式: YYYY-MM-DD HH:MM。
对于需求设计任务主要是以模块功能描述的方式说明，完成识别就是完成此User Story某部份的设计实现方案，必须有设计输出。对于开发类项目任务主要是以功能描述的方式说明，完成识别就是完成此功能描述地实现代码。对于测试类任务主要是以测试用例列表或模块说明，完成识别就是完成此测试用例列表，或模块的全部业务路径，输出BUG单。对于Overhead（整合、管理）类任务主要是以工作内容说明，完成识别就是完成工作说明的内容。
在"我的资料"界面下部"时间表"操作进入"时间表"，此界面可统计本人的时间累计工时情况。作为个人时间管理参考。
如果实际某任务工时累计超过了评估工时，将会显示"实际的工作时间已经超过了当前任务的评估工时.请进行新的任务评估以便于 XPlanner 的状态视图可以更精确."信息。此时可以按实际工时数调整原有的评估工时。新的评估工时与原有评估工时在"精确度"界面有显示。对于此类情况要求随着评估工时的准确程度提高而减少。
当任务完成后从"我的资料"界面相应的任务列表内的任务可进入任务管理界面，点击完成任务可以结束此任务。表示此任务已完成。
3． User Story跟踪者：一般就是项目负责人，也可以是由项目助理担任作为执行人。如果是客户直接参与研发，也可以是客户本身。可在"我的资料"界面跟踪迭代执行情况。可及时和项目组沟通。可配合督促项目相关人员添加、更新XPlanner上各角色负责的内容，做到每日下班前打开XPlanner监控项目进行情况。
4． 客户：可以是本公司市场部门相关人员，如果是客户直接参与研发，也可以是客户本身。可在"我的资料"界面跟踪迭代执行情况。

五、 项目组负责人利用XPlanner对项目进行持续进度跟踪管理过程
1． 在项目一次迭代完成后要求对迭代过程进行总结。主要内容有：
按照《软件项目迭代计划》总结迭代目标、迭代周期、涉及人员任务完成情况。
总结迭代目标达成情况，按照即定评定标准得出符合迭代目标程度。
总结本次迭代调整情况，找出调整原因。逐步减少调整。
在统计表上得出本次迭代趋势。
召开《迭代会议》作出简要的《软件项目迭代总结》（可以和下次迭代会议合并召开）
如果是项目软件、系统交付迭代，还需其他相关人员参加《迭代会议》，以说明刚完成的迭代输出的详细情况。
本项目全部迭代完成后向质控部门提交项目完成报告。内含此项目的质量目标总结统计。目前项目完成状态，客户投诉解决状态。
项目负责人负责各次《软件项目迭代计划》、《软件项目迭代总结》质量记录的保存。并定期提交归档。
2． 主要统计分析界面说明：
时间表：总体时间表可以通过设定时间区段、包含人员条件统计：实际工时按项目（按项目种类在此时间区段的实际工时分类比例）；实际工时按迭代（按迭代种类在此时间区段的实际工时分类比例）；实际工时按用户需求User Story（按User Story种类在此时间区段的实际工时分类比例）；个人时间表可以通过设定时间区段统计本人：时间区段内每日实际工时；实际工时按项目（按项目种类在此时间区段的实际工时分类比例）；实际工时按迭代（按迭代种类在此时间区段的实际工时分类比例）；实际工时按用户需求User Story（按User Story种类在此时间区段的实际工时分类比例）；
User Story主界面：列出该迭代下所有的User Story，所有User Story的合计评估工时（当前评估），实际完成，剩余工时合计。列表中显示所有的User Story的分类合计，可以点击列表头排序相应列（其他列表同此）。Progress条棒显示完成比例。
度量界面：在某迭代时间区段内人员的工时情况统计。上表显示时间区段内人员的实际工时排列（按降序）。下表（开发人员平均有效工时）显示在某迭代时间区段内评估工时（当前评估）按人员排列（按降序）。如果在"编辑任务时间"界面填写时间时填入结对开发人员，则条棒区分显示。
精确度界面：表头列出：当前评估工时（括号内为原始评估工时：创建任务时首次填入），实际完成工时，剩余工时（当前评估工时-实际完成工时）。列表依次为：User Story名称；优先级；此任务完成工时；当前评估工时；原始评估工时；符合度(此任务完成工时-原始评估工时)/ 原始评估工时 *100%；原始评估工时与当前评估工时比例；此任务完成工时与原始评估工时比例；此任务完成工时与当前评估工时比例；
统计界面：人员利用率表（缺省不使用）。迭代进度表：横轴为迭代时间区段，纵轴为工时量（长度自适应）；红线为当前评估工时，蓝线为实际完成工时。 Burn Down Chart剩余工时表：横轴为迭代时间区段，纵轴为工时量（长度自适应）；红线为本节点剩余工时合计。此二表由后台时间触发引擎 Quartz自动按照设定 Quartz Configuration项触发执行填入数据。

将极限编程进行到底：整合XPlanner和IntelliJ IDEA

工具毕竟只是工具，没有自己的主见和判断能力，不清楚自己究竟需要什么，再好的工具也是徒然。XPlanner只是一个功能恰好够用的工具，严格说来很多地方还很不完善，甚至做得有些傻。
不过XP并不是很依赖伟大神奇的工具，在《解析极限编程》中Kent Beck所使用的不过只是索引卡片等貌似原始的工具。KISS是我们需要常常牢记的格言。不要太聪明，太聪明了你会死的。王小波大师就是活得太聪明太明白死掉的。

实践XP，关键是要深入领会精神实质，而不是炫耀自己所掌握的工具。

建议仔细读一下Mike Cohn所著的《User Stories Applied: For Agile Software Development》一书，以前我为这本书写过一篇书评，列在下面。

第一本适用于小型开发团队的软件需求著作——《User Stories Applied》

关于软件需求，很多年前我仔细读过两本书：
《软件需求》：http://www.china-pub.com/22425
《编写有效用例》：http://www.china-pub.com/8285

《编写有效用例》要更实用一些，Cockburn（获得Jolt大奖的《敏捷软件开发》的作者）顶着软件工程大师的名头并非浪得虚名。

不过《编写有效用例》书中介绍的方法，对于小型开发团队来说，仍然是很重的。而我估计国内有80%的开发团队都是小型开发团队。我的意思是说，在一个项目中，人数不会超过10个人。

后来，我没有再试图去阅读其他软件需求方面的著作。因为那些书看起来比上述这两本书更加沉重，至少不比这两本书更轻（这里，“轻”、“重”是说需要编写的需求文档的数量）。适用于大型开发团队的方法对于小型开发团队来说等于是毒药。

很多软件需求方面的书都强调需求文档的重要性，以至于矫枉过正严重失去了平衡。这些书好像是华山派的气宗一样，教你在成为高手之前一定要苦练各种貌似很重要的基本功，以这样的套路练习，成材率是非常低的。而我就像令狐冲一样，总是渴望有更加快捷和实用的方法来取得成功。

大约与阅读上面两本书相同的时期，我还阅读了《解析极限编程》、《规划极限编程》、《极限编程实施》等书，我发现自己终于找到了组织，我是说，找到了一大群臭味相投的人。后来我还发现这些并非纯理论（有些经验主义者倾向于认为，书本上的东西都是纯理论），potian和gigix等同学都在实践这样的开发方法。

极限编程依靠User Story来与用户进行大量的沟通，通过这种方式来来驱动需求分析、估算工作量、制定计划、安排任务等等工作。这样一种方式是行之有效的，在我看来，对于小型开发团队这是唯一合理的需求分析方法。因为需求实现的时间往往都非常紧迫。

我至今仍然认为，人民邮电出版社2001年出版的那套极限编程系列丛书，是我所阅读过的软件工程方面最好的著作。我说的“最好”，其实就是最实用。据刘江老师说，那一套书销量很差（像刘江老师说的那样，因为劣币驱逐良币），但是我认为出这样一套书还是取得了很大的社会效益。

不过《解析极限编程》中对于如何编写User Story讲的不是很详细。后来我发现已经有人写了一本关于User Story的专著——《User Stories Applied》。我找到了这本书的电子版，阅读了一些内容就感到，这就是我在寻找的适用于小型开发团队的软件需求著作。

大师，能简明扼要的说说use case和user story之间的联系和区别么，基于XP的思想我们这些对于XP入门者也需要用XP的方式来学习XP