1. 工作步调要可持续，而不是累到筋疲力竭。

  2. 面对面沟通，而不是发邮件。

  3. 开诚布公，而不是藏着掖着。

  4. 工作强调提高效率，而不是加班加点。

  5. 多用“我们”、“咱们”，而不是“你”、“我”、“他”。

  6. 解决问题的PrOpER模型

  • 问题: 选择一个问题着手解决。
  • 选项: 考虑解决问题的备选方案。列出至少三个选项。
  • 试验: 选择其中一个进行尝试。
  • 校验: 检查结果。

  1. 成功了归功于团队，失败了一同担当。

  2. 提防“我们这里就这样做事”这种思想。抵制改变，就永远不会进步。

  3. 敏捷实践需要宽松的环境，研发人员在压力下是无暇顾及敏捷的。人们在全力以赴的时候，需要有安全感。

  4. 全神贯注地倾听，倾听团队的困苦和哀嚎。

  5. 要想获得提升，人们首先必须得学会用新的行为做事之道。

  6. 如何对人们产生影响，使其接受你的领导？

  • Kent Beck：从小的变化开始。每次只做一件事，其他的稍后慢慢来。
  • 温水煮青蛙，一点一点来。
  1. 启发式提问
  • 要让这个Bug不再出现，我们能做什么？
  • 我们怎样才能做到按时发布？
  • 我们如何做到更高效地工作？

  1. 挑战假设：规定真的是规定吗？

    公司是这么规定的？
真的吗？
是谁规定的？
为什么这么规定？

  2. 提问的技巧：

  • 问开放式问题。
  • 为什么。。。？这类问题隐含着批评的意思，要谨慎使用。因为这种提问趋向于关注问题，而不是解决方案。
  • 求助性提问。
  • 5Why提问法：从表层原因一步一步深入提问，直到找到底层原因。
  1. 沟通的前提是信任
  • 如果缺乏信任，任何沟通技巧都无济于事；如果保持信任，再笨拙的沟通方法也有成效。
  • 有信任才有团队协作。
  • 信任的建立以合理的自我揭露为基础。
  • 相互之间分享私密信息有助于培养信任。我在中科院的心理学课堂上亲身体验过这种沟通效果，老师让小组内成员相互分享成长中的三件积极事件和三件消极事件,完成分享之后，小组成员之间的信任程度明显提升了，开始变得无话不谈起来。
  1. 如何激励团队?
  • 打造卓越团队的秘诀：设定可达成却有挑战性的目标。不会觉得太无聊，也不至于觉得太焦虑。
  • 培养一种用实验的方式来试错的团队文化。如果一项难题有多种解决方法可以选择，又不知道选择哪个？那就选择用实验的方式来增进对问题的理解。
  • 为团队找一个能吸引人的目标。如果能让团队理解自己正在开发一个有价值的产品，他们就更容易产生动力。
  • 在开发赶进度之余，要留出创新空间。如果没有时间摸索新技术和实验创新性产品理念，团队会失去动力。
  • 在迭代计划中留出时间来，让他们可以探索新想法。可以提升团队成员工作的价值感。
  • 黄金卡：选择做自己喜欢的事情的特权。每个月可以使用两次黄金卡，使用黄金卡的当天可以不做产品相关的任务，而只研究自己喜欢的新技术和新想法。
  • 【想法】每个月拿出一天，整个团队不做产品相关的事情，完全做自己喜欢的事情。比如可以作为读书日，可以作为编程道场日。
  • 庆祝成功：重要的产品发布后，庆祝一下。比如一起吃吃饭。
  • 慎用奖励计划：旨在鼓吹个体生产力的奖励计划会侵害团队内的协作。
  1. 每日站会
  • 每日站会的三个基本问题：
    • 昨天我做了什么？
    • 今天我要做什么？
    • 我遇到了什么障碍？
  • 任务白板要处于团队的工作区，每日站会就在任务白板前进行最佳。目前我们团队就是这样。
  • 避免团队成员向你一个人汇报。每日站会是你们所有人一起确定今天要做什么，不是为了我！
    • 目前研发部的站立会议已经开始有这个苗头，大家认为站立会议是我要求的，他们每天是在向我汇报工作。如果我不在，站立会议就不再召开。这显然违反了站立会议的初衷：让大家在一起沟通协商要做的工作，并解决问题。
    • 采取措施：
      • 提醒他们站立会议不是为我一个人开的
      • 尝试让他们自己开，我不在场
  • 对问题的跟进。站立会议中如果发现问题，又不方便在会上直接讨论，就安排会后讨论，但要进行跟进，提醒相关人员进行讨论。
  • 问题“停车场”，这个点子非常棒。把一些重要的问题列到白板上（相当于停车场），后续一个一个地处理掉（相当于开出停车场），是很不错的主意。
  • 可视化跟踪信息：把一些信息展示出来，让大家都知道，无形中就会促进行为的改善。
    • 比如某些人总是迟到，他本人可能没有意识到这个问题的严重性。那么可以在看板上放一张签名表，每次有人迟到，就的把自己的名字加上去。通过这种反馈机制，能帮助迟到的人意识到问题的严重性。
  • 严格控制站会时间，不要超过15分钟。关键是控制团队成员的数量。当大家开始只关心他们自己的任务时，团队精神就会开始瓦解。针对大型团队，更好的方案是把他们拆分成多个子团队，各自独立地规划工作，召开稍小规模的站会。
  1. 用户故事
  • 用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。
  • 一个完整的用户故事包含三个要素：
    • 角色（who）：谁要使用这个
    • 活动（what）：要完成什么活动
    • 价值（value）：为什么要这么做，这么做能带来什么价值
  • 关于用户故事的3C咒语：
    • Card（卡片）：把故事写在索引卡上，引导小组进行交谈
    • Conversation（交谈）：问问题，找出拆分故事的方法
    • Confirmation（确认）：通过验收测试确认用户故事被正确完成。

  • 与卡片共舞：展示如何用卡片来记录用户故事。一张卡片写一个用户故事，平摊到桌面上，然后大家一起讨论。

  • 用户故事模板：

    作为一名xxx用户，
