首页 > 极客资料 博客日记
敏捷思维-项目实践
2024-10-22 19:00:03极客资料围观20次
这篇文章介绍了敏捷思维-项目实践,分享给大家做个参考,收藏极客之家收获更多编程知识
敏捷思维和方法管理项目-案例1
为什么选择敏捷方法?
背景和痛点:
- 我司每月进行中的项目数量超过100个,项目数量庞大。
- 每月中旬需要规划下个月的项目。
- 每月上旬需分析上个月的项目实际情况,包括进度达成率、质量和成本预实比等方面的分析。
- 项目信息主要通过Excel管理,难以追踪变更,数据统计过程繁琐。- 项目范围扩大情况频繁发生。
- 每月需提交项目状况报告,整理报告内容的工作量较大,不仅消耗大量工时,还容易出现错误。
解决方案:
我们计划开发一个项目管理系统,将项目信息录入该系统,实现项目管理系统化,各类报表自动化生成。
关于体制:
由于这是公司内部项目,无法组建专门的团队进行设计和开发。
计划利用项目间歇期的成员进行兼职开发,也就是说没有项目预算的开发人员可以随时加入项目管理系统的开发团队。
关于期限:
尽管该系统没有客户方要求的确切截止日期,我们希望尽早开发出一个初始版本,在使用中逐步完善功能,这正是采用敏捷的MVP(最小可行产品)理念的体现。
关于需求要件:
我们对系统的基本需求有一个大致的想法,希望实现项目管理各方面的自动化,以减少人工干预。
我们的目标包括将来实现自动生成项目报告,并自动发送给相关干系人。然而,很多细节尚未精细化考虑,因此我们希望以“滚雪球”的方式逐步发展我们的管理系统。
值得注意的是,兼职人员能在项目中停留的时间并不确定。如果有盈利项目,我们的人力资源可能会立即被抽调走。
我们召开了一次1小时的会议,明确了成员角色,并决定采用敏捷思维开展该项目。
需要注意的是,我们使用的是敏捷思维,而不是严格遵循敏捷方法。因此,我们将依据敏捷思维,结合组织能力、成员能力以及项目特点,灵活管理项目。
■定义角色
- 项目发起人:部门负责人
-产品负责人(PO,Product Owner):PMO成员
- 敏捷教练(Scrum Master,SM):部门负责人兼任
- 开发团队(Development Team):1名全职SE+4名SE+1名兼职架构师
- 用户:部门负责人、各团队责任人、项目经理(PM)、PMO成员
■定义产品方向
1.我作为项目发起人,与PO分享我的产品构想、痛点以及希望实现的愿景。
2.PO基于愿景召集用户(部门负责人、各团队责任人、PM、PMO成员),收集了很多零散的需求。
这些需求中,绝大多数是宝贵的,但也有一些不切实际的需求,不需要通过系统实现。
■制定Product Backlog
1.PO将收集的需求整理分类,形成用户故事(User Story),包括史诗级(Epic)和普通用户故事(User Story),并将这些用户故事放入产品待办事项列表(Product Backlog)中。
2.PO召集项目发起人和用户,讲解产品待办事项中的用户故事。
目的有两个:1)统一各方认知;
2)验证项目管理系统的可行性。如果用户认为与Excel没有太大区别,可能会在这一阶段终止项目。
■制定Sprint长度
Scrum Master与PO讨论定义Sprint的目标和长度。需要注意的是,敏捷思维强调尽早让团队成员参与,以增强团队的认同感。
尽管此阶段存在一些不完全符合敏捷原则的做法,但由于团队成员尚未从项目中释放出来,我们暂时不召集开发者。
最终,我们将每个Sprint的长度定义为两周,每两周发布一次版本。每次发布后,项目发起人和用户一起尝试使用并提出意见和建议。
■架构师出场
非功能性需求梳理兼职架构师作为开发团队的第一位正式成员入场。PO向架构师介绍系统的背景,并与架构师一起收集整理用户量、数据量等信息。
架构师开始系统设计,由于系统相对简单,并且已有现成的基础架构可供使用,因此我们给架构师1周的时间进行初步工作,定义为Sprint0。
在这1周内,架构师的任务包括:
1. 技术选型:Spring Boot + Vue + PostgreSQL
2. 搭建框架
3. 制定编码规范
4. 配置持续集成/持续交付(CI/CD)
■制定Sprint的Product Backlog
PO根据发布方针(产品路线图),将用户故事添加到Sprint1的产品待办事项列表(Product Backlog)中。
说明:
1.Backlog是需求列表,充当需求容器,内含多个item,这些item可以是史诗(Epic)或用户故事(User Story)。
2.任何需求和想法都可以作为用户故事,这意味着用户故事可以是未确定的,不必经过评审和讨论确认。
然而,产品待办事项中的用户故事是经过团队评审并确认的需求,这些需求可以在后续迭代中进行开发。
■开发成员入场
PO向开发成员讲述产品愿景、整体规划、产品待办事项中的用户故事,以及Sprint1里的用户故事。
同时开始听取成员的建议和意见,此阶段可以修改产品待办事项中的用户故事。
-----------------------未完待续-------------------------
【补充信息】
Scrum Master在敏捷项目中的具体职责包括:
促进团队工作:
帮助团队理解和遵循Scrum框架,确保团队成员之间的沟通顺畅,协助解决冲突和障碍。
确保敏捷实践的实施:
确保团队按照Scrum的原则和实践工作,包括规划会议、日常站会、评审会议和回顾会议。
协助产品负责人:
支持产品负责人进行产品待办事项的管理,帮助澄清需求,确保待办事项的优先级明确。
清除障碍:
主动识别和解决团队在工作中遇到的障碍,确保团队能够顺利推进工作。
促进自组织:
鼓励团队自我管理和自我组织,提高团队的自主性和责任感。
培训和指导:
为团队成员提供敏捷和Scrum方面的培训和指导,提高团队的敏捷能力。
与利益相关者沟通:
充当团队与外部利益相关者之间的桥梁,确保信息的透明和共享。
推动持续改进:
通过回顾和反馈机制,持续改进团队的工作流程和效率。
度量团队表现:
帮助团队使用指标和数据来评估工作效果,推动数据驱动的决策。
倡导敏捷文化:
在整个组织内传播敏捷思维和文化,促进敏捷实践的广泛应用。
Scrum Master的角色不仅限于管理,更重要的是引导和支持团队以更高效的方式工作。
为什么选择敏捷方法?
背景和痛点:
- 我司每月进行中的项目数量超过100个,项目数量庞大。
- 每月中旬需要规划下个月的项目。
- 每月上旬需分析上个月的项目实际情况,包括进度达成率、质量和成本预实比等方面的分析。
- 项目信息主要通过Excel管理,难以追踪变更,数据统计过程繁琐。- 项目范围扩大情况频繁发生。
- 每月需提交项目状况报告,整理报告内容的工作量较大,不仅消耗大量工时,还容易出现错误。
解决方案:
我们计划开发一个项目管理系统,将项目信息录入该系统,实现项目管理系统化,各类报表自动化生成。
关于体制:
由于这是公司内部项目,无法组建专门的团队进行设计和开发。
计划利用项目间歇期的成员进行兼职开发,也就是说没有项目预算的开发人员可以随时加入项目管理系统的开发团队。
关于期限:
尽管该系统没有客户方要求的确切截止日期,我们希望尽早开发出一个初始版本,在使用中逐步完善功能,这正是采用敏捷的MVP(最小可行产品)理念的体现。
关于需求要件:
我们对系统的基本需求有一个大致的想法,希望实现项目管理各方面的自动化,以减少人工干预。
我们的目标包括将来实现自动生成项目报告,并自动发送给相关干系人。然而,很多细节尚未精细化考虑,因此我们希望以“滚雪球”的方式逐步发展我们的管理系统。
值得注意的是,兼职人员能在项目中停留的时间并不确定。如果有盈利项目,我们的人力资源可能会立即被抽调走。
我们召开了一次1小时的会议,明确了成员角色,并决定采用敏捷思维开展该项目。
需要注意的是,我们使用的是敏捷思维,而不是严格遵循敏捷方法。因此,我们将依据敏捷思维,结合组织能力、成员能力以及项目特点,灵活管理项目。
■定义角色
- 项目发起人:部门负责人
-产品负责人(PO,Product Owner):PMO成员
- 敏捷教练(Scrum Master,SM):部门负责人兼任
- 开发团队(Development Team):1名全职SE+4名SE+1名兼职架构师
- 用户:部门负责人、各团队责任人、项目经理(PM)、PMO成员
■定义产品方向
1.我作为项目发起人,与PO分享我的产品构想、痛点以及希望实现的愿景。
2.PO基于愿景召集用户(部门负责人、各团队责任人、PM、PMO成员),收集了很多零散的需求。
这些需求中,绝大多数是宝贵的,但也有一些不切实际的需求,不需要通过系统实现。
■制定Product Backlog
1.PO将收集的需求整理分类,形成用户故事(User Story),包括史诗级(Epic)和普通用户故事(User Story),并将这些用户故事放入产品待办事项列表(Product Backlog)中。
2.PO召集项目发起人和用户,讲解产品待办事项中的用户故事。
目的有两个:1)统一各方认知;
2)验证项目管理系统的可行性。如果用户认为与Excel没有太大区别,可能会在这一阶段终止项目。
■制定Sprint长度
Scrum Master与PO讨论定义Sprint的目标和长度。需要注意的是,敏捷思维强调尽早让团队成员参与,以增强团队的认同感。
尽管此阶段存在一些不完全符合敏捷原则的做法,但由于团队成员尚未从项目中释放出来,我们暂时不召集开发者。
最终,我们将每个Sprint的长度定义为两周,每两周发布一次版本。每次发布后,项目发起人和用户一起尝试使用并提出意见和建议。
■架构师出场
非功能性需求梳理兼职架构师作为开发团队的第一位正式成员入场。PO向架构师介绍系统的背景,并与架构师一起收集整理用户量、数据量等信息。
架构师开始系统设计,由于系统相对简单,并且已有现成的基础架构可供使用,因此我们给架构师1周的时间进行初步工作,定义为Sprint0。
在这1周内,架构师的任务包括:
1. 技术选型:Spring Boot + Vue + PostgreSQL
2. 搭建框架
3. 制定编码规范
4. 配置持续集成/持续交付(CI/CD)
■制定Sprint的Product Backlog
PO根据发布方针(产品路线图),将用户故事添加到Sprint1的产品待办事项列表(Product Backlog)中。
说明:
1.Backlog是需求列表,充当需求容器,内含多个item,这些item可以是史诗(Epic)或用户故事(User Story)。
2.任何需求和想法都可以作为用户故事,这意味着用户故事可以是未确定的,不必经过评审和讨论确认。
然而,产品待办事项中的用户故事是经过团队评审并确认的需求,这些需求可以在后续迭代中进行开发。
■开发成员入场
PO向开发成员讲述产品愿景、整体规划、产品待办事项中的用户故事,以及Sprint1里的用户故事。
同时开始听取成员的建议和意见,此阶段可以修改产品待办事项中的用户故事。
-----------------------未完待续-------------------------
【补充信息】
Scrum Master在敏捷项目中的具体职责包括:
促进团队工作:
帮助团队理解和遵循Scrum框架,确保团队成员之间的沟通顺畅,协助解决冲突和障碍。
确保敏捷实践的实施:
确保团队按照Scrum的原则和实践工作,包括规划会议、日常站会、评审会议和回顾会议。
协助产品负责人:
支持产品负责人进行产品待办事项的管理,帮助澄清需求,确保待办事项的优先级明确。
清除障碍:
主动识别和解决团队在工作中遇到的障碍,确保团队能够顺利推进工作。
促进自组织:
鼓励团队自我管理和自我组织,提高团队的自主性和责任感。
培训和指导:
为团队成员提供敏捷和Scrum方面的培训和指导,提高团队的敏捷能力。
与利益相关者沟通:
充当团队与外部利益相关者之间的桥梁,确保信息的透明和共享。
推动持续改进:
通过回顾和反馈机制,持续改进团队的工作流程和效率。
度量团队表现:
帮助团队使用指标和数据来评估工作效果,推动数据驱动的决策。
倡导敏捷文化:
在整个组织内传播敏捷思维和文化,促进敏捷实践的广泛应用。
Scrum Master的角色不仅限于管理,更重要的是引导和支持团队以更高效的方式工作。
版权声明:本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!
标签:
上一篇:vue3 使用swiper轮播组件
下一篇:04.原型模式设计思想
相关文章
最新发布
- Nuxt.js 应用中的 prerender:routes 事件钩子详解
- 【问题解决】Tomcat由低于8版本升级到高版本使用Tomcat自带连接池报错无法找到表空间的问题
- 【FAQ】HarmonyOS SDK 闭源开放能力 —Vision Kit
- 六、Spring Boot集成Spring Security之前后分离认证流程最佳方案
- 《JVM第7课》堆区
- .NET 8 高性能跨平台图像处理库 ImageSharp
- 还在为慢速数据传输苦恼?Linux 零拷贝技术来帮你!
- 刚毕业,去做边缘业务,还有救吗?
- 如何避免 HttpClient 丢失请求头:通过 HttpRequestMessage 解决并优化
- 让性能提升56%的Vue3.5响应式重构之“版本计数”