2016-08-12 13:38:43 diyal 阅读数 1483

##游戏敏捷开发项目管理之我见(三) 沟通

一、沟通过程中的思路
这里写图片描述
1、询问信息

* 明确要问什么,沟通一定要带着目的性,否则就是扯闲篇了。最好是列好条例。
* 信息是否完备,沟通的信息是否完备了,是否都得到自己想要的答案了。
* 信息是否准确?是否掺杂感情色彩,或是片面之词。

2、工作任务

* 安排的工作任务,明确需要对方知道的信息有哪些?安排一个模块开发,首先要让对方知道,这个模块是要干什么,什么时候完成,任务否否紧急,你的诉求是什么,是否有困难,困难的解决方案是什么,通过什么帮助或者调整可以解决这些这些困难?如果delay了怎么办等等。
* 确定对方已经理解,最好是通过反问的方式来确定
* 最重要的是明确任务完成的时间节点,开发者肯定会觉得这个时间没办法给出,毕竟在什么都没干的情况下,谁都不敢轻易给出具体时间。所以最好是在开发者给出的时间留出一定的弹性。

二、沟通技巧,说话的艺术

1、不要说“但是”,而要说“而且”
“我觉得这种想法很好,而且,如果在这里再稍稍改动一下的话,也许会更好……”

2、不要说“首先”,而要说已经
跟老板汇进度,“首先”一词出口,就让人觉得你还有很多事要做,却不会认为你已经做了一些事情了。而且这样的讲话会给人一种悲观的感觉,而往往项目开发需要良好积极乐观的氛围。
“是的,我已经相当熟悉这项工作了……”

3、不要说“错”,而要说“不对”
一个leader最让人钦佩的,是让成员甘心情愿付出,当然犯错误是在所难免的,所以我们必须要注意的是,不要说“错”,而是说“不对”,这样在语气上,更让人接受。总之不管什么情况,你要有跟成员一起面对错误的态度。
“你这样做的确是有不对的地方,咱们最好是为此承担责任”

4、不要说“仅仅”
在一次Bug修改会议,或是一个需求评审的时候,你是这样说的“这仅仅是我的一个建议……”
这样说是绝对不可以的,这样一来,你的想法、功劳包括你的价值都会大大贬值。本来利于项目,团队的一个主意,反而让同事觉得你的自信心不够。
“这就是我的建议”

5、不要说“本来”
你和你的谈话对象对某件事持不同看法,你却轻描淡写“我本来持不同看法的”。这样不但没突出你的立场,反而让你没了立场。类似还有“的确”和“严格来讲”
有威信的领导都是直截了当“对此我有不同看法”

6、不要说“务必”而是“请你”
7、不要再说“老实说”

2016-11-03 17:37:57 buding_pmp 阅读数 4085

[摘要]  
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。

  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
  在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
  对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
  并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
  运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
  但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
  一、敏捷开发最少需要维护哪些文档?
  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
  实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
  但文档宜少且精炼,一般情况下建议维护三份文档:
  《产品需求规格说明书》
  也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
  《系统设计说明书》
  开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
  《测试用例和测试报告》
  由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
  二、敏捷开发是否需要系统设计?
  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
  小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
  传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
  三、敏捷开发是否需要项目计划?
  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
  它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
  但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
  四、敏捷开发的迭代周期大概多长?
  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
产品项目里的九个敏捷开发实战经验
  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
  五、敏捷开发为何提倡小版本?小版本有哪些优势?
  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
  1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
  2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
  3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
  六、敏捷开发与重构的关系如何?
  敏捷开发以重构为基础,时时刻刻处于重构过程中;
  七、敏捷开发为何强调团队人员的参与、用户的参与?
  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
  由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
