什么是自组织？

“自组织”并不是敏捷项目团队的专属概念。自组织的理论始于20世纪60年代末期，它的研究对象主要是复杂自组织系统（生命系统、社会系统）的形成和发展机制问题。自组织理论的起源是来源于生物系统，生物系统中，从细胞到组织、到个体、直到群体(社会),都具有极其复杂的结构。一个小小细胞的复杂程度并不亚于一个社会，而大自然却自有一套绝妙的方法来组织与运行生命系统，这就是自组织的方法。

如今人们所正在研究与推行的分布式网络、Multi-Agent系统、仿生制造和敏捷团队等等，其实是在不同程度上学习和借鉴了生物学中自组织的结构与运行模式。

自组织与他组织

要了解自组织首先需要了解与其对立的常规组织模式——他组织。

• 他组织：从外部来对系统加以设计、组织和控制的模式，迄今为止几乎所有的人造系统都是采用“他组织”的模式；
• 自组织：是以生命现象为代表的自然系统所采取的自组织控制模式。在对物种起源、生物进化和社会发展等过程进行深入观察和研究后，一些新兴的横断学科分别从不同的角度（系统论、热力学、统计力学、进化论等角度）对“自组织”的概念给予了解说，列举最通俗的有代表性的系统论的观点来说：“自组织”是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断地提高自身的复杂度和精细度的过程。

自组织的特征

 在研究自组织团队的过程中，传统自组织系统的现象和特征非常值得我们借鉴，概括起来有如下特征：

• 信息共享。系统中每一个单元都掌握全套的“游戏规则”和行为准则，这一部分信息相当于生物DNA中的遗传信息，为所有的细胞所共享；
• 单元自律。自组织系统中的组成单元具有独立决策的能力，在“游戏规则”的约束下，每一个单元有权决定决定它自己的对策与下一步的行动；
• 短程通讯。每个单元在决定自己的对策和行为时，除了根据它自身的状态以外，往往还要了解与它临近的单元的状态，单元之间通讯的距离比起系统的宏观特征尺度来，要小得多，而所得到的信息往往也是不完整的、非良态的；
• 微观决策。每个单元所作出的决策只关乎它自己的行为，而与系统中其它单元的行为无关；所有单元各自的行为的总和，决定整个系统的宏观行为；自组织系统一般并不需要关乎整个系统的宏观决策；
• 并行操作。系统中各个单元的决策与行动是并行的，并不需要按什么标准来排队，以决定其决策与行动顺序；
• 整体协调。在诸单元并行决策与行动的情况下，系统结构和游戏规则保证了整个系统的协调一致性和稳定性；
• 迭代趋优。自组织系统的宏观调整和演化并非一蹴而就，而是在反复迭代中不断趋于优化；事实上，这类系统一般无法达到平衡态，而往往处在远离平衡态的区域进行永无休止的调整和演化；一旦静止下来，就表示这类系统的“死亡”。

那如何建立自组织的敏捷项目团队呢？

由上述自组织的特征我们可以了解到自组织团队的必备原则：

           传统自组织  敏捷项目自组织团队

信息共享——目标与准则共享

单元自律——独立决策能力

短程通讯——增强沟通

微观决策——责任感

并行操作——并行操作

整体协调——确保整体协调

迭代趋优——迭代趋优

1.  目标与准则共享。团队每个成员有一个共同的目标，这个目标是每个团队成员共同商定并一致支持的，就如同群鸟飞行有共同的方向。在统一目标的同时，还有相同的行为准则，这是团队长期以来形成的工作方式与优秀实践，比如上班不能迟到，每日要开晨会等等。团队在共同的目标和准则下前行。
2.   独立决策能力。团队每个成员都有一定的自主权。能在共同的目标与准则下，积极主动地为团队出谋划策，主动认领工作任务，并自主决策完成任务的最好方法。在Google，个体的自组织和自支配特点显得尤为突出。公司鼓励个人将20%的工作时间用于从事自己喜欢的课题研究，创新的能量就在这种自组织和自支配过程中得到最大限度的释放。Google的不少产品，如Gmail、Google News，就是这样被开发出来的。
3.  增强沟通。自组织团队中的沟通显得尤为重要。团队再也不是一个决策者分配任务，每个成员埋头苦干，各不相干的工作方式，取而代之的是随时沟通，注重分享，及时抛出问题，共同面对困难。团队目标和任务在沟通中明确，团队的困难和问题在沟通中得以解决，团队每个成员在沟通和分享中快速成长。
4. 责任感。团队成员自身要具备一定的素质。其中最重要的是责任感。如果没有责任感，约定时间内的任务不能保质保量地完成，团队完不成交付，会对团队目标达成和团队的节奏上造成很大影响，更谈不上个人在遵循共同的目标和准则下的自主决策、自主创新了。
5. 并行操作。在自组织系统中，并行性指的是各个单元的行动是并行的，不需要排队和决策依赖。而在自组织团队里，由于个体是人，所以天生就具有操作并行性。这也是自组织理论应用到敏捷团队中的天生优势。
6. 确保整体协调。团队每个成员的自主决策性，决定了团队必须有一个整体协调机制，协调的规则是团队共同的目标和准则，协调人一般是团队的管理者。这里的管理者与传统管理者的区别是，管理者更像是一个服务者的角色，他负责争取外部资源，促进团队建设，协调团队成员工作，在争论不休时引导团队决策，更多的是协调而不是做决策。这样才能保证整个团队的协调一致性和稳定性，
7. 迭代趋优。自组织理论中有一个概念叫“突变论”，它是指在稳定性理论的基础上，由一种稳定态经过不稳定态向新的稳定态跃迁的过程。同样，自组织团队也不是一蹴而就，而是在不断优化团队准则，不断构建沟通氛围，不断增强责任感，不断形成合适的管理风格中演变而来的。所以自组织的团队的建设也可以看成是迭代式建设的过程，需要项目成员之间从不断发现新问题并寻求解决的过程当中形成默契，逐步趋向于真正的“自组织”。 

