版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u014267209/article/details/81155998
项目与项目管理
什么是项目?
在既定的资源和要求的约束下,为实现某种目的而相互联系的一次性工作任务
或者说，一些人在一定的时间里面完成一些事情
什么是项目管理?
把各种系统、方法和人员结合在一起，在规定的时间、预定和质量目标范围内完成的各种工作
或者说，怎样多快好省的完成项目
项目的特征
明确的目标
独特性资源成本的约束性
项目实施的一次性
项目的不确定性
特定的委托人
结果的不可你转性
研发项目管理–瀑布与敏捷
瀑布式管理
需求分析 >> 方案设计 >> 实施/编码 >> 测试/评估 >> 维护
研发项目常见问题
产品阶段问题
没有单独的角色负责产品，往往是项目经理兼任
做出来的功能不是用户真正想要的
产品不能按期交付
产品质量无法保证，后期维护成本很高
需求无休止的变更
客户的任何需求都答应下来，需求会永无止境
版本分支很多，新增功能或者需求变动改动太高
项目管理问题
项目经理往往从技术骨干转岗,懂技术,不一定懂管理
缺少系统的管理理论和方法,靠经验和人治
对项目的估计偏乐观,每月30天,每天8小时
需求分析,任务分解不够细致,粗枝大叶
项目周期过长,节奏无法控制,前松后紧
研发阶段问题
缺少统一的编码规范,或形同虚设
结构混乱,架构不合理,系统不灵活
滥用全局变量
没有良好的注释习惯
变量命名随意,含义不清晰,中英文夹杂
缺少安全和性能意识
没有测试意识,代码质量无法保证
跟风选择时髦的技术或者框架,遇到问题无法解决
测试阶段问题
项目前期无法展开测试,测试人员只能等
研发无法按期交付,压缩测试时间,最后只能牺牲质量
没有很好的bug管理规范和系统,口头/EMail/IM跟踪
往往缺少压力测试,真正上线发现问题比较严重
往往缺少安全测试,一旦出现问题影响严重
不做版本控制,混乱的代码库和开发环境
沟通问题
项目启动后产品经理就消失了,无人解释和确认需求
遇到问题互相扯皮,强调这是其他人的责任
一个人负责一摊,知识难以传承,风险比较高
缺少团队合作,遇到问题时不愿或不能请别人帮忙
项目内部沟通不畅,每个成员知识埋头做自己的事情
战略和组织问题
跟风,别人做什么,自己也做什么
不专注,事情开个头就匆匆结尾
产品没有创新,模式没有创新
等级划分太严格,管理人员脱离一线研发
找人难,留人难
敏捷价值观
交付
目标是通过尽早且持续地交付有价值的软件来满足客户
欢迎对需求提出变更,即使是在项目后期
不断交付可用的软件,周期越短越好(1-4周)
可用的软件是衡量进度的主要指标
倡导可持续的开发,行成开发,销售和客户稳定的节奏
沟通
业务人员和开发人员在一起工作
激励项目团队,给他们所需要的资源,并信任他们
最有效的沟通方法是面对面交谈
团队
团队的敏捷性依赖于对技术,过程和架构持续性的改进
保持简介,尽最大可能减少不必要的工作
最佳的架构,需求和设计出自于自组织的团队
定期反省总结如何改进研发过程并制定具体计划改进
极限编程实践
反馈
结对编程:质量,减少犯错,集体所有
计划游戏:用户故事,优先级排序
测试驱动开发:测试代码先行
客户加入团队
持续改进
持续集成:单元测试,持续集成服务器
重构:非重写,每时每刻都应该进行
小版本发布:小步快跑
共识
编码共识:团队的共识,尊重,集体所有的基础
集体所有权:消除单点,知识传播
简单设计:参考unix设计哲学
隐喻:意会,好的命名
编码
随时和客户沟通
单元测试优先
串行集成
延迟优化
莫加班
测试
单元测试完全覆盖
发布前单元测试全通过
发现bug后先写测试用例
定期执行验收测试并公布结果
实践经验,仅供参考
结对编程
代码规范
源代码管理
代码review
每日提交
交叉测试
重构
分享会议
简单设计
自动化
框架
禅道管理系统使用
禅道和SCRUM的对应关系
团队关系
产品基本管理流程
产品详细管理流程
第一步：产品经理 》建立产品
第二步：产品经理 》理整理需求
第三步：产品径路 》根据需求创立不同的计划
第四步：项目经理 》建立项目
第五步：项目经理 》关联产品
第六步：项目经理 》关联需求
第七步：项目经理 》分解任务
第八步：研发团队 》估算任务并领取
第九步：测试团队 》分解用例
第十步：项目经理 》 创建build(版本)
第十一步：产品经理 》 创建发布
第十二步：项目组 》 总结会议，形成改进计划列入下一期项目