产品项目里的九个敏捷开发实战经验
  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
  “是的,就是这样的”
  “这正是我想要的……”
  “这里需要修改一下……”
  “我的想法是这样的……”
  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
  八、怎么才能评估团队是否已经敏捷了?
  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
  • 团队有共同的愿景,并且对这个愿景充满信心;
  • 团队有明确的阶段目标并且为每个成员所知晓;
  • 团队知晓当前计划:做什么、何时完成、预期效果等;
  • 团队任务是低耦合的,并且紧密协作;
  发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
  九、敏捷开发能缩短项目时间并提高质量吗?
  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
  • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
  • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
  • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
  • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
  以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用

2011-05-17 10:45:00 angel_rabbit 阅读数 2702

from:

http://www.tup.tsinghua.edu.cn/Resource/tsyz/035257-01.doc 

 

 

 

 

 

 

 

 


敏捷项目管理模式

 

 

 

 

 

本书的第1版重点介绍了敏捷流程架构的几个主要项目阶段。然而,在过去5年中,敏捷方法已经开始广泛应用于较大型的项目和组织中,因此构建一个较为全面的敏捷企业架构显得尤为必要。例如,在大型跨国组织中,其项目并非都是敏捷项目,即使都是,某些地区可能使用不同于其他项目的敏捷方法。一个机构地区用Scrum,一个用极限编程(Extreme ProgrammingXP),而另一个使用功能驱动开发(Feature Drivern DevelopmentFDD),这种情况一点也不稀奇。并且,应该鼓励使用这种多样性的方法!因为很有可能的情况是,在中国的项目可以得到Scrum的良好支持(如培训、辅导等),而澳大利亚的项目得到FDD支持会更好些。

敏捷开发的信条之一是适应不同情况。《相互依赖宣言》的6个原则之一是:通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。因此,很难在一个跨国组织中,只使用单一的标准化敏捷方法。然而,使用一个共同的架构,而且能在其中选择各自不同的敏捷方法,对于较大型组织来讲,无疑具有很大的吸引力。

5.1  敏捷企业架构

敏捷企业总体架构如图5-1所示。投资组合治理层提供一些常见的检查点;项目管理层对各种项目的管理提供指导。项目管理层和迭代管理层不同,其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。最后,区分迭代管理层和技术做法层,有助于把核心技术做法融合到几个项目或者迭代管理方法中去。

5-1  敏捷企业架构

这个结构有利于组织采取混合的敏捷方法,即每层使用不同的敏捷方法,以满足组织的特定需要。该架构倡导底层(技术实践层)具有较大灵活性,上层(项目管理层)灵活性较小。这种结构认同没有哪一种敏捷方法适合所有层次。事实上,组织中使用的所有敏捷方法都是混合型的。例如,一个组织的项目管理层可能采用APM(和部分PMBOK的组合),迭代管理层用Scrum, 而在技术层选用XP做法。通过汲取几种敏捷方法的优点,公司可以构建高效的混合方法,或者可以为组织的不同部分构建几种不同的组合方法。

5.1.1  投资组合治理层

大公司拥有数以百计(如果不是数以千计)的项目。其中,有的敏捷,有的传统;有的使用这种敏捷方法,有的使用另外一种;有的使用敏捷和传统的混合方法。即使一个组织已经决心向敏捷组织转变,在维期几年的转变期间,将会混合使用各种方法。主管们需要的就是一个通用的架构,可以用来评估所有项目。这个架构涉及主管们所关心的主要问题——投资和风险。主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。他们不会真的关心需求文档是否完成了。他们想了解项目进程、投资和风险。因此无论项目是什么类型——敏捷或是其他,都需要创建一个管理机制,解决这两个关键的代表项目属性的指标。第12章将会详细讨论投资组合治理层。

5.1.2  项目管理层

许多人认为项目管理即是与核心小组的外围利益相关者打交道,而迭代管理与核心小组的内部利益相关者打交道。这的确是两者差异的一部分,但只是一半。另一个很大的不同是一个是管理发布,一个是管理迭代。一个完整的项目发布计划(见第7章和第8),涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。