当然，人和机器有所不同，团队和系统也不一样。对自组织系统，我们为它设定好一定的程序，它的各个单元就能按照既定的设计执行下去。但团队中的单元是人，是完全自主的个体，我们如何团队的每个成员都能按照统一的准则，保证各项工作准确进行下去呢？这对我们自组织团队来说提出了额外的要求：

1.         统一目标的策略

自组织团队不仅要有统一的目标，更重要的是，要保证团队成员持续认定这一目标。通常目标分为长线目标和短线目标，为了确保长线目标的达成，团队需要建立若干里程碑式的短线目标，在每一阶段的工作中不断与团队成员确认长线与短线目标，在每一阶段启动和完成之时以庆祝奖励等激励措施让大家知道目标越来越近了，也有助于保持团队的持续兴奋。

2.         引导型的管理者

1）管理者=服务者。这一点在上文的“确保整体协调”中提到了。

2）信任原则。管理者应当充分信任团队成员，用人不疑，疑人不用。在沟通顺畅的基础上，充分相信团队成员的主动性与责任感，而不是时刻以一种监视的态度对待每个成员的工作，这样才能在一定程度上刺激团队成员工作的积极性与创新意识。

3.         奖惩分明

在自组织团队建设的过程中，尤其是建设初期，奖惩制度有利于对引导团队建立共同的准则和团队成员主动性与责任感的培养。比如晨会迟到者需要为团队贡献活动基金等，同时适时表彰榜样的力量也能促使团队成员积极投入到学习与工作中。这里要注意的是奖惩机制必须得到团队的认可，是由团队成员共同决定的，这样才不违背自组织团队。

建立自组织团队是一个长远而艰巨的过程。这里非常赞同传统自组织“迭代趋优”的特征。只要团队成员和管理者有自组织的意识，有培养自主性与责任感的决心，相信就能在敏捷的道路上越走越远。

在Rally中，产品经理可以完成如下工作：

1. 创建Backlog
2. 进行Backlog的优先级整理
3. 组织Story的层级结构
4. 缺陷的分类处理
5. 发布计划
6. 发布跟踪

1. 创建Backlog

概述

产品经理通过Rally创建Backlog（整理好优先级的列表）和User Story（需求）。

使用Rally

1. 在Backlog & Schedules > Backlog 页创建User story
2. 确保你从系统右上角的项目选择器进入到正确的项目
3. 点击按钮并选择”New User Story”
   1. User Story必须有一个名称。名称应该描述需求的核心功能，例如”向购物车中添加新商品”
   2. 详细描述字段用来描述完整需求，例如”作为一个买家，我希望能够向我的购物车中增加新商品，以便我稍候购买”
   3. 可以在详细描述中填写核心条目作为验收标准
4. 如果你的团队和你一起新建backlog，你可以向他们了解每个User Story 的预计完成时间并将他们的名字写入User Story。

小贴士

1. 如果你只是希望在backlog中快速创建story一面遗漏一些细节，你可以选择”Inline Add User Story”操作。

2. 进行Backlog的优先级整理

概述

Rally提供了两种不同的排序方式。在”强迫排序模式”下，所有对象（包括story、defect和defect suites）在任何时候都按优先级排成列表，通过拖动可以方便地对他们进行重新排序。在”十进制排序模式”下，产品经理可以通过手动为每个对象添加数字标签来进行排序。”强迫排序模式”简单易用，它不允许重复的优先级，所以不会使排序混乱。你的项目管理员可以决定选用哪种排序方法。

 使用Rally

