持续更新…
禅道项目管理
- 1. 项目和项目管理
- 2. 研发项目管理-瀑布和敏捷
- 2.1 瀑布模型
- 2.2 敏捷开发模型
- 2.2.1 敏捷价值观
- 2.2.2 极限编程价值、原则、实践
- 2.2.3 Scrum迭代式增量软件开发过程
- 3. 禅道项目管理
- 3.1 引出禅道
- 3.2 禅道定位
- 3.3 禅道管理软件使用流程
- 3.3.1 禅道和SCRUM的对应关系
- 3.3.2 研发项目的三个核心的角色（产品经理，研发团队，测试团队）
- 3.3.3 禅道四个基本要素（Story，Task，Case，Bug）
- 3.3.4 禅道基本流程
- 4. 禅道的使用-第一个演示项目
- 4.1 添加用户
- 4.2 创建产品
- 4.3 创建需求
- 4.4 创建项目、关联产品、设置团队
- 4.5 关联需求
- 4.6 分解任务
- 4.7 创建bug
- 4.8 提交测试
- 4.9 创建发布
- 5. 禅道的使用-测试团队篇
1. 项目和项目管理
项目：在既定的资源和要求的约束下，为实现某种目的而相互联系的一次性工作任务（一些人在一定的时间内完成一些事情）。
项目管理：把各种系统、方法和人员结合在一起，在规定的时间，预算和质量目标范围内完成项目的各项工作（多快好省的完成项目）。
项目的特征：
1）明确的目标
2）独特性
3）资源成本的约束性
4）项目实施的一次性
5）项目的不确定性
6）特定的委托人
7）结果的不可逆转性
研发项目常见的问题：
1）产品：有些公司产品经理的工具往往交给了项目经理，但是这样是不对的，产品经理和项目经理所分析问题的角度往往是不同的，产品经理往往会站在客户的角度考虑问题，而项目经理则希望项目能够少点改动…
2）项目管理：项目经理往往是技术岗位晋升，懂技术，但不一定懂管理；缺少系统的管理理论和方法，主要靠经验和人治；对项目的评估偏乐观，需求分析，任务分解不够细致，项目周期过长等…
3）研发：缺少统一的编码规范，或形同虚设；结构混乱，架构不合理，系统不灵活；滥用全局变量；没有良好的注释习惯；变量命名随意，含义不明，中英混杂等；缺少安全和性能意识；没有测试意识，代码质量无法保证；跟风时髦的技术或者框架，遇到问题无法解决…
4）测试：项目前期无法开展测试，测试人员只能等；研发无法按期交付，压缩测试时间，牺牲测试质量；没有很好的bug管理规范和系统；缺少压力测试，真正上线发现问题比较严重；缺少安全测试，一旦出现问题影响严重；不做版本控制，混乱的代码库和开发环境…
5）沟通…
6）战略和组织…
2. 研发项目管理-瀑布和敏捷
研发项目管理常见的方法：瀑布，敏捷。
研发项目管理：
1）对软件研发过程的管理称之为研发项目管理
2）早期的研发项目管理大量借鉴了工程项目管理的方法，其中瀑布式开发是最为主流的管理方式。
2.1 瀑布模型
早期的瀑布式开发的生存场景：
1）军工国防，基础软件居多，对软件的品质要求严格
2）软件以物理介质发行为主要途径
3）软件售出后升级，修复成本较高
4）行业竞争节奏相对平缓
后来场景发生了变化：
1）互联网逐渐兴起，B/S架构的应用成为主流
2）软件的交付手段发生了重大变化：在线更新，网络下载
3）各种各样的应用软件蓬勃发展（需求无限大）
4）竞争速度越来越快
那么瀑布式开发的缺点也日益突出：
1）响应周期长，客户在项目开发的末期才能见到开发的成果
2）软件越来越复杂，早期的需求分析和设计难以保证正确
3）最终结果和预期的结果往往有很大的偏差
4）难以形成整个公司的节奏
2.2 敏捷开发模型
如何看待敏捷开发？
1）敏捷开发不是银弹，敏捷项目的失败率也一直居高不下，不管喜欢与否，迭代开发已成为主流。
2）敏捷的目的是为了快速交付有价值和质量的产品服务
3）xp，scrum，tdd，ci等等这些都是手段，手段不是目的，很多争论都是停留在手段上的争论。
4）敏捷的产生有其文化背景，在国内实施也要因地制宜。
实用主义者的项目管理：
1）着眼与解决问题，而非采取何种手段
2）根据自身实际情况找到合适的方法和节奏
3）辅助以必要的工具支持
4）持续改进遇到的问题
2.2.1 敏捷价值观
为了解决早期的开发模式的问题，在2001年提出了敏捷宣言：
敏捷价值观-交付：
1）尽早且持续地交付有价值的软件来满足客户；
2）随时对需求提出变更，即使在项目的后期；
3）不断交付可用的软件，周期越短越好（1-4周）；
4）可用的软件是衡量进度的主要指标；
5）倡导可持续的开发，形成开发，销售和客户稳定的节奏；
敏捷价值观-沟通：
1）业务人员与开发人员一起工作；
2）激励项目团队，给他们以所需要的资源，并信任他们；
3）最有效的沟通方式是面对面的交谈；
敏捷价值观-团队：
1）团队的敏捷性依赖于对技术、过程和架构持续的改进；
2）保持简洁，尽最大可能减少不必要的工作；
3）最佳的架构，需求和设计出自于组织的团队；
4）定期反省总结如何改进研发过程，并制定具体计划改进；
2.2.2 极限编程价值、原则、实践
极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性能性以及面临的困难。
极限编程价值标准：
1）沟通：团队成员，面对面沟通，从需求到编码一起努力；
2）简单：聚焦于当下需求，不做过多的设计，通过重构应对将来变化；
3）反馈：系统反馈（单元测试），客户反馈，团队反馈；
4）勇气：真实面对工时和进度，无惧失败，无惧将来变化；
5）尊重：尊重他人，提交可测试通过的代码，通过重构获得高质量的代码；
极限编程原则：
快速反馈：系统反馈，客户反馈，团队反馈；
假设简单：简单设计，聚焦当下；
增量前进：小步快跑，快速迭代；
包容变化：拥抱变化，积极应对；
极限编程规则：
1）计划：用户故事，发布计划，小型发布，迭代开发
2）管理：开发空间，可持续节奏，站立会议，评估速率，角色互换
3）设计：简单设计，隐喻，原型，莫过早加入功能，重构
4）编码：现场客户，规范，单元测试，结对编程，持续集成，集体所有
5）测试：单元测试覆盖，发布前测试通过，bug先创建测试。
极限编程实践：
反馈：
1）结对编程（两个人一起编程工作）：质量，减少犯错，集体所有；
2）计划游戏：用户故事，优先级排序；
3）测试驱动开发：测试代码先行；
4）客户加入团队；
持续改进：
1）持续集成：单元测试，持续集成服务器；
2）重构：非重写，每时每刻都应该进行；
3）小版本发布：小步快跑；
共识：
1）编码规范：团队的共识，尊重，集体所有的基础；
2）集体所有权：消除单点，知识传播；
3）简单设计：参考unix设计哲学；
4）隐喻：意会，好的命名；
程序员福利：
可持续的节奏，中国程序员的创新很少，加班的习惯对于程序员来说没有益处，只会消磨程序员的热情。
编码：
1）随时和客户沟通
2）单元测试优先
3）串行集成
4）延迟优化
5）莫加班
测试：
1）单元测试完全覆盖
2）发布前单元测试全通过
3）发现bug后先写测试用例
4）定期执行验收测试并公布结果
2.2.3 Scrum迭代式增量软件开发过程
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
"接力赛"式的产品开发模式一定程度上违背了以人为本，最大化生产力，灵活的生产方式的原则。
相反，“橄榄球”式的产品开发模式，是整个团队无间合作，灵活机动的处理接球，传球，并像一个整体迅速突破防线。
SCRUM精要（SCRUM能给我们带来什么？）
1）SCRUM聚焦于如何在最短的时间内交付最有价值的产品；
2）SCRUM能让团队快速且经常地监督产品的进展（2到4周）；
3）每隔2到4周，就可看到上线的产品，并据此作出调整；
4）团队按照商业价值的高低，优先完成高优先级的功能；
5）团队实施自主管理，持续改进团队内部流程，提高效率。
SCRUM特点：
1）团队实施自我管理
2）产品开发以Sprint为单位进行迭代
3）使用产品backlog记录产品需求
4）并没有特定的工程实践
5）自适应的规则
6）SCRUM是一种敏捷方法
7）SCRUM对需求，设计，代码，测试这些流程采用并行的方式
8）要确保迭代进行中不受影响（即一个迭代周期的长短的设定取决于能够保障多长时间需求变化不影响到产品开发）
SPRINT周期
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）保护团队不受到外来无端影响
…
3. 禅道项目管理
3.1 引出禅道
Scrum + xp + zentao:
1）Scrum偏重宏观管理
2）明确界定了什么角色在什么阶段要做什么事情
3）极限编程偏重于工程实践
4）二者可以互相结合（Scrum+极限编程）
5）再结合禅道作为工具支撑
一些工具：
SharePoint：需求管理工具+流程管理工具
Bugfree：缺陷跟踪管理软件
XPlanner：项目和任务跟踪管理工具
使用上述的软件产生的问题：
1）信息靠手工在各系统中关联，重复劳动
2）流程靠自觉来执行，N多的检查点，繁琐
3）形似Scrum，但是实际上感受不到持续改进的快乐
于是为了改进这些问题，禅道在2007着手准备，2009年0.01版本，中间发布了很多版本，至今—
3.2 禅道定位
1）禅道的定位是研发项目管理；
2）囊括了产品、项目、测试、计划、发布、文档等功能；
3）完整覆盖了整个软件研发的过程；
4）可以辅助团队实施敏捷开发；
5）定位严谨的项目管理；
6）开源软件，用户可以私有部署并进行二次开发；
7）scrum作为管理框架，开发采用极限编程，而禅道作为工具。
3.3 禅道管理软件使用流程
3.3.1 禅道和SCRUM的对应关系
SCRUM | 禅道 |
product | 产品 |
user story | 需求 |
sprint | 项目 |
task | 任务 |
burndown | 燃尽图 |
交付物 | 发布 |
product owner | 产品经理 |
scrum master | 项目经理 |
team | 项目团队 |
3.3.2 研发项目的三个核心的角色（产品经理，研发团队，测试团队）
3.3.3 禅道四个基本要素（Story，Task，Case，Bug）
3.3.4 禅道基本流程
但这个流程不在禅道中设计。
禅道项目管理流程（简洁）：
禅道项目管理流程全图：
4. 禅道的使用-第一个演示项目
禅道开源版windows x64安装
禅道官网 这里我下载了开源版Windows x64
双击执行文件
重点来了，抽取的路径选择一定不要有空格，不要有中文，不要有什么特殊字符，只能字母，数字，下划线组成。进入抽取完成后的目录，将start.exe发送到桌面快捷方式，重命名为“禅道”
双击禅道
点击更改，这里我把密码改成了123456，点击确定
（这里最好不要像我这样图省事设置弱密码，除非你跟我一样只是为了练习和熟悉禅道）
点击<启动禅道>
点击<访问禅道>
输入用户名和密码，点击<登陆>
点击<开源版>
设置用户名admin，密码123456，点击<登录>
但我这里设置的是弱密码，需要重新设置密码HyhRoseWind选择合适的公司的流程，点击<保存>
正式进入禅道
4.1 添加用户
禅道>组织>添加用户
在禅道中决定用户权限的是分组
eg:
这里我无论添加什么用户，密码统一与admin一致（学习期间省事）
添加一位产品经理Perry
添加一位项目经理Lucia
添加一位测试主管Helen
添加一位研发人员Ulysses
添加一位测试人员Samira
4.2 创建产品
一般由产品经理创建
禅道>产品>产品主页
点击<添加产品>
填写信息后，点击<保存>
产品就创建出来了
4.3 创建需求
为产品提需求
禅道>产品>新生寝室自选系统—管理员端>需求列表
添加一个管理员登陆的需求，点击<保存>
点击<评审>
评审结果选择<确认通过>，点击<保存>
该需求的状态变为了"激活"
4.4 创建项目、关联产品、设置团队
项目一般由项目经理创建
禅道>迭代>迭代主页
添加一个迭代-第一期，点击<保存>
选择<设置团队>
点击<团队管理>
设置团队完成后，点击<保存>
一般项目创建完毕后，团队成员会开会，产品经理会讲解需求…
4.5 关联需求
禅道>迭代>新生寝室自选系统—管理员端（第一期）>需求列表
选定要关联的需求，点击<保存>
选定需求，点击<编辑>，进入批量编辑
团队可以一起评估需求的优先级（p），工时等，设置完毕后，点击<保存>
4.6 分解任务
确定项目的关联需求后，我们可以详细地对某个需求分解任务（即我们可以把每个需求都拆分成详细的任务）
设置完任务和任务类型后，点击<保存>
我们发现T变成了3，即表示我们将该需求拆分成3个任务
然后，我们进入禅道>迭代>新生寝室自选系统—管理员端（第一期）>任务列表
发现多了3条任务，我们可以对这些任务进行指派等操作
选定要批量编辑的任务，点击<编辑>
填写完毕后，点击<保存>
查看团队
禅道>迭代>新生寝室自选系统—管理员端（第一期）>团队成员
查看项目概况
禅道>迭代>新生寝室自选系统—管理员端（第一期）>迭代概况
对于开发人员比如Ulysses
进入迭代>任务
进入指派给自己的任务
对于还没有开始的任务，点击<开始>，可以设置
对于正在进行中的任务，点击<工时>，可以设置
可以设置每天的工时，备注等
如果该开发的任务完成了，可以点击<完成>
4.7 创建bug
对于测试人员
禅道>测试>新生寝室自选系统—管理员端>用例
点击<建用例>
设计完一个功能测试用例后，点击保存
当然这里的创建人应该是测试人员，我这里还是图省事啊
我们也可以使用批量添加用例
4.8 提交测试
假设开发人员已经完成了一个阶段的功能，这时候开发人员就可以去提交一个版本
禅道>迭代>新生寝室自选系统—管理员端（第一期）>创建版本
填写版本信息后，点击<保存>
选择要关联的需求，点击<关联需求>
其实就是告诉测试人员，该版本实现了哪些功能
禅道>迭代>新生寝室自选系统—管理员端（第一期）>所有版本
将该版本提交测试
填写完信息之后，点击<保存>
待测的版本
这时测试经理拿到这个测试版本后，可以关联测试用例
这时可以指派测试用例给测试人员
比如此时我的角色是Samira（测试人员），我就可以执行指派给我的测试用例
可以直接将失败的用例转bug
填写完bug信息后，点击<保存>
如果此时我是开发人员Ulysses，这时我们可以去修复bug
如果一个公司没有那么严格的版本迭代，我们的<解决版本>可以选择<主干>，否则就选择解决的具体版本。
这时测试人员就要验证该bug是否被修复完成，如果修复完成就将它关闭
如果没有修复完成，bug依然存在，就激活bug，再次指派给开发人员
这时开发人员再次修复bug，测试人员验证bug真正修复完成后，关闭bug。
4.9 创建发布
假设最近一个版本通过了测试，稳定，执行可交付了
假设此时的角色是产品经理，就可以发布稳定，可执行的版本
禅道>产品>产品主页
5. 禅道的使用-测试团队篇
测试人员要做的事情：
1）参加计划会议，积极发言，做到对需求的充分了解
2）维护bug视图和用例视图的模块
3）开发人员编码的时候，撰写测试用例
4）收到测试申请后，确定测试范畴，组织测试用例
5）执行测试，提交bug
6）验收bug，解决的bug要关闭，而未解决的要重新激活
7）参加演示和总结会议
禅道中的bug:
bug状态：激活中，已解决，已关闭。
bug的解决方案：已解决，延期，重复，外部原因，无法重现，不予解决，设计如此。（其中"已解决"和"延期"为有效bug）