项目管理还包括与核心小组外围的利益相关者和供应商合作。因此,项目管理层关注全面的项目/发布活动,协调多功能团队和管理项目外围事件。除此之外,像风险分析、合同管理等凡是对项目有用的做法,无论敏捷与否,都属于这个管理层的管理范畴。(这些做法可能来源自美国项目管理协会的PMBK)

需要指明的是项目管理和迭代管理是可以是同一个领导者,也可以是不同的领导者,取决于项目的大小。例如,一个有4个团队的大项目可能每个团队有一个迭代经理,整个项目有一个项目经理。

5.1.3  迭代管理层

迭代管理层关注每个短期迭代的计划、执行和团队领导。本章最后一节会概述一下区分迭代和项目管理层的原因,基本上区分的是发布和迭代工作,以及项目内部和外部的管理活动。

5.1.4  技术实践层

软件项目中的技术实践,包括从持续集成到结对编程,从测试开发到重构等做法。硬件项目可能采用一系列工程做法,从电子到机械不等。虽然本书的重点是其他三层,但是项目有效执行的基础在于技术领域。在各种各样的组织中,变革技术实践是实施敏捷方法的关键。例如,持续集成和自动化测试是不能忽略的核心敏捷软件做法。

分离出技术实践层的另外一个原因是,使敏捷项目管理更适合各种项目和产品类型。尽管我很难做到让电子工程师或者机械工程师准备结对编程,但是事实证明,敏捷软件的等值做法在各种产品开发领域都很有价值。此外,除了硬件项目中可能存在较长时间的迭代外,投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

5.2  敏捷交付架构

流程也许不如人那么重要,但它绝非不重要。在敏捷圈内,流程被指责为静止的、常规的和难以改变的。就流程本身而言,不应该是负面的,它必须同企业目标联系起来。如果目标是重复性的制造,那么常规性流程是完全合理的;而如果目标是可靠的创新,则流程架构必须是有组织的、灵活的和容易适应的。敏捷交付架构需要体现前几章描述的原则,除了支持企业目标之外,该架构还需要:

          支持构想、探索、适应文化;

          支持自我组织、自律的团队;

          根据项目的不确定性程度,尽量提高可靠性和连贯性;

          保持灵活和易于适应;

          支持流程的透明化;

          合并知识;

          囊括支持各个阶段的做法;

          提供管理检查点。

敏捷项目管理模式的结构:构想推测探索适应结束,重点在交付(执行)和适应(如图5-2所示)。它基于Adaptive Software Development(海史密斯,2000)一书提出的一个模式。

5-2        敏捷项目管理交付架构

该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同,其意义重大。第一,“构想”代替较传统的“开始”,指出构想的重要性;第二,推测阶段代替计划阶段。每个词都传达一定的意义,而各个意义来自他们长期的系统用法。“计划”一词已经与预测和相对确定性相关联,而“推测”表示未来是不确定的。许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。我们必须学会推测和适应,而不是计划和建造。

第三,敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭代交付的方式,很明显探索是非线性的、并存的、非瀑布式的模式。在推测阶段提出的问题需要“探索”。鉴于结果不能完全预测,推测暗示着灵活性的需求基于现实。敏捷项目管理模式强调执行以及探索性而非确定性。实施敏捷项目管理的团队密切关注构想、监控信息,从而适应当前情况,这就是适应阶段。最后,敏捷项目管理模式以结束阶段收尾,这个阶段的主要目标是传递知识,当然它也是一个庆典。

总之,敏捷项目管理的5个阶段是:

          构想:确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。

          推测:制定基于性能和/或功能的发布计划,确保交付构想的产品。

          探索:在短期内计划和提供它经测试的功能,不断致力于减少项目风险和不确定性。

          适应:审核提交的结果、当前情况以及团队的绩效,必要时做出调整。

          结束:终止项目、交流主要的学习成果并庆祝。

