开发过程思考

我是软件工程毕业的，大学时把自己定义为软件开发的工程管理人软，在工程化的软件开发人员，自认为学习了形形色色的软件工程理论后，用来做底层开发有点可惜，应该站在上层指导和监督。
且不说中国高校课程是否合理，单单是自己的这些想法已是可笑。
现在进公司后的第三个项目已经进行到CT阶段，觉得有很多需要反思和总结的地方。因为这次Leader不是很强势，自己有很多需要思考和实践的地方。
项目的计划书是PM来做的，作为普通开发人员，我可以利用这段时间来学习项目中要使用的技术，比如C#，自动化测试等等。实际情况是，当时我负责上次项目的扫尾，没有顾及新项目的学习，C#语言看来比较容易上手，直接就可以适应开发了（因为是改造开发，可以依葫芦画瓢）。
项目开展是按照传统瀑布模型，这样大家都比较容易接受，而且是公司一向的开发模式。计划，功能设计，详细设计，编码，测试...即使是学生也是耳熟能详的。
如 果我现在是项目经理怎么办？原本的项目我并未参与，从哪里改造？测试工具怎么选择，我有时宁愿选择非自动化的工具，我认为设置工作环境太麻烦了。还有最后 阶段的MP测试，32bit，64bit；UNIX，Linux，Solaris 等多个平台如何保证，我到现在还不熟悉非Windows的环境，所以每次要转到其它平台时都不知从何做起。
这次的项目进度是这样的：
PP：一周，最后改到第四版
FD：一周时间，因为做的外包，客户方也是软件公司，当然给的需求很明确，所以FD不成问题，只是比以往躲了用户手册部分
SD：一周，得益于FD阶段调查，将序列图画了出来，按图索骥，把改造的函数很快的确定
MK：编码一周，其实两天就完成了
MK23：单元测试和接口测试；使用了要因分析方法，因为是在DotNet环境，所以使用了Nunit和Ncover，作为自动化测试和覆盖验证工具
CT和MP对应放在下周以后进行，共三周时间。
SD阶段，为了估算代码，就已经开始写代码，并且基本功能已经实现，有点像螺旋开发；
MK阶段，两个人分工非常明确，几乎是独立的，一个负责数据的插入，一个负责数据的查询
MK23阶段，写测试用例和写测试代码，其实是可以相互交替进行，有点像敏捷里面的配对编程
由于使用了Nunit，有点像测试驱动开发
......
一个小项目是可以融合多种开发观念，灵活多变，因为成本低，其实是可以尝试敏捷过程的。
我累的时候，会吵着要使用Scrum的开发模式，因为开发要有激情，每周都进行Scrum，这样前两天进度非常快，后两天作为质量保证和确认，还可以有一天的缓冲时间。
告诉自己的话：话有点啰嗦和冗余，辞不达意，天马行空，而且主题不够鲜明，没关系，能写出来就是进步，坚持多写就行了