第83章 开发周期的敏捷管理(2/3)
“对。” 张天放点点头，又在流程图旁画了一个小方框，标注 “每日站会”：“我们再建立‘每日站立会议’制度，每天早上花 15 分钟，每个人说说昨天做了什么、今天要做什么、遇到了什么问题 —— 不用长篇大论，重点是同步进度、暴露风险。比如老郑遇到设计接口的问题，当天就在会上提出来，设计组当场协调修改，不用再拖三天。”
“可这样会不会太碎片化？” 陈星还有些顾虑，“每个模块单独迭代，最后整合的时候会不会出现兼容性问题？”
“不会。” 张天放笑着摇头，“我们要做‘持续集成’—— 每个模块完成后，立刻和已有的模块整合测试，发现兼容性问题及时解决，而不是等所有模块都做完再整合。就像流水一样，小问题随出随解决，不会积成大麻烦。” 他顿了顿，补充道，“我们不追求一次‘编译’通过一个完美的‘大型程序’。我们‘持续集成’，‘持续交付’，让‘产品’这个‘进程’和‘市场’这个‘环境’同步演进 —— 这才是‘顺势而为’的研发。”
陈星拿着那张流程图，反复看了几遍，之前的焦虑渐渐被兴奋取代：“我现在就去跟设计组、编码组沟通，把模块拆分开！第一个周期我们就做打印机适配和 windows 95 驱动，这两个是用户反馈最多的需求，做好了也能提振士气。”
“别急。” 张天放叫住他，“先开个全体研发会议，把理念讲清楚，让大家都理解为什么要变 —— 改变流程会有阻力，只有达成共识，才能真正落地。”
下午两点，研发部的大会议室里挤满了人。张天放站在白板前，把那张 “迭代流程图” 画在板上，先解释了瀑布模型的困境：“我们现在就像在闭着眼睛走路，要等撞到墙才知道转弯，而敏捷迭代就是睁着眼睛小步走，每走一步都看看方向对不对，及时调整。”
他刚说完，设计组的老王就皱起眉：“张总，按迭代来做，需求和设计会频繁变动，我们的工作量会增加不少吧？而且每个周期都要测试，测试组的压力也大。”
“表面上看工作量增加了，但实际上减少了返工。” 张天放耐心解释，“以前一个设计缺陷要到编码后期才发现，改起来要重新设计、重新编码、重新测试，耗时耗力；现在在迭代周期里发现，当天就能调整，成本要低得多。至于测试压力，我们可以把测试融入每个周期，而不是堆到最后，反而更轻松。”
测试组的组长老赵点点头：“确实，现在测试都堆在最后，二十天要测完所有模块，根本来不及仔细测；要是每个周期测一个模块，我们能测得更细致，还能提前发现问题。”
编码组的老郑也放下了顾虑：“要是设计能及时调整，我们编码也不用卡壳了 —— 之前为了等设计修改，我硬生生空等了三天，要是能在站会上当场解决，效率能提高不少。”
看到团队态度逐渐转变，张天放松了口气，开始分配第一个迭代周期的任务：“第一个周期（11 月 15 日 - 11 月 28 日），我们聚焦三个模块：打印机适配（兼容 8 种主流机型）、windows 95 即插即用驱动、内存占用优化（降至 20% 以下）。需求组负责细化这三个模块的需求，设计组出接口设计，编码组同步开发，测试组每天跟进测试 —— 每天早上 9 点准时开站会，同步进度。”
会议结束后，团队立刻行动起来。需求组的小李不再抱着 “需求不能改” 的执念，而是主动找设计组、编码组沟通，把模糊的需求细化成可执行的模块功能；设计组的老王也不再等需求完全定死才开始设计，而是先出核心接口方案，边设计边调整；编码组的老郑拿到调整后的打印机适配设计，当天就开始编写驱动代码，cRt 显示器上的代码一行行增加，他脸上的愁容也渐渐散去。
11 月 28 日，第一个迭代周期结束的那天上午，技术部的办公区里弥漫着兴奋的气息。陈星拿着测试报告，快步走到张天放的办公室：“张总，第一个迭代的三个模块都通过测试了！打印机适配兼容了 10 种机型，比计划多 2 种；windows 95 即插即用在测试机上一次成功；内存占用率降到了 18%，超额完成目标！”
张天放接过测试报告，看到上面 “测试通过” 的红色印章，嘴角露出欣慰的笑容。他跟着陈星来到技术部，只见老郑正在演示打印机适配模块 —— 爱普生、夏普、佳能等品牌的打印机依次连接，打印出的表格清晰无误，没有一丝乱码；旁边的小周则展示着 windows 95 的即插即用功能，汉卡插入电脑后，系统自动识别并安装驱动，整个过程不到一分钟。
“太不可思议了！” 设计组的老王看着演示，忍不住感叹，“以前半个月都未必能完成一个模块的设计，现在两周就完成了三个模块，还通过了测试 —— 这敏捷模式真管用！”
“更重要的是，我们能快速响应变化。” 张天放补充道，“昨天收到用户反馈，希望汉卡支持一款新
本章未完，请点击下一页继续阅读》》
“可这样会不会太碎片化？” 陈星还有些顾虑，“每个模块单独迭代，最后整合的时候会不会出现兼容性问题？”
“不会。” 张天放笑着摇头，“我们要做‘持续集成’—— 每个模块完成后，立刻和已有的模块整合测试，发现兼容性问题及时解决，而不是等所有模块都做完再整合。就像流水一样，小问题随出随解决，不会积成大麻烦。” 他顿了顿，补充道，“我们不追求一次‘编译’通过一个完美的‘大型程序’。我们‘持续集成’，‘持续交付’，让‘产品’这个‘进程’和‘市场’这个‘环境’同步演进 —— 这才是‘顺势而为’的研发。”
陈星拿着那张流程图，反复看了几遍，之前的焦虑渐渐被兴奋取代：“我现在就去跟设计组、编码组沟通，把模块拆分开！第一个周期我们就做打印机适配和 windows 95 驱动，这两个是用户反馈最多的需求，做好了也能提振士气。”
“别急。” 张天放叫住他，“先开个全体研发会议，把理念讲清楚，让大家都理解为什么要变 —— 改变流程会有阻力，只有达成共识，才能真正落地。”
下午两点，研发部的大会议室里挤满了人。张天放站在白板前，把那张 “迭代流程图” 画在板上，先解释了瀑布模型的困境：“我们现在就像在闭着眼睛走路，要等撞到墙才知道转弯，而敏捷迭代就是睁着眼睛小步走，每走一步都看看方向对不对，及时调整。”
他刚说完，设计组的老王就皱起眉：“张总，按迭代来做，需求和设计会频繁变动，我们的工作量会增加不少吧？而且每个周期都要测试，测试组的压力也大。”
“表面上看工作量增加了，但实际上减少了返工。” 张天放耐心解释，“以前一个设计缺陷要到编码后期才发现，改起来要重新设计、重新编码、重新测试，耗时耗力；现在在迭代周期里发现，当天就能调整，成本要低得多。至于测试压力，我们可以把测试融入每个周期，而不是堆到最后，反而更轻松。”
测试组的组长老赵点点头：“确实，现在测试都堆在最后，二十天要测完所有模块，根本来不及仔细测；要是每个周期测一个模块，我们能测得更细致，还能提前发现问题。”
编码组的老郑也放下了顾虑：“要是设计能及时调整，我们编码也不用卡壳了 —— 之前为了等设计修改，我硬生生空等了三天，要是能在站会上当场解决，效率能提高不少。”
看到团队态度逐渐转变，张天放松了口气，开始分配第一个迭代周期的任务：“第一个周期（11 月 15 日 - 11 月 28 日），我们聚焦三个模块：打印机适配（兼容 8 种主流机型）、windows 95 即插即用驱动、内存占用优化（降至 20% 以下）。需求组负责细化这三个模块的需求，设计组出接口设计，编码组同步开发，测试组每天跟进测试 —— 每天早上 9 点准时开站会，同步进度。”
会议结束后，团队立刻行动起来。需求组的小李不再抱着 “需求不能改” 的执念，而是主动找设计组、编码组沟通，把模糊的需求细化成可执行的模块功能；设计组的老王也不再等需求完全定死才开始设计，而是先出核心接口方案，边设计边调整；编码组的老郑拿到调整后的打印机适配设计，当天就开始编写驱动代码，cRt 显示器上的代码一行行增加，他脸上的愁容也渐渐散去。
11 月 28 日，第一个迭代周期结束的那天上午，技术部的办公区里弥漫着兴奋的气息。陈星拿着测试报告，快步走到张天放的办公室：“张总，第一个迭代的三个模块都通过测试了！打印机适配兼容了 10 种机型，比计划多 2 种；windows 95 即插即用在测试机上一次成功；内存占用率降到了 18%，超额完成目标！”
张天放接过测试报告，看到上面 “测试通过” 的红色印章，嘴角露出欣慰的笑容。他跟着陈星来到技术部，只见老郑正在演示打印机适配模块 —— 爱普生、夏普、佳能等品牌的打印机依次连接，打印出的表格清晰无误，没有一丝乱码；旁边的小周则展示着 windows 95 的即插即用功能，汉卡插入电脑后，系统自动识别并安装驱动，整个过程不到一分钟。
“太不可思议了！” 设计组的老王看着演示，忍不住感叹，“以前半个月都未必能完成一个模块的设计，现在两周就完成了三个模块，还通过了测试 —— 这敏捷模式真管用！”
“更重要的是，我们能快速响应变化。” 张天放补充道，“昨天收到用户反馈，希望汉卡支持一款新