5305人阅读
项目经理---项目管理（4）
&&& 最近第二次迭代时，我们带领的开发小组长文哲，这两天在补需求文档、部署文档（二次迭代完成了哪些客户需求？未完成的？），在迭代开发之前就应该有一个文档即是不全，那该多好啊，不用现在这么着急的补充啦。
&&& 思考：倘若没有文档，给客户迭代完后，如何表明我们所做的内容呢？客户是否满意呢？如果没有文档，和客户的交流验收时就很难办了？
到底要不要写文档？
&&& 记得合作开发的时候，前期花费了很长时间，我们是采用了传统的瀑布模型，需求文档、概要设计、详细设计、数据库设计、甘特图等文档都是前期设计全了，遵循着文档驱动开发，当我们开发过程中到最后，发现文档、图、解决方案根本对不上了，中间修改了很多，相差很多，再验收以前我们三个是饿补啊，在整个开发的过程中由于前期的设计不可能考虑的很详细，每一步不可能考虑的很清楚，最后的文档成了我们头大的问题。
初设敏捷开发
&&& 自从接触了敏捷开发，我们就体会到这个开发思想不提倡写文档（很爽啊，先开发，当初理解的浅显）我们现在根据客户的需求拿来就开始干了，在这个过程中确实使用着禅道等项目管理工具，但是现在体会还是有些乱，规划的还有很多不合理的地方，给大家的每天的目标还不是很明确（时间段、任务、弹性时间、困难、该完成什么功能？）没有明确的规划，可能会引发项目拖延，时间一长大家会有懈怠心里啦。
&&& 项目一开始，根据客户的需求我们就开始干了，设计、开发、等真正给客户架过去之时发现需求理解的不是很到位、使用还有常见的bug（测试文档没有）等，造成了没有给客户部署成功、我们浪费时间、给客户留下不好印象等等一系列问题，敏捷开发确实可以应对一些变化，但是因为文档不全的问题又一些给大家带来了苦恼。
&&& 今天抽些时间查了敏捷开发的相关资料，敏捷并非不写文档，而是重视文档的作用，也重视文档的维护；它认为文档宜少且精炼，不需要冗余的文档；文档也是作为细化部分，在每个迭代过程中不断重构；一般需求文档、概要设计、详细设计、数据库设计、项目管理文档（甘特图等等）都是必须的，在许多外企的迭代开发中都是这样的，倒是国内的公司确实提倡一种：敏捷无文档，开发效率慢， 基本的文档都是必须的；敏捷开发中的写文档，有了方向性的指导。
&&& 开发要有开发文档（需求文档、数据库设计、概要设计）、开发计划（甘特图、燃尽图）、测试计划（时间、地点、人员、任务模块分配、禅道bug提交管理）都应该有一个时间段，在大家的一起商量之下可以每个人做到心中有数，对任务整体有个全局观，我们每天该干什么？紧急重要的需求？客户迫切需要上线的功能？都有一个好的规划，避免在不必要的文档上（官话、客套话）浪费更多的时间，劲使在刀刃上，提高我们的开发效率，有明确的目标、去按照我们的计划一步步的完成。
&&& 各个工作流自有它的价值……努力吧，继续深入理解敏捷开发理念！
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1103124次
积分：21743
积分：21743
排名：第244名
原创：245篇
评论：6348条
阅读：13099
阅读：85959
文章：11篇
阅读：29702
阅读：17704
阅读：23930
阅读：12595
阅读：13422
文章：13篇
阅读：37614
(1)(4)(4)(10)(4)(8)(4)(5)(5)(4)(4)(4)(4)(4)(5)(8)(5)(9)(7)(5)(4)(4)(5)(4)(5)(7)(5)(4)(7)(4)(5)(5)(6)(15)(10)(11)(4)(7)(14)(4)(8)(2)(3)(1)您的位置：
导致你的敏捷开发项目失败的五个原因
日 20:19:11　|　作者：佚名　|　来源：IT168
摘要：敏捷方法受到开发团队的极大青睐，但还是有太多的敏捷开发项目失败。这很难甚至精确地测量这么多的软件开发项目失败的次数，本文总结了敏捷项目失败的5个原因。
太多的项目失败。这很难甚至精确地测量这么多的软件开发项目失败的次数，因为最终“完成”和发布，即便：
-他们花了足够长的时间来构建
-构建的质量很差
-构建的产品不是客户所期望的的
-构建的成本大大超出预期
多年来，我在多个不同的敏捷开发团队工作过，同时也为一些敏捷开发提供咨询和培训。在这期间，我发现5个共同的问题，如果这些问题不被解决，就很可能会导致项目失败。
1. 不是产品所有者
所有的事情，都可能会导致一个敏捷软件项目的失败，而不是一个正在开发的产品 的最终的决策者的人，是确保其(产品)消亡最快的方式。
如果你追随的，没关系，只管做你自己的Kanban style project 项目或者别的事;如果你想你的项目能取得成功，你需要能一个能多所开发的产品设定方向和做决定的人。
想想要改造一个厨房。如果你聘请了一堆的承建商进来，做各种各样的工作，如：管道，木工，地板等，但你没有一个人来决定实际完成的厨房看起来应该像什么样，最终你将会得到一个乱七八糟的厨房。
少有的几个承建商可能会足够的聪明的，能找到正确的人以询问应该做什么，但设计一个厨房需要的不仅仅是随意的决定橱柜放哪儿，而是需要更多。你需要的是有人能真正的提出符合实际的设计和愿景，并随着工程的不断推进能对愿景进行纠正，以避免问题的发生。
话费大量钱财重建你的厨房，看起来相当疯狂，但不想在设计成品或者雇佣人员上投资任何时间和努力，已完成该项工程。
当然，日复一日，我在软件项目中的确看到很多这样的行为。我看见很多公司在敏捷开发上花费了大量的金钱，但并不会委任任何人成为正在建设的项目的真正的主人，并为它设置愿景。
迭代是敏捷开发给软件开发世界带来的关键价值之一。
但什么是迭代呢?
你可能会认为，这意味着将你的项目分成两个短周期或者迭代周期。虽然这样做可以促进迭代开发，这并不意味着你是在使用迭代。
感到困惑了吧?下面就让我们揭秘吧：
迭代的关键是在时间范围内，一点点的开发一个产品。这将准确的，作为一个产品的演进来描述迭代过程中的商品。
无论你是否相信宏观进化，微进化，或适应性是否是一个成熟的概念。进化背后的想法是事情随着时间的推移逐渐被改变。由量变到质变。
试想一下，如果进化论是最“敏捷”软件内置的方式工作，这将是多么的愚蠢。
试想一下，如果你是一条在大洋中游动的鱼，并有一些自己的在出生时就有功能健全的腿的鱼宝宝。然后，那些有腿的鱼宝宝长大了，然后又有翅膀的鱼宝宝。
也许腿和翅膀并不会让鱼能活的更好，也没有被恰当的设计，因为腿和翅膀的出现，不是随着时间的推移因适应所做的改变，而是突然出现。
产品功能不应该以单一的短周期或迭代来建立。好比在单一的一代鱼的身上出现退一样愚蠢。
反之，功能应该随着时间的推移和进化。某种功能不应被放入到某种单一的短周期或迭代，然后去实现。一种功能应该从小规模开始，并随着时间的推移进行进化和开发收到反馈，客户或者产品所有者试图将其开发出来。
太多的时候，我看到敏捷开发的项目进行了错误迭代和迭代开发产品。
不要试图发送一次完成的功能，而是让它随着时间的推移来完成。
3.没有将事物分解的足够小
对于将事物分解成小的、易接受的块，我是坚定支持者。
为什么如此重要的一个主要原因，是这样做可以避免延期。
延期经常发生在当我们对大型的可能困难的任务感到畏惧的时候，或者我们不知道接下来该做什么的时候。
如果你能将大项目分成很多小块，这将使项目看起来很容易完成，并有一个明确进展步骤。
我经常看到，没有给之前的软件项目考虑足够的工作，人为的创造了积压工作或工作项目。
我创造了一个长期的积压类型：fatlogs。Fatlogs积压没有分解成足够小，并且经常对于要完成什么非常模糊。
当试着理解和解释他们的时候，Fatlogs是出了名的难以估算和浪费时间。关键是fatlogs被分解成更小的可操作的积压工作给敏捷开发团队或大量的时间将被浪费。
很多时候，我发现fatlog 的创造者可以很容易的将工作分成小的易于解释和理解的积压工作，即使对于软件开发知之甚少。
我时常建议敏捷开发团队，他们应该彻底拒绝fatlogs 并将其送回到某条链上。
如果你不能花足够的时间来清楚地说明你想要什么，那么它就没那么重要。
但这也不足以豁免开发团队。 开发团队应该将他们得到的任何积压工作分解成小块任务。
4.没有设置标准
当你订一块牛排的时候，服务生问你的第一件事是什么?
显而易见，他们问你你想如何完成它。
如果厨师不知道你想要完成的牛排的制作标准，厨师就必须决定他或她的制作标准是什么。
你可会得到一个完美的牛排(+微信关注网络世界)，或者一个让你难以置信的牛排，或者介于两者之间，完全取决于为你烤制牛排的人。
这不是一个烤制牛排的好方式，同样也不是制作软件的好方式。
在大多数软件项目中，我经常遭遇到大量的在烤制时没有定义的牛排。积压工作当时间耗尽的时候，经常被“做”。
对于一个敏捷开发团队，做任何积压工作有一个明确的标准是相当重要的。
这意味着，产品所有者应该定义一些可接受性测试。测试是手动测试还是全自动测试没有关系，与团队指定的标准是否能达到其测试目标有关。
缺乏标准，好比父母对孩子所提的问题“我应该吃多少豆子?”时所做的回答：“吃饱就行”一样。
没有制定标准会导致负面情绪，并为什么在手指指向的方向没有做正确的事。
我发现，如果你详细的告诉某人你对他的期望是什么以及评判的标准是什么，你将会比仅仅分配给他们任务得到更好的结果，牵着他们的鼻子说，“好好干。”
5.不要为了团队而建立团队
团队是一个奇怪的组织，特别是敏捷团队。
有很多的变数，会影响到团队的行为和交互。有太多的方式组建一个健康的团队，亦有很多方式创建很烂的团队。
一个健康积极的团队具有协同作用，一个不健康的消极团队比其团队成员各干各的好不了多少。
关键是有一个健康的团队，能让每个团队成员都变得很自主。无论你的政见如何，你也许会同意以下观点，当一个国家入侵另一个国家，并建立了一个并非由公民选举的政府来管理人民，肯定有问题的。
同样的问题发生在敏捷开发过程中。
我并不是说团队不应该有责任制。但如果你想以敏捷的方式管理一个软件项目，你必须让团队在达成共识的基础上自我组织以及自我管理。
当团队老大总是监督和干扰的话，团队互动变得非常困难。
自然而然的，团队时常有他们自己的开发节奏，领导力和角色(称之为准则)。
然而，当外部力量直接干扰团队工作时，他们没有权力决定他们自己的命运，团队成员就会开始意识到他们需要好自为之。
额外的敏捷开发资源
我发现在这些议题中发现好的资源是相当困难的，但这里有一些书，我发现了一些和我上面描述的有用的期刊的地址。
Succeeding with Agile: Software Development Using Scrum-这本书专注于Scrum 但它同样适用于不同种类的敏捷项目。Mike Cohn和我时常在大部分敏捷主题上达成一致。
Agile Retrospectives-我发现这本书对于团队回顾能得到启发，这些想法将真正有助于打破障碍，帮助团队解决他们自身遇到的问题。
Scrumban 和 Kanban and Scrum - 两本书都提供了丰富的信息，关于combining Scrum and Kanban以及对于解决上述提到的问题，提供了好的解决方案。
你认为如何?我错过了任何的敏捷项目真凶?与他们打交道的任何有用的提示?
[责任编辑：软件频道 ]
正在加载...
我也说几句
汇编一周来国内外网络和IT行业发生的焦点新闻，精挑细选，第一时间推送独家采写的深度报道和热点专题，深入挖掘新闻事件背后的故事，剖析新闻事件的来龙去脉，让读者准确把握业界的发展态势。
汇集存储频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的购买指南，专家博客，皆汇聚在此。
定期为您带来深入权威的网络，交换机，路由器，无线，通信领域信息服务，涵盖产品，技术，新闻，应用案例，评测,购买指南，专栏，技巧等多个方面的信息。与企业网络相关的一切，尽在网络通信邮件，您怎可错过？
新一代数据中心建设管理最新信息快递――聚焦新一代绿色数据中心的设计、建设、运营和管理，汇集业界专家与用户的最精粹观点，展示国内外数据中心经典案例！
定期为您带来安全领域权威专业的产品，技术，新闻，应用案例，评测，购买指南等信息，保护您在网络畅游之时不受病毒的威胁，企业运行之际减少安全的风险。一份邮件在手，一份安全在心！
深入、专业关注云计算相关的技术与实践，范围覆盖私有云建设、公有云服务运营、开源云平台发展、重要云服务商动态等领域，面向企业CIO和IT经理提供深度原创报道，以及云计算、云服务领域最新的市场资讯。
汇集软件频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的企业软件新闻，SOA，SaaS，BI，ERP，开源技术，产品，技巧等全方面的实用资讯。还犹豫什么，这就开始体验一下吧！
深入、专业关注大数据相关的技术与实践，提供Hadoop、NoSQL等领域的最新技术资讯，定期发布由业界专家撰写的大数据专栏文章，面向企业CIO、IT经理、DBA提供深度原创报道，以及大数据领域的最新市场资讯。
汇集服务器频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的服务器虚拟化，刀片服务器，操作系统，大型机，服务器芯片信息，最新最全的服务器技巧，购买指南，专家博客，皆汇聚在此。
网界网网络学院频道，内容涵盖移动互联，技术开发，Web前端，安全，网络通信，云计算，数据中心，存储，服务器，软件等内容。
订阅过的用户，全部取消选择，可取消订阅
网络世界移动客户端网界网微信订阅号敏捷开发其实意义不是很大，在复杂项目中复杂系统的开发，不会采用敏捷的方式，而是要在开始阶段，多考虑完善，多在架构层面，留有余量，而这个余量，更多的是通过设计方法--例如，采用灵活的顶层设计，留有余地的接口，抽象类来实现，而敏捷式开发，更多的强调是，你做出来多少个需求要求你完成的功能特性，其实，从某种程度上说，敏捷和较为完善的设计，是背道而驰的。因为敏捷要求的是完成可交付的功能--用户可用。而好的设计，是强调的通过较为周到的考虑，将架构合理的搭建起来--这个时候还远远没有到用户可以用的程度。现在好多人喜欢谈敏捷，其实，敏捷，意思不大，就是开发流程短平快，可是如果做不好，往往会适得其反，拥抱变化，敏捷给的解决方案是--勇气，重构，而要知道，即便你有天大的勇气，即便你能重构来重构去，也远远抵不上一个设计完善的软件架构的巨大价值。打个比方，敏捷就是某个小国政府，今天政变一把，张三搞一套政府班子，明天李四再政变一把，再搞一套政府班子，搞来搞去，都在拥抱变化，可是屁用没有。而好的架构设计，就像美国的国父们仔细坐下来，琢磨独立宣言，琢磨政府的三权分立架构，使得有一个持续可用，优美合理，能够扩充，接纳改进的良好政治框架一样。同志们，脑袋是否清晰了一点？
我不这么认为！
敏捷软件工程方法的真正意图是：通过开发管理的敏捷促成软件系统敏捷，而很多人忽略这个目的，结果导致人忙的要趴下，系统还是老样，这真是缘木求鱼。人敏捷得像猴，系统还是熊孩子。走向即时反应，就是让系统变得敏感敏捷，符合达尔文的适变生存。go reactive宣言
11:37 "@banq"的内容人敏捷得像猴，系统还是熊孩子。 ... 说的真贴切。我认为软件建模和敏捷开发是两个不同的思考方向。软件建模关注与业务、归纳、抽象，适应需求变化，敏捷开发如何高效实现。两者完全不是一对排斥的矛盾体，我觉得甚至可以将敏捷开发运用在软件建模的过程，就如“just do it”。很多人视敏捷如神典，找到理论基础，陶醉于精妙的代码，高效的运行。但是他们不肯将敏捷精神用在需求分析、软件设计。这种现象的逻辑：我们足够敏捷，以至于如果需求变化能快速丢弃原系统（或者大幅改动）而重新实现。咳，人家爱因斯坦做的两个小板凳都舍不得丢弃，用来做对比。程序员怎么舍得丢弃自己呕心沥血加班得来的软件代码呢？
&我们足够敏捷，以至于如果需求变化能快速丢弃原系统（或者大幅改动）而重新实现。在系统初期，丢弃也是一种前进，通过折腾代码获得认识提高。是摸着石头敏捷过河，还是首先进行顶层设计，这个选择问题在实际生活中也到处存在。不管选择哪种方式，目标都是能使系统本身更加敏捷，更具有扩展性 可用性和可靠性。如果系统很差，开发管理虽然敏捷，那不是围着一堆破铜烂铁在跳舞吗？小型项目的代码可以全部丢弃，一个复杂项目呢？当然，复杂项目开始阶段，采取敏捷方式，也许能提升队伍对系统的认识层次，抛弃一定代码是值得的，但是项目开发了五年，这么多代码不是说扔就仍吧？
最佳分辨率
OpenSource
Code & 2002-20您正在使用IE低版浏览器，为了您的雷锋网账号安全和更好的产品体验，强烈建议使用更快更安全的浏览器
发私信给郭晓龙
导语：敏捷开发越来越火热，但在实际应用当中很多时候都是只有敏捷的“形”，却缺少敏捷的“神”，。在国内，这种模式不少人仍在摸索，大家在借鉴这种新的模式的时候，最好能够批判性的吸收其精华的部分，不能全部照搬，照搬了反而会出问题。
同步到新浪微博
当月热门文章
为了您的账户安全，请
您的邮箱还未验证,完成可获20积分哟！
您的账号已经绑定，现在您可以以方便用邮箱登录