1. 过程裁剪的理念
所谓过程裁剪（Process Tailoring）就是通过增加、删除、替换方法、修改顺序、组合等方式对软件开发模型进行优化，使之符合团队和项目的具体特点。
由于各种生命周期模型在软件工程领域已经有深入的研究，业界对于瀑布模型、迭代模型、增量模型、螺旋模型等经典软件开发模型的使用场合等也基本达成了共识。因此，项目只需要将项目的实际特点与生命周期模型的应用场合相匹配，选择合适的生命周期类型即可。同时，敏捷开发方法论也深入人心，对于Scrum、极限编程、精益思想和看法方法的理念和具体工程实践也获得越来越多的应用，这就为我们建设符合自身特定的过程体系提供了输入。
进行过程裁剪的第一步是明确可裁剪的对象。可裁剪对象确定了裁剪的范围，可裁剪对象不仅限于过程元素和活动，还包括标准、方法和工具、输出的工作产品及模板等。其次，需要明确裁剪所考虑的要素。对于某个裁剪对象，其范围、频度、正式度等都是裁剪要素。如，对于已有类似开发经验的项目，可以适当减少过程培训、业务培训等活动；对于开发周期较短的项目，可以适当合并一些评审活动，如概要设计和详细设计评审合并进行。当我们对活动、文档、度量指标等进行裁剪并形成新的过程体系之后，一般也需要评审该过程体系并把它上升到基线标准。
采用简单易用的图、表等形式展示裁剪的指南有助于裁剪工作的推进，对上述提到的裁剪对象、裁剪的方法应都有描述，可以针对不同类型的项目或不同类型的活动提供裁剪后的几套模板，并确保裁剪指南的描述没有二义性，确保减少沟通的误差。
2. 过程裁剪的几种表现形式
通过过程裁剪我们形成了一定的过程体系，这些裁剪活动也具有层次化特征，即不同级别所应用的裁剪方法和结果可以是不一样的。我们分别从应用级别、团队级别和行业级别描述过程裁剪的几种表现形式。
（1）应用级别
顾名思义，应用级别的过程裁剪指的是每个应用对裁剪的标准和原则是不一样的，经裁剪所获得的过程体系自然也不一样。结合各个应用的自身特点灵活应用软件开发过程很大程度上满足敏捷的价值观。下图展示的就是将不同的敏捷工程实践在不同的应用之间进行过程裁剪的示意图。
有些应用的开发可能偏向纯敏捷型，而有些则可能带有传统瀑布模式下的工作方式。对前者而言，短周期迭代是必须要采用的一种工程实践，但对于后者而言，可能很难具备固定的迭代周期，则可以从每日例会、回顾会议、持续集成等与生命周期关系并不是很紧密的工程实践入手。
（2）团队级别
下图展示的另一种过程裁剪的维度，即团队级别。开发团队根据其是否专职于某一项职能、是否分布式在不同的地理位置、是否有专职的敏捷管理人员等可以分成不同的类型，也就可能会采取不同的开发流程和工程实践。
举例来说，如果一个开发团队内部包含技术、测试、产品、项目等多个角色，那么推行Scrum这样的全生命周期的过程管理框架相对会比较容易一些；反之，由于不同职能团队之间需要较多的跨团队协作，优先使用持续集成、回顾会议和可视化管理可能是不错的选择。
（3）行业级别
行业特性有时候也能影响到过程裁剪。我们以医疗这个特定行业下的过程裁剪方法为例展开讨论。医疗行业的最大特定就是作为用户的患者数据和作为客户的医护数据都位于医院内部，外部系统无论是传统的HIS、LIS、PACS系统还是现在流行的各种互联网化APP，都需要与医院的信息系统进行集成，这样类似配置管理、持续集成等工程实践就需要发挥其作用。同时，由于很多应用是面向医院，所以为了把控产品需求的正确性和实效性，也建议与客户坐在一起、使用统一语言等敏捷工程实践。另一方面，由于与医院的合作通常会基于项目实施的方式开展工作，因此传统的项目管理的过程和工具同样在医疗行业中得到普遍应用。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