5-2展示了所有的阶段和工作流程;图5-3表示的是两个主要的合作周期(构想周期和探索周期)中的相同活动。构想周期包括构想和推测阶段(产品构想、项目目标和约束、发布计划);而探索周期包括探索和适应阶段(迭代计划、开发和审核/调整)。图5-3强调周期而不是流程,说明在整个项目中,全部或者部分构想周期可能会多次执行。例如,可能(应该)每次或者每两次迭代就需要构建一个修改后的发布计划。在费时较长的项目中,可能会定期修正整个构想周期的结果。

5-3  敏捷项目管理的构想和探索周期

5.2.1  阶段:构想

构想阶段为客户和项目团队创建构想,该构想包括什么、谁提供提供和如何提供。如果没有构想,其他的项目启动活动都是无用之功。用商业用语来说,构想是项目早期“成功的关键因素”。首先,我们需要构想提供什么,即产品及项目范围构想;其次,我们需要构想参与者都有谁:客户、产品经理、项目团队成员和利益相关方组成的社团;最后,项目团队成员必须构想他们打算如何共同工作。

5.2.2  阶段:推测

“推测”一词首先让人们想到的是不计后果的冒险,但实际上字典上它的定义是“根据不完全的事实或者信息猜测某事”,这正是这个阶段要做的事情[1]。“计划”一词具有确定和预测的含义,至少对于探索性项目来说,计划的更有用的定义是基于不完全的信息推测或者猜测。肯·德科尔评论道:“人们认为制定计划就是引进确定性,但事实并非如此。他们带来的只不过是衡量绩效的东西,而一旦这个衡量尺度与现实出现偏差,他们又不能重新计划。”敏捷项目管理包括的构想和探索比计划和执行要多,它迫使我们面对这样的现实:不稳定的商业环境和变化多端的产品开发环境。

推测阶段包括:

          收集初始的、广泛的产品要求;

          将工作量定义为一个产品功能清单;

          制订一个迭代的、基于功能的交付计划

          把风险降低策略纳入计划;

          估计项目成本,并生成其他必要的行政管理和财务信息。

5.2.3  阶段:探索

探索阶段交付产品功能。从项目管理的角度看,这个阶段有3个关键的活动区域:第一,通过管理工作量和使用适当的技术方法和风险降低策略,按计划交付产品功能;第二,建立协作的、自我组织的项目社团,这是每个人的责任但需要由项目经理和迭代领导者推动;第三,管理团队与客户、产品经理和其他利益相关方的相互交流。

5.2.4  阶段:适应

控制和纠正是这个周期阶段常用的术语。计划制订了,结果监控了,纠正也完成了:这个流程意味着计划是正确的,而如果实际结果与计划不同,则表明计划是错误的。适应意味着修改或改变而不是成功或失败。如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”,则将失败归罪于对计划的变动是没有成效的。非常特别的流程并不能从错误中吸取教训,而吸取教训是敏捷项目管理的关键部分。

在适应阶段,需要从客户、技术、人员和流程绩效,以及项目状况等方面对结果进行检查。该分析将会对比实际结果和原计划结果,但更重要的是,要根据项目得到的最新信息,思考实际的与修订后的项目前景。修改后的结果将反馈并应用到重新计划工作中,以开始新的迭代。 

自构想阶段以后,其循环通常是推测探索适应,每次迭代都不断地优化产品。但是对团队收集新信息来说,定期修正构想阶段也尤为重要。

5.2.5  阶段:结束

在某种程度上,项目由开始和结束来界定。由于许多组织没有明确项目的结束点,而导致与客户之间发生很多问题。项目应该以庆功典礼为结束。结束阶段(以及每次迭代末尾的小型结束)的主要目标是:学习并将学到的东西融入下一次迭代工作中,或者传递给下一个项目团队。

5.2.6  不是完整的产品生命周期

有人提醒说,本章及后面章节介绍的敏捷流程架构的几个阶段不能构成一个完整的产品生命周期。产品生命周期的前后两个阶段(早期的概念构想阶段和晚期的配置阶段)没被包含在这个架构中,不是因为它们不重要,而是因为它们超出了本书的范围。

5.2.7  选择和整合做法

