Lean Software Development的七個原則與管理觀念

在agilesoftwaredevelopment.com看到一篇Seven Principles of Lean Software Development 才 知道原来Agile Software Development和日本制造的JIT有这样的渊源关系. 依据作者的说法:日本最赚钱的汽车制造商Toyota运用JIT(Just-in-Time)在生产制造上大幅领先同业. Taiichi Ohuno(大野耐一)-JIT创始人,写了多本相关JIT的书, 最有名的Toyota Proudction System , 成为美国Lean Manufacturing的基础. 在软件产业上, 则启发了Lean Software Development(精简软件开发)的观念, 而Lean Software Development酝酿了Agile Software Development Method的两个分支Scrum与Crystal Clear.


在Lean Software Development中以 Mary and Tom Poppendieck 着的书最有名.

在他们着的书中  "Implementing Lean Software Development - from Concept to Cash" (Mary and Tom Poppendieck著作)提出7个实作Lean的原则, 呼应JIT的观念, 且反应软件开发的特质. Lean Software Development背后的想法是: 让客户在还没有清楚信息以供做正确的决定前, 尽量延后"定型". 不过只要客户一提出要求, 开发团队可迅速做出客户所要的, 在客户来不及改变主意前出货给他. 这个作法, 就如我们在线一下单购物, 隔天东西就寄来了, 大多收货者都不会说要退货或做任何变更.

这七个Lean的原则是:

1. 避免浪费
如 JIT 的「彻底的なムダの排除」（彻底排除浪费）, 只要在客户看来没有任何附加价值的过程或产出都被视为浪费. 软件开发的七浪费:

• Particaly Done Work (开发过程中的预先完成品)
• Extra Processes(以文件中心来管理的开发最容易有这种现象)
• Extra Features(应该只开发客户要的功能)
• Task Switching(每人应一次只专心完成一件事)
• Waiting(等待指示或签核, 等待信息..)
• Handoffs(换手的过程一些默认的知识很有可能跟着遗失)
• Defects(无法马上测到的问题)

实行重点:

• 结合市场与技术领导 -整合市场与技术的专家才有可能激发出先进创新的产品. 你必须了解什么是对你的客户有价值, 以及你拥有或可以采用什么技术来实现.
• 仅聚焦于价值链 - 小心过分的流程改造, 确定这些流程是你必须的, 你应该聚焦在可以创造价值的流程. （想到软件项目界常讲的CMMI吗? "裁适"应该比"完美"来得重要)
• 精简程序代码 - 越多程序代码相对需要越多的测试,如此增加工作量. 所以如果有的功能没必要, 就不要浪费时间在上面.

由上看来, 也许我们可以想想自己的团队是否有以下的问题:

• 是否有例行的报表, 会议, 或文件但无济于价值创造呢?
• 每个人写的codes在项目范畴内吗?
• 需求分析有切中要领, 规划出真正对客户有价值的东西吗?
• 是否能将工作尽量独立切分, 平行运作, 避免相依?
• 如何从coding的质量要求, 即早发现瑕疵?
• 团队沟通是否要跑很冗长的流程, 有办法达到如神经组织般的沟通效能?

2. 增强学习能力

软件开发这途需要不断精进技术, 也面临团队和项目的scale挑战, 客户需求变更的不确定性, 和是否熟悉domain know-how的问题. 所以

• "增强学习能力"是改善软件开发竞争力的最佳法门.
• 避免累积瑕疵, 最好是控管coding的质量或一写好马上测试
• 与其写很多文件或做详细的计划, 不如尽快写code跟做个build来测试一下想法是否行得通
• 客户需求的收集与整理应简单明了,建议以screens的方式与终端使用者讨论需求
• 运 用短的开发循环周期(short, full-cycle)来加速学习过程--短周期指的是一个星期到一个月的周期, 每个周期都应做出working software, 周期应包含重构(refactoring)和整合测试(integration testing)
• 简短且多次地和客户沟通, 让开发者与客户双方频繁的对话, 可清楚厘清现阶段应投入的功夫(efforts), 以及未来改进的方向. 客户可以就每次开发团队完成的结果更明确给与意见, 开发者也可在多次客户回馈中更厘清domain know-how以及如何做才能满足客户.

实行重点:

• 建立有设计能力的建筑团队 - 开发团队的领导者必须能倾听团队成员的声音并聪明提问让所有成员有办法很快地自己找答案或解决问题, 或酝酿更新更好的解决方法- 创造一个可以让人们在工作中持续改善的环境, 他们应该被知会没有最完美的, 永远有更好的方法, 且一定要不断改善别无他途.
• 培训问题解决技巧 -开发团队应该像小的研究单位, 其应该有办法建立假设, 然后快速执行实验求证.

由上看来, 也许我们应考虑一下:

• 团队是否做daily build?
• 如何控管coding的质量? 个人能力和自我把关? 有coding style的check或 辅助工具 ?
• 如何才能实时方便地有记录地和客户讨论需求, 报告进度, 或做需求变更, 瑕疵回报,文件分享并让所有参与者知悉呢?
• 如何才能切出可掌控的工作大小, 排出有效的开发循环周期, 而其中的refactory和integration testing的准则和方法又是什么?
• 如何建立持续改善的机制和环境?

3. 尽量延迟决策 

软件开发不确定的变量很多, 在刚开始时很难预测后面的变化, 所以建议尽量多留活口, 采用options-based approach. 应该根据事实而非根据假设来做决策. 不到清楚明朗, 最后关头, 都要留多个选项. 另一方法是运用iterative approach(如上述的short, full-cycle), 来应变软件不可避免的需求变更和机动修正错误.

实行重点:

• 到最后关头才做无法逆转的决定 - 你应该要知道往哪里去但你有可能不知道应走哪条路, 但有可能越走越清楚. 最重要的是要往正确的方向走.
• 打散依赖度 - 组件的关联应该越松越好, 如此才可以任意的次序来开发.
• 保持弹性 - 为所有关键决策开发多种解决方案以便能从中挑出最好的. 运 用Set Based Development的方法:尽可能拆解"产品生产"为可平行运作的"零件生产", 并清楚定义各零件间的整合接口. 如此您可以多头同时进行, 每个零件也可有多种生产进行的方法. 到要整合的时候, 您将更清楚如何定义这些零件间的整合接口, 且有多种选择以做出最佳的产品.

建议增加弹性的一些可行方法:

• 将部分完成的设计信息分享(不只是团队内, 也可以权限分级的分享给客户)
• 建立团队每位成员能直接沟通的协同作业机制
• 建立何时应该做决策的共识 建立如何吸收变更的共识(避免重复, 分散关连, 打包变量, 延迟使用未来开发资源)
• 致力于重构(refactoring)
• 采用自动化测试工具

4. 尽快出版

尽快出版的目的是让您的客户能在最佳的信息了解状态下做最好的决策. 一旦客户一决策, 您的团队就能很快提供一个可用的版本. 以市场观点来看, 越快将没啥大问题的产品上市让客户使用, 可以越早获得客户的回馈, 并入下一轮开发排程中. 越短的开发周期, 能越快让开发团队从市场获得实时的信息, 也让团队有办法快速应变市场的变化. 采取可快速应变后续变动的短周期开发法, 才能降低贸然决策后所遇到客户或市场需求转向所造成的冲击.

实行重点:

• 以小批生产方式 - 切割项目成多个release cycles,让每次release间隔不要太长, 保持开发的速度与稳定的开发环境, 如发现窒碍的原因和作法, 请尽量移除.
• 就资源安排适量工作 - 尽量减少排队等待的工作(在一两个iteration后来做还可以), 建议如果要排很久才会轮到的工作, 可以考虑直接排到下一轮, 且如果自己的list里还有等待自己完成的工作, 就应该拒绝接新的工作.
• 聚焦 cycle time而非利用人力到最大限度 - 在排程中应该将工作切割成小量, 尽量减少因需时太长而看不到工作完成日的问题. 请降低每一iteration的需时, 将每个工作范围切少一些, 减少排队等待完成的工作.

5. 授权与尊重 

相较传统的命令式管理, Work-out技巧已被很多有经验的经理人证实, 反过来做的成功率比较大, 让你的组员深入参与并决定怎么做比较好, 自己给commitment, 经理人仅提供如何加强或改进的建议. 如果回顾管理的历史(请参考Mary Poppendieck走过历史的演说 The role of leadership in software development ) ,  团队成员不应只被当reources(资源)看待, 并不是给成员工作的list, 然后就可以完成. 激励(Motivation), 知道为什么而做, 以及时常的沟通, 让成员知道所有相关工作者正在发生什么事, 对于整体的工作士气会有很大的帮助. 另外, Lean Software Development很鼓励让开发者直接面对客户,如此开发者对于domain kow-how, 以及自己到底为什么而做, 会有更深的感触. 而团队领导者应提供所有团队成员应有的支持和帮助, 以克服困难, 维持团队的合作默契和士气. 至于所有的团队成员, 应该给与他们在什么情况下如何应付的经验分享和培训, 已帮助他们做正确的决定.

实 行重点:

• 训练团队领导者和专家 - 训练你的团队领导者和专家, 让他们有能力分享他们的专业, 训练组员, 建立可实行Lean的环境.
• 将责任与决策权转移到有可能的最底层 - 让你的人自己思考和决定, 他们应该知道如何运用复杂的算法或运用完美的软件架构来写程序与运用完美的软件架构.
• 加强工艺的自豪感 - 鼓励团队成员热情的参与他们所有的执行工作与方法

