《xplanner的基本观念》由会员分享，可在线阅读，更多相关《xplanner的基本观念（16页珍藏版）》请在金锄头文库上搜索。
1、XPlanner的基本观念 * XPlanner是一套支援XP(Extreme Programming;极限编程)的规划及追踪软件 *在XPlanner中，你可以建立许多的用户与项目，每个用户在每个项目中可以有不同的权限 *一个项目可以视为一套产品的开发过程，当然也可以对应到与顾客合作进行的软件开发项目 * XPlanner在项目层级下设有迭代(Iteration)，基本上一个项目应该要有许多features或requirements。透过迭代，你可以安排要将哪些features放在哪个迭代，而将另一些feature放在另一个迭代。开发时间越早的迭代，应该包含项目越核心的功能，或是较为重要的功
2、能。而后面的迭代则放入选择性的功能。 *迭代层级里面放置用户故事(user stories)。用户故事用来代表一个用户可了解的需求，应该是一组独立，且不可分割的功能。用户故事同时也用来作为工时估算的单位。决定一个迭代里要有哪些用户故事、要把哪个用户故事放在哪个迭代的过程，就是发布计划(release planning) *用户故事层级里放置任务(Tasks)。如果把用户故事看作是需求，那任务就是完成某需求所需进行的工作。任务由开发人员撰写，它同时也可用来较为精细的估计工时。 *在XPlanner里面你不用怕故事放错迭代，也不同怕任务放错故事，因为它们都是可以在不同的容器中移动或接续的。使用XP
3、lanner规划及追踪软件开发项目这部份有些内容参考自XPlanner网站：Planning and TrackingXP (Extreme Programming;极限编程)是极富弹性，且还在进化中的软件开发流程。在实施上有许多的XP规划方法。我们在此说明XPlanner所支援的流程。规划流程的特性及步骤包含：由顾客及开发人员定义发布计划(release plan)XPlanner目前还没有直接支援发布计划(release planning)。不过XPlanner倒是可以让你定义许多迭代，并在其中放入适当的故事(stories)。你可以把这种功能当作是发布计划的一种方式。实际上，我们还会定义
4、虚拟迭代(pseudo-iterations)来容纳那些还未排入正式迭代的故事。这样就可以让顾客定义他们想看到的产品特性，并为接续的迭代规划存留原始题材。使用虚拟的迭代(pseudo-iteration)储存尚未纳入排程的故事(stories)XPlanner目前尚未直接提供未规划故事(unplanned story)的容器。然而，许多团队会建立一个称做是backlog(注:应该是起源于Scrum开发方法学，用来代表feature repository)或unplanned stories的虚拟的迭代，并将迭代启始时间设定为很久之后，来当作未规划故事的容器。将未规划故事先放在这个虚拟迭代中，之
5、后在概念规划(planning game)时再把适当的故事移到适当的迭代中。由顾客定义用户故事(user stories)你可以在规划某一迭代时直接建立用户故事，或将别的迭代里的用户故事移到某迭代中。故事的优先权必须协同顾客敲定。由开发人员估计实作故事的代价XPlanner可以在为故事定义任务(tasks)之前，就先预估工时。这对一开始时粗估是否能在时间、资源限制内，实作出顾客所要求的故事集是非常有用的。观察员(tracker;追踪者)将会参与这个阶段，来帮助顾客开发故事。观察员通常会是故事的开发人员之一，但这并非必要。一旦选定了一组可行的故事集之后，开发人员将会定义实作故事所需进行的任务(t
6、asks)。这个时候，由开发者为某一故事的工作项目所进行的工时估计，将会取代原始故事的工时粗估。每一个任务，都会有一个受理的开发人员(acceptor)。当开发工作正式进行时，受理人将会(或可能会)与另一个配对程序员(paired programmer)一同进行开发工作。开发者以过去迭代的指标来决定其可用预算(budget,这里偏向时间上的预算，而不是指经费上的)。而预算决定了某开发人员在此迭代中可接受的工作。在XPlanner中，迭代中每个开发人员的所花费的工时可透过iteration metrics页面呈现。一般来说，将工时除以二(假如是采用配对程式设计方式)就是当前迭代可用的预算。实作故
7、事如果透过任务重新估计的工时仍然在此迭代可接受的预算之内，就可以开始进行任务了。进度追踪任务开始进行后，就可以追踪其工时。XPlanner会在迭代、故事，以及任务层级的网页，以进度条的方式来展示进度。进度条可用来(例如，让相当忙碌及时间有限的顾客)快速检视整个团队的进度。进度条已经过正规化(normalized)以减少视觉杂讯的显示。正规化的缺点是故事的相对大小没有显现出来。这样的资讯是以数值化的方式显示在迭代表(iteration table)及其他页面中。如果一个任务还没有记录任何工时，则整条进度列都会是灰色的。而当任务开始进行后，进度条上会以蓝色表示已进行的工时。如果某个任务的实际工时已
8、经超出了之前的估计，则XPlanner会强制你更新估计工时，才肯让你储存输入工时。之所以这么做的原因是，XPlanner不可能在你超出预估工时后，还能帮你估算剩余工时。而原本的预估并不会丧失，因此还是可以产生预估正确性指标(estimation accuracy metrics)。迭代页面所示的故事层级(story-level)进度条，则是任务层级进度的整合。要学习这个东西就得对XP要比较的熟悉才行呀，今天看了一天的XP，然后再回过头来看Xplanner系统。果然清晰了不少。1. 一个项目Project包含1.N个迭代Iteration。2. 每个迭代Iteration包含1.N个用户故事Us
9、er Story。（翻译的不准确了，姑且可以理解成用户需求吧）3. 每个用户故事User Story包含1.N个任务Task。4. 人员管理（People）默认包含了Admin，Developer，View三个角色。所有参与到项目的人员都需要添加到人员People里边去。5. 迭代Iteration需要计划开始时间Start Time和结束时间End Time。根据开发人员的多少一般在数周的时间内。每个迭代结束后都应该有个发布版本Release。以后迭代都遵循“Yesterdays weather”原则。6. 根据User Story程序员估计开发时间，细分为多个Task。Task是Xplan
10、ner中最小单元既元数据。时间一般在1-3天，小于1天的与其他Task合并，大于3天的药考虑拆分。7. 每个Story之间根据商业价值，风险等因素就有顺序Order之分了。在Story视图上也可以看到估计时间，已用时间，剩余时间等状态信息。8. 程序员选择Task进行结对开发。并且填写开发进度。9. 在Iteration、Story、Task各个视图上面，各用户可以轻松的创建Notes。并且可以容易的查看各用户操作的历史记录。10. 程序员用的比较多的应该是Me功能了。可以查看和自己相关的各种任务及相关信息。一下是用图形的方式写下的笔记：老兄，你的进度表周银辉据说XPlanner在Team中流
11、行过一段时间，但后来被默默地扫入历史的垃圾箱。（注：XPlanner是一个基于Web的XP团队计划管理和跟踪工具。XP独特的开发概念如Iteration、User Stories等，XPlanner都提供了相对应的管理工具，XPlanner支持XP开发流程，并解决利用XP思想来开发项目所碰到的问题。XPlanner特点包括：简单的模型规划，虚拟笔记卡(Virtual Note Cards)、Iterations、User Stories与工作记录的追踪，未完成Stories将自动迭代，工作时间追踪，生成团队效率，个人工时报表，SOAP界面支持）到后来我们意识到这是极其可惜的，虽然在一个月前的“
12、回顾大会”上就使用XPlanner的问题不少同事仍然很犹豫，但我和部分同事仍然坚持将其利用起来的观点还是得到了大家的支持。现在看来那时的坚持是很正确的。至于部分同事的犹豫是可以理解的，因为我也有过类似的担心：对于任务的划分和时间的估算的确是一个挑战。但没有进度表的开发无异于自杀行为。虽然说在开发人员所能掌控的范围之上肯定有一个更粗粒度的时间表（比如什么时间发布新版本），但仅仅依靠这个我们无法知道开发的最新情况，更不知道能不能按时发包，我想谁都不愿像网景公司一样由于产品迟迟不能发布而丢失绝大部分市场份额而成为众多书籍中的反面教程。其实对于任务时间的估算，不仅仅对开发人员是一个挑战，对老板们同样是
13、一个挑战，老板们也害怕自己一时冲动拍着胸脯说：“OK，三个月”。然后自己都没法知道自己的团队实际需要6个月才能搞定。一个比较搞笑的说法是“开项目时拍胸脯，项目中拍大腿，项目结束后拍屁股”。坚持制定计划表可以大大避免这种情况的发生，一是结果长时间的摸索，老板能了解到自己的团队能力，能很好的估算项目时间，二是通过计划表能尽可能早地发现时间不够的情况，然后可以采取相应的措施，比如砍掉一些相对不重要而耗时较多的功能特性而将时间节约给那些很好很重要的功能特性。对于开发人员而言好处也是很明显的，我们可以很好的安排任务和对自己在目前这段时间能完成的任务量和进行估计，一是可以让自己的工作更有条理性、效率更高，
14、二是能及早发现存在的风险（比如某个任务的确很费时间，除了工作量外还学习一些新知识才能完成）然后你可以在任务进行的最初期发现这些风险并及时跟你的老板提出来，而不会等到快发包时解释说“我真的很努力，但真的搞不定了，任务太多了”，那就死定了。不要害怕任务时间估计不准确，没有准确的（我们又不能完全预知未来），但这是可以积累的经验，经过长时间的经验积累，你所估算的时间就越能接近真实消耗的时间。1，这篇文章不是XPlanner的广告要声明的是，之所以文中很多地方提到了XPlanner，是因为我目前正在使用它，而且觉得很不错，然后本文的主要目的是表明进度表的重要性以及相关经验教训。至于到底使用什么样的工具，
15、我不能做出好的推荐，这方面我的经验不足，需要更多地了解XPlanner可以访问这里：http:/www.xplanner.org/。但据说在此方面Microsoft Project等也有着杰出贡献，其实Microsoft Excel也是一个不错的选择。2，进度表不是工时报表还好，我们不是钟点工，否则进度表极其可能沦为工时报表。遗憾的是，进度表不具备这项功能。如果有人想这么做，可能其大错特错了，员工进度表中的任务时间可能被拖得很长以及员工恨不得将开机关机都计入进度表以表明自己一直在干活。3，进度表不是老板们的工作这里讨论的进度表不是由老板们来安排的，而是由开发人员自己来计划与填写的，一个很简单的道理是，只有开发人员自己知道完成该任务需要做那些事情，需要多少时间。如果让你的经理来为你填写计划表那就太糟糕了，除