我想要完成xxx活动，
以便于实现xxx价值。

  • 用户故事例子：

    作为一名购书者，
我想要通过书名查找书籍，
以便于我能购买。

  • 用户故事测试模板：Given-When-Then

    给定用户在什么场景下,
做了什么操作,
那么将会产生什么结果。

  • 用户故事测试例子：

    给定用户正在浏览首页或任何目录页，
如果用户输入书名并执行搜索，
那么将会显示出包含购买链接的书籍详情页面。
注意：书名可以进行模糊查找。

  • 有关用户故事的难点：没有面向用户的功能（非功能性开发），还适合吗？

    框架开发，代码库等纯技术任务，如何用用户故事来描述？
挖掘做这件事的深层原因。

比如我要实现一个消息队列和任务分发系统。
为什么要做这件事？
因为目前的接口调用在性能上有瓶颈。
为什么接口调用在性能上有瓶颈？
因为目前的接口设计同步模式，一次只能允许一个请求进来。
所以，我需要添加上消息队列和任务分发系统，这样就可以提升接口的性能。

最终的用户故事为：
作为产品经理，我想要接口的并发性能得到提升，这样我们就可以接入更多的用户。
  1. 敏捷会议
  • 规划会议：讨论用户故事
  • 每日站会：跟进用户故事
  • 演示会议：演示产品新功能
  • 回顾会议：总结本次迭代的优缺点，加以发扬或改正

  1. 缺陷管理

    如何处理迭代中发现的缺陷？
