敏捷工具箱

1.wiki

• 目的团队成员知识分享

2.版本控制

• 项目资料统一管理

3.单元测试

4.CI/CD 持续集成/持续交付

5.Code View

• 实行代码审查，团队成员之间需要阅读他人的代码

45个习惯

1.目标导向。

• 团队成员在一起应该是互相帮助而非指责，解决问题为第一目标。

2.代码复审。

• 代码逻辑整洁敞亮。修复BUG添加代码前要理解。

3.专业不自我。

• 尊重团队中每个人的观点。引导性的提出疑问。

4.代码质量优先。

• 真实勇敢说出实情，找到合理的论点阐明利益关系。

5.学无止境。

• 关心行业动向、技术变化、迭代增量式学习。

6.分享会。

• 每周的中期(周三)下午3~4点进行，应用相关的技术或非技术主题会议。
• 总是要成为你所在的团队中最菜的那个。

7.摒弃思维定式，拥抱变化。

• 敏捷的根本之一就是拥抱变化。生产效率为第一准则，在适当的技术栈使用适当的手段。

8.打破砂锅问到底

• 未知现象，不停地问为什么、直到真正的理解了问题。

9.把握开发节奏

• 设定任务节点、合理规划迭代周期、注重正反馈。

10.用户参与决策

• 项目经理最重要的职责就是判断哪些是业务决定不了的、应该让客户决定。

11. 设计指导而非操纵开发

• 设计描述的目标实现，而非精确细节。软件研发工程师而非码农。

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.及时通报进展与问题
积极发布进展状况、新的想法、目前关注的主题、不要等着别人来问项目状态。