6. 整体经验 

客户对于软件的感觉不是只有产品本身, 而是整体产品经验(integrity), 一种是perceived integrity, 包含产品如何营销, 出货, 上线, 接触, 直觉反应, 价格, 和问题解决经验. 这是客户不会告诉你的需求, 需要团队本身细腻的市场观察. 另外一种是conceptual integrity, 指系统每一零件的运作和合起来运作的在弹性度, 维护度, 效能, 响应效率等整体状况是否协调,达到某一定的水平. 要达到令顾客满意的程度一方面要靠对于问题领域有深度了解的基础, 一方面要能同时快速解决, 而非要按顺序一个一个解决. 所需的数据与其要等全部完整写成一大篇文件或开冗长的会议,不如持续不断的双向沟通, 每次沟通的信息可以是短短的,不浪费太多时间的. 尽量避免长久隔离后才一次给与大量信息的方式, 这会让双方的沟通充满挫折感, 也较难给客户好的整体经验.


实行重点:

• 顺畅详细的信息流 - 建立客户, 使用者, 开发者间快速同步沟通的联络网. 正如Agile强调: Customer collaboration over contract negotiation.
• 与人同步前的质量保证 - 为了让你的软件达到高质量, 你应该在一行程序都还没写之前就开始操心, 如果你是等到要与别人同步时才开始操心, 会很惨的.
• 自动化 - 强调及早, 经常, 全面性的测试. 所以如果能够自动化test, build, deploy,只要是例行作业都能自动化, 将有助于提升 integrity.
• 重构(Refactor) - 将程序代码复制降到"零"-每次运用程序重构, 测试, 或文件来降低复杂度

7. 系统思考

如果我们去观察大多数的管理理论, 多强调工作拆解后被分析出来的个个元素的最佳化. 但Lean thinking认为如果你从局部来做最佳化, 常常导致整体的次等化. 为何会这样? 作者举例, 如果你想要最佳化测试资源的运用, 那么你将降低一定时间内整体产生测试过且可用code的数量. 此外, 就算你倾全力来降低个人的瑕疵, 还是避免不了一个有名的事实-80%的瑕疵来自系统工作方式, 也就是管理上的问题. 欲避免这样的问题, 建议应该去鼓励人与人之间的沟通协调, 着重"我能影响什么"而非"我能控制什么". 由高于"个人"一层来观察, 如去看整个团队的瑕疵数量, 而非去探讨个人的瑕疵数量. 改善的方式与结果评量也以整体表现来考虑. 要求系统思考的原因是: 作者发现加强个人并不会真的提高整体表现, 但发觉如果是整个团队一起探讨改进, 修改系统工作方式, 整体表现可以很显著的提升.

实行重点:

• 聚焦于整体的价值链 - 专注于赢得整体的比赛, 不要只看到每个局部的改善, 要从整个组织产品整体来考虑最佳化.
• 完整的出货 - 整个团队需要好的领导也需要好的工程师, 业务, 市场专家, 助理秘书...全部合起来以最好产品和服务呈献给客户.

总而言之, Lean的基本想法是如果开发者能被尊重且互相有效的沟通协调, 这群开发者就比其它团队更有可能做出好的产品来满足客户---- 聚焦人本与沟通协调 .


如果你看上面那7个原则感觉还不够的话, 建议看看Mary Poppendieck走过历史的演说 The role of leadership in software development 应该可以更清楚了解整个Lean概念的启蒙, 以下撷取几张片段, 看过后应该有更深的感触.


1. 对于传统的MRP模式, 作者认为这不是working hard就能100%达到规划好的进度.
没有所谓的SOP, 只有how to constantly improve the way to get work done.

2.第一个提出Perl管理项目概念的Polaris项目成功的原因并不归功于Perl, 而是以下几点：

3. 发现Mission Critical Job能够成功做到不危及生命的Mind Set是:

4. US Army 发觉战胜的Leadership应该是给mission command而不是detailed command. 重点在delegate(委派), 如果你要让人发挥他的价值, 就要授权让他思考判断. 主要让他知道What need to be achieved, 而不是What to do.

5. 整个组织要训练expert能分享他的经验, 教育其它人, 在产品Concept到Cash的阶段, 是个不断Technology与Marketing marriage的collaboration和创造, 与知识的创造和分享.

 

6. 你要找的是认知自己在建教堂的工人, 而不是认为他在切石头或填饱肚子的工人.

参考数据:

Youtube: The role of leadership in software development

agilesoftwaredevelopment.com Seven Principles of Lean Software Development

Lean Software Development

Wikipedia: JIT生産システム

Wikipedia: Lean software development