1、关于超负荷工作
曾几何时，Brad也想过试着给团队施压让他们多承诺些，后来他发现，团队的速率，即每个Sprint能够玩的的故事点，是不会撒谎的。更搞笑的是，Brad发现，公司承诺维持可持续的速度并削减了疯狂时间之后，团队的生产力不降反升。
施压团队接受“挑战性目标”所有的成果就是增长的缺陷数目，这都是归因于更多的压力和更长的工作时间。
心得：领导或客户要求在某一天（或者提前）必须上线，往往要付出更多的代价：
① 往往还是会再“拖上”一两天延迟交付，这不仅让团队成员疲惫不堪，同时严重打击团队成员的信心；
② 赶鸭子上架，上线后出现一系列bug,导致产品用户体验差，这隐性的成本远比提前上线来带的收益高得多；
③ 长期下来，开发团队获得或少会抵制管理者，至少内心会有所抵触，在这样的心态下的工作效率可想而知。
2、瀑布开发模式
报告指出，以传统方式运作的企业级软件项目中，只有16%可以按时按预算交付，31%的项目被取消，还有53%的项目预算超标189%。当他们被问及这些项目为何失败得如此惨烈如此频繁的时候，IT经理们提到的首要原因就是“用户参与少”，第二位的是“需求不完整”，二者相距甚远。
心得：传统的瀑布模式，往往是在最后一公里时候（验收阶段）暴露出种种问题，需求不符合预期，功能缺陷太多。即使给产品经理和开发团队在开发前期花在需求上的时间再多，他们也很难再需求阶段真正地分析和挖掘出所有需求。有些需求注定会在设计实现或在用户使用过程中才逐渐出现。所以需求必然是渐进明细，不断纠正的过程。
3、敏捷开发模式
所有种类的敏捷流程都有一个共同点：它们拥抱变化，视变化为成长的良机、而非障碍。
敏捷开发和瀑布开发之间差别在于：瀑布开发必须先完成当前步骤之后才能头也不回地向下一步骤。而敏捷团队会做一点点需求收集，一点点设计、编码和测试，最后交付一点点价值给客户。接着团队再重复此过程…..周而复始，工作推进过程中不断改善、调整流程，一直到项目完成为止。
心得：
① 无论是传统企业还是互联网企业，都是以项目导向。这种管理思维更多是把员工当做一个创造价值的机器而已。员工是一个活生生的人，随着员工的进步，同样的时间，不同的时期，他为公司创造的价值可以是不断增加的，甚至是可以裂变的。
② 敏捷开发模式是能够给团队、企业产出更多的效能。需要一个很好的领导者（强调领导而不是管理）去引导团队和企业组织进行变革。但这样的优秀的领导者很少。
4、敏捷实践
① 边做边测试，别等到最后关头，现在就修复缺陷，等它有机会再系统繁衍存活好几个月后，修复成本可就高了。
② 及早且频繁地交付产品，只有通过展示可工作软件的方式，你才能发现客户真正想要的是什么。正因为敏捷流程能够照顾到客户的持续反馈，项目才能不偏不倚地走下去；也因为只交付已完成的增量，敏捷开发才能规避项目被取消的风险，客户还能用上按期交货的软件。
③ 文档边做边写，只写必需的文档。将文档工作融入流程，只写有关的、有效用的文档。
心得：
① 以前总逼着产品经理写出面面俱到的需求文档，还经常找茬“你这个需求连XX场景都没有考虑到”，“你知不知道你写的需求前后矛盾”，“你这个需求不完整，没有清楚说明具体要求和限制”…. 我们要交付的是可用的产品，而不是格式很规范，很详细的文档（其实是又臭又长，实际开发过程中，很多开发人员不看需求）。
5、关于合同（一）
合同型工作的缺陷：
开发商（传统企业一般称为供应商）的出价通常是份赌注，赌他们能够在一定时间内完成工作，而利润则取决于他们能否多快好省地地满足客户最低要求。
需求方（经常被称为甲方爸爸）：合同是能够保你不被涨价困扰，但却无法避免偷工减料和最低标准施工的情况。
心得：这也是外包公司与客户之间的“对立面”。这是不是不可协调，其实外包公司应该多想一些办法得到客户的信任和满意。
乙方经常抱怨甲方公司“什么都不懂，就想着拿奥拓的钱，让我们给他造出一辆奔驰来”。
同样，甲方经常怀疑“不就那几个功能点么，真的要这么多钱吗”
其实我个人看来，乙方应该多站在甲方的角度思考，如果甲方都懂，还需要来找你们/p>
多一些沟通合作，而不是谈判。关于工作量和报价，有理有据的算给出来。同时把项目分几个里程碑，每2~3周交付一部分可用功能出来，过程中多交流，这样彼此的信任也会增加。
6、关于合同（二）
敏捷宣言的作者们最终得出结论，基于合同的项目侧重方向不对。他们更喜欢采用时间材料模式，相关各方就像是一群合伙人，齐心协力在规定时间和预算范围内努力构建最有价值的系统。降低客户风险，不是靠前期担保方式转嫁风险给开发商，而是依靠流程中客户的持续参与，以及敏捷团队定期交付可工作软件增量的能力。
7、敏捷过程之痛
采用敏捷方法的组织通常会经历显著的成长之痛，因为这些被误导的优先级类型会被连根拔起暴露得一览无遗。
心得：无论个人、团队还是企业，任何的改变都会带来痛苦。就像一个人明知道有某方面的缺点，也知道这个缺点可能会对工作或生活带来一定的影响，更知道改善的方法，但是没有决心，没有行动。有时还会安慰自己“其实这个缺点大部分都有”。
为什么敏捷在团队执行起来那么困难，即使它看上去流程很简单，好像很有用的样子。我觉得原因有二，一是固定思维，基本上所有企业也是采用瀑布开发模式，我们为什么要变是，一下子暴露的问题太多，无从下手，没有勇气改变，一旦出现质疑的声音，就可能打回原形。
8、产品经理与开发团队的微妙关系
① 产品负责人和团队其他人之间有一层天生的紧张关系，产品负责人总想要更多，而团队则必须维持可持续的速率。只要不是单方面说了算，这层紧张关系就还是有益的。
② 开发人员说，业务人员总是悠悠然地问些浅薄的问题，提出愚蠢的要求。而业务人员则认为，开发人员骄傲自大还很古怪，关心代码的抽象美比关系最终产品多。
心得：产品经理觉得开发人员不可理喻，无法沟通。开发人员觉得产品经理傻傻的，经常问些傻不拉几的问题。
产品经理真的很笨吗实不是，只是他们是门外汉而已，举个例子，我前两天要更换家里净水器的滤芯和PP棉，客服人员发了相关的操作视频给我，我还是摸索了很久才把滤芯拆卸下来，也不知道什么是滤芯什么是PP棉，怎么装。在客服心里可能会想：你是猪吗/p>
产品经理侧重点是业务，所有的技术都是为业务服务的。产品经理有时会问一些看似很“弱智”的问题，我们应该尝试理解，不是仅从技术人员角度思考。（有很大部分开发人员在产品经理面前 潜在的自然产生一种优越感）。
而产品经理也应该理解技术人员，并尊重他们，大部分开发人员是很单纯的，同时他们在表达沟通方面相对于产品、销售人员弱一点点。
9、需求文档
在敏捷开发中，可能没有需求文档，取而代之的是产品列表（或称为待办事项，待办列表）。
① 产品列表是产品预期交付物的累计清单。这包括了特性、缺陷修复、文档变更和任何值得创建的东西。
② 列表的优点就在于，就不会浪费时间给那些永不见天日的特性写详细规格书。
③ 用户故事、交谈和接受标准结合起来组成了完整的需求规格说明书。
10、完成的定义（Definition of Done）
① 完成的定义应该是你的团队和项目所特有的，团队需要针对它包含和不包含的内容达成共识，而这很大程度上取决于产品和组织的本质。
完成的定义很可能 包括：
代码评审
设计评审
重构
性能测试
单元测试通过
更多内容
② 完成的定义和验收标准是有区别的。验收标准属于产品负责人与或客户的领域，明确定义了被视为“可接受”产品所必须满足的条件并记录在案。像是回归测试和版本集成这些内容，则不属于验收标准的范畴。
③ 写得马马虎虎或不完整的完成的定义存在风险，会攒出一个看不见的技术债务池，即那些游离在计划及流程之外，但必须在产品交付前完成的任务。
心得：
“嘿，Fred,那个高级所搜功能你做完了吗
“当然的啦，都做完了！”
但我们真的知道Fred所谓“都做完了”是什么意思吗仅仅开发完了，还是开发并自测了，或者是已经提交测试并通过了/p>
没有对“做完了”下定义，你永远得不到真实的项目进度。
11、临时增加资源
短期内增派人手一般都会导致速度放缓。
心得：在项目紧急情况下，不要第一想法就是增加人力，因为增加人力有可能让项目进度更慢。
12、测试驱动开发
测试驱动开发（TDD）就是，开发人员先写一个自动化测试，然后再编写产品代码，并让它测试通过。
TDD可以降低缺陷水平，且无需牺牲生产力。IBM和微软的四个开发团队所做研究发现，TDD能够降低千行缺陷率40%到90%。考虑到维护和调试现存代码所消耗的大量开发时间，TDD带动开发更快进展的效果很快就能显现出来，虽然创建测试很明显是“额外的工作”。
心得：在进入开发之前，测试人员应该确定好测试用例，并和产品经理、开发团队同步和确认，帮助团队进一步了解需求，并进行查漏补缺。
13、回顾会议
① Scrum就是为了帮助团队持续地进行检验和适应而设计，能够带动绩效和幸福感不断提升。
② 会议目标很简单，找出1到2件可改进的实事，制定行动计划，实现这些改变。
③ 很多人有参加过传统“时候分析”或“经验总结”会议的经验。它们都是项目结束时才召开，收获的往往是一份罗列“好处”和“改变”的冗长清单，会议刚结束就差不多全忘了，大家还都嘀咕者抱怨“亡马锁厩,为时已晚”。
④ 要在回顾会议刚开始的时候，先建立起大家对目标的共同理解，这样人们在第一时间知道为什么开会。
心得：每周例会可以稍微总结一下上周的工作情况，有哪些可以改进的，只选1到2件在下一个迭代中就开始改进。（首先定下基调，不要相互抱怨和攻击。不然会议气氛就变质了）
14、过度承诺
很多新手团队容易犯过度承诺的毛病。一直承诺过度而交付不足的泥潭中挣扎的那些团队，可以考虑使用“昨日天气”技巧。使用此技巧的话，“昨日”也即一个sprint团队实际交付了多少故事点，这个sprint他们就承诺交付多少故事点数。此方式天生就有自我矫正的功效。
心得：有些团队在估算工作量过于乐观，评估的都是理想状态的工作量。每天工作的8小时，有效时间可能就3~4个小时，因为中间总会有一些琐事或意想不到的事情干扰，例如，临时任务，临时的会议，遇到bug修复等等。所以在估算时候，一定要预留20%到30%的工作处理其他事情。不然，你将会为此买单——加班。
15、电梯演讲
你有一个值得公司为此发起项目的绝妙想法，而且你凑巧和公司CEO搭乘同一部电梯。你正好可以借机说服他支持你的项目。
你的电梯演讲应该只有简短几句话。关注项目要解决的问题，以及公司或客户将由此获得的好处。
来源：一直在敏捷的路上
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！