敏捷开发笔记

• 1，就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善 — 这个类似之前待过的外包公司的做法

• 2，重构：功能不变的情况下，重新设计部分代码，改善代码的质量。

• 3，工作中一定要将解决问题设为最高优先级别，对事对人！解释清楚你想要什么，并清晰地表面你的目的是解决问题，
  而不是职责或者进行争辩。团队就是要有互帮互助的精神！

• 4，不要坠入快速的简单修复之中，要投入时间和精力保持代码的整洁、清晰

• 5，注意说话的语气和方式，多用些问句来说问题，不要用职责性的话语。学会和客户聊天，不要太直接，假如不小心关了
  服务器，客户上门问罪了！礼貌，先要道歉，接着说话一定要专业、负责，如：“对不起，我们正在查是什么地方出错了。系统会在几分钟内重新启动起来。”

• 6，你不需要很出色才起步，但是你必须起步才能变得很出色

• 7，没有最好的方案，只有最合适的方案！

• 8，多点看些非技术主题的图书：项目估算、沟通技巧…

• 9,跟得上潮流，多点去接触学习并且用这些新事物在自己的工作中，提高工作效率
  丢弃那些旧习惯，相信自己已有的基础，有能力去驾驭它，人家说，汽车总比马车强吧！

• 10，多问几个问什么，如：为什么这样做？这样做会成功失败有怎样的效果和后果？…

• 11，庆祝每一个难忘的成功：共享美食和啤酒或者团队聚餐。

• 12，让您的客户来决定问题，你就在旁边给出相应的建议和方案，也尽量有利于开发的！但最终决策权是客户，要不最后客户不满意就很麻烦的，如果到时要改什么的时候就可以公正地就成本和时间重新谈判。

• 13，计划是没有价值的，但计划的过程是必不可少的 – 爱生豪威尔

• 14，大型项目就要按照短期内版本迭代和增量的方式开发，这样可以提前发布，先于抢占市场，也有利开发者可以更加专注开发且高效！

• 15，项目的迭代和维护，一般安排一周来维护，4周来迭代。不一定要按固定周期来的，不过在迭代一定要按照用户的需求来的。

• 16，项目不能以固定价格来衡量，因为开发过程中会遇到很多大大小小问题，有时候需求也会改。
  可以安排一部分模块，一块块来，做好了交给客户去检查，要做下一步继续给钱，继续迭代。要不就找其他团队继续开发。
  这样可以做到项目可以控制，随时开始，随时结束。自己也能较为精确地预算出时间和花费。

• 17，不同环境，就有不同的问题

• 18，度量真实的进度。

• 19，开发者：黄金法则–无论何事，你们愿意人怎么待你，你们也要怎么待人 —— 《圣经》

  • 1，代码要清晰表示自己的意图。能让自己或者团队其他成员一年后，再看时也能读懂代码运行的机制，所以多写一些注释

  • 2，增量式编程：出一个版本，后期再慢慢的添加新的功能和模块进去。

  • 3，编写内聚代码

  • 4，能用简单、有效的解决方案就用，除非有什么不可反驳的原因，否则都不要用什么设计模式等等高难度之类的东西。

  • 5，写代码原则用两个词来概括，就是简单、可读。

• 20，动态取舍：性能、生产力、优雅、成本以及上线时间，这个几个都是决定一个项目成功的关键。
  很多时候要适当地取舍一下，在性能表示足够的前提下，将注意力放在其他因素上。不要为了性能提升或设计的优雅，去
  将设计负责化。

• 21，养成一个好的习惯，记录问题日志。防止同样问题发生时，还要继续在网络上找之前解决方案。日常中遇到问题要做好适当的记录

• 22，谨记警报就是错误的开始。

• 23，对各个问题逐个击破。在解决问题过程中要将会获得更多的知识

• 24，代码发生异常时就要及时处理，不要继续抛出去，这样做法很不负责任。

• 25，定期安排时间给团队成员会面，谈话内容主要向好的方向走，不是问责大会。把握项目进度，帮助团队整体实力的提高。

  • 1，昨天有什么收获？———— 促进代码和思路共享，提高团队能力

  • 2，今天准备做什么？———— 提醒安排好工作进度，让个人尽量快投入工作中

  • 3，有没有面临什么障碍和问题？———— 及早发现问题并解决问题，帮助成员快速成长。

• 26，允许大家一起想办法，学会向他人学习。如果别人有更好的方法，就从中汲取经验，自己的头脑也得到扩展。

• 27，在提交自己的代码前，先更新代码，再一定要测试清楚确保提交代码没错误，要不就是一个大坑。

• 28，做代码检查，刚刚做完时，是最好时机。能大大减少出现bug的情况

• 29，要及时主动向上级或者客户通报项目进展和问题，别要总是等到别人来询问。