软件项目管理论文.docx
《软件项目管理论文.docx》由会员分享，可在线阅读，更多相关《软件项目管理论文.docx（16页珍藏版）》请在冰豆网上搜索。
软件项目管理论文
第一部分：
XX公司IT项目总结
一、项目背景
本论文要分析的项目是一个企业内部的IT项目，即：
企业商业信息支持系统升级。
这个项目发生在一家中型规模的企业，同时向企业客户和消费者两方面提供产品和服务。
表面上看，这个项目是一个企业内部的IT项目，但是这个IT项目是和另一个商业流程项目同时进行，互相配合的。
因为商业流程有改变和创新，所以，这个项目并不是对老系统的升级和维护，而是一次创新，质的飞跃。
因此，这个IT项目有一些特点：
该项目与商业流程项目同时进行
项目会影响到公司其他部门的运营流程。
该项目隶属于一个现有范围更广更复杂的IT系统
项目涉及人员主要有如下角色：
领导小组：
由公司高层经理，以及有影响力的高工，业务牛人组成。
项目组：
由IT部门、商业部门、以及外部IT供应商共同组成
受众：
所有将受到此IT解决方案影响的员工。
二、项目管理涉及哪些方面
在总结本IT项目管理效果之前，让我们想想：
如何评价一个项目是否取得成功？
这里边涉及的因素很多很多。
而且，不同的人可能会有不同的标准和角度：
项目过程是否做得很好、很舒畅？
项目是否达到了预期的目标？
项目受益人拿到收益和价值最大？
项目成员得到的成长和良好的感受？
项目过程值得称道，项目管理很有一套？
…
在能够回答这个问题之前，我想最好还是回到本源，从根本来上看，然后再逐步地展开。
那就是：
什么是项目？
这里有一个普遍的定义：
项目就是一套独特互相联系的任务，有明确的开始与结束，充分地利用资源，共同实现一个特定的目标。
这里有几个关键词：
开始与结束：
说明项目是有时间限定的，有deadline。
也说明，项目启动要有启动的姿态，项目结束要有像样的收尾。
实际项目中，时间资源永远都是一种稀缺资源，项目经理经常面临火烧屁股的情势。
充分地利用：
说明项目是在意成本的。
事实上，成本总是一个敏感的词，任何项目都是划拨有限的资源。
实际公司软件项目中，经常性的情况就是人手总是紧缺的。
特定的目标：
说明项目要达到什么目的和意图。
也解释了，为什么做这个项目？
这个项目存在的意义和价值。
其实概括起来，这就是影响项目同时也是项目干系人关注的三个主要因素：
商业价值、成本、进度。
如图一所示
图一影响项目的三个主要因素
商业价值，主要是指从项目可得到的已知的和未知的商业利益。
我更喜欢用商业价值来代替“质量”来表示项目的关键三要素之一。
这是因为，商业价值可以富含比较多的内容：
比如，项目的产出IT系统赢得客户的认可；项目成员得到了成长；项目团队增强了凝聚力；上级经理（领导小组）任何项目的运作过程…等等，让项目涉及的各方都有正向的反馈和收获，那就是这个项目的广义价值。
而项目管理，就是在这三个因素的限制下，尽其所能地去逼近这样一个极限，那就是：
用尽可能少的资源投入，在尽可能短的时间内，取得最大的商业价值。
所谓“两控制一追求”：
控制时间和控制成本，追求最大商业价值。
这是一个动态的平衡。
而项目管理就是一个平衡的艺术。
在“两控制一追求”的情况，项目经理怎么办？
“好钢用在刀刃上”，“分清主次，重点投入”。
是的，这就是项目管理的法宝。
这就意味着：
目标：
定义明确的目标，尤其是项目“完成”的。
人：
组建并保持一个有战斗力的团队。
因人择事，利用团队的力量。
保持团队的热情和凝聚力。
事：
要对项目范围进行管理。
控制需求，对需求分级而治。
合理规划，保持项目的节奏。
任何时刻都在做最有价值的任务。
沟通：
保持高效的沟通，让信息正确地流动，信息对称。
过程管理：
项目的整个执行过程：
启动、规划、执行、监控、收尾。
包括但不限于：
识别项目的关键过程，找出关键路径。
评估任务的工作量，利用非关键路径上任务的浮动时间…
风险管理：
分析项目的RAID（Risks、Assumptions、Issues、Dependencies），可视化出来，持续跟踪。
下面，我就从这6个方面对IT项目的管理进行总结。
三、IT项目管理分析结论
Ø关于项目目标管理
这个IT项目有明确的目标：
按照新的商业流程，实现一套商业办公系统，替代旧的商业办公系统。
要求：
操作简单，效率高。
我们来看这个IT项目的目标。
做什么，很清楚，就是做一套商业系统。
规则限定也很清楚，即：
按照新的商业流程。
用户界面交互友好性方面也提出了要求，操作简单，效率高。
效率高同时也对系统的性能提出了要求。
这个作为待交付产品目标或许也可以，但是总是觉得还有点欠缺。
在哪里？
是的，有一些不够具体，不具备评估性。
比如，效率高？
到底什么样子才算效率高呢？
查询功能多久返回结果？
1秒钟？
还是30秒钟？
这里只是提出了待交付产品目标。
商业价值中我们提到过，除了交付的产品即涉及用户之外，项目中还有团队、领导小组等角色的人员。
也许，团队目标也可以设定一下，比如，增加产品的自动化冒烟测试所占的百分比，或者，团队希望采用新技术和新架构，来帮助产品取得更好的扩展性和灵活性。
领导小组则更关心组织能力的成长，也许，项目可以设定这样的组织目标：
较少项目的耗费时间，提升组织的敏捷性。
结论：
目标比较明晰，但是需要细化的某些目标点；建议增补团队目标和组织目标。
Ø人力管理
组建一支有战斗力的团队对于项目成败至关重要。
项目经理需要使出换身解数来营造英雄团队存在的氛围。
这个IT项目似乎又有些复杂，涉及的项目成员有公司内技术部门的开发人员、商业部门的业务人员、IT设备供应商的技术人员，而且有一些人员的投入是0.5个人力的情况。
为了帮助大家尽快熟悉起来，在项目准备阶段，特意安排了全体项目成员的拓展训练。
这对项目团队的热场很有效。
后续，为了让项目成员对本项目有了解，对项目背景知识以及相关领域的业务知识进行了培训。
培训采用，由对各领域了解的项目组员负责针对整个团队讲解的方式进行，反响不错。
在项目过程中，团队建设活动及业务交流同样定期举行。
为了让项目成员能够高效，项目过程中，特意关注大家的工作并行情况，帮助减少工作负荷的安排。
让那些除了项目之外，还有其他事情的成员对项目得到了有效地投入。
结论：
人员管理比较成功。
不同工作的并行性，是项目中经常遇到的难题。
如果有条件，最好安排全力投入项目的人员。
Ø范围管理
项目范围管理很重要。
范围说明，除了我们都了解的需求管理，还包括项目的理由、产品描述、项目交付物、项目限制、项目假设等内容。
这里我们仅针对需求管理进行分析和总结。
变化总是比计划快，这是大家做项目中常遇到的情况。
需求变化不仅会打乱项目的节奏，还经常在项目末期给项目致命的一击。
“这真的是我们想要的吗？
”这句话你一定耳熟吧？
这是失败的项目，用户最常见的一种反馈。
如何进行有效地需求管理，在本IT项目中尤其显得重要。
因为，本IT项目是和另一个商业流程项目同时进行的。
这个商业流程项目是这个IT项目需要参考的业务流程标准。
那这个IT项目做了哪些呢？
首先，心态要摆正：
拥抱变化。
是的，项目经理在项目启动会上就对大家就此进行了沟通和讨论：
项目要做“正确的产品”，因此我们要有开放的心态，保持及时进行调整的热情和灵活度。
这是由其好的做法，统一了团队的认识，后续的工作就水到渠成了。
项目成员及项目经理一致决定：
第一、要保持同“商业流程项目组”紧密的沟通，保持同步的进展互通；
第二、前期调研多好充分的准备，细致地了解；
第三、采用需求池管理，为每一个需求都评估后，打上唯一的优先级标号（按照数字1、2、3…，数字越大优先级越低）；
第四、迭代式开发。
每次迭代都从需求池中，按照优先级编号，顺序最高优先级的一组；
第五、每个迭代都拿去和用户代表以及负责商业流程的相关人员讨论、评估；
第六、滚动式规划，就已经明确的需求（即商业流程）进行设计、开发、测试等工作安排；
结论：
需求管理非常到位。
不是以死板的“需求变更”流程来退却需求方，而是和需求方一同明确需求、锁定需求。
取得团队的理解和认可，这是关键。
Ø沟通管理
我们说项目其实是死的，有了沟通，才让项目活色生香起来。
可见沟通的重要性。
沟通不到位，会导致信息不对等的情况，进而可能出现项目成员无效的工作投入。
这对项目组是很大的伤害。
在这个IT项目中，沟通尤其重要，因为项目组面对的组织和人员又多又复杂。
沟通既有项目组内各角色项目成员之间的沟通，又有同项目组外部的沟通：
同客户方，同需求方，同商业流程兄弟项目，同上级领导等等。
这个IT项目的沟通尝试如下：
集中项目成员座位，在一个大会议室内，这样就保证了项目成员之间讨论的及时性；
每个迭代内，每天站会15分钟，作为开发过程的跟进和交流
每个迭代结束，定期同需求方进行review
同需求方以及商业流程项目保持随时沟通，派人员参加商业流程项目组例会
同领导小组的沟通，主要在需求评审会和设计评审会、阶段汇报等方式进行。
结论：
项目团队内部的沟通很好，集中坐在一起对与加强大家集中精力攻坚于一个项目是个很大的帮助，形式上的改变也很重要。
前文提到了，本项目成功的关键之一是需求控制，因此同需求方的沟通做得很好，但是，似乎有些过多。
对于用户的关注，似乎做得不够好，开发阶段没有任何同用户的沟通和反馈，只是到了ß版本才关注用户的反馈。
Ø过程管理
过程管理包含了项目运作整个范围。
从启动开始，规划、执行、监控，最后收尾，横跨项目发展的各个阶段。
启动阶段，一般包括项目预研、项目启动会等。
在本IT项目中，项目预研阶段既做了队就有系统的研究、又做了新技术以及新方案的研究和培训，同时对于团队通过这个活动也起到了建设作用。
项目启动会，在这个IT项目中成为项目动员大会，呵呵，有一些鼓动的味道，但是确实对项目目标、产品意图、发布条件、里程碑设置等进行了说明，充分的讨论，听取大家的意见，最终取得全体项目成员的认可和一致。
记住，这是值得花时间来做的。
规划阶段，因为需求的变化性，不可能做到一下子把所有任务都规划得清清楚楚。
因此，在这个IT项目中，采用的是滚动式规划的方式，能把多远看清楚就详细规划多少，不断的明确需求，不断地推进项目向前进展。
因为这种特点，本IT项目中采用了迭代式开发的开发模式，这是组织敏捷性的一个尝试，虽然，大家没有认识到。
但，对于需求不明确的分析型项目，我们不是一直在这样做嘛。
很简单，为了控制进度。
执行阶段，进度总是让人很揪心的。
尽可能利用项目组可用的一切资源。
关键路径以外的非关键路径活动就是上乘之选了，面对上级领导和蔼可亲，但是就是不给资源的讨厌面孔，这是唯一可挖出来的buffer。
这一点，体现出这个项目中项目经理的素质了。
监控方面，这个项目中不外乎用上文沟通管理中谈到的各种方式达到的，保证了项目组充分信息共享，项目经理可以及时了解进展，进而可以做到适时调动调整的。
规划做得好，这块就可以放心一些了。
收尾阶段，有一些慌乱。
为什么呢？
因为这是对旧系统完全的取代，即使是全新的系统，但是也要考虑到用户的使用特性。
用户接入的阶段太晚了，在ß版本才开始关注用户的反馈。
所以，用户界面调整了，导致后续的培训计划及材料，都要调整。
但是，好在实施阶段搭乘了“商业流程项目”的顺风车，虽然有些曲折，也顺利通过了用户的评估。
结论：
过程创新不错，关键路径外的任务浮动时间的利用，是这个项目中的亮点。
Ø风险管理
风险管理对于进度控制非常重要。
即，做到心中有数，决胜千里的作用。
不战以屈人之兵也。
本IT项目的风险管理采用最简单的形式来跟踪，内容则遵循RAID的原则指导，进行识别。
RAID是指：
Risks-风险，具有不确定性。
任何情况。
如果发生就会对项目造成很大的影响，甚至导致项目失败。
每个项目成员眼中Risk不一样。
Assumptions-假设，关于项目的任何假设。
每个项目成员都是基于一定假设来做项目的，比如理解需求、出方案、做设计、出测试方案等。
每个人的假设必然不会一致。
当假设被过高估计，一旦有所变化，对项目就是灾难性的影响。
Issues-项目确确实实存在的问题。
需要最高级别的考虑和处理，以防问题变成项目阻碍或者导致项目失败。
Dependencies-依赖，可能是内部依赖，比如，一个任务的开始需要依赖令一个任务的输；也有可能是外部依赖，对其他系统的依赖，比如对用户中心的依赖。
对资源的依赖，对关键人员的依赖等都是。
怎么做？
有几个原则：
1、开动大家的脑筋。
既然是项目的，那就是跟每个项目成员都相关，所以RAID来自于所有项目成员，而不是一个人。
项目启动时，大家一起头脑风暴。
2、可视化出来，让项目成员都关注。
形成列表，比如从头脑风暴中top出20个。
3、持续跟踪。
RAID的动态要持续跟进，更新。
列表是动态的，可以补充和删除。
4、迭代式的管理推进项目。
不要等着所有的RAID都列清楚，才开始项目。
想多少做多少，不断反馈和总结。
结论：
风险管理很轻量级，但是很专业，很实用。
这个IT项目最终是取得了成功。
在成本内、时间线内、以极高的商业价值，得到了大家的认同。
从项目管理角度来看，这个项目经理所起的作用非常大。
需求管理、沟通管理采取的都是比较有效地做法，既提升团队的能力和热情，又很好的把握了项目走向和节奏。
这是一个堪称该公司典范的项目。
第二部分：
浅析项目开发模式：
瀑布VS.敏捷
一、项目背景
这里要分析的案例项目是某网络公司的一个真实项目，简称为B项目。
B项目是做一款WEB应用产品，目标用户是某一特定范围的网民，具有相似的爱好、某一年龄段、具备相似的关注点和生活习惯等。
下面，简单介绍一下项目相关的情况：
项目人员组成：
9人，其中，
项目经理1人，负责整个项目的规划与执行；
产品工程师1人，负责产品定义，需求收集与分析，页面以及美工设计；
研发工程师4人，负责技术选型，完成系统设计以及具体的开发工作；
测试工程师3人，设计测试用例，执行测试任务，负责产品的质量保证工作。
二、B项目遇到的问题
这个项目有一个比较复杂的客观情况，也可以说是难点吧。
那就是：
这是一个新产品开发，受众面较大，用户的想法和需求很难预先获得，或者说用户可能也说不清楚哪些是他需要的或者喜欢的，产品到底是不是真的满足客户需求的事先评估再怎么做也做不到最准确。
这种困扰，在很多软件开发项目中都存在。
其实，用户只是有个方向，大致的想法，具体是什么样的，怎么操作比较顺手，这些细节都是模糊的，含混不清的。
这种情况，就必然会导致，事前集中花时间想把需求不完整、清楚，然后lockdown，这是不可能的。
变更是必须的，客观存在的。
完整，清楚，更不用提，做不到。
提前花整块的时间来做需求，是不现实的。
如果按照惯例，采用瀑布式开发流程的话，那么，需求不清，变更频繁对后续的开发测试工作有什么影响呢？
瀑布式开发模式，各个阶段划分得非常清晰，需求->设计->编码->测试–>发布，一般周期都比较长。
如果，想让各阶段按部就班地进行，那这个项目计划就无比地复杂，要全面，要具体。
项目成员不断地开发出新模块，最后都齐活了才进行整体集成，将各个工程师所写的编码整合到一起，预测整体系统的行为，包括可靠性和性能等。
如果需求发生变化，意味着什么？
调整计划，要花费几倍的精力，来调整计划以及后续所有阶段的工作。
很可能之前所做的工作会被废弃，架构也要调整，导致大量的重复工作。
这种浪费对于项目来说是致命的，时间紧迫了，项目的节奏被打散了，很可能到了截止日期却拿不出可用的产品，项目只好延期。
新产品研发，需求不甚清晰，这种情况下，划分需求阶段的做法是没有意义的。
显然，瀑布式开发模式不太适合的。
三、B项目的解决方案
那怎么办呢？
这个项目是怎么做得呢？
引入需求池，拥抱变化，迭代式开发，快速应对变化。
需求不是不能提前做到完整、清晰嘛，好，那就分为短期和长期两部分。
长期表示前进的方向，宏伟的目标，这是确定的而且基本不会变化的。
短期目标，就是在目前掌握信息的水平上想清楚多少就完成多少用户需求。
这些想好的，确定的，明确的需求不断地放入需求池中。
研发工程师，就从这些已经确定的需求中不断地取出需求，设计，编码，测试，产出。
产品工程师拿到产出进行评估，各种范围的评估，甚至拿给部分用户进行评估。
然后得到反馈，就这样，不断地边做边想便评估，不清楚的需求自然就慢慢变得清晰起来，又可以纳入到需求池中，作为下一次的迭代的目标。
我们来看这个变化，需求管理方式的变化导致项目开发流程也发生了变化：
如果想快速的推出产品给产品工程师评估，就要尽量的并行工作，减少串行，缩短bug反馈和修复的时间间隔，那么研发工程师和测试工程师就不能像瀑布式一样，严格的串行。
研发工程师交给测试工程师的就不能是一个琐碎的零件，而应该是端到端的可见的功能，用户使用的一个功能。
再往前推，那产品工程师提出的需求就不能是零件，而应该是一个feature，而且要足够的小，最好是1天之内的工作量。
根据B项目成员的能力水平，这个迭代周期，他们选择了2周，2周给出一个评估版本。
很显然，B项目采用了敏捷开发的模式。
四、敏捷模式和瀑布式有何区别
瀑布式开发模型分为若干阶段：
需求分析、系统设计、编码和单元测试、系统集成，以及运行和维护等几个基本阶段。
瀑布模型做了4个主要假设：
如果我们花时间来理解的话，存在着一套定义相当明确的需求
在开发过程中，需求的变化非常小，使我们能够应付，而不用重新构思或者修改我们的计划
系统集成是一个适当且必要的过程，我们能够在架构和计划的基础上合理地预测系统集成的运行情况
创建一个大型的新软件应用程序所需要的软件创新和研发工作，是可以按照预先制定的时间表进行的
但是，很遗憾，现实情况表明这4个假设都是错误的，很难站得住脚的。
假设1，已经在B项目中被证实是不存在的了。
即使是在最擅长的行业领域，客户想法的变化，独特化，都是没有办法保证需求是可以一下子就全面到位的。
假设2，确定需求和交付系统之间的时间间隔越长，变化也就越多。
如果开发速度很慢而变化发生的太快，那情况就很糟了。
假设3，系统集成会顺利进行？
别开玩笑了，这个假设的前提是，只要进行适当的计划和分析，我们就可以预测复杂系统那个的所有组件系统工作的情况。
现实情况，告诉我们，前期所有的分析，既不能预知也不能控制系统集成的过程。
问题过于复杂，变化不断发生；项目进行期间技术不断革新；关于集成的假设都是错误的，并且发现错误时已经为时太晚。
假设4，计划其实是一种预测，只能反映预测的精确程度，但并不见得能够反映实际情况，尤其是超大的计划。
超出4周，就基本上是胡说了，变化太快。
其实，不是瀑布式模型概念错误了，而是从瀑布式模式被提出到现在这30多年来，我们都错误的理解瀑布式模型。
其实，瀑布式模型的应用是有前提条件的。
Royce在1970年发表的《管理大型软件系统的开发》中，提到：
这个模型建议在关键的原型阶段之后应用，在原型阶段首先要充分的理解所要应用的关键技术以及客户的实际需求。
瀑布式开发模式想得很美好，但是，在残酷的现实面前，却因为缺乏灵活性，适应性不佳而渐渐被放弃。
与此同时，业界不断探寻适合软件项目的开发模式，其中，敏捷软件开发模式越来越得到大家的关注和采用。
接下来，让我们看看有何不同。
图二敏捷颠覆了瀑布模式的传统假设
图二显示，瀑布模式倾向于需求（功能）而不是评估资源和日期（成本和日程）。
在敏捷中，假设是不同的：
日期和资源是固定的，因此，为了满足日期的要求，需求必定是可变的。
这是敏捷的关键原则：
任何事情都安排在时间盒内完成。
这条原则迫使团队筛选最高优先级的需求，首先交付最高客户价值的条目。
同时，这条原则迫使团队承认，我们不知道什么时候交付什么，仅知道哪个时间段。
在概念上，敏捷是简单的，但是却改变了大多数事情。
图三敏捷带来的变化
图三通过对比的方式描述了敏捷带来的变化，可以说这些变化都是颠覆瀑布模式的。
敏捷让团队和组织从遵循计划发展到能够响应变化。
这是从传统的工作分解结构到基于优先级实现故事和需求的“以交付价值为中心”的转变。
最重要的就是可执行的、经过测试的并可以使用的代码。
计划是灵活的，可以调整。
实际交付是在当时情况下能够达到的最好情况。
实际交付可以发布。
瀑布模式下，管理固定了范畴、期限和资源，并且为团队明确了技术方向，同时也为团队的效率负责。
在敏捷方法中，正好相反。
管理指明方向，团队竞标，并计划如何在规定的时间框架内完成尽可能多的工作。
为了实现目标，团队必须有自我组织的能力。
团队制定技术决策，并根据需要在执行中纠正。
敏捷模式下，管理工作是排除组织内的干扰，信任团队能够实现目标。
团队完全负责交付产品，并且负责满足时间期限和交付质量。
其实随着所看到的工作进展，每个迭代不断交付的产品，这种信任感不断增加。
在敏捷方法中，团队不用投入几个月来构建详细的软件需求规范、架构模型。
团队的注意力集中在尽早交付科技城的有价值的需求模块。
尽早交付有助于测试，证实对于需求和架构的假设，来避免风险。
如果软件不可用，团队就需要重新调整，直到可用。
这种方法增加了用户的可视化，甚至用户可以在团队工作环境中配置或评估迭代的产出，允许用户的持续反馈。
管理和用户不必再一边祈祷团队能够做出正确的东西，一边默默地等上几个月。
编码方式是不同的。
在瀑布模式下，开发人员对所有的功能同时编码，最后产生一个大的，完全的软件包。
而在敏捷模式下，整个团队首先集中精力解决最早、最明确、最高优先级的功能。
持续地集成，不延缓测试。
仅生成一种代码：
测试过的、工作良好的、及成果的代码。
反馈及时并且持续，每个队员都知道，为了实现迭代的目标，每天应该在什么位置，完成什么事情。
敏捷模式下，对测试组织的影响是实质性的。
测试不再是生命周期的一个阶段，而是持续的行为。
测试人员不在测试没有经过测试的大块代码，而是测试系统，包括已经完成的单元代码和经过准入测试的代码。
这种转变，要求项目组必须开展代码集成和自动化测试。
测试水平随着测试者参与技术决策以及测试自动化的开发而得到增强。
测试人员不再是纯手工的测试执行者。
而是水平提高，等同于研发人员。
规划并没有在敏捷模式中消失，实际上，应用得更加充分了。
在两个层次上都要做规划：
为产品发布制定整体计划，为迭代制定的细致规划。
根据迭代的推进，规划也是滚动式的进行，在开发过程中不仅制定一次规划，在每次发布和迭代的前期都要进行规划。
规划不再是粗略的和即兴的，变成了系统和常规。
规划被极大地简化，每次都是在提前知道确定日期的情况，再来筛选feature的。
追踪也变得简单，每天的站会和平凡的演示显示出实际的项目进展。
计划和实际之间不再隔着深深地鸿沟。
上文我们提到过：
日期和范畴相比，总是优先考虑日期。
更确切地说，迭代长度决定开发范畴，而不是范畴决定开发周期的长度。
在计划驱动的的方法中，范围决定时间，范围和时间在每个规划周期和每次重大变化中都会发生改变。
由于敏捷模式下，固定时间，并根据时间来定义范围，所以，团队能够自由的根据需要进行，将注意力持续集中在到期需要完成的任务上。
即使因为某些原因，交付的结果缺少有效的功能而成为未完成的任务，那么也不用担心，因为，下一次迭代仅需要两周时间，一个月或者两个月之后的下一次发布将是可用的。
敏捷崇尚时间盒内创建小块的可工作的代码。
软件项目大多饱受需求不清，变化太快，就像B项目一样。
但是，又没有足够的能力把敏捷方法一次性的投入到开发流程中，那就从时间盒入手吧。
这是敏捷模式的重要动力。
当团队掌握这个技巧后，自然就会带来敏捷方法集中的其他特征和办法。
升级会员 