接下来的几章将介绍APM交付架构每层的具体做法。这些做法应该看作是一个做法系统,因为只有作为一个系统,他们才能相互补充,从而与价值观和原则保持一致。但他们并不局限于保持一致,他们还着眼于实施。没有做法的原则只是个空壳,而没有原则的做法经常会被毫无判断地生搬硬套。没有原则,我们就不知道如何实施做法。比如说,没有简单原则,人们往往会过多地看重做法的形式和仪式。原则指导做法,做法用实际例子证明原则,两者是相辅相成。

使原则和做法保持一致昭示了这样一个现实:“最好做法”只是虚假的无法实现的梦想。对于某个项目团队非常奏效的做法也许对另一个团队是极其糟糕的。做法就是具体做法,它仅是实现一些目标的方式。一个具体做法只有在特定的环境中,才能知道它是好是坏,这个特定环境可能包括原则、问题类型(如探索性)、团队动力和组织文化。

没有最好的做法,只有更适合具体情况的做法。

后面章节中论述的做法已经在多个不同场合得到证明,其中一些可能在生产型项目中也很有用途,就像本书中没有提到的一些做法同样对敏捷项目也有用一样。在选择和使用这些做法时,作者采用了如下指导原则:

          简单的;

          再生的而非常规性的;

          与敏捷价值观和原则一致的;

          关注交付活动(增值)而非合规活动;

          最少数量(刚好可以完成工作)的;

          相互支持的(做法系统)

在后面章节中描述,基本上不是新的做法。其中一些是其他人描述的某类做法的变种,一些是为人熟知的,其他的则是人们不太了解的。例如,风险控制做法在项目管理书籍里被广泛论述,而其他的(如参与式决策)则很少论述到。因此,对于风险控制这些通用做法,将作简要论述,或者只提供其他的参考资源,而对于其他地方很少涉及的做法(如决策),将在本书中较详细地论述。

5.2.8  需具备的判断力

因为产品和项目管理长期以来受到顺序开发流程的熏染,所以看起来像图5-2那样的图例都被认为是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序,但人们不应该将整个模式看作是固定的。生产型模式所用的阶段名称暗示着一个线性和重复的模式:开始、计划、定义、设计、构建、测试,而这里选用的敏捷项目管理术语是用来表示迭代演变:推测、探索、适应。

过分强调线性会导致停滞不前,而过分强调演变会导致无休止的、最终证明是盲目的变化。对于任何一种模式,开发团队成员、产品团队成员和高级主管在应用时都需要作出敏锐的判断。

关于敏捷项目管理的一个最常见的问题是:“计划、架构和需求阶段如何?”最简单的答案是:这些是活动而不是阶段。敏捷方法中这些活动所用时间和传统的序列方法一样多,只是在敏捷方法中这些活动被分配到几次迭代和多次功能开发中。

第二个令人关注的是:在初始的软件架构工作中(这节的讨论指的是构建、计划和需求)忽略了一个关键项目,而导致的敏捷开发返工的风险问题。其实与其相当的一个的更大难以形容的风险——即前期架构工作出错——在顺序开发中也存在。在序列开发过程中,早期的架构决策在项目晚期及实际的构建出现时才能得到验证。到那个时候,已经花费了大量的时间和金钱。到时再改变这个架构,就成为一项重大的耗时的决定,但通常已经不可能修改了。

一切工作都应该是循序渐进的,即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差,因为没有人能够承受得起在项目晚期再改变架构。

5.2.9  项目规模

敏捷项目管理的核心价值观和原则适用于任何规模的项目,相似的,在后面章节描述的做法也适用于任何规模的项目。但是,对于超过100人的项目团队,可能除了本书中描述的做法外,还需要其他做法或本书描述做法的延伸,其中一些在第11章会有所论述。随着项目团队不断扩大,通常需要有更多的文档、有其他的协调做法、增加仪式或者其他合规活动(如财务控制),这些扩展的做法同样也受敏捷项目管理的价值观和原则的指导。例如,简化原则仍然适用于大型项目,只不过意味着采用最简单的、适用于150人而非15人的团队的做法。

