如何把握中大型软件开发流程？
第一，Delphi 到Qt ，这不叫重构了，应该叫重写。第二，把“优化”放到最后，先保证功能正常。第三，测试驱动，通过完备的测试用例保证功能正常；第四，原来的代码质量如何，MVC三个层次清晰吗？纯界面
如何把握中大型软件开发流程？第一，Delphi 到Qt ，这不叫重构了，应该叫重写。第二，把“优化”放到最后，先保证功能正常。第三，测试驱动，通过完备的测试用例保证功能正常；第四，原来的代码质量如何，MVC三个层次清晰吗？纯界面的工作能否分开同时进行？第四，老板给的时间够用吗？要不要争取更宽松的期限？第五，团队成员的水平如何？能做到合理分配任务吗？
暂时想到这么多，仅供参考。这种项目本身还是有一定难度的，其中最大的难点还是由于需要重写，那么就需要在重写下掌握所有原有的代码实现逻辑和底层数据模型结构，最大的还原原有的需求，才谈得上进一步的功能优化和类优化，其中要注意的关键点在于。
1. 好好研究原来的数据库设计和数据表结构，表和表之间的关系，每一个数据表的每一个字段属性的含义和起到的作用。前台的每一个功能点要列成详细的功能清单，每一个功能点对于后台数据库包括字段的CRUD影响都要分析清楚，确保没有遗漏。
2.详细的Review原来Delphi程序的所有代码，要知道第一步分析是容易遗留大量的业务规则和处理逻辑的，因此在第二步的重点就是造成代码里面的业务规则和逻辑，把这些也全部罗列清楚，每一个逻辑点的实现描述清楚。
3.根据第一步和第二步完成的内容，开始整体总体架构设计文档，注意这一步不能去迭代，总体架构设计文档的重点还是在于底层的数据库设计的完整性，上层核心类逻辑模型的完整性和优化。这一步做完后应该新的应用的组件划分，接口识别，复用识别应该全部搞清楚。
4.最后一步即到了真正的重写和实现阶段，有了前面的基础你会发现所有的需求都可以列成详细的features功能点，这些需求功能点清单即可作为敏捷开发中的product backlog，再根据迭代周期的安排来划分为spint backlog和详细的迭代版本计划。前面真正把控好了到这一步基本不会再出大的方向性的问题。
再次说明下类似这种项目的成功关键还是在于技术和架构把控能力，其次才是项目管理能力。说简单点，做个翻译词典的工具。通过该工具直接把所有代码先简单转换。有错无所谓，然后一行行校对修改。可以写个简单基盘实现许多语言差异导致的功能。目的就是一行代码对应一行代码。
不要考虑原来功能。同样数据跑，走出来一样效果就ok。测试分支多一点。
一个个类去分析再实现再测试，效率极其低下。而且你能保证你分析肯定不会出错？之前参加过IBM的培训，讲师讲到复杂项目的定义，不在乎项目是大是小，凡是项目经理看不清楚的项目，都是复杂项目
你这个就是典型的复杂项目
你的描述还是比较概略的，这样很难提出具体的建议
结合我的经验，只能给出一些问题
那么问题来了
第一层
你对这个项目的业务有个整体的把握了吗？
有完整的业务流程图吗（脱离的技术实现的）？
业务流程中每个环节是怎么划分的，环节与环节之间对接是怎么样的（图示，结合数字）？
每个业务环节的详情是怎么样的（图示，结合数字）？
对每个业务环节有性能要求吗（精确到数字）？
第二层
整体业务实现要用到哪些技术？
在生产环境、开发环境分别需要部署什么样的一套配置（硬件，软件）可以支撑起整个业务？
根据业务流程、环节划分、性能要求以及技术实现，在技术上怎么划分模块（大致等同于概要设计）？
模块之间怎么通信？
模块内部怎么设计（大致等同于详细设计）？
做到这个程度，基本上开发计划可以定了，开发任务已经可以出backlog了。
需要注意的是模块内部设计这个部分，如果经验很丰富，对于各个模块内部实现有把握，可以不用一次都做完，需要开工哪个模块就开始做设计。
相反如果对于某个模块没有足够的把握，最好先期设计做细一点。一般说起来，项目延期大部分是因为开发人员认为事情很有把握，但是实际做的时候发现跟自己想象的不一样所致，相信很多开发人员都有这种经历的 哈哈哈哈
进入到开发阶段
要点就跟随敏捷的要求就行，比如
每个迭代产出一个可以使用的东西，在迭代开始之前就计划好的要做什么
拆任务拆到2人日以下
迭代启动会集体估时和认领任务
等等等等敏捷迭代开发显然是最佳选择，何况还是一个非正式的2-3人年项目。
建议你先把Product Vision、Development Plan、Project Management Plan等文档草案写出来， 做到规划在先、心中有数，网友也好参与评论。
选择合适的项目管理和开发方法论很关键。敏捷开发方法有许多流派，纯Scrum+XP估计不适合你们两人吧，建议参考下AUP和Taij/BP。
//但是目前我还没有过做这种中大型项目主负责人的经历，不知道怎样才能把控好整个开发过程。因此想请教各位有什么好的方法来保证项目的成功。具体到措施上来说，一方面我们公司内部提倡用敏捷开发，借助迭代开发来降低风险。我也打算用迭代的形式来交付成果。这是一个跨语言的重构项目，项目只有两个人，我觉得倒不涉及过多的项目管理的内容。更多的是看你如何把有效地把握重构过程。
暂时想到这么多，仅供参考。这种项目本身还是有一定难度的，其中最大的难点还是由于需要重写，那么就需要在重写下掌握所有原有的代码实现逻辑和底层数据模型结构，最大的还原原有的需求，才谈得上进一步的功能优化和类优化，其中要注意的关键点在于。
1. 好好研究原来的数据库设计和数据表结构，表和表之间的关系，每一个数据表的每一个字段属性的含义和起到的作用。前台的每一个功能点要列成详细的功能清单，每一个功能点对于后台数据库包括字段的CRUD影响都要分析清楚，确保没有遗漏。
2.详细的Review原来Delphi程序的所有代码，要知道第一步分析是容易遗留大量的业务规则和处理逻辑的，因此在第二步的重点就是造成代码里面的业务规则和逻辑，把这些也全部罗列清楚，每一个逻辑点的实现描述清楚。
3.根据第一步和第二步完成的内容，开始整体总体架构设计文档，注意这一步不能去迭代，总体架构设计文档的重点还是在于底层的数据库设计的完整性，上层核心类逻辑模型的完整性和优化。这一步做完后应该新的应用的组件划分，接口识别，复用识别应该全部搞清楚。
4.最后一步即到了真正的重写和实现阶段，有了前面的基础你会发现所有的需求都可以列成详细的features功能点，这些需求功能点清单即可作为敏捷开发中的product backlog，再根据迭代周期的安排来划分为spint backlog和详细的迭代版本计划。前面真正把控好了到这一步基本不会再出大的方向性的问题。
再次说明下类似这种项目的成功关键还是在于技术和架构把控能力，其次才是项目管理能力。说简单点，做个翻译词典的工具。通过该工具直接把所有代码先简单转换。有错无所谓，然后一行行校对修改。可以写个简单基盘实现许多语言差异导致的功能。目的就是一行代码对应一行代码。
不要考虑原来功能。同样数据跑，走出来一样效果就ok。测试分支多一点。
一个个类去分析再实现再测试，效率极其低下。而且你能保证你分析肯定不会出错？之前参加过IBM的培训，讲师讲到复杂项目的定义，不在乎项目是大是小，凡是项目经理看不清楚的项目，都是复杂项目
你这个就是典型的复杂项目
你的描述还是比较概略的，这样很难提出具体的建议
结合我的经验，只能给出一些问题
那么问题来了
第一层
你对这个项目的业务有个整体的把握了吗？
有完整的业务流程图吗（脱离的技术实现的）？
业务流程中每个环节是怎么划分的，环节与环节之间对接是怎么样的（图示，结合数字）？
每个业务环节的详情是怎么样的（图示，结合数字）？
对每个业务环节有性能要求吗（精确到数字）？
第二层
整体业务实现要用到哪些技术？
在生产环境、开发环境分别需要部署什么样的一套配置（硬件，软件）可以支撑起整个业务？
根据业务流程、环节划分、性能要求以及技术实现，在技术上怎么划分模块（大致等同于概要设计）？
模块之间怎么通信？
模块内部怎么设计（大致等同于详细设计）？
做到这个程度，基本上开发计划可以定了，开发任务已经可以出backlog了。
需要注意的是模块内部设计这个部分，如果经验很丰富，对于各个模块内部实现有把握，可以不用一次都做完，需要开工哪个模块就开始做设计。
相反如果对于某个模块没有足够的把握，最好先期设计做细一点。一般说起来，项目延期大部分是因为开发人员认为事情很有把握，但是实际做的时候发现跟自己想象的不一样所致，相信很多开发人员都有这种经历的 哈哈哈哈
进入到开发阶段
要点就跟随敏捷的要求就行，比如
每个迭代产出一个可以使用的东西，在迭代开始之前就计划好的要做什么
拆任务拆到2人日以下
迭代启动会集体估时和认领任务
等等等等敏捷迭代开发显然是最佳选择，何况还是一个非正式的2-3人年项目。
建议你先把Product Vision、Development Plan、Project Management Plan等文档草案写出来， 做到规划在先、心中有数，网友也好参与评论。
选择合适的项目管理和开发方法论很关键。敏捷开发方法有许多流派，纯Scrum+XP估计不适合你们两人吧，建议参考下AUP和Taij/BP。
//但是目前我还没有过做这种中大型项目主负责人的经历，不知道怎样才能把控好整个开发过程。因此想请教各位有什么好的方法来保证项目的成功。具体到措施上来说，一方面我们公司内部提倡用敏捷开发，借助迭代开发来降低风险。我也打算用迭代的形式来交付成果。这是一个跨语言的重构项目，项目只有两个人，我觉得倒不涉及过多的项目管理的内容。更多的是看你如何把有效地把握重构过程。
- 能不能够寻找到原有delphi系统中的物理模块边界？从一两个与外界耦合较少的模块开始，C++重写后与其它原有系统同时运行。如果没有，推荐先重构原有系统，划分物理边界。
- 在重写过程中不要过早考虑体系结构的优化问题，风险太大。
- 强烈推荐重写过程中使用TDD方式，逐步补充测试用例，以便后期针对体系结构时行重构。
- 还应该考虑到过度期中，原则系统的业务变更需求。所以应该自底向上地进行重构，与业务需求最紧密的部分最后动。
60万行代码换种语言重写，直觉是不要开展这样的项目！
除非你有把握把这60万行代码缩减到6万行。
如果没看到代码大幅度缩减的可能。假设一天的生产率是300行代码，一年260个工作日，仅仅是把代码敲出来，两个人也需要约4年时间。考虑到测试和bugfix，估计要6年时间。考虑还有不少缺陷要产品上线后才能发现，要达到和老版本相同稳定程度，花费的时间会更长。这六年里面，还会出现新需求，新老两套班子需要同时工作。更要命的是，你不知道6年后这个产品还有没有存在的价值。
不过既然题主说是delphi写的代码，作为那个时代过来的人，直觉是这60万行代码存在缩减为6万行的可能。那个时代市面上轮子少，每个产品都在自己造轮子。比如我们十多年前做通信产品，从操作系统一直做到应用层协议栈，自己去实现现在linux下唾手可得的各种工具，放到现在，可以直接用现成的OS替代了。所以我的建议是：
- 最理想的情况，能否用目前现成的软件加上一些数据配置来实现？
- 次理想的情况，能否分离出原软件中的非业务特定功能，用今天的现成软件来实现？然后只写业务特定的代码。
如果题主维护的是信息系统，命中选项一的可能性相当大；如果维护的是比较小众的领域，选项二的可能性很大。另外，为题主的职业前途考虑，也为公司寻找后续维护人员考虑，如果存在可以使用java或者脚本语言的可能，坚决抛弃c++。
重写要达到什么商业目标？如果没有商业目标，失败概率很大。最好是不重写不足以支持马上，至少是近一年的商业目标，否则我觉得重写没必要。责任编辑：
