这篇文章并不欠缺，更多的是在团队初期总结的一些疾速执行的思路和流程和一些规定。
对于麻利开发
什么是麻利
麻利的外围是迭代：
咱们的研发流程应用麻利开发的Scrum形式，绝对传统的瀑布模型和其余的麻利形式来说，更加合乎咱们的现状：
- 迭代开发
- 增量交付
- 自组织团队
- 高优先级的需要驱动
同时咱们的研发流程也并非标准化的Scrum，联合了本身企业的特点以及团队的特点，做到更合乎咱们理论状况的一套流程。
以下是麻利开发的价值观：
- 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
- 软件可能运行，优于详尽的文档。
- 跟客户的密切协作，优于合同和会谈。
- 可能响应变动，优于遵循打算。
以下是麻利开发的十二条准则：
- 通过晚期和继续交付有价值的软件，实现客户满意度。
- 欢送一直变动的需要，即便是在我的项目开发的前期。要长于利用需要变更，帮忙客户取得竞争劣势。
- 一直交付可用的软件，周期通常是几周，越短越好。
- 我的项目过程中，业务人员与开发人员必须在一起工作。
- 我的项目必须围绕那些有外在能源的集体而建设，他们应该受到信赖。
- 面对面交谈是最好的沟通形式。
- 可用性是掂量进度的次要指标。
- 提倡可继续的开发，保持稳定的停顿速度。
- 一直关注技术是否优良，设计是否良好。
- 简略性至关重要，尽最大可能缩小不必要的工作。
- 最好的架构、要求和设计，来自团队外部自发的意识。
- 团队要定期反思如何更无效，并相应地进行调整。
麻利开发要求
- 高水平的代码品质和人员素质
- 高水平的自动化测试
- 高水平的配置管理（代码版本、利用、环境）
- 继续集成、继续交付、继续部署
团队划分
咱们的团队划分为物理团队和麻利团队：
物理团队：UI团队、Android团队、IOS团队、FE团队、Java团队、QA团队、产品团队
- 领有一个团队负责人
- 代码库、配置库、知识库等追随物理团队
- 人员归属于物理团队
麻利团队：
- 跨职能，包含UI、前端、后端开发人员、QA
- 能够根据我的项目而建，也能够根据需要周期而建
角色：
- Power Owner(PO)：我的项目负责人，最好有技术背景
- Dev Team(DT)：开发团队
研发流程
对于研发阶段的根本要求有：
- 团队是平级的。
- 所有必要产出必须进入知识库治理。
- 所有人员必须严格应用项目管理工具jira，继续跟踪属于本人的工作状态。
- 当某个阶段PO不太善于的时候，须要由物理部门负责人提供反对。
- 物理团队须要对我的项目团队进行撑持。
- 所有研发事宜必须恪守各个物理团队的标准规范，物理团队负责人校验产出。
需要
当确定须要做的时候，进入需要阶段，需要阶段分以下步骤：
需要收集
- 确定PO。
- PO向需要起源方收集需要，起源方可能是产品也可能间接是客户
需要剖析
- 参与者：PO、需要剖析人员（目前根本是各物理团队负责人）、UI、QA、产品
头脑风暴：PO组织需要剖析会，对需要进行剖析、合成、提出问题并解决问题、确认需要各个细节。
- 需要剖析会可能屡次，直到再无对于需要的疑难。
- 需要剖析会是平等的，不是命令的模式，否则会限度头脑风暴的成果。
- 需要剖析人员须要较高的业务理解力和参与度，尽量放大会议的范畴，防止所有人都参加的低效的形式。
对于需要的边界
- 若需要较大，对于需要是否分阶段进行以及每阶段需要边界必须确定，当需要周期超过4周必须分阶段。
若需要不分阶段
- 当周期超过两周时，PO有权在开发流程进行分期，即多个冲刺，保障继续产出。
若需要分阶段
- 各阶段需要必须明确，若有阶段需要不明确，不该当划入本次的需要剖析。每个需要阶段针对麻利开发中的一个Epic(史诗)。
- 接下来的研发过程仅针对以后的需要阶段开始。后续需要阶段间接从开发流程开始周期。
产出：
- 历次会议纪要，归档知识库
- 需要周期以及需要边界
需要定稿
- Jira和Confluence初始化我的项目
- PO编写需要文档
- UI设计原型
产出：
需要文档
若需要分阶段
- 需针对每个Epic建设需要文档
- 需要文档以矩阵形式，明确Epic下 User story（用户故事，相当于功能模块的概念）的列表，防止像传统形式的需要文档一样简短，只需简略形容性能（在麻利的短周期下，每个User story并不会太简单）。
UI设计原型
- UI设计以后Epic的原型
- 若需要分阶段，并且各阶段需要明确，UI必须在下一个阶段的开发环节前，提交相应Epic的原型。
需要外部评审
- 参与者：PO、需要剖析人员（目前根本是各物理团队负责人）、UI、QA、产品
- 依据需要文档和UI设计原型确认需要是否合乎预期。若有需要变更以及不迭预期处，及时调整。
需要内部确认
- 和业务部门确定需要
- 业务部门签字
需要合成
PO需对需要进行合成，依照：
- Epic（史诗）
- User story（用户故事）
- Task（工作）
- Sub-Task
的层级来合成需要，保障到DT团队人员身上曾经是很细的开发工作。
- PO须要在Jira上录入Backlog。
- 若PO没有技术背景，可由物理团队负责人帮助。
组建DT团队
- PO须要和物理团队负责人进行沟通，协调人员。
- 物理团队负责人须要依据需要的优先级、团队成员的能力、现有工作量、和需要的匹配度进行判断和合理安排。
PO须要和DT进行首次的沟通，明确：
- 团队做什么？
- 什么时候要做好？
- 谁来做？
物理团队负责人也须要参加沟通，进行帮助和倡议。
设计
API接口设计
- 依据UI原型设计前后台数据交互接口。
- 若PO没有技术背景，须要物理团队负责人帮助。
数据结构设计
- 物理团队负责人设计数据结构，交付开发团队。（数据结构比拟非凡，应防止不同的人来设计）。
业务流程/交互设计
- PO依据需要文档对于一些外围的、简单的业务须要设计好流程和前端交互。
- 若PO没有技术背景，须要物理团队负责人帮助。
零碎设计
- 零碎设计由物理团队负责人执行
评估此次需要对于现有线上零碎的影响
- 是否须要其余服务的反对
- 是否须要改变现有架构
- 是否导致现有服务须要进行扩大
设计解决方案
- 若波及较小，物理团队负责人间接安顿人员解决。
- 若波及交广，包含了前后台，各物理团队负责人协商计划，各自安顿人员解决。
- Jira新建User story和Task，归属于以后我的项目需要。
- 安顿人员不属于以后我的项目团队。
高效沟通
PO和DT必须建设高效的沟通
- DT对于需要的疑难
- PO对于需要的设计目标
- 物理团队负责人随时对团队进行帮助和反对。
产出：
- API接口文档
- PDM数据结构文件、数据库降级脚本
开发
- 物理团队负责人初始化相应的代码库、配置库、权限等开发前置条件。
PO在Jira上建设对应的冲刺阶段，并对冲刺的品质富裕监督责任。
- PO需依据理论状况管制开发进度，调整人员工作
- PO与DT须要保障高效的日常沟通
- 物理团队负责人须要对提交代码进行审查
每日站会
- 我明天做了什么
- 我今天打算做什么
- 我遇到了什么问题
内部测试
- DT成员在实现本人的某个性能后必须进行测试，保障性能可用
- PO须要对每日产出做根本的功能测试
提交测试部门
- PO有权决定是否依照每日或者某几个已实现工作来局部提测版本，来调整个冲刺的的工夫（例如开发慢了）。
- 物理团队负责人审查代码并建设测试版本，筹备好降级脚本（sql、配置等）。PO与测试部门沟通该版本涵盖内容（Jira上工作号），并告知测试版本号。
产出：
- 可测试版本
- 降级脚本
- 部署阐明（能够与测试沟通解决）
回归
- 若局部提测，测试周期和开发周期重叠时，DT优先批改缺点，再做新工作。
对于DT
- DT必须实时更改Jira上本人工作的状态。
- DT必须严格依照所属物理来源gaodaimacom搞#^代%!码网部门的代码标准编写。
- DT实时反映本人的疑难和问题，业务问题PO负责，技术问题由各物理团队负责人负责或者与团队其余成员探讨。
对于冲刺失败
- 若冲刺工夫截止，工作没有实现，则冲刺失败。
- 冲刺失败时，优先持续实现工作，PO预估残余实现工夫，开启新冲刺，把未实现工作拉进新冲刺里。
- 对于PO和DT的责任，将在评估会上进行具体探讨。
测试
- 开发和测试的连结次要是提测和回归，通过规范的测试版本号和Jira工具互动。
部署/评估
部署
- 测试部门批准上线，约定上线工夫
- 物理团队负责人在代码库建设上线tag版本，筹备好部署阐明和相干脚本配置等必备条件
上线
- 参加人员：PO、物理团队负责人、QA
- 物理团队负责人负责上线
- 筹备好上线失败的回退计划
- 上线后QA做线上测试，确定没有问题，上线胜利
- 物理部门负责人须要保护上线列表，包含预计上线工夫、范畴、影响等，不便版本治理，防止造成上线凌乱，前后台不对立。
评估
PO须要在上线胜利后，组织团队进行冲刺回顾
- 物理团队负责人、QA须要加入
- 剖析冲刺中做的好的局部和不好的局部，总结经验
- 若冲刺失败，探讨失败起因。
PO须要编写冲刺回顾文档
- 记录回顾会议的明细。
- 总结评估DT团队人员，代码品质差、缺点数量多的人员须要扣分，好的须要加分，联合工作量、体现等作为我的项目激励发放的规范。
- 若冲刺是失败的，须要剖析起因，若为内部起因导致，也需阐明。
日常保护
线上问题
- 由PO和物理团队负责人一起解决
快速通道
针对优先级十分高、需要迫切或者影响比拟大的需要走快速通道。
现有我的项目需要变更或者新增小需要
- PO和物理团队负责人协商，安顿人员。
疾速流程为：
- 设计
- 开发
- 迭代测试
- 部署
相干产物为
- API接口
- Jira的Task
- 缺点记录
- 部署须要的配置脚本、可上线包
新的需要迫切的大块需要
人员够的状况下失常走研发流程
- 测试采纳局部提测的迭代测试。
人员不够的状况下
- 研发分管领导确认需要优先级
- 解冻正在进行的优先级较低的冲刺
- 确定本需要PO， 间接进入需要阶段。
- 若人员量级不够，尽可能不解冻更多的正在进行的冲刺，抽调人员进入需要，被抽调人员的冲刺延期。
- 测试采纳局部提测的迭代测试。
日常治理
日常治理是基于物理团队来进行的。
团队治理
团队外部架构
- 团队外部划分由物理团队负责人负责管理和优化
团队人员应次要分3局部：
外围人员
承当外围业务和模块的开发工作，也须要承当局部纯技术工作（技术框架降级、新技术学习钻研）以及新进人员的帮带，PO的筛选次要为外围人员。
开发人员
承当次要开发工作，筛选素质好、有上进心、品格端正的作为外围人员造就。
实习造就人员
承当一些简略的，根底的功能模块的开发，旨在深刻学习以及尽快融入团队。如果不行须要及时淘汰。
人员造就
帮带
一对一
新进员工或者实习人员，将由团队外围人员或者技术扎实的人员进行一对一的帮带。次要在技术上进行领导，使相应人员尽快上手和融入。
结对编程
在人员条件容许下，合成的开发工作能够按2人一组进行实现。
- 一个骨干开发者 + 一个稍弱的开发者
- 一个外围人员 + 一个实习或新进员工
培训/共享
定期举办团队外部的交流会
- 针对开发标准、开发技能进行培训
- 团队外部分享好的技术计划、办法、工具，采取轮流制。
- 对于问题解决的教训分享
分享
- 激励团队内部人员分享本人所善于的技术、工具、办法等，上传知识库。能够依据后果适当激励。
止损
- 对于不能适应团队、不违心进步本人、品行不端的人员即便淘汰。
- 对于后劲有余，主观能动性不强，然而不影响实现工作的人员，适当发出造就的重心，升高期望值。
团队气氛
- 团队负责人须要放弃团队外部积极向上、忙而不乱。
技术体系
技术体系的优化和降级是一项继续的、生态性的工作。
- 技术框架降级
- 实现计划的优化
- 新技术、新概念的学习、引入
- 技术体系次要由团队负责人以及外围人员来负责
这个方面的工作见效慢，产出低，然而确是整个团队能走多远的根底，作为技术人，进行脚步意味着被淘汰。
代码库/配置库治理
- 由团队负责人负责管理， 要做到保障安全性，不泄露生产环境的配置。
欢迎关注搞代码gaodaima网的博客
转载请注明原文链接：关于java:关于敏捷开发流程的一点思路