一个500人的团队可能不如一个10人团队敏捷,但它可以比竞争对手的500人团队更敏捷。只要将重点集中在价值、交付、自我组织和自律,即使团队再大,面临的协调问题再复杂,它也能随时应对商业、技术和组织的变化。

5.3  扩展的敏捷交付架构

5-4展示的是敏捷交付架构的扩展版。在这个层面上,该架构确定了做法,也有效地成为混合方法的开始。它把探索阶段细化分成在迭代期的工作。这个扩展板的架构也指出了其他每一个阶段的做法。在接下来的几章中,将会详细描述这个架构中概述的做法。

5-4  扩展的APM交付架构

5.4  结束语

像敏捷项目一样,敏捷架构应该在结构和灵活性之间保持平衡。随着组织中敏捷项目的数量和规模不断增大,组织就需要有一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观。同时,假如一个项目团队在中国北京,另外一个在华盛顿的西雅图,他们有着不同的团队成员和不同的环境,他们就需要拥有适应这个通用架构和做法的自由权。这就是“敏捷艺术”,即平衡结构和灵活性的能力。它用有效的领导力和敏捷经验去发现每个组织的最佳平衡点。



1. 摘自微软的电子百科全书中的世界英语词典,该书1999年和2000年版权属于微软公司。

2007-08-30 11:08:00 nuaalfm 阅读数 5706

原文地址:http://www.infoq.com/articles/agile-kanban-boards

我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

1 任务板

任务是分解到手头的实际的工作

把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

可以画一些横的泳道来表明任务应该是谁来完成.

 

2 需求特性板

需求特性是软件大的功能需求,通常按照月份来进行归类.

3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

特性: 对最终用户有意义的一个功能
用例:由特性分解而来的一个可以用来做功能测试的小情节
任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

4 敏捷过程中,时间分为: 发布->迭代->每日

发布:通常一到六个月
迭代:通常一到四周
每天:

5 我们把工作和时间对应起来,就是这样

在每一个发布过程中,我们完成需求.
在每一个迭代周期中,我们实现案例
每一天,我们都要完成多个任务

6 更形象一点,我们把他们都结合起来:

你要准备三块黑板:

需求特性黑板:每一列标识一个发布需要完成的特性
案例黑板:每一列标识每一个迭代周期需要完成测试的案例
任务黑板:每一天要做的任务

 
2012-09-04 10:01:44 seucbh 阅读数 460

                              敏捷开发的借鉴

个人觉得敏捷开发的思想在于程序员之间的交流,提倡人与人之间信息的共享,而不是各自埋头做事。

 

1、 晨会制度

    每天早上小会,告知昨天作了什么,存在什么问题,后续可能需要怎么解决,需要什么协助。

    这样可以及时让项目组成员了解到其他人当前的工作状态,个人也可以及时反映出问题并可以寻求到帮助。

 

2、燃尽图

    记录项目的进展。项目进度可以说是管理者最关心的问题,这种问题必须毫不含糊的告知项目管理者。

    项目管理者可以清楚知道项目过程中的问题和风险,这样才可以很好的控制项目开发。

 

3、详细的文档比较少

    代码就是最好的文档。前提要建立一个很好的制度,保证代码能够达到文档说明的自说明的水平。否则的话,代码成为不了文档,又没有文档,这样项目就可能不可控了。

    所以,个人觉得敏捷开发应该是有一定水平的程序员才能够很好的进行工作,很自我的程序员在一起,很难进行敏捷开发。

 

4、持续集成

    这个好像是敏捷开发中唯一不可少的。个人觉得也是所有项目开发中不可少的。持续集成,才能提升整理的项目开发能力。

    比如,规范制度建立,自动化测试环境搭建,需求控制能力的提升都是持续集成的体现。

 

 

Scrum敏捷项目管理

阅读数 3150

没有更多推荐了,返回首页