敏捷开发实战总结原创
# 敏捷开发团队总结（总结在子长科技工作中）
# 1. 敏捷开发优势
- 作战单位小，一个组长带多个基础开发，基础开发只需要关注卡的内容，业务甚至都不需要懂太多，全局也不需要懂太多就能上手干活。
- 成员工作量方便量化，方便考核。
- 敏捷开发沉没成本比瀑布流开发小，做过的卡都是有价值的任务，不会一整个项目要砍掉，全部都白做。（学软考高级信息系统管理得出结论）
- 会议多，所以所有人对需求的理解没有偏差
小缺点：需求分析产品经理，时间比较紧张，没太多时间画原型图，不利于维护项目。
# 2. 角色和对应的职责
# 1. 角色
- SM：Scrum Master，敏捷专家（奔驰金融部的songjia）
- BA：Business Analysis，Consultant（如：jiasong，zangheng，zhanglin）
- TL：Tech Lead，Architect（如：子长的liwei，liuwei。奔驰金融部的xinyi，测试领导like，前端领导yashi）
- PM/PO：Project Manager（如：子长的gupeng，wangzhen。奔驰金融部的zhuangjie、sutong）
- Developer：Developer、FE、BE、App（如：我、likun、jiahao、wenyu、jiaojiao）
- QA：QA Engineer, Automation Engineer, Tester（功能测试majie、自动化测试hongliang）
- UI/UX：Designer, User Interaction（子长科技的qulingqian）
- DevOps：Development and operation（cg公司的shaopeng、donghui）
- Annotation：子长本部有，大概是做标注的（如：fanqian，成都的同事）
- Others：辅助型职位（如：yangleilei，hejunyi）
# 2. 职责
SM职责：
- 统筹当前敏捷周期的任务卡进度，协调各人员顺利完成开结卡，组织敏捷周期开板、结板、任务估点会议。
BA职责：
- 收集并整理客户的需求，包括奔驰金融部用户和奔驰经销商用户的需求。
- 整理业务流程，细化并拆分故事点，做成一张一张的任务卡，卡分为story和enabler，卡内写清一个一个的action功能点。
- 输出原型图，与UI对齐界面和业务逻辑，对齐交互设计。
- 开发完成任务卡，并结卡后验收。
TL职责：
- 梳理项目业务流程，根据每个敏捷周期的任务，协助BA拆分任务点，按照一个周期人均7个点来拆分卡，将卡合理分配给组员，参与估点会、开/结卡会议，检查组员卡片的实现方案是否可行，检查组员卡片完成情况是否满足要求。
- 解决环境上的报错问题，发布上线版本（准备上线前的拉分支、需要执行的SQL脚本、需要配置的K8S的ConfigMap，以及解决可能遇到的Bug）。
- 总结当前项目技术栈和流程，与新加入的组员分享，尽快拉平所有人员的工作能力，使之至少能满足能干活。
PM/PO职责：
- 负责和外部团队沟通。
- 制定团队计划，规划里程碑等工作。
- 负责促成各种活动/会议按时、高效的召开。
- 识别和消除团队的障碍，保证团队运作流畅。
Developer职责：
- 负责用户故事的需求澄清、设计、开发。
- 技术方案的调研、修复安全问题。
- 编写技术文档、单元测试编写、业务自测。
DevOps职责：
- 审核架构设计合理性。
- 分析安全风险。
- 环境和Pipeline搭建。
- 环境设置和程序部署。
- 系统问题分析和处理。
# 3. 能力团队/执行团队 - 团队说明
# 1. 人员配比：
1 TL/PM/BA : 3-5 Developer : 1 QA
- 管理团队，尽可能保持2人次及以上。
- 团队规模的扩大一般都是指开发人员数量扩大，当团队规模扩大时，BA和QA数量需要等比扩张。
- DevOps，Annotation团队可以在不同Project共享，对于规模不大的项目，管理人员也可以共享。
# 2. 岗位交叉：
- 实际应用中，只有Developer和DevOps可以交叉，并且是Developer兼顾DevOps。
- TL可以兼顾Developer和DevOps。
- 其他岗位务必保证独立。
# 4. 能力团队/执行团队 - UI/UX，QA和Annotation
# 1. QA职责：
- 对用户故事进行功能测试。
- 制定测试策略，包括但不限于功能测试、回归测试、冒烟测试、性能测试、安全测试、验收测试。
- 编写自动化测试。
- 搭建测试环境和准备测试数据。
- 维护测试用例。
- 度量团队质量指标，例如缺陷密度。
- 分析和重现收到的缺陷。
# 2. Annotation职责：
- 训练数据的准备。
- 数据结果的审核。
# 3. UI/UX职责：
- 输出软件产品的用户界面。
- 持续优化软件产品的交互设计。
- 统一软件产品的风格，输出设计元素。
- 维护设计系统，对常用组件进行规范化。
- 对可用性进行分析，例如响应式布局下各种屏幕尺寸的设计。
# 5. 谁和需求方对接？
- PO和需求方对接。
- PO不是对接所有，需要指定特定人对接特定事。
- PO不是处理所有事，他更多的事是把任务分出去。
- 对的人做对的事，“对”是相对的。
# 6. 项目工具
- JIRA、Confluence、Figma（主要是原型图设计，预览等）、GitHub、DevOps相关工具、Docker、Kubernetes等。
# 7. 项目流程
# 8. 项目常见的会议
- 敏捷开发会议：grooming估点会（大家在Teams上视频会议，把卡的点数发给奔驰的技术领导），开结卡会，每日站会，开板Sprint会（两周为一周期，业界常规做法），code review（结卡后下午开），Sprint review（周期结束最后一天开，也就是第二周周五回顾下卡）
- 使用工具：敏捷开发工具：JIRA（卡相关的管理）、Confluence（记录文档，更新脚本什么的）
# 9. 常见的项目管理问题，以及解决方法
- 如果延期了怎么解决？
- 延期原因主要有以下:1.预估时间不准.2.开会过多,开发和qa时间被挤压3.因为需求膨胀导致延期的不多，第二周周四排下周的任务的时候,会根据上个开发周期留下来没做完的,根据卡的位置决定优先级高低,越往上越高 总结解决方式: 1.加班.2是不是能拖到下下周期做. 但是不会砍需求
- 工作点数怎么确认的?
- 开发自己觉得需要的时间评估出来,再由pl(奔驰自己的人)决定,决定后可以申诉
- 工作时间粒度问题？
- 一般是半天到四天
编辑 (opens new window)