一位成功项目管理者的管理日志，不看后悔

fuxin

现在的方法可以算是很轻量级的方法.人员可以控制在小于10人.团队中有一个核心的了解需求的开发人员或者是现场客户,他负责将需求以用例的方式表达出来,这类似于fdd的特征列表或是xp的user story(因为对二者的把握不是很清楚,而且现在的形式还有待改进,所以有待进一步讨论).如果是现场客户,而且不懂用例,则需要一个开发人员与之沟通,并最终以用例的形式记录下来.
之后将团队集合起来,确定一个迭代的范围并进行这个迭代的设计.(用例编写人员负责讲解需求).这个步骤有些想象的成分.现在我们的操作不是这样的,是由real和yang设计,我来评审.这样导致的问题是因为双发的思路不同,很多东西都被我改掉了,这样设计左右摇摆.下一步要努力尝试进行讨论.
设计的最终结果是团队一致了解了需求,并得到一个一致同意的类的设计.然后就可以开始开发了.现在的情况是我一个人开发.感觉有些时候力不从心,如果可以有人结伴就好了.所以如果团队大于三人的话则可以考虑结对编程.因为对需求和类有了统一的理解,沟通的代价就大大减小了.
而real所说的葡萄就在这儿了.一组组的开发人员(结对为一组)像是一个个葡萄,由了解需求并编写用例的人连接在一起.或许葡萄并不合适了,因为不会有那么多的组,而且,这个水果也不是我的最爱 :)
在开发之后,开发人员会重新聚在一起,评审在这个迭代中所做的修改,并联调系统,在评估好新的问题后加入下一个迭代.这样可能会存在新的问题,就是开发过程中某个组的改动比较大,很难和别的组的结果协调工作.一个解决的办法就是尽量缩短迭代的周期以控制差异,最极端的方式就是xp的将自己所做的改动实时加入到系统中,并每日集成,这样做最大的后盾是自动测试.我们现在的过程中这一点还做的很不够.所以测试会是一个薄弱环节.
不过现在编码临时就我一个,可以先不考虑组之间的协调问题.自动测试的问题则是不能忽略,需要进一步加强.

fuxin

之后将团队集合起来,确定一个迭代的范围并进行这个迭代的设计.(用例编写人员负责讲解需求).这个步骤有些想象的成分.现在我们的操作不是这样的,是由real和yang设计,我来评审.这样导致的问题是因为双发的思路不同,很多东西都被我改掉了,这样设计左右摇摆.下一步要努力尝试进行讨论.
设计的最终结果是团队一致了解了需求,并得到一个一致同意的类的设计.然后就可以开始开发了.现在的情况是我一个人开发.感觉有些时候力不从心,如果可以有人结伴就好了.所以如果团队大于三人的话则可以考虑结对编程.因为对需求和类有了统一的理解,沟通的代价就大大减小了.
而这儿了.一组组的开发人员(结对为一组)像是一个个葡萄,由了解需求并编写用例的人连接在一起.或许葡萄并不合适了,因为不会有那么多的组,而且,这个水果也不是我的最爱 :)
在开发之后,开发人员会重新聚在一起,评审在这个迭代中所做的修改,并联调系统,在评估好新的问题后加入下一个迭代.这样可能会存在新的问题,就是开发过程中某个组的改动比较大,很难和别的组的结果协

fuxin

现在的方法可以算是很轻量级的方法.人员可以控制在小于10人.团队中有一个核心的了解需求的开发人员或者是现场客户,他负责将需求以用例的方式表达出来,这类似于fdd的特征列表或是xp的user story(因为对二者的把握不是很清楚,而且现在的形式还有待改进,所以有待进一步讨论).如果是现场客户,而且不懂用例,则需要一个开发人员与之沟通,并最终以用例的形式记录下来.
之后将团队集合起来,确定一个迭代的范围并进行这个迭代的设计.(用例编写人员负责讲解需求).这个步骤有些想象的成分.现在我们的操作不是这样的,是由real和yang设计,我来评审.这样导致的问题是因为双发的思路不同,很多东西都被我改掉了,这样设计左右摇摆.下一步要努力尝试进行讨论.
设计的最终结果是团队一致了解了需求,并得到一个一致同意的类的设计.然后就可以开始开发了.现在的情况是我一个人开发.感觉有些时候力不从心,如果可以有人结伴就好了.所以如果团队大于三人的话则可以考虑结对编程.因为对需求和类有了统一的理解,沟通的代价就大大减小了.
而real所说的葡萄就在这儿了.一组组的开发人员(结对为一组)像是一个个葡萄,由了解需求并编写用例的人连接在一起.或许葡萄并不合适了,因为不会有那么多的组,而且,这个水果也不是我的最爱 :)
在开发之后,开发人员会重新聚在一起,评审在这个迭代中所做的修改,并联调系统,在评估好新的问题后加入下一个迭代.这样可能会存在新的问题,就是开发过程中某个组的改动比较大,很难和别的组的结果协调工作.一个解决的办法就是尽量缩短迭代的周期以控制差异,最极端的方式就是xp的将自己所做的改动实时加入到系统中,并每日集成,这样
现在的方法可以算是很轻量级的方法.人员可以控制在小于10人.团队中有一个核心的了解需求的开发人员或者是现场客户,他负责将需求以用例的方式表达出来,这类似于fdd的特征列表或是xp的user story(因为对二者的把握不是很清楚,而且现在的形式还有待改进,所以有待进一步讨论).如果是现场客户,而且不懂用例,则需要一个开发人员与之沟通,并最终以用例的形式记录下来.
之后将团队集合起来,确定一个迭代的范围并进行这个迭代的设计.(用例编写人员负责讲解需求).这个步骤有些想象的成分.现在我们的操作不是这样的,是由real和yang设计,我来评审.这样导致的问题是因为双发的思路不同,很多东西都被我改掉了,这样设计左右摇摆.下一步要努力尝试进行讨论.
设计的最终结果是团队一致了解了需求,并得到一个一致同意的类的设计.然后就可以开始开发了.现在的情况是我一个人开发.感觉有些时候力不从心,如果可以有人结伴就好了.所以如果团队大于三人的话则可以考虑结对编程.因为对需求和类有了统一的理解,沟通的代价就大大减小了.
而real所说的葡萄就在这儿了.一组组的开发人员(结对为一组)像是一个个葡萄,由了解需求并编写用例的人连接在一起.或许葡萄并不合适了,因为不会有那么多的组,而且,这个水果也不是我的最爱 :)
在开发之后,开发人员会重新聚在一起,评审在这个迭代中所做的修改,并联调系统,在评估好新的问题后加入下一个迭代.这样可能会存在新的问题,就是开发过程中某个组的改动比较大,很难和别的组的结果协调工作.一个解决的办法就是尽量缩短迭代的周期以控制差异,最极端


做最大的后盾是自动测试.我们现在的过程中这一点还做的很不够.所以测试会是一个薄弱环节.




【文件名】:07128@52RD_项目管理日志.rar
【格　式】:rar
【大　小】:8K
【简　介】:
【目　录】:

jy496602

太贵了,没RD

yangyou

没什么内容。

fuxin

我觉的挺好的啊

xupeter

不知所云