《敏捷开发之道》读书笔记

1、项目研发过程就像是冲浪，你永远不知道接下来遇到什么风险。项目的成功和失败取决于团队所有成员的技术水平；

2、开发需要持续不断，切勿时续时断；

3、有人认为敏捷开发方法有所顾忌，认为它只是另一种危机管理而已。事实并非如此。危机管理是指问题积累并且恶化，直到它们变得非常严重，以至于你不得不立即放下一切手头工作来应对危机。

4、防微杜渐，把问题解决在萌芽状态，你要探索位置领域，在大量成本投入之前你先要确定其可行性。

5、敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

6、它强调团队一起合作，（敏捷开发团队一般是一个小团队，或者一个大团队分队的若干小团队10人左右）。团队所有成员一起工作，最好有个独立的小空间。一起共享代码和必要的开发任务，而且大部分时间都能一起工作。同时和客户或者软件的用户紧密的工作在一起，并且尽早的频繁的给他们演示最新的系统。

7、要以迭代方式进行工作，确定一小块时间的计划如一周，然后按时完成它们。及时给客户演示迭代工作成果，这样及时得到反馈。并且根据实际情况尽早的频繁的发布最新系统给客户使用。

8、不断的通过培训来提高整个团队的技术能力，学无止境。只有团队的能力上去了，只有团队一起成长，才能取得更大的成功。

9、交付用户想要的软件。

10、敏捷开发之所以能工作的顺利，而不会陷入泥潭挣扎导致项目的失败，就是因为一直使用反馈来纠正软件的开发过程。

11、一般的软件方法学要求对一个项目分配35中不同的角色，包括架构师、设计人员、编码人员、文档管理者等。敏捷方法却是背道而驰。只需要一个角色：软件开发者，也就是你。项目需要什么，你就做什么。你的任务就是紧密和用户协作，一起开发软件。敏捷依赖于人而不是项目的甘特图和旅程表。

12、图或者工具、开发环境设计工具，它们本身是无法生产软件的，软件是从你的大脑中产生的，而且他不是孤独的大脑活动，还会受很多因素影响，还会有很多其他的方面的因素：人的感情，办公环境，自我意识，记忆力等；他们混合一起，态度和心情瞬息变化都会导致巨大的差别。因此态度非常重要。

13、我们都有自我主义。我们都会为完成一件事情而感到骄傲，但是这种骄傲又会使得我们主观和现实脱离。你可能见过方案的讨论变成了人生攻击，而不是就事论事的讨论问题。对事不对人能为工作带来高效。

14、反馈是敏捷的基础。一旦你意识到了走错了方向，就要立即作出决策，改变方向。

15、一旦出现问题第一件事就是去解决问题而不是去找出“凶手”。

16、抱怨是无意义的，在敏捷团队中，情形截然不同。如果你开始抱怨，他们会对你说“我能为你做什么”，去解决问题而不是一起抱怨。

17、用于承担自己不知道的问题，这样会让人感觉到放心。一个重大的错误应该当作是一个学习的机会而不是一个指责他人的机会。

18、如果你没犯过错误，说明你没有努力工作。

19、如果团队的一个成员误解了一个需求、一个API调用，或者最近一次会议中做出的决策。那么，也许就意味着团队的其他成员也有相同的误解。要确保团队尽快的去解除误解。

20、要么融入集体一起奋斗，要么离开。

21、千里之堤溃于蚁穴，快速修复bug并且深层次的杜绝其他的可能发生的问题。在工作压力之下不去深入的了解问题的所在和后果，就快速修复代码，这样只会解决表面问题，最终会引发出大问题。

22、不要坠入快速简单的修复之中，要把投入的时间和精力保持带代码的整洁、敞亮。

23、每个人都能萌生一些积极的创新想法，同样也会萌生一些愚蠢的想法。在团队中需要紧密合作的团队，若果能稍加注意礼貌对待他人，将会有益于整个团队去关注真正有价值的东西。而不是勾心斗角，误入歧途。看到他人有错误的地方是，以提问的方式让他自己明白比你直接戳穿好一千倍。同样如果你有一个想法也会担心被取笑丢掉面子，那么你也就不会再提这个问题了。你认为这样自己爽吗？团队这样的气氛你会喜欢吗？分享不同的问题和观点的好气氛，远远胜于单个想法为项目带来的利益。

