
项目经理
产品经理
后端开发人员
前端开发人员
测试工程师
运维工程师
UI设计师
架构师
瀑布模型是将软件项目划分为不同阶段,从一个阶段流动到下一阶段,每个阶段输出一个或多个评审通过的文档,后续阶段在上一阶段结束前不应该开始,每一个阶段的输出是下一个阶段工作的输入,典型的计划驱动软件过程。

优点:
每个阶段都在上一阶段结束后才开始,质量有保证
各个阶段文档齐全
缺点:
项目周期长
项目变更困难
适用:
需求明确、变更少的项目
螺旋模型将整个项目开发过程划分为几个不同的阶段(类似瀑布模型)。每个阶段在都要进行风险分析之后才开始该阶段任务。在每个阶段中,都要先风险分析,再构建软件原型,然后完善的产品,然后进入下一个阶段,同样下一个阶段开始之前也要进行风险分析,以此往复。

优点:
每个阶段都有风险分析,将风险降低最低
将一个大项目分阶段完成,容易控制成本
缺点:
风险管理成本较高
项目周期容易拖得过长
适用:
适用于需求不确定,风险高的项目
增量模型就是把软件项目分为一系列的增量模块:分析、设计、编码、测试。每个模块都能够完成特定的功能而且是可测试的。

优点:
能够快速出可用的产品
能够应对多变的需求
缺点:
新的需求必须要不在破坏原有项目基础上进行,就是原有项目很难改动
适用:
适用于可以分阶段开发的项目
项目人员不足,必须要分阶段开发
原型模型是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。

优点:
能让客户参与进来,及时获取用户反馈
设计上灵活,开发周期短,费用相对少
缺点:
已有原型模型功能进行扩展时,需要修改原代码,违背了开闭原则
反复更改可能导致产品质量下降
适用:
适用于需求变化较快、客户参与度较高的中小型项目
明确自己项目组成员的能力、工作态度、工作积极性、工作的意向、手头已经有的工作量等,分配工作的时候要根据这些来分配,尽可能让成员自己选择任务,让他们做自己愿意做的事
根据任务的任务量、任务性质、紧急程度、难度进行分析然后拆分成各个小的任务,然后再分配给成员或者让他们自己选择
一定要告知成员任务要达成的目标和完成的时间点,比如什么时间要做完那些工作量,什么时间要提交测试等。
分析任务可能出现的风险,比如那些任务有可能不能按时交付,那些任务会出现技术、业务、开发上的困难,那些会出现中途需求变更的风险,对这些都要做好应对。
让成员做好定期反馈或者定期去询问成员,比如写周报汇报任务进度和任务难点,及时和成员沟通、及时给与帮助以及调整任务量;定期开会过进度在做调整等等。
任务结束后一定要做好总结。对任务完成度总结,那些按预定期限做完,那些没有,什么原因;对团队所能承受的任务量、任务完成时间、任务分配都要有个大体认识,要了解团队的最大完成任务量和任务完成时间,下次任务安排、时间制定都尽量要在团队合理承受范围内;对成员也要做好总结,那些成员能力比较强,那些成员更适合做什么,以及和成员沟通的方式等等;对客户也要做总结,比如客户是否清晰自己的需求,和客户的沟通方式,客户最后的满意程度等。
平时自己遵守规章制度,如果要加班也要陪着组内成员一起加班
平时多看到组内成员优秀的一面(而不是缺点);对于表现优秀的成员给与奖励、甚至是升职等;对于表现不太好的成员要私下跟他多沟通,及时私下给与他诫勉;尽量避免责罚,如果要责罚应该责罚整个团队,而不是单单那一个人
工作是工作,生活是生活,做管理要对事不对人,不要因为工作而带着有色眼镜看成员;最好能和成员保持共同爱好,并能定期一起组织活动,比如打羽毛球、打游戏等
不要压倒式的去命令成员,应该尽可能从协商、帮助的角度去管理,当成员工作未能如期完成,要多了解他的困难,并尽可能提供帮助
平时多注意关心成员的工作和生活,多和成员聊聊工作之外的事情,不要给与太多压力
不要有偏见;奖罚公平、有理有据,升职加薪也要根据能力而来,而不是依据领导个人情感
平时多换位思考,不仅要站在项目的角度、客户的角度,也要站在成员的角度去看待问题,这样才能真正了解成员的想法,有利于解决问题。