项目管理目标
- 减少失败可能性,提高生产率,降低缺陷率,提高客户满意度,让业务部门满意
- 尽早的发现和解决各种问题和风险(技术,需求,目标,可用性等),对进度建立合理的预期并完成
- 敏捷的响应用户的反馈并调整,能持续改进和添加新的工程,使得系统更接近涉众的真实需求
- 各参与人员能获取持续的个人提升,包括对业务领域的深入和技术上的成长
项目管理原则
各个项目因按照产品特点选用合适的项目管理流程和相应的管理工具,从瀑布模型,Scrum,极限编程,结对编程,测试驱动开发,看板等各种实践中选用对自己项目有益部分.下面以敏捷开发为例
agile development
敏捷宣言
- 个体和迭代,超越过程和工具
- 工作的软件,超越完整的文档
- 客户协作,超越合同谈判
- 响应变更,超越履行计划
敏捷原则
- 优先级最高的是,通过早期和持续交付有价值的软件来满足客户
- 欢迎变更需求,即使在开发的后期提出.敏捷过程为客户的竞争优势而控制变更.
- 以两周到两月为周期,频繁地交互可运行的软件,首推较短的时间定量
- 在整个项目过程中,每一天开发人员都要和业务人员合作
- 由个体推动项目的建设,为个体提供所需的环境,支持和信任
- 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面交谈.
- 衡量进展的重要尺度是可运行的软件
- 发起人,开发者和用户应该步调一致
- 不断地关注技术上优越的设计会提高敏捷性
- 简洁是最重要的,简洁就是尽量减少工作量的艺术
- 最佳的架构,需求和设计来自自组织的团队
- 团队要定期反省如何使工作更有效,然后相应的调整行为
项目人员
- 产品经理 & 实施工程师
- 与业务部门沟通,收集整理需求,编写说明文档及原型
- 调研竞品/近品,持续改进产品设计
- 与研发小组其他人员沟通,确保大家充分理解需求
- 确定需求的重要性和优先级,商定研发计划并进行上线验收
- 培训用户并收集反馈意见,优化用户体验
- 研发经理
- 确定技术框架(必要时进行培训学习)
- 确定研发计划并尽量让项目按计划进行
- 选择项目组人员组成并进行合理分工
- 掌握项目具体执行进度并对项目质量,风险进行控制
- 研发工程师
- 充分理解产品经理的需求说明和技术框架
- 按计划完成工作,对负责的项目进行设计,编码,单元测试和文档说明等维护
- 及时响应测试工程师的反馈,确保软件质量
- 测试工程师
- 充分理解产品经理的需求说明
- 制定测试计划,设计测试用例
- 准确的定位并跟踪软件中的问题,推动问题及时合理解决
- 编写测试报告
- 运维工程师 & DBA
- 负责运行环境的维护,保证各系统稳定
- 响应发版请求
- 对数据库进行监控,对数据库设计进行评审和改进
- 对数据进行备份和修改,确保数据安全,正确
- UI工程师
- 充分理解产品经理的需求说明,重建各个用户操作的场景
- 负责对软件从界面风格,操作流程,交互体验等进行改进
- 负责对改进后的页面进行验收
项目流程
开发过程
先写设计
再写代码
最后文档
总体流程
1 项目立项
2.项目启动
3.需求整理
4.业务建模
5.架构设计
6.开发实现
7.测试
8.环境搭建
9.部署上线
10,用户培训
注意,对于采用Scrum方式的开发而言,上面的部分流程会反复执行
评审
在软件开发的各个阶段根据重要性都可以进行评审,不必在软件开发完毕后进行评审.
评审目标
- 发现软件功能,逻辑或实现方面的错误
- 保证代码与需求文档,代码与设计说明文档等各种文件的一致
- 使得代码,文档以一种更容易理解的方式呈现
评审准则
- 评审产品,而不是评审设计者
- 限制会议人数并坚持做准备工作
- 建立议事日程并维护,不能脱离主题
- 尽量使用评审清单,帮助评审人员思考,避免遗漏
- 展示记录,随时写在白板上
- 限制争论,主要是发现问题而不是解决问题
- 对评审进行评审,持续改进
评审过程
1.召集评审会议,确定评审范围.参与人员不宜过多,时长不宜操作两个小时
2.进行评审,结束时必须做出以下几种决策之一:
- 接受,无需修改
- 暂时接受
- 无法接受,需要修改
3.评审记录,对于评审中的问题进行记录,包括最终决策及其理由,以及保留意见.
源码,SQL,文档
1.产品所有源码,数据库的DDL,文档都需上传到版本控制软件,进行统一管理
2.产品经理应对源码进行评审或安排他人进行评审,保证代码质量
3.DBA应对SQL语句进行评审,结合数据库情况对SQL提出改进意见,保证系统的高效运行
SRACEY矩阵
- 预测型
- 迭代型
- 增量型
- 敏捷型
迭代是逐渐变好(画画)
增量是逐渐变多(印刷)
其他差异可以参见
https://www.zhihu.com/tardis/bd/art/398196682?source_id=1001