软件开发中如何分工
请问各位高手软件开发过程中如何分工，又是如何结合起来的
------解决方案--------------------
需求分析 （developer & tester)            10%
设计 (developer)                          30%
开发 (developer) -- 测试用例设计 (tester) 30%
测试 (tester)    -- bug fix (developer)   30%
维护 (developer)
------解决方案--------------------
人员分工?
------解决方案--------------------
已经很清楚了嘛！
------解决方案--------------------
具体 看 公司  基本上都不一样
------解决方案--------------------
模块分工。。
------解决方案--------------------
我无法像抄别人的软件工程书一样很“科学地”回答你这个问题，我可以举一个反例，有时候你对关键的反例了解清楚了，真理就自然浮现了。

许多时候，我们碰到的那些pm，他们非常喜欢分工，而不懂自己的设计职责以及如何很好地结合。这就是水平低劣的 pm 的一个明显标志。

因为搞办公室政治手腕，再了解一些需求，就可以（把需求界面或者现在流行的三层模型简单分解给程序员）“分工”了。对他们来说，所谓合并就是点评程序员，扣工资，而他们自己并不能做出“优秀”的表率。


我所认识到的好的团队（特别是大公司的外包）管理，是pm尽量给开发人员免责，他在部署任务（单）之前对测试标准写得很具体（但是并不要求全面），开发人员如果做到了基本的测试就没有任何其它责任了。当pm发现需要补充更多的测试来重构软件，他会重新部署新的任务（单），而不会纠缠原来实现那段代码的开发人员“写出的代码不够完美”。也就是说，pm从来不把自己的设计质量和进度控制方面的责任推卸给开发人员来完成（不对开发人员的开发结果挑三拣四）。

这样的基础下的分工是可以加快开发速度的，而那种只懂功能分解的人的分工策略，只会让团队保持一堆初学者的平均水平进行作坊式的开发。
------解决方案--------------------
敏捷团队的pm拼什么可以做到给开发人员免责？他需要有很好的技术水平，有非常高灵活性的测试驱动策略，他即使2天之内构造和发布软件的用户体验版本也毫不畏惧，他对进度无需排列一张长长的日程表（因为根本不可能按照那个日程）但是他总是最快最高质量地达到里程碑的目的，他拥抱需求的千变万化而不是尽可能躲避。

有了技术支持，那么一个pm就可以将眼前（2周之内的）设计划分一个个小功能单元，然后开发人员谁爱做哪一个就认领哪一个。不用玩什么高深的“分工”游戏。
------解决方案--------------------
我有一个oa产品的工作安排，大家看合理不


第一阶段
一．项目策划
结合泛微的OA产品或其他OA产品，规划出项目的主题思想和主要架构（一天），现已完成。
二．项目规格说明书
结合泛微或其他OA产品，规划出OA应包含哪些模块，子模块，以及数据说明，流向。（3天），待熟悉泛微OA产品后再写。
三．前期demo制作
根据以上的规格说明书，制作出OA产品的所有静态页面，作为以后开发的模板使用。（3天）

以上是OA产品规划的前期安排，这些工作是为本公司OA产品立项做准备。
在项目立项之前必须确定此OA产品时在原功能上改还是从启。

第二阶段

五．针对前期页面开会讨论，做出一定量的修改（一天）
六．概要设计：
根据修改的demo确定功能模块。（3天）,要详细的。

7.详细设计：（一星期到二星期时间）
1.此详细设计和以前的详细设计不一样，因为是未开发项目，但此详细设计文档必须说明，功能模块与模块的关系，具体模块的表单设计。
2.编码规范
3.项目种可能出现的问题

八：数据字典：
根据详细设计要设计出各个表单的数据字典，以备开发。要包含字段的中文描述。(3天时间)
九．技术手册
技术攻关手册，为开发扫平障碍（待详细设计完成再确定时间）

九：项目工作安排，任务单分解：（2天）
工具：project
要求：安排工作人员人数，工作任务，要出现紧要，紧前，紧后之分，工作任务安排好之后，要出现工作流向图，老总可按图纵观全面。

十．第二阶段评审
由杨姐进行第二阶段的评审，最终确定终极开发手册。（一天）

第三阶段：
项目立项，开发待续，现在无法确定时间

第四阶段，项目测试，评审（3-5天）
第五阶段，项目结束

------解决方案--------------------
喜欢，学习
------解决方案--------------------

引用:

敏捷团队的pm拼什么可以做到给开发人员免责？他需要有很好的技术水平，有非常高灵活性的测试驱动策略，他即使2天之内构造和发布软件的用户体验版本也毫不畏惧，他对进度无需排列一张长长的日程表（因为根本不可能按照那个日程）但是他总是最快最高质量地达到里程碑的目的，他拥抱需求的千变万化而不是尽可能躲避。

有了技术支持，那么一个pm就可以将眼前（2周之内的）设计划分一个个小功能单元，然后开发人员谁爱做哪一个就认领哪一个。不用玩什么高深的“分工”游戏。

    顶~~
------解决方案--------------------

引用:

我无法像抄别人的软件工程书一样很“科学地”回答你这个问题，我可以举一个反例，有时候你对关键的反例了解清楚了，真理就自然浮现了。

许多时候，我们碰到的那些pm，他们非常喜欢分工，而不懂自己的设计职责以及如何很好地结合。这就是水平低劣的 pm 的一个明显标志。

因为搞办公室政治手腕，再了解一些需求，就可以（把需求界面或者现在流行的三层模型简单分解给程序员）“分工”了。对他们来说，所谓合并……