24、一个智商很高能力很强是没有用的，如果他还顽固的不合作那就更糟糕了。

25、你不需要很出色才能起步，只有你起步了才能优秀。

26、“能容纳自己并不接受的想法，表明你的头脑足够有学识”------亚里士多德

27、设定最终期限：有时间限制，就没有效率。
28、逆向思维：团队的每一成员都应该意识到权衡的必要性。一种客观对待问题的方法是：先积极的看到问题的正面，然后努力从反面认识它。目的是要求找出有点最多缺点少的方案。而这样做可以尽早的发现问题的优缺点，这样也有助于少带个人感情。

29、会议设仲裁人：负责会议的流程，并维持会议的正常运行。仲裁人负责确保每个人发言机会，避免明星员工操作会议，并及时打断大空式发言。仲裁者和监督者应该专注于调停，而不是发表自己的观点。（理性情况下不应该在项目中有即得利益）；

30、一旦决策做出就必须全队努力合作执行。

31、对事而不对人，我们应该骄傲的是解决了问题而不是提出了主意。

32、不带个人情绪并不是盲目的接受所有的观点。用适合的词和理由去解释为什么你不赞同，提出明确的问题。

33、“谁去给猫系铃铛”，美好的计划因为没有人敢去事实而泡汤了。

34、“即使你已经处在正确的轨道上，但是如果只是停止不前进，仍然会被淘汰出局”

35、每天都花一定时间来学习新技术，它不需要花很长的时间，但是需要经常进行。

36、当听到一些不熟悉的术语或者短语时，简单的记录下来，让后花时间去学习它。

37、了解最新行情，如饥似渴的阅读。

38、跟踪技术变化，你不需要精通所有技术，但是需要清楚行业的动向，从而规划你的项目和职业生涯。

39、你能嗅到将要流行的新技术，知道它们已经发布或者投入使用。如果必须要把工作切换成一种新的技术领域，你能做到的。

40、学习新语言要用新的集成开发环境。

41、问问题要知道自己为什么问这个问题；

42、在许多不成功的项目中，基本上都是随意安排工作计划导致的；

43、上帝发明了时间，就是为了防止所有的事情同时发生。因此我们需要更具远见，保持不同的开发节奏，这样敏捷项目的所有事情就不会同时发生，也不会随机发生，时间也不会不可预知；

44、时间盒，既定的任务既定的时间完成。

45、站立会议最好每天在固定时间和地点举行，比如上午10点。

46、项目开发需要有一致和稳定的开发节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会跟更容易。

47、就像减肥一样，一点点的成功也是很大的激励。小而可达到的目标会让每一个人全速前进。庆祝每一次难忘的成功。共享美食和啤酒团队聚餐。
48、交付用户想要的软件。

49、软件开发就像是场战争，我们的敌人不是自己，不是队友，不是客户，而是变化。形式变化快速而又剧烈。

50、成功的软件开发方法取决于你识别和使用变化的能力。

51、要么现在就让用户做决定，要么现在就开始开发，迟一些让用户做决定，不过要付出很高的成本。

52、让你的客户做决定。开发者、业务分析师不应该做业务方面的决定。。

53、记录客户做的决定，并注明原因。好记性不如烂笔头。

54、好的设计应该是正确的，而不是精确的。也就是说，他描述的一切必须是正确的。不应该涉及不正确的或者不确定的和可能发生变化的细节。他就是目标，不是具体的方法。

55、“计划是没有价值的，但是计划过程必不可少的”

56、白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力，而不是启发你的工作。

57、在引入新技术是一定要慎重。根据需要选择技术，首先决定什么是你需要的，接着为这些具体问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实的做出回答。

58、新技术就应该像是新工具，可以帮助你高效的工作，而不让它自己成为你的工作。

59、在团队里工作，修改一些东西必须特别谨慎。你需要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。

60、《项目自动化之道》