敏捷开发（Scrum）
敏捷工具箱
1.wiki
- 目的团队成员知识分享
2.版本控制
- 项目资料统一管理
3.单元测试
4.CI/CD 持续集成/持续交付
5.Code View
- 实行代码审查，团队成员之间需要阅读他人的代码
45个习惯
1.目标导向。
- 团队成员在一起应该是互相帮助而非指责，解决问题为第一目标。
2.代码复审。
- 代码逻辑整洁敞亮。修复BUG添加代码前要理解。
3.专业不自我。
- 尊重团队中每个人的观点。引导性的提出疑问。
4.代码质量优先。
- 真实勇敢说出实情，找到合理的论点阐明利益关系。
5.学无止境。
- 关心行业动向、技术变化、迭代增量式学习。
6.分享会。
- 每周的中期(周三)下午3~4点进行，应用相关的技术或非技术主题会议。
- 总是要成为你所在的团队中最菜的那个。
7.摒弃思维定式，拥抱变化。
- 敏捷的根本之一就是拥抱变化。生产效率为第一准则，在适当的技术栈使用适当的手段。
8.打破砂锅问到底
- 未知现象，不停地问为什么、直到真正的理解了问题。
9.把握开发节奏
- 设定任务节点、合理规划迭代周期、注重正反馈。
10.用户参与决策
- 项目经理最重要的职责就是判断哪些是业务决定不了的、应该让客户决定。
- 设计指导而非操纵开发
- 设计描述的目标实现，而非精确细节。软件研发工程师而非码农。
12.根据需求选取技术
- 新技术应该是工具，可以帮助你更好的工作。而不是为新技术本身造轮子。
13.保持可发布
- 保持系统随时可编译、运行、测试并部署。
14.提早集成、频繁集成
- 合理的阶段集成代码、绝不要做大爆炸式的集成。
15.提早实现自动化部署
- 系统的安装部署应该简单的一键操作。
16.使用演示获得频繁反馈。
- 用户的期望和想法也是在不断变化的。客户也应该可以感受到自己在一定程度上控制项目的方向。
17.短迭代、增量开发
- 大部分用户都是希望现在就有一个够用的产品,而不是一年后得到一个超级好的软件。长周期、详细的计划设计文档注定完蛋。
- 合同支付费用应该也是迭代的。降低客户风险、规避违约金。
18.自动化单元测试
- 很多时候人们不编写UT其实本质就是代码中有设计缺陷。
19.TDD（Test Driven Development）测试驱动开发
20.不同环境会有不同的问题
21.自动验收测试
22.度量真实进度
以确定的功能作为量化指标而不是时间。
23.倾听用户的声音
24.代码清晰的表达意图
代码的可读性、清晰程度排在执行效率之前。
25.用代码沟通
注释描述代码意图和约束，注释不能代替优秀的代码。
26.动态评估取舍
类似经济学的边界效应。过度优化是万恶之源。
27.增量式编程
在很短的编辑/构建/测试循环中编写代码。
28.保持简单
代码逻辑简单、优雅、清晰。
29.高内聚、低耦合
30.记录解决问题的日志
将问题日志记录到wiki
31.警告就是错误
32.定期安排会面时间
简单的立会每人发言时间言简意赅。到公司半小时到一小时之间。
33.架构师必须写代码
34.实行代码集体所有制
让开发人员轮换完成系统不同领域中不同模块的不同任务。注意人员分配、任务分配。
35.成为指导者
分享自己的知识，实现双赢
36.允许大家自己想办法
用问题来回答问题，引导提问的人走上正确的道理。
指给他们正确的方向，而不是直接提供解决方案。
37.准备好后再共享代码
绝不能提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对项目来说是在犯罪。
38.代码复查
需要CodeView，codeview时需要评估可读性、设计，业务逻辑中可优化的点。
CodeView之后确立待办。
39.及时通报进展与问题
积极发布进展状况、新的想法、目前关注的主题、不要等着别人来问项目状态。
