敏捷两实践分享（转载）

近期，在与各团队接触，或多或少的谈到&推进&尝试敏捷，有几点实践和大家一起分享下：
1.  最佳实践之：demo sharing  
     区分：demo sharing  ≠ show case

     showcase 主要是指开发过程中由产品owner 来验证 “已开发出来的工作成果”，尽早发现 开发成果 与需求不符的情况；

     demo sharing 是指 工作成果展示与共享（分享），工作成果可以是 “一份设计文档（也可以是一张成型的设计图）、一段代码、一个测试用例 、一个代码检查的思路” 等，总之鼓励团队成员 及时拿出工作成果来“秀”一下。（demo sharing 的形式可以不用那么太正式，团队中如果有可拿出来sharing的东东，就及时拿出来，开始时SM每天需要询问大家是否有东西可拿出来share）

     目前，很多外部团队每天用晨会后的15分钟来进行“demo sharing”, 通过此活动（实践）可以达到多重目的：a. 对于团队，达到活跃气氛，互相学习互相促进的目的（当然也有种无形的压力）；b. 对于个人，锻炼表达能力；c. 对于管理者，及时洞察真正的进展、成果、问题与风险； -- 这也是敏捷中谈到的自组织团队“透明、可视化”的一种体现 。

 

2. 打造“1-3-9”团队，把“传帮带”进行到底：

   “1”  一般是指团队leader;   “3” 是指团队中经验稍丰富、能力较强的人员；“9” 是指团队中经验稍少、能力稍孙的人员 -- 形成1带3的局面。

   a. 在团队组建时，团队leader(1) 要充分授权 团队中的3，让他们分别去面试人员 （这样可以找到他们需要的人，与他们臭味相投的人，甚至一起去东莞的人-- 这样工作起来的效率也是很高的） -- 这是敏捷中“自组织”的一种表现方式。

        PS： 当前，我们很多团队的招聘时，一般由某位主管去面试，然后分派到相应的组中去 . -- 这种方式未必是较好的团队组建方式。

   b. 在团队管理上，形成分层管理模式，团队中的“3” 要分别对其下的“3”负责，包括帮助他们去理解需求、指导他们设计与开发、对他们的代码进行review 等，同时也要及时解决他们的困难与痛经。

   c. 在沟通层次上，也形成了分层沟通局面。不要形成1对12的局面。

 

最后，让我们大家一起再来回顾敏捷中的12条原则，个人感觉，我们实施敏捷时要 时刻记住敏捷的12条原则（这是精髓），（这些在网上都能搜索得到，也一大把，但我们需要真理解她，并奸行她）：

 

 

1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使产品&用户满意

　 规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户（产品、市场）形成早期的良好互动，及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术（用户故事 = 用户+功能 + 价值），它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷故事使用了这个模板：“作为【什么什么用户】，我希望可以【通过什么功能】以便达到【什么业务价值】“。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口交了。

2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为产品创造竞争优势。
　　敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。［当然，我们需要尽量减少因人员能力问题、团队协作不顺带来的需求变更］
3、经常性的交付可以工作的软件，交付的间隔可以从几天到几个周，交付的时间间隔越短越好。
　　迭代是受实践框限制的，意味着即使放弃一些功能也必须按时结束迭代（时间盒）。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到了可发布的质量标准的。
PS： 为此，团队的中代码分支管理将变成灰常重要。


4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。（UC的座位安排已充分考虑到这点了）
　　软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以产品、开发人员以及涉众之间必须进行有意义的、频繁  的交互，这样就可以在早期及时的发现并解决问题。showcase 是其中一项不错的实践措施（日常showcase  与 每周定期showcase相结合）

5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
      业务和技术是引起不确定的二个主要方面，人是第三个方面。而业务和技术又必须由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致，我们就需要鼓舞起每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。-- 这也是自组织的一种表现 （给他们快乐、给他们爱、给他们授权、充分相信他们，使管理变成领导） 

6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
　　在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
7、可工作的软件是首要进度度量标准。（注：可工作 ≠ 可运行）
　　一般的工作都比较容易衡量任务进展，比如让你去搬运1吨的木材，我只要去称一下你已经搬运的木材重量就知道你完成多少了。而对于软件来说，在软件没有编码、测试完成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。--敏捷中衡量生交效率也是“以完成”的标准 去计算的，做了一半故事（或功能），都不会计算的迭代的工作效率中的。
  当然，为了把控迭代过程中的进度，那么就使用看板、燃尽图。

8、敏捷过程提可持续的开发速度。团队应该能够保持一个长期的、恒定的开发速度。
　　敏捷中开发速度是以“故事点”的方式来评价。

 

9、不断地关注优秀的技能和好的设计会增强敏捷能力。
　 敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。
    推荐大家系统化读三本书《SCRUM敏捷开发》、《精益和敏捷开发大型应用实战》、《用户故事与敏捷方法》。

 

10、以简浩为本，极力减少不必要的工作量（消除浪费）----这也是精益 的思想（关注当前用户最需要的、以及减少冗余-- 如代码冗余，需求文档冗余等）。

      我们不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说，我已经预计到了肯定存在哪些需求扩展点，我们在一开始是否需要考虑呢？这时团队需要根据自己的理解去决定是否考虑，如果深信在明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。
[p=25, null, left]PS：近期与 敏捷中文的老师 交流时，这点深有体会，通过打造“1-3-9”团队是“消除浪费”的一项好的措施。

11、最好的构架、需求和设计出自与自组织的团队。
       敏捷中有很多种实践，大家都知道，迭代式开发是主要的实践方法，而自组织团队也是主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。自组织团队的第一个要素就是必须有一个团队（团队 = 团结的队伍），而不仅仅是一群人。一群人是一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也并不视彼此为一体。项目一开始，我们就会组建“团队”，但很多时候由构架师、产品人员、开发人员和测试人员组成的是一群人而已。他还认为，团队的形成必须经历几个时期。在经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班，都会主动询问别人是否需要帮助，也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。
　　虽然敏捷开发小组是以小组为整体来工作的，但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者（Product Owner）。产品所有者的主要职责包括：确认小组所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具有价值的功能，以及作出决定使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队（developer），这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、运维人员等，有时产品所有者也可以被看作是开发人员。还有一个重要角色就是项目经理（project manager）。敏捷开发的项目经理（也可叫做SM）会更多的关注领导而不是管理。在某些项目中，项目经理可能同时也是开发人员，少数时候也会担任产品所有者。
　　
12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
　　由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。　敏捷不是基于预定义的工作方式（区别于CMMI），而是基于经验性的方式，对以上这些变化，小组通过不断的反省调整来保持团队的敏捷性。