http://www.kuqin.com/projectmanage/ 挖经验 / 项目管理 zh-cn Copyright &copy; 2007-2008 <A href="http://www.kuqin.com">酷勤网</A> All Rights Reserved <A href="http://www.miibeian.gov.cn/" target="_blank">京ICP备07011765号</A> kuqin.com@163.com http://www.kuqin.com/projectmanage/20080705/10507.html 当问到开始实践敏捷的年限时，回应结果如下：5年以上 12% ；2 - 5 年 26.1%；1 - 2 年 20.9% ；6 - 12 月 16.6% 。关于组织中是谁最初提倡敏捷开发的问题，调查的结果如下：团队领导/开发经理22% ；主管开发的副总/总监 19% ；C级主管 18% ；项目经理 15%…… 2008-07-05 项目管理 Chris Sims译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080704/10408.html Mark Levison写了一篇有意思的blog文章，总结出关于敏捷异味的目录。以下这几种异味你可能很熟悉： 说话的小鸡：这种异味发生的情况是，团队以外的成员——例如外部的项目干系人——过分干预每天的站立会议；“确实‘完成’了么？”；“我们不像一个团队” 2008-07-04 项目管理 Amr Elssamadisy译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080704/10402.html Roger依据成本和收益这两个变量来评估ROI。研究对比了敏捷项目和计划驱动这两种不同的途径，并对成本降低和收益提高的结果进行了评估。Roger研究了TCO和信任的重要性，结果显示敏捷方法优于传统的方法。 2008-07-04 项目管理 Vikas Hazrati译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080704/10401.html 总的说来，并不是所有的敏捷社区成员都赞成专家机制。应该根据团队的人员和项目具体情况，来安排通才和专家的比例，或者努力增加通才型专家的数量，他们可以携手并进，推动项目取得成功。 2008-07-04 项目管理 Vikas Hazrati译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080703/10343.html 让客户成为团队的一员，把团队成员介绍给客户，告诉他每个人的责任，告诉他我们的目标，让他感觉到大家是在一个团队，大家的目标是一致的。淡化利益关系，强化团队精神，更高效的完成项目，并保持好客户关系。 2008-07-03 项目管理 heli猫 博客园 http://www.kuqin.com/projectmanage/20080630/10272.html 在同团队一起工作的过程中，你遇到什么困难了吗? 我最关心的问题，就是确保目标清晰。我在这其中起的作用，就是把它传达给我的团队成员。因为我和大家处在两个不同的世界：其中一个是我并不熟悉的技术世界，所以一开始要把信息清晰地传递出去有一些困难。 2008-06-30 项目管理 受访人 Segundo Velasquez 采访 InfoQ http://www.kuqin.com/projectmanage/20080630/10269.html Brent认为，一定要正确使用投票驱逐这个概念。有些团队连平等对话的机会都没给对方，也没试过解决冲突，就直接投票。还有些团队远远没有意识到重要性，他们觉得自己没有权利这样做。James S. Fosdick说，有人从一个团队中被赶了出后，应该进入另一个团队，观察合作效果 2008-06-30 项目管理 Vikas Hazrati译者 李剑 InfoQ http://www.kuqin.com/projectmanage/20080628/10194.html 谈到需求变更，几乎所有的开发人员都谈虎色变，那简直是一个让人深陷的泥谭，相当多的技术牛人们，都倒在了需求变更的途中。为了解决“需求变更”这件项目中最令人痛苦的事情，总结几招：第一招：找准目标；第二招：深入了解业务；第三招：寻找背后的真相；第四招：非请 2008-06-28 项目管理 personable 博客园 http://www.kuqin.com/projectmanage/20080628/10189.html 稳定的团队成就了稳定的项目, 而只有大家的心被笼到一起, 团队才会稳定: 任何把程序员当枪用的管理思想, 必将被程序员所开发出来的子弹所击毙!而笼络人心, 从而维护住了一个团队, 形成了团队的凝聚力, 战斗力, 才能有更好的执行力. 2008-06-28 项目管理 代震军 博客园 http://www.kuqin.com/projectmanage/20080614/9504.html 软件工程里面有个著名的brook定理，大意就是向一个进度落后的项目加人，只会让这个项目更加落后，引申开来就是应该避免在项目的中后期大幅度加人。因此一般正确的做法是避免在项目中后期加人，虽然这么显然简单的道理大部分老板都不相信。 2008-06-14 项目管理 不详 BlogJava http://www.kuqin.com/projectmanage/20080614/9500.html 在开发团队中沟通基本上是人和人之间的事情，人都是有情绪的；我们在设计或开发中，多数是为了具体问题而沟通，而非为了情绪而沟通，但我们应首先处理好情绪，避免因情绪而带来麻烦，然后才能很放开的去充分沟通问题。 2008-06-14 项目管理 奇遇 奇遇,目标导向设计 http://www.kuqin.com/projectmanage/20080613/9475.html 哲总结出十项原则，能够帮助您实施有效的程序管理和项目管理架构：1.依靠简单、灵活的方法，以支持不同的开发类型；2.采用阶段发布计划；3.管理并跟踪项目使之保持在可控制的“规模”之内；4 .通过转换点或“阶段门槛”来控制工作流程和质量…… 2008-06-13 项目管理 埃森哲 畅想博客 http://www.kuqin.com/projectmanage/20080613/9474.html 组织项目管理是跟公司的组织架构和职能相结合的一个概念，项目管理不是个人或小团队较为随意的过程，而是需要提升到组织级别来关心的，需要形成一些组织级的固化的过程，方法，规范，资产和工具等内容。 2008-06-13 项目管理 人月神话的Blog 畅想博客 http://www.kuqin.com/projectmanage/20080613/9452.html 规范是团队协作的根本，没有规范的代码会让其他同事无法正常理解或花费大量精力去理解你的代码。再忙一周也要进行一次代码检查，把MODEL补充齐，把注释和说明补充好。安全和性能是互联网公司的程序员必须关注的。团队中应该有专门研究安全的同事，把安全条例做为天条进 2008-06-13 项目管理 萧远山 博客园 http://www.kuqin.com/projectmanage/20080613/9436.html 这里要说的就是“客户的问题”，如果客户认为确实是自己的问题，那就不是个问题了，客户自然会同意延期或付费， 但大部分是客户不认为是自己的问题，这就真的成为问题了。比如需要客户确认而客户没有确认导致无法继续，而客户又不认同 2008-06-12 项目管理 王德水 博客园 http://www.kuqin.com/projectmanage/20080612/9427.html NO.1：需求变更，我变我变我变变变！NO.2：我们需要文档吗？不需要吗？NO.3：松散的团队.NO.4：BUG！超级多的BUG！NO.5：规范？那是无能者的借口！NO.6：不懂技术的管理者。NO.7：口吐莲花的销售，只有想不到没有做不到。NO.8：技术狂人…… 2008-06-12 项目管理 personable 博客园 http://www.kuqin.com/projectmanage/20080612/9416.html 。相对广东其他小城市，深圳和广州要招一个熟手太容易了，一个有经验的新人进入一个中大型公司，还是比较好管理的。而其它城市情况就不一样，在处理有经验的新人上，应该有所不同，具体怎么实施还得边实践边总结边改进。 2008-06-12 项目管理 梁-兄 博客园 http://www.kuqin.com/projectmanage/20080608/9270.html 分支是浪费的一种形式，我们的目标是消除分支。我们采用单独的代码库，只支持最近发布的一个版本，每次发布都强行推送给所有用户，并频繁发布（理想情况是，一次发布增加一个功能，或移除一个缺陷）。采用SaaS的方式实现起来会更简单。 2008-06-08 项目管理 Mark Levison译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080607/9230.html WfXML-R旨在围绕WfMC的参考模型里的5个接口建立规范：接口1：在流程定义与建模工具和工作流引擎之间定义一个标准接口。接口2：为客户端应用向工作流引擎请求服务定义APIs。接口3：为APIs定义一个标准接口，以便工作流引擎可以通过公共代理软件来调用各种各样的应用。 2008-06-07 项目管理 Gavin Terrill译者 徐涵 InfoQ http://www.kuqin.com/projectmanage/20080607/9223.html 重点要放在流程，而不是内容之上。你的目标是保证每个人都有机会发言，说出自己的想法，形成共识，并为最终决议的形成贡献自己的力量。不要去强制推行你认为的最佳方案，……要让大家知道，当你发言时，你所表达的只是个人观点。 2008-06-07 项目管理 Mark Levison译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080607/9222.html Alistair Cockburn在其中分享了他认为影响“团队涌流”的一些主要干扰：（1） 过多会议（程序员必须放下工作去参加一个接一个的会议，以及）;（2） 过多同时进行的项目（程序员必须放下项目A的工作，切换到项目B）。这些干扰会消耗很多的时间和精力。 2008-06-07 项目管理 Vikas Hazrati译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080604/9207.html 项目经理的一个重要工作是根据项目目标拟制项目计划，因此项目计划不应该被低估，计划是项目后续执行，监控，总结的基础。对于进度，质量，成本，沟通，团 队建设，问题和风险管理等各项内容都应该在计划中有所体现。成功的项目总是有成功的项目团队共同交付 2008-06-04 项目管理 不详 人月神话的Blog http://www.kuqin.com/projectmanage/20080604/9206.html 4.周例会没有和项目成员共同分析和确认风险以及风险参数；5.不是所有的成员都参加了项目主计划的评审获取项目承诺；6.项目成员不清楚项目自定义过程和作用；7.项目在一些技术方案和实现方式选择上面没有形成规范做法；8.WBS分解计划阶段没有包含风险计划分解结果 2008-06-04 项目管理 不详 人月神话的Blog http://www.kuqin.com/projectmanage/20080530/9077.html 从概念上讲，每日例会非常简单，但往往团队要采用却并非易事。如果要将我们的敏捷规则应用到每日例会上（敏捷的变种），我 们必须非常清楚每日例会的目标，这样才能“验证”各种特殊情况下每日例会是成功还是失败。可惜大多数讨论都没有把这个目标讲清楚。 2008-05-30 项目管理 Amr Elssamadisy译者 徐毅 InfoQ http://www.kuqin.com/projectmanage/20080525/8920.html 1、需求调研、分析 2、功能节点设计 3、数据库设计 4、使用“管理程序”建立数据库、表。5、使用“管理程序”添加字段（包括表）的描述信息。6、使用“管理程序”设置分页控件需要的属性和添加修改删除等使用的表名 。7、其他的不能套用“控件”的功能…… 2008-05-25 项目管理 金色海洋（jyk） 博客园 http://www.kuqin.com/projectmanage/20080521/8785.html 导致sprint长度减少的因素：无变化：是指在当前sprint中不改变范围；结束：sprint的结束让团队感觉很爽，在一切继续开始之前，应当庆祝团队的胜利；ROI：每个sprint都可以部署新特性；承诺可靠度：sprint长度越短，越容易发现承诺是否可以兑现。 2008-05-21 项目管理 Mark Levison译者 李剑 InfoQ http://www.kuqin.com/projectmanage/20080512/8412.html 本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例。我假定你已经熟悉了Scrum的基本元素、XP方法和任务板。这些方式不是我发明的，它们是基于“主线（mainline）模型”或“稳定主干（stable trunk）模式”。 2008-05-12 项目管理 Henrik Kniberg译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080512/8411.html 在不带个人评判的环境中，“强力问题”可以开启学习和问题解决之门，而暗藏的“噢，快闭嘴吧”之类的想法也会悄然无踪。要注意：消除不必要的 “为什么”问题是一个好的开始，有助于建立不会互相责备的和谐环境，而“强力问题”的积极作用也得以生根发芽。 2008-05-12 项目管理 Deborah Hartmann译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080512/8377.html Vikram Dhiman讲述了在某公司发生的一个小事故：4个资深的技术人员拒绝加入敏捷团队，因为他们预料到自己无法得到足够的尊重和威信。这些资深成员认为：如果所在团队只以“团队的成功”作为唯一的衡量标准，他们的经验会遭到侮辱。 2008-05-12 项目管理 Vikas Hazrati译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080510/8305.html 要请他走的“那个人”，如果真的表现不好，那只有请项目经理平时就要完整的搜集他的“犯罪事实”，越详细越好。说实话，请人走的方法说的容易，做起来难呀。理论很简单，但轮到自己实践时，就不是那么一回事了。但是，你不想办法让他走，最后就是你走 2008-05-10 项目管理 胡百师 CSDN博客 http://www.kuqin.com/projectmanage/20080510/8304.html 一个项目在进行时，既然会产生不同的风险，而且可能在同一个阶段好几个风险。这个时候限于有效可处理时间与人力的限制条件下，项目经理如何去辨识风险的优先等级？就变成一件颇有学问的事。如果，一个不小心产生判断疏失，下错了决定，可能为项目带来无法挽救的危机。 2008-05-10 项目管理 胡百师 CSDN博客 http://www.kuqin.com/projectmanage/20080510/8303.html 为什么应该保留TOP 10风险列表？道理其实很间单，因为处理不当而让项目崩溃的原因，往往都是这“前十大风险”。请项目经理务必记住，TOP 10 风险列表的可变性：它会随着项目的进行而改变，千万不要做一个从头到尾只有一份“供交代用”风险清单的项目经理 2008-05-10 项目管理 胡百师 CSDN博客 http://www.kuqin.com/projectmanage/20080510/8287.html 根据Scrum中的定义，障碍是任何阻碍团队提高生产效率的因素。我个人认为世上没有完美的事物，所以我觉得任何东西或多或少都是障碍。关键在于要识别出当前最大的一个或两个障碍。 Scrum还认为障碍涵盖的范围很广，包括工程实践和个人问题等方面。 2008-05-10 项目管理 Mike Bria译者 郑柯 InfoQ http://www.kuqin.com/projectmanage/20080509/8270.html 需要承认，工作流其实与最终用户还差得很远，也就是说在众多厂商的网页上，那副著名的业务流程生命周期其实是一句空话。一句话说，就是那个什么流程设计器是给程序员用的，至于用户，哪凉快哪去。也就是说现在的工作流还不能给最终用户提供价值。 2008-05-09 项目管理 ronghao BlogJava http://www.kuqin.com/projectmanage/20080507/8070.html 一个好的任务宣言可以解释我们应该做什么与不应该做什么。它可以明确界定我们工作的边界，并阐述开发团队如何与整个组织融合到一起。一个卓越的任务宣言可以为工作提供一个清晰的、可测的目标，这样其他的组可以看到我们负责什么——以及不负责什么。 2008-05-07 项目管理 Mark Levison译者 韩楷 InfoQ http://www.kuqin.com/projectmanage/20080506/8025.html py工作流还是一个不错的工作流引擎，抛开它的宣传，感觉引擎的实现还是有些简单，或者说只是满足了目前的一些常见需求，至于所说的SOA和服务编排，我觉得目前还不现实。它的优势在于与其平台的完全融合，能够利用很多既有设施，可是这又何尝不是把双刃剑？ 2008-05-06 项目管理 ronghao BlogJava http://www.kuqin.com/projectmanage/20080501/7716.html 第一,不要总说那些"正确的废话"；第二, 不要把太多的精力耗费在开会上。尽管很多公司认为人是最宝贵的资源，却往往看不到人的最宝贵资源是时间。很多人之所以是技术官僚，就在于他们把会议当成了休息时间；第三,不要任何事情都和竞争对手看齐。 2008-04-30 项目管理 Fenng DBA notes http://www.kuqin.com/projectmanage/20080430/7696.html 网站项目或网站频道虽然有了比较明确的定位和目标客户，但这些都是未知数，我们在前期不可能花很多时间与网站将来的目标客户进行直接地沟通获取需求，更多的来源是策划人员、行业专家和自己或老板对这个行业的理解，模拟目标客户的期望值来获取需求。 2008-04-30 项目管理 vfp_system CSDN博客 http://www.kuqin.com/projectmanage/20080430/7695.html 一个B/S项目从立项开发就需要根据项目的规模、经费的预算、应用的技术、项目开发的模式等方面考虑好开发这个项目所需的人员构成及数量。作为B/S项目，必须配备美工、初级程序员、中高级程序、项目经理兼数据库设计、需求分析和项目管理及集成。 2008-04-30 项目管理 vfp_system CSDN博客 http://www.kuqin.com/projectmanage/20080429/7670.html 为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。 2008-04-29 项目管理 李默 捷道·敏捷堂 http://www.kuqin.com/projectmanage/20080429/7669.html 假设你要替换系统中已经存在的一大块，而此时人们需要使用这个系统。你并不会使用每一天改动一点点的方法。然而，你可以每天从主线上取下遗留系统中将被替换的部分，与团队成员当前所做放在一起。他们可以持续地从主线中获取，然后做修改，他们所做的就是持续集成。 2008-04-29 项目管理 Deborah Hartmann译者 徐毅 InfoQ http://www.kuqin.com/projectmanage/20080423/7456.html 与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。博弈结果，就是双方都不能达到最好的情况。 2008-04-23 项目管理 李默 捷道·敏捷堂 http://www.kuqin.com/projectmanage/20080423/7455.html 在项目中，应用敏捷方法最重要的一部分就是管理团队所用的过程，但并不仅仅是过程，还包括其它方面：比如团队的开发、文化变迁的管理、相应的技术及管理工具，以及那些与项目有直接或者间接关系的敏捷建导师的合作。 2008-04-23 项目管理 Vikas Hazrati译者 韩锴 InfoQ http://www.kuqin.com/projectmanage/20080420/7108.html 适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：1、在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；2、奖励方式应因人而异，必须最大程度地投合员工的喜好。因此，在对你的团队以及员工进行奖励之前，先询问他们究竟喜欢什么 2008-04-20 项目管理 张逸 捷道·敏捷堂 http://www.kuqin.com/projectmanage/20080420/7081.html 人们是如何在信息过载和信息匮乏之间很好地掌握平衡？！网站又是如何在维持用户的使用频率和避免用户感觉到干扰中间拿捏得当呢？Google Groups在接收设置上提供了E-mail、Digest Email、Abridged Email和No Email四种选择给用户。 2008-04-20 项目管理 小容 大学小容>善用网络，助益成长 http://www.kuqin.com/projectmanage/20080420/7056.html 当前任领导走后，一个老技术人员被提拔为领导后，千万要注意管理上的策略：第一就是千万不要否定甚至全盘否定前领导的所做所为，不管错误或者正确；第二就是先宽后严，不管是老员工升上来做领导，还是从一个部门调到另一个部门。 2008-04-20 项目管理 梁-兄 C++博客 http://www.kuqin.com/projectmanage/20080420/7041.html 项目经理也强调组织的配置是工程师 Pool，所以随时调配任一工程师可独立完成整个功能。我的建议是变成多个专业人才 Pool，就这个例子而言，是划分成 UI、AP Service、DB Pro 三个 Pool，若哪个子团队缺哪层的工程师，就由专业 Pool 调配。 2008-04-20 项目管理 胡百敬 CSDN博客 http://www.kuqin.com/projectmanage/20080415/6792.html 整个项目在员中的贯彻理解的要求，以及工作成果的分配精度在一些情况下可能也会更高。对于工作时间的安排，不宜过于民主，项目经理大可以按照成员报上来的时间，按照自己的经验作一些“集中”，毕竟项目经理是对整个项目负责的人，这个时间应该是要项目经理非常有把握的 2008-04-15 项目管理 王德水 博客园 http://www.kuqin.com/projectmanage/20080413/6649.html 在丰田，技术管理工作是极其重要的。他们的核心角色就是充当教师和一线工人的协作者，持续改进他们的过程和实践。技术经理跟他们的团队合作，帮助他们通过实验找出如何更好的工作；当找到改进方式以后，经理们可以让其他团队快速学到他们的做法…… 2008-04-13 项目管理 Mark Levison 译者 李剑 InfoQ http://www.kuqin.com/projectmanage/20080413/6631.html 我们很多项目的客户直接负责人一般都不是“皇帝”，而是“和绅”，我接触过一个客户就说，你们的产品能不能运行是次要的，重要的是能不能在我负责时让我赚到钱，让我提高政绩，哪怕是你们的系统只是个摆设。所以我们在做产品的功能是尤其要注意这点 2008-04-13 项目管理 王德水 博客园