发布时间:2025-12-10 11:44:31 浏览次数:4
持续更新…
项目:在既定的资源和要求的约束下,为实现某种目的而相互联系的一次性工作任务(一些人在一定的时间内完成一些事情)。
项目管理:把各种系统、方法和人员结合在一起,在规定的时间,预算和质量目标范围内完成项目的各项工作(多快好省的完成项目)。
项目的特征:
1)明确的目标
2)独特性
3)资源成本的约束性
4)项目实施的一次性
5)项目的不确定性
6)特定的委托人
7)结果的不可逆转性
研发项目常见的问题:
1)产品:有些公司产品经理的工具往往交给了项目经理,但是这样是不对的,产品经理和项目经理所分析问题的角度往往是不同的,产品经理往往会站在客户的角度考虑问题,而项目经理则希望项目能够少点改动…
2)项目管理:项目经理往往是技术岗位晋升,懂技术,但不一定懂管理;缺少系统的管理理论和方法,主要靠经验和人治;对项目的评估偏乐观,需求分析,任务分解不够细致,项目周期过长等…
3)研发:缺少统一的编码规范,或形同虚设;结构混乱,架构不合理,系统不灵活;滥用全局变量;没有良好的注释习惯;变量命名随意,含义不明,中英混杂等;缺少安全和性能意识;没有测试意识,代码质量无法保证;跟风时髦的技术或者框架,遇到问题无法解决…
4)测试:项目前期无法开展测试,测试人员只能等;研发无法按期交付,压缩测试时间,牺牲测试质量;没有很好的bug管理规范和系统;缺少压力测试,真正上线发现问题比较严重;缺少安全测试,一旦出现问题影响严重;不做版本控制,混乱的代码库和开发环境…
5)沟通…
6)战略和组织…
研发项目管理常见的方法:瀑布,敏捷。
研发项目管理:
1)对软件研发过程的管理称之为研发项目管理
2)早期的研发项目管理大量借鉴了工程项目管理的方法,其中瀑布式开发是最为主流的管理方式。
Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心,找到正确的Sprint周期将帮助敏捷团队交付更高质量的产品。
1)SCRUM项目周期以一组迭代周期“sprints”组成;
2)可以和极限开发的迭代周期类比;
3)典型的迭代周期为2-4周或者最多一个自然月;
4)一个固定的周期能够创造出项目的更优美的节奏感;
5)产品的设计,开发,测试全部都在一个迭代内完成。
SCRUM结构框架
| Product owner Scrum master Team | 计划会议 站立会议 演示会议 总结会议 | 产品backlog 迭代backlog 燃尽图 潜在交付物 |
Product owner(产品所有者):
1)定义所有产品功能
2)决定产品发布内容以及日期
3)对产品的投入产出负责
4)根据市场变化对需要开发的功能排列优先顺序
5)合理的调整产品功能和迭代顺序
6)认同或者拒绝迭代的交付
SCRUM MASTER:
1)对项目直接管理
2)领导团队完成SCRUM的实践以及体现其价值
3)排除团队遇到的困难
4)保证团队的效率和状态
5)做好团队的协作和沟通工作,跨角色跨功能协作无障碍
6)保护团队不受到外来无端影响
…
Scrum + xp + zentao:
1)Scrum偏重宏观管理
2)明确界定了什么角色在什么阶段要做什么事情
3)极限编程偏重于工程实践
4)二者可以互相结合(Scrum+极限编程)
5)再结合禅道作为工具支撑
一些工具:
SharePoint:需求管理工具+流程管理工具
Bugfree:缺陷跟踪管理软件
XPlanner:项目和任务跟踪管理工具
使用上述的软件产生的问题:
1)信息靠手工在各系统中关联,重复劳动
2)流程靠自觉来执行,N多的检查点,繁琐
3)形似Scrum,但是实际上感受不到持续改进的快乐
于是为了改进这些问题,禅道在2007着手准备,2009年0.01版本,中间发布了很多版本,至今—
1)禅道的定位是研发项目管理;
2)囊括了产品、项目、测试、计划、发布、文档等功能;
3)完整覆盖了整个软件研发的过程;
4)可以辅助团队实施敏捷开发;
5)定位严谨的项目管理;
6)开源软件,用户可以私有部署并进行二次开发;
7)scrum作为管理框架,开发采用极限编程,而禅道作为工具。
| product | 产品 |
| user story | 需求 |
| sprint | 项目 |
| task | 任务 |
| burndown | 燃尽图 |
| 交付物 | 发布 |
| product owner | 产品经理 |
| scrum master | 项目经理 |
| team | 项目团队 |
但这个流程不在禅道中设计。
禅道项目管理流程(简洁):
禅道项目管理流程全图:
禅道开源版windows x64安装
禅道官网
这里我下载了开源版Windows x64
双击执行文件
重点来了,抽取的路径选择一定不要有空格,不要有中文,不要有什么特殊字符,只能字母,数字,下划线组成。
进入抽取完成后的目录,将start.exe发送到桌面快捷方式,重命名为“禅道”
双击禅道
点击更改,这里我把密码改成了123456,点击确定
(这里最好不要像我这样图省事设置弱密码,除非你跟我一样只是为了练习和熟悉禅道)
点击<启动禅道>
点击<访问禅道>
输入用户名和密码,点击<登陆>
点击<开源版>
设置用户名admin,密码123456,点击<登录>
但我这里设置的是弱密码,需要重新设置密码HyhRoseWind
选择合适的公司的流程,点击<保存>
正式进入禅道
禅道>组织>添加用户
在禅道中决定用户权限的是分组
eg:
这里我无论添加什么用户,密码统一与admin一致(学习期间省事)
添加一位产品经理Perry
添加一位项目经理Lucia
添加一位测试主管Helen
添加一位研发人员Ulysses
添加一位测试人员Samira
一般由产品经理创建
禅道>产品>产品主页
点击<添加产品>
填写信息后,点击<保存>
产品就创建出来了
为产品提需求
禅道>产品>新生寝室自选系统—管理员端>需求列表
添加一个管理员登陆的需求,点击<保存>
点击<评审>
评审结果选择<确认通过>,点击<保存>
该需求的状态变为了"激活"
项目一般由项目经理创建
禅道>迭代>迭代主页
添加一个迭代-第一期,点击<保存>
选择<设置团队>
点击<团队管理>
设置团队完成后,点击<保存>
一般项目创建完毕后,团队成员会开会,产品经理会讲解需求…
禅道>迭代>新生寝室自选系统—管理员端(第一期)>需求列表
选定要关联的需求,点击<保存>
选定需求,点击<编辑>,进入批量编辑
团队可以一起评估需求的优先级(p),工时等,设置完毕后,点击<保存>
确定项目的关联需求后,我们可以详细地对某个需求分解任务(即我们可以把每个需求都拆分成详细的任务)
设置完任务和任务类型后,点击<保存>
我们发现T变成了3,即表示我们将该需求拆分成3个任务
然后,我们进入禅道>迭代>新生寝室自选系统—管理员端(第一期)>任务列表
发现多了3条任务,我们可以对这些任务进行指派等操作
选定要批量编辑的任务,点击<编辑>
填写完毕后,点击<保存>
查看团队
禅道>迭代>新生寝室自选系统—管理员端(第一期)>团队成员
查看项目概况
禅道>迭代>新生寝室自选系统—管理员端(第一期)>迭代概况
对于开发人员比如Ulysses
进入迭代>任务
进入指派给自己的任务
对于还没有开始的任务,点击<开始>,可以设置
对于正在进行中的任务,点击<工时>,可以设置
可以设置每天的工时,备注等
如果该开发的任务完成了,可以点击<完成>
对于测试人员
禅道>测试>新生寝室自选系统—管理员端>用例
点击<建用例>
设计完一个功能测试用例后,点击保存
当然这里的创建人应该是测试人员,我这里还是图省事啊
我们也可以使用批量添加用例
假设开发人员已经完成了一个阶段的功能,这时候开发人员就可以去提交一个版本
禅道>迭代>新生寝室自选系统—管理员端(第一期)>创建版本
填写版本信息后,点击<保存>
选择要关联的需求,点击<关联需求>
其实就是告诉测试人员,该版本实现了哪些功能
禅道>迭代>新生寝室自选系统—管理员端(第一期)>所有版本
将该版本提交测试
填写完信息之后,点击<保存>
待测的版本
这时测试经理拿到这个测试版本后,可以关联测试用例
这时可以指派测试用例给测试人员
比如此时我的角色是Samira(测试人员),我就可以执行指派给我的测试用例
可以直接将失败的用例转bug
填写完bug信息后,点击<保存>
如果此时我是开发人员Ulysses,这时我们可以去修复bug
如果一个公司没有那么严格的版本迭代,我们的<解决版本>可以选择<主干>,否则就选择解决的具体版本。
这时测试人员就要验证该bug是否被修复完成,如果修复完成就将它关闭
如果没有修复完成,bug依然存在,就激活bug,再次指派给开发人员
这时开发人员再次修复bug,测试人员验证bug真正修复完成后,关闭bug。
假设最近一个版本通过了测试,稳定,执行可交付了
假设此时的角色是产品经理,就可以发布稳定,可执行的版本
禅道>产品>产品主页
测试人员要做的事情:
1)参加计划会议,积极发言,做到对需求的充分了解
2)维护bug视图和用例视图的模块
3)开发人员编码的时候,撰写测试用例
4)收到测试申请后,确定测试范畴,组织测试用例
5)执行测试,提交bug
6)验收bug,解决的bug要关闭,而未解决的要重新激活
7)参加演示和总结会议
禅道中的bug:
bug状态:激活中,已解决,已关闭。
bug的解决方案:已解决,延期,重复,外部原因,无法重现,不予解决,设计如此。(其中"已解决"和"延期"为有效bug)