1. 在Backlog页面（其余Rally页面也存在这种情况），如果列表按照”Rank”排序，你就可以看到图标；
2. 需要优先级排序时，鼠标移到上拖动当前行至合适的位置上去；
3. 如果你需要将一个story移动较长的距离（比如从100行移动到第10行），采用编辑rank字段的方法会更加容易。
   1. 双击各行的空白处，会出现在线编辑（inline edit）模式，然后改变Rank值至10；
   2. 点击图标保存编辑结果后，当前story会被移动到列表的第10行。 

小贴士

1. 你可以在Backlog & Schedules > Backlog页面上将Defect和Story一起进行优先级排序
   1. 点击左上部分的按钮，所有未关闭的和未规划（这里指未排入release）的Defect会出现在列表中；
   2. 拖动Defect同Story一起进行优先级排序。

 3. 组织Story的层级结构

概述

User Story可以按照层级关系组织。如果某些特性（feature）太大，无法在一个迭代中完成，那么可以将这类特性建立为一个父User Story和它的孩子Story的结构。比如，你可以建立成：

购买事项

       购物车

              * 添加商品到购物车

              * 查看购物车

              * 改变购买数量

              * 删除购物车中的商品

              * 保存购物车

       付款

              * 进入付款程序

              * 付款前登录

              * 输入地址信息

              * 输入支付信息

              * 确认订单

              * 支付流程

              * 邮件确认

在Rally中，story的状态（status）和预计工时（estimates）是story树积累的结果，所以即使需要通过几个迭代、几次发布或几个项目组（Team）来实现，”购买事项”这个父story的进展情况还是可以方便地被了解到。

 使用Rally

1. 在Backlog & Schedules > User Stories页面进行story层次结构的建立
   1. 这个页面可以通过选择左上角的和按钮来选择进入树结构视图还是平铺列表结构视图。
   2. 在树结构视图中，每个story可以通过右边的图标创建子story
   3. 点击上述图标可以打开一个story新增页面。新增的story自动挂在老story下面
   4. 点击 按钮后可以在页面上看到新的story被挂在老的story下面 

小贴士

1. 你也可以将一个已存在的story挂在本story下，通过修改story的”Parent”属性实现。

4. 缺陷的分类处理

概述

缺陷（Defect）同样也需要划分优先级（prioritize）和排序（rank）。新创建的缺陷是”submitted”状态，除非你自定义了缺陷的状态。你可以通过在缺陷页面采用自定义视图显示”submitted”状态的缺陷来快速地找到并处理它们。这样有助于你的团队方便地在backlog顶部抽取重要的工作。 

使用Rally 

打开和查看缺陷

1. 打开Defects & Tests > Defects页面
2. 在状态列选择”submitted”状态
3. 点击 按钮进行过滤。在出现的过滤结果中挑选合适的缺陷并将它们的状态变为”Open”
4. 点击 按钮选择”批量编辑”来对状态进行批量修改

缺陷优先级排序

1. 在Backlog & Schedules > Backlog页面对缺陷进行优先级排序
   1. 采用拖动排序的方法对缺陷进行排序
   2. 如果你没有采用拖动方式，你可以在缺陷页面新建一个自定义视图并通过”批量编辑”功能来进行排序（详见小贴士）。你也可以通过手动输入数字优先级来进行排序 

将缺陷和story共同放到backlog中

1. 使用backlog页面左上角的按钮可以让缺陷和story共同展现在backlog

小贴士

1.  为Defects & Tests > Defects页面创建自定义视图，定义状态为”Open”，并选择”Rank”列，就可以在缺陷页面对缺陷进行拖动和输入数字排序了。

5. 发布计划

概述

对产品经理来说，发布计划通常是指将经过优先级排序的backlog介绍给项目组成员，使项目经理和项目成员更好的进行迭代规划和认领。

 使用rally

1. 使用Backlog & Schedules > Backlog页面来向项目成员介绍backlog
   1. 点击 和 图标，在backlog中同时展示story和缺陷
   2. 将鼠标移动到story或缺陷的ID上来显示本对象的摘要
   3. 点击ID或名称链接可以查看story或缺陷的详细内容
2. 团队成员可以在Backlog & Schedules > Plan页面将story或缺陷规划到发布或迭代中去

小贴士

1. 在发布计划会议上，可以同时将开发工作分配到发布中以及迭代中

6. 发布跟踪

概述

发布可以在（工作产品状态）Work Product Status dashboard中进行跟踪，如果你希望在看到大的工作是如何进行的，这个dashboard可以展示所有story的层级关系。

 使用rally

