前言
团队组织相关概念集合
技术氛围
技术沉淀是一种修养，每个程序员都希望自己技术可以提升，所以可以在团队中可以组织技术分享；重复造些轮子是一种必然，团队应该有自己的追求，沉淀经验和技术，有开源的愿景。
用户故事
敏捷开发常提的词，把系统的需求开发比喻为一个大世界的历史书，但历史是由每个章节组成的，每一次用户提需求，我们都要把需求闭环，这个把用户的需求闭环的过程称为用户故事，一般一个用户故事由1到2个人就可以开发完成。属于增量开发模式，缺点是只有局部，没有大局观，优点比较适合快速迭代的业务节奏，快速交付业务价值。
Sprint迭代
团队开发组织的一种周期迭代模式，比较适合业务团队，不太适合技术团队，一般分为两周14天作为一个周期，周期内活动包括：技术方案设计、方案评审、方案设计、测试、上线；同时产品和开发、测试都应该按照这个周期一同协作活动。
产品需求池：业务产品化的需求池，由产品维护，产品Leader带团队进行评审；
技术需求池：系统需求有可能是产品需求、也可能是技术需求，技术需求池由技术小Leader维护。
同时注意，需求池应该以用户故事来组织，但求需求闭环和逻辑严谨。
使能故事
使能故事是相对于用户故事而言，使系统能力得以提升，属于大局观的系统概念，所以为了保证系统概念一致性不建议经常换掌控系统大局的人，也不用没有大局观的人。
敏捷团队需要完成用户事故外拿出部分经历开发使能故事。主要内容有：
- 挖掘用户需求的本质，注意是挖掘，不同与获取用户的需求；
- 优化甚至重构现有代码，提高代码质量；
- 调整系统架构，支持未来可见的变化；
- 下沉算法和技术，构建业务中台，业务通用框架等；
使能故事计较忌让没有技术追求的同学做，如果只是领导下命令，同学为了使能而使能，大概率失败。
两顶帽子
在设计使能故事的时候，（或者小部分用户故事），可以分配设计者和实现者部分事件去使用两顶帽子戏法，一般是在你需要添加新功能的时候，发现代码和既往的抽象无法很好的支持该功能，而做的事情：
第一顶是：把当前的软件编写目的为重构，改良软件结构，不改变软件功能，目的是为了代码和结构更加容易的添加新功能。
第二顶是：为当前软件添加新功能，这个时候应该是第一顶帽子发挥作用后，使得添加新功能变得非常容易。
技术中台
技术沉淀每个公司应该有自己定制化的可复用技术，当业务沉淀发现有适合公司的轮子可以服用的时候，可以沉淀一种技术中台，其实也可以用外部开源技术，然后组织一部分同学专门做技术中台；技术沉淀大概率上是由使能故事的结果。
约定优于配置：技术中台必然要走的路，复用技术后，必然要做倒置依赖，所以各个业务系统需要遵循中台约定，牺牲个性的路线，才能达到提效目的。
DevOps和GitOps大部分要求完善的技术中台和基础设施平台，小公司慎用。
测试驱动
注重测试，尤其在核心系统上，注重单元测试和建立集成测试、回归测试；互联网平台要建立完善的系统边界对每个业务场景用例进行自动化集成测试。成本较大，并且适合有重构和演进追求的系统，普通CURD和打算堆人力系统不会认为测试有用。
结对编程
慎用！
极限编程
文档其实是会说谎的，最会说谎的是PPT，其中极限编程其实围绕的核心是主张完全不使用（多余的）设计文档，而是让代码解析自己；因为实际运行的代码不会说谎，但是其他文档则不然；
沟通成本
组织人员的工作安排，最好在同一个闭环的逻辑子域中，让更少的人参与，1个人最佳；人和人之间的合作逻辑交互越高，沟通成本越大，效率越低。所以工作安排不要把一项工作定位20人/日后，就认为存在2个人只需10日就可以搞定这样的神话故事。
概念一致性
愿景—〉战略—〉战术—〉方案—〉落地，不同架构师有不同职责，软件系统架构师是规划师，要注意：
- 技术团队子域架构Leader的规划是细到模块和对象级别
- 技术团队子域架构Leader必须要参与核心代码设计与开发，至少要了解代码，控制腐烂程度
- 别做分任务和催进度的传话人
- 别做只设计业务PPT而概念的人，而不关注过落地的人，对自己系统的模块做啥都不了解的请尽快离职。
最后注意，一场手术，只能有一个操刀医生，医生要对手术结果负责——择：人月神话
统一规范
规范可以作为概念一致性的辅助工具，也是减少沟通成本的一种工具，例如：代码规范、日志规范、通用框架规范、通用请求返回结构体规范等；