Think about manage project

ID:51773 · 发表于 2013-8-16 15:36

Thinking ...

在这里已经整整一年了，觉得还是有必要总结一下发现的问题。

1，版本。
问题：没有真正把CVS的功能使用起来，check in时注释不写或者不写清楚，没有及时update和
diff，造成check in旧版本的覆盖着新版本的；CVS使用不严谨，造成check in太随便，版本过多，一天N
个版本的现象比比皆是，有点像收到垃圾邮件似的，想diff一下都困难重重。
解决：版本控制的使用不仅仅是管理者熟悉，重要的还是使用者的使用，只有更多地去学习，更
有效地使用才是正道。
2，需求。
问题：需求变化太快，快过了开发的速度。有总会有想法的，脑袋转得比手脚还快也正常。
解决：不管是领导还是客户，不管需求变化得如何地快，都不能来个大转弯改向，应该在保持原来大计划的方向下急时地做出一些改动来适应新的变化，后面再抽时间来去改变。
3，大局。
问题：有计划就不乱就不累，没有侧反然。没人把握大局，没有计划，整个团队就沉浸在修改需
求，修改BUG的大漩涡之中。
解决：找个人能不受外界的影响来定下长远和各种中期的计划，然后一直走下去，并定期按实际情况和进度进行适度的调整。
4，项目。
问题：有问题就整个团队进入进行解决，如果是战场的话那可能就会得个全军覆没的结局，可是
，难道我们这不是战场吗？
解决：几年前就看过当时刚起步的一种软件工程的新管理方法--XP。现在虽然没怎么关注了，不
过应该发展得不错了吧。XP比较合适小团队开发，特别是多变化式的。我觉得，从大局来看，应该保持整
个项目的前进，如果有问题只留小部分人进行处理，大部队继续前进。这是我的战略。
5，架构。
问题：没有架构或者架构很差，那就给维护带来很多很大的麻烦，成本也会上升，坏的结果还会
让项目流产或失败。
解决：
6，设计。
问题：只有最差的工人才会死着脑筋按着设计师的意思去做东西，不管是否有问题。说有人就借
说：那是他们设计的，我只负责编码！
解决：不要做代码工人，要就做软件工程师。不管是谁设计的，你都要了解清楚，要知道是否有
问题，有好的吸收，有坏的改出进。

帐号		自动登录	找回密码
密码			立即注册