团队是应该在当前迭代修复这个缺陷，还是推到后一个迭代再处理？
如何决定，要看缺陷的重要程度和优先级！
由于这是计划之外的工作，修复缺陷可能会让团队陷入无法完成其他故事的境地。怎么办？
具体问题具体分析，评估具体缺陷的重要程度和优先级，决定是否在本迭代中修复。

  2. 迭代结束时彻底清理干净看板。清零，重新开始。

  3. 测试驱动开发（TDD）

  • 如何在团队推动TDD？
    • 内部培训：安排内训课，帮助大家学习如何写单元测试。
    • 结对编程：亲自示范如何写单元测试。
    • 一次只选择一个问题，而不是搞一刀切的大动作。
    • 从新代码开始，旧的系统先放一放。
  1. 持续集成
  • 平台系统大了之后，集成的难度越来越大。开发人员迟迟不肯集成代码是因为集成过程过于耗时，但是间隔时间越长，集成也就变得越困难。
  • 持续集成（Continuous Integration， CI）：尽早且频繁地集成代码变更。每次集成都很小，所以集成起来就很轻松。
  • 持续集成是团队达成的共同约定：
    • 我们从代码库中获取的最新代码要能构建成功并通过所有测试
    • 我们每2到4个小时提交一次代码
  • 持续集成不是小开发团队随便能玩的，如果用不好，反而会变成拖累。

  1. 增量式设计
    我本人很喜欢增量式设计的方式，只要把需求理解清楚，然后在脑子里构建一个大概的蓝图，我就可以开始编码了。
    在编码的过程中，我会不断地重构我脑子中的那个蓝图，让它变得更合理、更具体、更清晰。
    只要我们把大的流程和关键点想清楚了，就可以开始编码。如果执着于在开始编码之前一定要面面俱到地完成设计，可能会阻碍我们的脚步。
    就像旅行，我们不可能规划好每一条路线，我们在出发前能做到的是规划好目的地和大的路线方向，但真实旅途中的小岔路只有真正到了现场才能清楚明白。

  2. 重构

  • 需要单元测试的支撑。你怎么知道你重构后功能没有受到影响？如果有完善的单元测试集，就完全不用担心这个问题，重构完成之后执行一下单元测试集，正常通过的话表示一切OK。
  • 增量式重构。开发人员应该把重构工作融入日常的功能开发中。随风潜入夜，润物细无声。
  • 重构的最典型场景：提升可读性、减少冗余代码。
  1. 集体代码所有权
  • 任何团队成员可以编辑任意代码。
  • 如何能做到集体代码所有权呢？
    • 如果人员不充足，每个人都在拼命地忙着自己手头的工作，做到集体代码所有权就是痴心妄想。
    • 大家只有在时间充足的情况下，才会愿意翻看别人的代码。
    • 即使有充足的时间，如果保证开发人员相互之间不嫌弃对方的代码，而产生重写一遍的冲动呢？
    • 编码风格：团队若能遵循一致的设计和编码风格，集体代码所有权就比较容易实现。但统一编码风格，却是一件很难的事情。像最新的Go语言，从语言层面强制规定了编码风格，的确是一项英明之举。开发人员完全不用再操心编码风格的事情了。
  • 结对编程
    • 跟TDD相结合：乒乓编程——一个人先写一个失败的单元测试，然后把键盘控制权交给第二个人，让第二个人编写代码刚刚让这个单元测试可以通过；然后第二个人再写另外一个失败的单元测试，把键盘控制权交给第一个人。如此循环。
  1. 演示成果
  • 演示工作成果能够激励人们按时完成任务。
  • 产品开发团队的所有人都要参加演示会议。
  • 演示会议只演示本迭代完成的用户故事，并不是面面俱到的产品演示，要向不清楚迭代流程的人员解释清楚。
  • 做好准备，演示会议之前团队要预演，保证要演示的功能可以正常工作。
  • 演示的技术准备：会议室、投影仪、演示电脑、演示人、网络连接等。
  • 可以在演示完成之后讨论产品是否适合发布。
  1. 迭代回顾会议
  • 设置一些开会时的基本守则：
    • 不用电脑
    • 手机设成静音
    • 轮流发言
  • 迭代回顾会议的最高指导原则：每个人对自己的工作都已全力以赴！
  • 如何安全探究出错原因？
    • 相比于学习最佳实践，探索犯错实境能给人们带来更多的收获。
    • 遵循回顾会议的最高指导原则，能帮助我们安全地探索出错原因。
    • 回顾会议尽量避免讨论个人绩效问题，以免产生个人情绪上的逆反心理，反而不利于对问题的解决和流程的改进。
    • 回顾会议应该专注于如何改进团队流程，而不是责备某些人。
    • 最高指导原则有利于抵消“基本归因错误”的影响。
    • 基本归因错误：人们倾向于高估他人行为的内在性格因素，而低估其环境因素。
  1. 作为管理者，要加强团队成员工作理念和工作方法的引导，要让他们知道什么是正确的事情，以及如何正确地做事。