“莫羽”通过精心收集，向本站投稿了5篇关于敏捷项目管理工具，下面是小编整理后的关于敏捷项目管理工具，欢迎您能喜欢，也请多多分享。
篇1：关于敏捷项目管理工具
最近extremeprogramming讨论组有一个关于工具的讨论很热闹，也激发了灵感，去写一篇分享我的看法。
很多团队中喜欢使用一个电子化的项目管理工具。有支持传统的CMM方式的甘特图的管理工具(mpp, excel...)，也有支持敏捷和Scrum的工具。很多公司也愿意开发这样的产品来迎合这样的需求。PM经常要求大家去sharepoint或者source control中更新mpp或者excel反映开发进度。如果要修改Release plan和task plan，PM也会到sharepoint或者source control里面去修改。这些工具能够支持生成很炫的图表，而且比较方便。对PM来说很有满足感。
但是在我们的团队中，提倡大家使用简单工具，例如：用白板来反应迭代的进度，通过故事墙story wall来反映release plan。为什么？。
Tell, Don“t Ask。Ron Jeffries有一生动的比喻来说明区别tell和ask的区别，”Whether she calls you, or you call her“。其实这也是一个Pullinformation和Push(broadcast) information的区别。电子表格，工具往往需要打开电脑，点击文件或者链接才能看到，因此总是one click away。除非你去经常查看电子文件或者工具，你往往不知道里面是否有更新。而PM往往想当然认为自己更新了MPP或者Excel他的team member就会立刻知道（其实很多情况下并不是这样的）。尽管很多工具提供email或者RSS通知,比如sharepoint，但是这样的话，往往这样的mail很多，而且直接就做一条Rule送到垃圾箱了，很少有人会去关心，
其实这是一种Pull模式，也就是Ask。但是白板和故事墙就不一样了，它们反映的总是最新的状态，项目进度，项目计划，任何时候人们想要了解，只要抬一下头就可以了。这是一种Push模式，白板和故事墙会把最新的信息广播(broadcast)到整个团队，任何对项目感兴趣的人，都可以看到。
更好的交互性、更简单。大家可以在白板上挪动卡片，需要用手、眼，还要说。这个比在电子工具里面去更新状态的用户体验要好的多，这个是任何电子工具不能替代的。而且不需要培训，任何人都会在白板上挪动卡片。
支持并发修改。大家同时可以修改白板，不需要Merge。也不需要等待其他人修改完，check in之后。
反应进度，问题。任何人只要走进团队的工作区域，项目的状态，运行情况，存在的问题一目了然。而这个是很难通过电子的工具替代的。
当然有时候公司的高层也会关心项目进度，给他总结整理报告对团队也是不小的负担。很简单，用数码相机，即实时又有效。
不过也不是完全否定电子工具，只不过很多情况下简单的东西效果反而比一些花了大价钱买来的工具实用得多。
Cheers!
Daniel
来自：www.cnblogs.com/tengzy/archive//02/17/1392799.html
篇2：敏捷项目管理工具ScrumWorks Pro 3.0发布
Danube科技近日发布了ScrumWorks Pro 3.0版本，这一版本是在8月的时候提出的，ScrumWorks Pro是一个敏捷项目管理工具，它能够帮助团队跟踪每次迭代与整个版本发布的过程。本次版本的变化集中在两个方面：可用性的改进以及使用MySQL作为 后端数据库。
根据Danube的CTOVictor Szalvay所说，这一版本关注的一个方面是对界面美观性和可用性方面的改进。对UI作出的多个改进包括：
新的产品创建向导——指导用户根据决策（团队、角色和权限以及产品的属性）创建一个新产品。
Docking框架——与Eclipse相似，用户能够使窗口停靠（dock）在其父控件的任何一侧，以便于能够同时浏览多个编辑器。
标签方式编辑——与Firefox相似，用户能够在自己的标签（tab）中，整齐地显示针对不同故事或任务的编辑器。
拆分（Split）特性——在创建一批故事（或者任务）时，用户通常认为一个单独的故事会拥有多个条目。拆分特性简化了将它转换到一个单独故事的步骤。
Sprint详细信息视图——增强了树型视图的支持，该视图能够将任务与它们的故事关联起来，
此外，Sprint视图还支持根据“认领人”、“任务状态”或其他任一列对内容进行筛选。
根据Victor的观点，或许最重要的改变是对MySQL的支持，企业用户希望工具能够支持更大的部署需求规模，而不是使用一个内嵌的数据库。新的标签页方式的编辑器
Sprint详细信息视图
ScrumWorks Pro提供了桌面客户端和Web客户端——桌面客户端具有全部特性，而Web客户端则提供了Spring的一个视图，用于更新任务状态和任务估算。服务器 组件可以运行在Windows XP/Vista/ Server，Mac OS X 10.4.2+以及Linux上，而桌面客户端则支持：Windows XP/Vista，Mac OS X 10.4.2+和Linux KDE。
查看英文原文：Agile Project Management ScrumWorks Pro 3.0 released
来自：www.infoq.com/cn/news//03/ScrumWorksPro_3
篇3：项目管理工具：邮件讨论组
邮件讨论组之一：本地工作与远程工作
邮件讨论组之二：几个关键影响因素
邮件讨论组之三：半虚半实的IPO项目邮件讨论组
邮件讨论组之四：IPO工作组的项目管理诀窍
邮件讨论组之五：为校园活动创建邮件讨论组
邮件讨论组之六： 盘点你的Google邮件讨论组
邮件讨论组之七：Google Groups的接收设置和Gmail的过滤设置
邮件讨论组之八：行为与环境，控制与赋权
邮件讨论组之九：关于网络工具的场论2.0公式
篇4：项目管理工具推荐：Redmine和DotProject
项目管理逐渐在各行各业深入人心，于是应运而生出现了许多的在线项目管理网站，去年我曾经介绍过忙吧和易度两家在线项目管理服务网站，最近还发现了趣客、快做网，国外提供在线项目管理服务的网站则更多，
不过在这类网站上进行项目管理存在着安全隐患，对于开发类的项目不能和代码开发和测试等结合起来存在很大局限性，另外功能扩展也相对较困难。因此今天我主要向大家推荐适合在公司内部安装，并适合对IT项目进行管理的两款轻量级开源工具：Redmine和DotProject。（注意：这两款轻量级工具比较适合中小型企业，大型公司建议用更专业的集成管理工具）
DotProject：是一个基于LAMP的开源项目管理软件，历史比较悠久(号称始于)，在全世界被翻译成几十种语言，涵盖了公司管理、项目管理、任务跟踪(带甘特图)、论坛、问题跟踪、文件管理、日历，通信录、备忘录、投票、权限管理、主题管理。这是个老牌的项目管理系统，使用人数较多，而且功能也比较全面和强大，不过配置较复杂，另外虽然有中文包但部分地方仍然出现乱码，最近的更新也非常的迟缓，从2.1.1版本升级到2.1.2版本花费了接近一年的时间，官方主页也失效了，不知是否开发人员方面有何变动。不管怎样，DotProject仍然是目前应用广泛，比较成熟的一套轻量级项目管理系统。
Redmine：这是基于ROR框架开发的一套跨平台项目管理系统，是项目管理系统的后起之秀，据说是源于Basecamp的ror版而来(未考证)，支持多种数据库，除了和DotProject的功能大致相当外，还有不少自己独特的功能，例如提供wiki、新闻台、时间跟踪、feed聚合、导出pdf等待，还可以集成其他版本管理系统和BUG跟踪系统，例如SVN、CVS、TD等等，
界面友好性胜过Dotproject，配置功能强大而且方便，自定义属性和更新通知也很实用，详细的介绍可以看看清华同方的redmine站点。中文版Redmine在线演示：ezWORK、英文版可看Redmine提供的官方演示。李征还建立了一个提供免费redmine服务的站点：Redmine.NET。
之所以推荐这两款工具，首页因为他们是免费开源的，具备良好的扩展性，大家可以在此基础上做适合自己公司的扩展开发，其次它的B/S架构非常方便实用，很适合团队的项目管理，另外和一些版本管理和错误跟踪工具的初步集成也让项目管理更加轻松容易。个人比较偏好Redmine多一些，在之前的公司就是使用Redmine进行项目管理、知识分享、任务分配和KPI考核。当然如果你仅仅是做个人或单一的项目管理，平时使用ms的projcet或者excel都足够了。
除此之外还有一些基于web的项目管理系统：XPlanner、Onepoint、]project open[、JIRA、Trac也值得关注。
虽然上面提到的系统可以解决日常大部分的项目管理需求，但仍然没有实现将需求、设计、任务、开发、版本控制、测试用例、bug跟踪、版本发布等完美的结合到一起，这估计是免费开源系统的一个缺陷，缺乏足够的资源支撑进行更大规模的集成开发。而商业化的工具在这方面就更具优势，例如被IBM收购的Telelogic就有一系列工具，Doors、Changes等等，基本实现了上述所有流程的整合，但是在费用方面就不是中小型公司可以承受的。不过对大部分中小型企业来讲，在DotProject和Redmine基础上进行适当的扩展已经可以满足日常需求了，毕竟还有相当部分的企业还是采用project和excel在进行项目管理。
本文出自：www.kuangfeng.cn/blog/?p=1846
篇5：失败的敏捷项目
作为敏捷专家，我们热衷于谈论在项目上取得的成就，却很难做到对失败直言不讳，Robin Dymond在“一个失败的敏捷项目”这篇文章中谈到了有关失败的话题。
Robin的文章中谈到一个替换内部现有流程的例子，从任何角度看这个项目都应该成功：
实施基于现有的商业软件（COTS， Commercial Off The Shelf Software）
产品负责人对现有流程有着深入的了解
团队成员具有在商业和敏捷项目实施上的成功经验
资深敏捷教练曾与该组织有过广泛的合作
3个大型的咨询公司为团队成员提供产品方面的知识
第二个迭代结束时，事情开始变坏。产品负责人怀疑COTS工具能否完成任务。在第三次迭代过程中，业务用户试用软件的反馈普遍都是负面的。因为不具备长远的眼光，产品负责人被撤销了。Elizabeth Hendrickson曾说过“在第三次迭代中，如果所有用户的反馈都是负面的，应该取消这个项目或者重新仔细规划。”
Rpbin认为，在项目开始之前，这次失败就已埋下了伏笔：
立项:项目由IT总监和运营总监一起推动。现有的业务并没有成为驱动这个项目的动力，其流程也不需要进行改进。平台选择:选择新平台的驱动力在于，大家确信基础设施需要从原有的定制系统转向商用软件。……应用系统在项目开始之前就已经选定了，没有人试过它是否能满足需求。而且，团队开始使用这个应用系统时，才发现它的能力非常有限，业务用户们使用起来也非常痛苦。而总监拒绝承认这些数据。
Allan Shalloway认为这个项目的问题在于：“没有真正的用户认可，只是业务负责人说要这么做”。在Allan和团队建议取消这个项目数月之后，他谈到这个项目的失败原因：
根据我的经验，许多Scrum项目并没有真正按照Scrum的要求实施。每当我们去帮助或训练这些团队时，他们都会说自己已经有多少个月的Scrum实施经验。一旦问到他们真正在做什么，就会发现这些并不符合Scrum的要求。此后Allan指出，他看到很多团队都对Scrum的原则缺乏清晰的理解：
一次只着眼于一个产品
让团队把关注点集中在业务价值上
拥有强有力的业务出资人支持
让团队的工作针对故事进行
清晰定义“完成”对于团队的含义
……
最后Robin描述了他登山的经验，他谈到加拿大的阿尔卑斯俱乐部有一本刊物——《阿尔卑斯意外事故月刊》。这本杂志记录了登山发生的意外事故，可以让其他的登山者们认识到什么地方出了问题，如何摆脱危险，以及事故发生的经过。Robin认为我们也需要这样的月刊：“每天都有数十亿的资金耗在这上面，跟其它行业相比，软件项目存在惊人的高失败率，难道我们不应该正式地记录和分析这些失败吗？”
查看英文原文：Failures in Agile Develoment
InfoQ的读者Joakim Holmbäck在评论中认为：
识别项目中的失败之处并从中吸取教训，是改进流程的关键。我也同意我们应该（更多地）讨论失败的敏捷项目，但是文中的例子并不恰当，管理资料
文中的敏捷过程显然起到了作用。在第一个迭代中，COTS软件就被证明是不合格的了，产品负责人被替换也证明了这一点。项目失败的唯一原因，是管理层不能听从项目团队的建议。
不管使用什么样的项目管理技术，发生类似的事情总是会失败的。
读者Julian Browne提到：
在深水潜水社区中，有一个常用的时间：任何发生的小事故都会被公布出来，防止再度发生。British Sub Aqua Club会发布年度报告，供大家认真研读。不考虑故事中的敏捷因素，我觉得其中缺少了解决问题——而不是实施解决方案——的上佳实践，记录并共享失败项目的教训就是其中之一。
不幸的是，很多（绝大多数）失败的信息都被限制在商业组织之内，而且这样的信息很少能被泄露出来。我们只能自己进行项目实施后的复查，这个主意不错，但是通常都执行不好。
针对文末的问题，Mark Levison公布说他开始准备收集整理《敏捷与Scrum失败月刊》，并希望大家提供素材，网址是：www.notesfromatooluser.com/2008/07/journal-of-agilescrum-failure.html。针对Joakim的说法，他认为：
还能有什么其他失败的原因么？Jerry Weinberg说过：“总是人的问题。”我想所有失败的项目到最后都能归结到人和沟通的问题上去。我倒想看看有没有能够证明我错误的例子。针对Julian的问题，Mark认为，既然现在市场上有如此多的教练和培训师，从他们那里一定能够得到很多失败的例子。
而InfoQ资深编辑Deborah Hartmann对Mark的做法表示赞赏，同时她也向读者征求失败的案例，供未来的“理解”练习和研究使用，其网址为www.m3p.co.uk/blog/2008/04/14/what-is-going-on-out-there-a-narrative-inquiry-project/。
面对Mark的质疑，读者Joakim这样回应：
虽然总是可以归结到人的问题上，Scrum项目的任务失败还是会有N多种原因。上文中提到的失败，主要是由于管理问题：产品负责人被去掉了，而且团队的看法也没有人注意。（一个敏捷项目具备成功的所有要素，还是会失败；这看起来还是挺有意思的。）Scrum团队失败的其他原因：
-依赖其他Scrum团队（scrum构成的scrum不能正常运作，每个scrum的日程不同）
-“完成”的定义没有正确使用
-故事太大太长
-团队不具备完成手上任务的技术能力
-团队的故事组织有问题，每个成员处理自己的故事，但是故事之间互相依赖
-团队不愿意做正确的回顾活动，因此很难进行改进
来自：www.infoq.com/cn/news/2008/07/agile_failures