1. 发布可以在Dashboard > Work Product Status页面中进行跟踪。
   1. 页面展示了story的层级关系，并提供了摘要，展示大的工作是怎么进行的；
2. 使用Dashboards > Release Status 页面
   1. 页面展示了包括任务在内的所有的工作
   2. 一个发布的焚烧图会在页面的上部显示

小贴士

1. 如果你的story完成趋势不如人意，你可以在backlog & Schedules > Plan页面将其取消排期
   1. 将story拖动移出迭代和发布，将它重新放到backlog中

什么是用户体验？

我们经常在说“用户体验”，用户体验究竟是什么？Garrett用浅显的语言向我们作了解释——用户体验（user experience），并不是指一件产品本身是如何工作的，而是指“产品如何与外界发生联系并发挥作用”的，也就是人们如何“接触”和“使用”它。

任何产品都存在着用户体验，但在“网站”上，用户体验比任何一个其他产品都显得重要。因为不论用户访问的是什么类型的网站，对大多数人来说，它都是一个“自助式”产品。没有事先阅读的说明书，没有任何操作培训或讨论会，用户所能依靠的只能是自己的智慧和经验，独自面对。因此，“去理解人们所想和所需”这件简单的事情，是任何网站发展过程中都应该格外重视的。

面向外部网站毋庸置疑，用户体验直接影响着用户是否会第二次访问它，直接影响着网站的投资收益率。企业内部的网站，如果不注重用户体验，让企业员工使用网站花费的时间越多，依据“时间就是金钱”的原则，将直接从一个“为企业创造价值的项目”变为一个“资源消耗噩梦的项目”。

什么是好的用户体验呢？

协调一致、直观明了、让人愉快的体验，一次“每件事情都按照正确的方式工作”的体验，就是好的用户体验。

用户体验的因素很多，归纳起来，有五个要素，也是五个层面，由上而下分别是表现层（surface）、框架层（skeleton）、结构层（structure）、范围层（scope）和战略层（strategy）。这五个层面抽象的提供了一个网站基本架构，由下而上各层相互影响、相互关联。

在阐述这五个层面时，作者区分了网页作为软件的界面和作为内容的载体这种双重性质，并指出了如何在产品设计过程中对二者进行处理。如图所示：

让我们从底层到上层进行阐述：

战略层：指用户需求与网站的目标。成功的用户体验，其基础是一个被明确表达的“战略”。知道企业与用户双方对网站的期许和目标，有助于确立用户体验各方面战略的制定。

范围层：指网站的功能规格及内容需求。带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们就能弄清楚如何去满足所有这些战略的目标。当你把用户需求和网站目标转变成网站应该提供给用户什么样的内容和功能时，战略就变成了范围。

结构层：指网站的交互设计和信息架构。在收集完用户需求并将其排列好优先级别之后，我们对于最终产品将会包括什么特性已经有了清楚的图像。然而，这些需求并没有说明如何将这些分散的片段组成一个整体。这就是范围层的上面一层：为网站创建一个概念结构。

框架层：页面设计，包括布局、导航与信息设计。在充满概念的结构层中开始形成了大量的需求，这些需求都是来自我们的战略目标的需求。再框架层，我们要更进一步地提炼这些结构，确定很详细的界面外观、导航和信息设计，这能让晦涩的结构变得更实在。

表现层：指网站的视觉设计。在这个五层模型的顶端，我们把注意力转移到网站用户会首先注意到的那方面：视觉设计。这里，内容、功能和美学汇集导一起来产生一个最终设计，这将满足其他四个层面的所有目标。

上述五层要素中，要求每个层面的工作再下一层面可以开始之前完成，会导致你和你的用户都不满意的结果。一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成。

无论网站有多大，用户体验的要素都是一样的，但将这些要素背后的想法付诸实施，却是一个心态的问题。 

大部分时候，关于用户体验的决策总会体现在以下这些场景之中：

1.由现状决定的设计（design by default）。

2.由模仿决定的设计（design by mimicty）。

3.由领导决定的设计（design by fiat）。

很多时候，你必须在不同的做法之间作出妥协并评估利弊以及进行取舍。

如果在网站开发过程中，始终从完整的用户体验出发，那么最后得到的网站就是一份有价值的资产。有意识、有目的地做出每一个决定，并在执行时将每一个决定都建立在对其背后的议题的理解之上之忧这样才能确保这个网站能同时满足我们的战略目标和用户需求。

 顺便说一句，本书在强调“用户体验为何如此重要”时举了一个非常生动的日常生活中的遭遇的例子，与最近奥斯卡大热的《Benjamin Button》的一个倒叙片断如出一辙，不论书还是电影，这都是一种非常棒的用户体验。^­_^