【配置管理案例08】

        A公司与某餐饮巨头签订了合作意向，为其定制开发一款智能点餐设备。项目一期计划在A公司已上市的一款消费型平板产品A100上直接改造原有软件系统，更新后作为点餐机先试产200台投放至即将开业的机器人服务餐厅。由于项目一期复用A100的硬件和软件，A公司任命A100的项目负责人小李为项目经理，预计在2个月内完成软件系统的升级改造，以满足餐厅的开业要求。

        小李认为在A100现有系统上修改软件，改动不多，工作量也不大。因此在A100软件系统的正式版本上拉出一条新的分支，让研发人员直接合入新代码即可。由于前期需求调研时间仓促，很多细节迟迟无法确定，小李要求需求定义、产品设计、研发测试人员全部封闭开发，边讨论、边开发、边测试。然而，随着需求定义和功能点的持续增加，项目组遇到了以下问题：

（1）研发人员反映代码服务器上没有稳定的中间版本，在出现严重问题需要回溯时，只能从初始版本开始将所有代码—笔一笔重新提交重新编译来排查；

（2）大家发现项目文档不全，功能定义只是通过互相口述确认的，测试人员无法编写完整一致的测试用例；

（3）有些研发人员自行编译的软件版本号格式不统一，导致系统更新升级经常失败；

（4）测试人员执行测试时，发现实际功能与需求不一致，却被研发人员告知由于开发难度大，已经联系产品经理修改了定义。

        小李每天在这些问题之间疲于应付，还要抽时间进行软件版本管理和项目文档的收集整理。眼看交付时间越来越近，项目面临着进度和质量的双重压力。