引子
10岁以后，已经30多年没有躺过医院住院部的病床了。既然住下了，就安心休养吧。
但是，由于我职业病(敏捷教练)一直在作祟，让我无法停止观察。一周下来，在不经意间发现一个隐藏的大秘密。
住院治疗系统的运作方式俨然是一个严密的敏捷流程，而且堪称完美，比普通的软件研发流程还要高效和流畅。
团队
这里有一个以科室主任为leader的高效团队，他领导着手下的团队，奔着一个共同的目标：住院治疗者的早日康复，而持续不断地向前推进。
他的团队成员有：住院医生和住院护士，他们各司其职，承担着医治和护理的明确职责。
如果对照到软件研发团队，医生至少有两个角色：BA和Dev，而护士也有两个角色：Dev和QA。
科室主任(SM)→↓
↓→住院医师(BA、Dev)
↓→住院护士(Dev、QA)
流程
一位住院治疗者从诊断入院到康复出院的全过程，也和软件研发中的需求交付非常相似。
我们做个简单类比：
住院治疗者→用户需求
门诊诊断→需求收集
入院信息收集→用户访谈
诊疗方案研讨→需求分析
治疗方案→设计方案
治疗实施→开发实现
每天查房→验收测试
体征收集→持续度量
康复出院→需求交付
简直可以完美匹配！
医生作为BA角色，也是需求交付负责人，在全过程当中是紧密参与的，每天两次的查房活动，就等同于需求完成情况的持续验收和反馈收集，确保了交付目标(入院者尽早康复)的方向不跑偏。
护士每天持续进行的工作：发药，输液，体征测量，活动收集等，也是一个实施→评估→反馈的循环过程，直至目标达成。
方法
住院治疗和软件研发在方法上也有诸多可以相互对照的内容：
治疗方案→最佳实践
责任医生→BA全程跟踪
当日任务上墙→看板系统
每日费用公示→研发成本透明
固定床位数量→限制在制品规模
最后一条是保证交付质量的关键因素，是用户体验的保障。我发现一个有趣的“7±2”的案例：每位责任医生管理的床位不会超过7个，一般是6+1的模式，6个正式床位和1个加床。
总结
住院系统完美交付的秘密在于两个关键因素：分工明确且协作紧密的团队(医生和护士)；严格限制的在制品规模(固定的床位限制)。
我们软件开发交付是否也能做到这样的水平，收获这样的效果呢？
共同的目标不是问题，协同明确的团队也不是问题，严格限制的在制品规模？这是一个很大的挑战！
我们要控制用户需求的输入规模，乍一看是mission impossible。但是我们细细想想，真的不可能吗？
医院系统为什么划分门诊和住院两大体系？这就是一个很好的启示。
门诊通过许多通用化模式化的方案，极大程度上分流了住院的需求(个性化诊疗)。我们的软件研发是否可以借鉴这个思路呢？完全可以！
当我们的软件产品具备一定的成熟度的时候，可以借鉴这种方式来应对用户需求的冲击。
1、通过提供通用化可配置的系统方案，解决相当一部分非紧急的普通用户需求，控制需求入口的流量；
2、严格控制个性化定制化的需求数量，通过需求分析和价值评估等方法，过滤通用普通需求，保证在研需求的交付质量和用户体验。
