三大支柱
- 经营可持续的业务(Run a sustainable business)
- 推动IT变革，追求软件卓越(Champion software excellence and revolutionize the IT industry)
- 积极提倡社会和经济公正(Advocate passionately for social and economic justice)
核心原则
价值驱动
什么是价值驱动
一种成效导向的、基于价值和反馈驱动来进行优先级排序的决策系统。这套系统是一个闭环，能够持续提供反馈并修正方向。首先建立起对愿景和目标的分解机制，并充分认识到每个投注的不确定性，通过尽量小的尝试来不断调整投资组合，保证对外界变化的快速响应。
为什么要做价值驱动
在如今的大环境下，我们很难将传统行业的投资管理的那一套方法和理论应用在软件开发行业中。因为软件开发充满了不确定性。用最少的力，验证当前设想的业务价值。
Story是什么
Story是开发团队的最小工作单元。User Story(用户故事)是业务需求的载体。一张合格的story应该包含一个完整的用户故事，通常以Given，When，Then的结构。翻译过来大概意思是：假设我（使用者）处于一个什么样的环境，当我（使用者）进行了什么操作，那么我（使用者）应该接受到什么样的反馈。如果团队中的任何一个角色看不懂Story，那么会认为这个Story本身有问题。
Story本身不包含Task拆分，只承载业务价值。当开发在进行Kick Off后，会根据自身习惯来选择对这张Story做一些技术上的Task。也有遇到同事直接根据拆分的Task为基础来TDD出整张业务卡的代码。
技术卓越
核心实践
基于统一迭代节奏的全功能团队
全功能团队已经在很多地方都听到过，常见的角色包括但不仅限于BA、QA、PM、Dev、UX、DevOps。
需要再强调一次统一迭代节奏，在TW待过的项目里，确实有遇到过迭代节奏不统一的问题。例如客户方需求变化频繁，导致在迭代开发中，BA改完卡就交给Dev做开发。又或者前后端节奏不一致，导致Story在某个泳道（比如Ready For Integration）停留时间过长。再或者某个迭代遇到无法解决问题（需要集成的第三方系统迟迟没有准备好），导致迭代的卡拖延到下个迭代。如果团队遇到这些问题就直接妥协，而不是想办法解决，那么这个全功能团队也会渐渐变成功能残缺性团队。
基于Story的需求及范围实时管理
项目的整体需求会先模糊拆分成Topic被放到Backlog中，Story是基于Topic梳理清晰并且和客户澄清后的产物。为了保证统一迭代，BA会提前一个迭代梳理下一个迭代的Story需求。TW团队会让客户或者业务负责人参与Story的澄清，并能够持续调整Story的优先级。