敏捷思维-项目实践
敏捷思维和方法管理项目-案例1
为什么选择敏捷方法？
------------------------------------------
背景和痛点：
- 我司每月进行中的项目数量超过100个，项目数量庞大。
- 每月中旬需要规划下个月的项目。
- 每月上旬需分析上个月的项目实际情况，包括进度达成率、质量和成本预实比等方面的分析。
- 项目信息主要通过Excel管理，难以追踪变更，数据统计过程繁琐。- 项目范围扩大情况频繁发生。
- 每月需提交项目状况报告，整理报告内容的工作量较大，不仅消耗大量工时，还容易出现错误。
解决方案：
我们计划开发一个项目管理系统，将项目信息录入该系统，实现项目管理系统化，各类报表自动化生成。
关于体制：
由于这是公司内部项目，无法组建专门的团队进行设计和开发。
计划利用项目间歇期的成员进行兼职开发，也就是说没有项目预算的开发人员可以随时加入项目管理系统的开发团队。
关于期限：
尽管该系统没有客户方要求的确切截止日期，我们希望尽早开发出一个初始版本，在使用中逐步完善功能，这正是采用敏捷的MVP（最小可行产品）理念的体现。
关于需求要件：
我们对系统的基本需求有一个大致的想法，希望实现项目管理各方面的自动化，以减少人工干预。
我们的目标包括将来实现自动生成项目报告，并自动发送给相关干系人。然而，很多细节尚未精细化考虑，因此我们希望以“滚雪球”的方式逐步发展我们的管理系统。
值得注意的是，兼职人员能在项目中停留的时间并不确定。如果有盈利项目，我们的人力资源可能会立即被抽调走。
--------------------------------------
基于以上因素，我们决定采用敏捷思维开展本项目。
需要注意的是，我们使用的是敏捷思维，而不是严格遵循敏捷方法。因此，我们将依据敏捷思维，结合组织能力、成员能力以及项目特点，灵活管理项目。
★★★★★★下面介绍我们是如何使用敏捷思维做项目的★★★★★★
■定义角色
- 项目发起人：部门负责人
-产品负责人（PO，Product Owner）：PMO成员
- 敏捷教练（Scrum Master，SM）：部门负责人兼任
- 开发团队（Development Team）：1名全职SE+4名SE+1名兼职架构师
- 用户：部门负责人、各团队责任人、项目经理（PM）、PMO成员
■定义产品方向
1.我作为项目发起人，与PO分享我的产品构想、痛点以及希望实现的愿景。
2.PO基于愿景召集用户（部门负责人、各团队责任人、PM、PMO成员），收集了很多零散的需求。
这些需求中，绝大多数是宝贵的，但也有一些不切实际的需求，不需要通过系统实现。
■ 制定产品待办事项（Product Backlog）
产品负责人（PO）将收集到的需求进行整理和分类，形成用户故事（User Story），
包括史诗级（Epic）和普通用户故事（User Story），并将这些用户故事纳入产品待办事项列表（Product Backlog）中。
说明：
待办事项列表（Backlog）是需求的集合，充当需求的容器，容器中包含史诗（Epic）和用户故事（User Story）。
任何需求和想法都可以作为用户故事，这意味着用户故事可以是尚未确定的，不必经过评审和讨论确认。
然而，产品待办事项中的用户故事是经过团队评审并确认的需求，这些需求可以在后续的迭代中进行开发。
为了便于理解，我将产品待办事项（Product Backlog）分为产品级别和Sprint级别。
Sprint级的待办事项中的用户故事必须经过团队评审并确认，且必须是在一个Sprint内能够完成的内容。
■宣讲用户故事
PO召集项目发起人和用户，讲解产品待办事项中的用户故事。
目的有两个：
统一各方对项目的认知；
验证项目管理系统的可行性。如果用户认为与Excel没有太大区别，可能会在这一阶段终止项目。
■确定Sprint长度
Scrum Master与PO讨论定义Sprint的目标和长度。需要注意的是，敏捷思维强调尽早让团队成员参与，以增强团队的认同感。
尽管此阶段存在一些不完全符合敏捷原则的做法，但由于团队成员尚未从项目中释放出来，我们暂时不召集开发者。
最终，我们将每个Sprint的长度定义为两周，每两周发布一次版本。每次发布后，项目发起人和用户一起尝试使用并提出意见和建议。
■架构师出场
非功能性需求梳理兼职架构师作为开发团队的第一位正式成员入场。PO向架构师介绍系统的背景，并与架构师一起收集整理用户量、数据量等信息。
架构师开始系统设计，由于系统相对简单，并且已有现成的基础架构可供使用，因此我们给架构师1周的时间进行初步工作，定义为Sprint0。
在这1周内，架构师的任务包括：
1. 技术选型：Spring Boot + Vue + PostgreSQL
2. 搭建框架
3. 制定编码规范
4. 配置持续集成/持续交付（CI/CD）
■ 召开发布计划会议
会议的目的在于制定产品路线图并规划用户故事。
在会议中，PO主导讨论并制定产品路线图，明确希望在什么时间点发布哪些功能。
产品路线图的一个节点可以理解为一个Sprint。PO将已收集的用户故事规划到每个节点（Sprint）中。
虽然产品路线图大概率不会改变，但每个节点（Sprint）中的用户故事会根据实际情况更新。
架构师将参与发布会议，并粗略估算用户故事的工时。
■ 制定Sprint 01的产品待办事项
将用户故事添加到Sprint 01的产品待办事项列表（Product Backlog）中，细化用户故事，确保其清晰明确，并能够在一个Sprint内完成。
■ 开发成员入场
本项目共有5位开发成员。PO向开发成员讲述产品愿景、整体规划、产品待办事项中的用户故事，以及Sprint 01中的用户故事。
同时，听取成员的建议和意见，此阶段可以对产品待办事项中的用户故事进行修改。
说明：敏捷思想的基本原则是尽早让开发成员参与项目，以便他们能够获取更多的信息，从而深入理解目标，并对目标达成共识。
尽管本项目因各种因素选择在所有准备工作完成后再邀请开发成员加入，这与敏捷思维略有不同，但仍能实现相同的目的。
■ 召开Sprint启动会
・会议主要包括以下事项：
・讨论完成Sprint的可行性；
・深入理解用户故事；
・将用户故事拆分为具体的任务（task）；有些独立的用户故事可以拆分为多个任务，由两位成员共同承担；
・领取用户故事或任务。
基于敏捷思维，成员自主领取用户故事。对于拆分成多个任务的用户故事，成员之间可以自主协调合作进行开发。
敏捷教练（SM）主持会议，只起辅助作用，推动成员讨论和领取任务，不对用户故事的具体内容发表意见。
注意：在此时间点，架构师已完成所有开发作业的准备工作，包括基本架构的搭建、编码规范的制定及代码库的创建等。
■ 每日站会
敏捷教练（SM）每天召开站会，成员汇报自己的进度及遇到的困难。PO、架构师和SM会协助解决问题。
由于成员均具备敏捷开发经验，因此无需进行敏捷方法的培训。站会结束后，成员会找时间向PO询问或确认业务问题。
-----------------------未完待续-------------------------
【补充信息】
Scrum Master在敏捷项目中的具体职责包括：
促进团队工作：
帮助团队理解和遵循Scrum框架，确保团队成员之间的沟通顺畅，协助解决冲突和障碍。
确保敏捷实践的实施：
确保团队按照Scrum的原则和实践工作，包括规划会议、日常站会、评审会议和回顾会议。
协助产品负责人：
支持产品负责人进行产品待办事项的管理，帮助澄清需求，确保待办事项的优先级明确。
清除障碍：
主动识别和解决团队在工作中遇到的障碍，确保团队能够顺利推进工作。
促进自组织：
鼓励团队自我管理和自我组织，提高团队的自主性和责任感。
培训和指导：
为团队成员提供敏捷和Scrum方面的培训和指导，提高团队的敏捷能力。
与利益相关者沟通：
充当团队与外部利益相关者之间的桥梁，确保信息的透明和共享。
推动持续改进：
通过回顾和反馈机制，持续改进团队的工作流程和效率。
度量团队表现：
帮助团队使用指标和数据来评估工作效果，推动数据驱动的决策。
倡导敏捷文化：
在整个组织内传播敏捷思维和文化，促进敏捷实践的广泛应用。
Scrum Master的角色不仅限于管理，更重要的是引导和支持团队以更高效的方式工作。
用户故事通常由“作为...，我想要...，以便...”这种格式编写。
用户故事的特征有哪些？
以用户为中心：
用户故事通过将焦点放在用户的需求和期望上，确保开发团队始终考虑最终用户的体验，从而提高产品的用户满足度。
简洁易懂：
用户故事通常用简单的语言表达，使得各种利益相关者（包括开发人员、产品经理和非技术人员）都能理解需求。这有助于促进沟通，避免误解。
促进迭代开发：
用户故事帮助团队以小的增量方式工作，使功能的开发、测试和反馈变得更加灵活。在每个迭代周期内可以根据用户的反馈调整优先级。
优先级排序：
通过使用用户故事，团队能更容易地对功能进行优先级排序，从而确保最关键和最有价值的功能首先交付给用户。
鼓励团队协作：
编写和讨论用户故事的过程需要团队成员之间的合作，促进了团队内的交流和知识共享。
衡量价值：
用户故事不仅描述了需求，还明确了实现该功能的商业价值。这有助于团队判断每个功能的优先级以及其对项目成功的贡献。
增强可测试性：
用户故事可以帮助团队定义验收标准，从而为后续测试提供清晰的依据，确保功能符合用户预期。
总之，用户故事在敏捷开发中起到了桥梁的作用，连接了用户需求与开发实施，帮助团队更高效地交付用户想要的产品。
为什么选择敏捷方法？
------------------------------------------
背景和痛点：
- 我司每月进行中的项目数量超过100个，项目数量庞大。
- 每月中旬需要规划下个月的项目。
- 每月上旬需分析上个月的项目实际情况，包括进度达成率、质量和成本预实比等方面的分析。
- 项目信息主要通过Excel管理，难以追踪变更，数据统计过程繁琐。- 项目范围扩大情况频繁发生。
- 每月需提交项目状况报告，整理报告内容的工作量较大，不仅消耗大量工时，还容易出现错误。
解决方案：
我们计划开发一个项目管理系统，将项目信息录入该系统，实现项目管理系统化，各类报表自动化生成。
关于体制：
由于这是公司内部项目，无法组建专门的团队进行设计和开发。
计划利用项目间歇期的成员进行兼职开发，也就是说没有项目预算的开发人员可以随时加入项目管理系统的开发团队。
关于期限：
尽管该系统没有客户方要求的确切截止日期，我们希望尽早开发出一个初始版本，在使用中逐步完善功能，这正是采用敏捷的MVP（最小可行产品）理念的体现。
关于需求要件：
我们对系统的基本需求有一个大致的想法，希望实现项目管理各方面的自动化，以减少人工干预。
我们的目标包括将来实现自动生成项目报告，并自动发送给相关干系人。然而，很多细节尚未精细化考虑，因此我们希望以“滚雪球”的方式逐步发展我们的管理系统。
值得注意的是，兼职人员能在项目中停留的时间并不确定。如果有盈利项目，我们的人力资源可能会立即被抽调走。
--------------------------------------
基于以上因素，我们决定采用敏捷思维开展本项目。
需要注意的是，我们使用的是敏捷思维，而不是严格遵循敏捷方法。因此，我们将依据敏捷思维，结合组织能力、成员能力以及项目特点，灵活管理项目。
★★★★★★下面介绍我们是如何使用敏捷思维做项目的★★★★★★
■定义角色
- 项目发起人：部门负责人
-产品负责人（PO，Product Owner）：PMO成员
- 敏捷教练（Scrum Master，SM）：部门负责人兼任
- 开发团队（Development Team）：1名全职SE+4名SE+1名兼职架构师
- 用户：部门负责人、各团队责任人、项目经理（PM）、PMO成员
■定义产品方向
1.我作为项目发起人，与PO分享我的产品构想、痛点以及希望实现的愿景。
2.PO基于愿景召集用户（部门负责人、各团队责任人、PM、PMO成员），收集了很多零散的需求。
这些需求中，绝大多数是宝贵的，但也有一些不切实际的需求，不需要通过系统实现。
■ 制定产品待办事项（Product Backlog）
产品负责人（PO）将收集到的需求进行整理和分类，形成用户故事（User Story），
包括史诗级（Epic）和普通用户故事（User Story），并将这些用户故事纳入产品待办事项列表（Product Backlog）中。
说明：
待办事项列表（Backlog）是需求的集合，充当需求的容器，容器中包含史诗（Epic）和用户故事（User Story）。
任何需求和想法都可以作为用户故事，这意味着用户故事可以是尚未确定的，不必经过评审和讨论确认。
然而，产品待办事项中的用户故事是经过团队评审并确认的需求，这些需求可以在后续的迭代中进行开发。
为了便于理解，我将产品待办事项（Product Backlog）分为产品级别和Sprint级别。
Sprint级的待办事项中的用户故事必须经过团队评审并确认，且必须是在一个Sprint内能够完成的内容。
■宣讲用户故事
PO召集项目发起人和用户，讲解产品待办事项中的用户故事。
目的有两个：
统一各方对项目的认知；
验证项目管理系统的可行性。如果用户认为与Excel没有太大区别，可能会在这一阶段终止项目。
■确定Sprint长度
Scrum Master与PO讨论定义Sprint的目标和长度。需要注意的是，敏捷思维强调尽早让团队成员参与，以增强团队的认同感。
尽管此阶段存在一些不完全符合敏捷原则的做法，但由于团队成员尚未从项目中释放出来，我们暂时不召集开发者。
最终，我们将每个Sprint的长度定义为两周，每两周发布一次版本。每次发布后，项目发起人和用户一起尝试使用并提出意见和建议。
■架构师出场
非功能性需求梳理兼职架构师作为开发团队的第一位正式成员入场。PO向架构师介绍系统的背景，并与架构师一起收集整理用户量、数据量等信息。
架构师开始系统设计，由于系统相对简单，并且已有现成的基础架构可供使用，因此我们给架构师1周的时间进行初步工作，定义为Sprint0。
在这1周内，架构师的任务包括：
1. 技术选型：Spring Boot + Vue + PostgreSQL
2. 搭建框架
3. 制定编码规范
4. 配置持续集成/持续交付（CI/CD）
■ 召开发布计划会议
会议的目的在于制定产品路线图并规划用户故事。
在会议中，PO主导讨论并制定产品路线图，明确希望在什么时间点发布哪些功能。
产品路线图的一个节点可以理解为一个Sprint。PO将已收集的用户故事规划到每个节点（Sprint）中。
虽然产品路线图大概率不会改变，但每个节点（Sprint）中的用户故事会根据实际情况更新。
架构师将参与发布会议，并粗略估算用户故事的工时。
■ 制定Sprint 01的产品待办事项
将用户故事添加到Sprint 01的产品待办事项列表（Product Backlog）中，细化用户故事，确保其清晰明确，并能够在一个Sprint内完成。
■ 开发成员入场
本项目共有5位开发成员。PO向开发成员讲述产品愿景、整体规划、产品待办事项中的用户故事，以及Sprint 01中的用户故事。
同时，听取成员的建议和意见，此阶段可以对产品待办事项中的用户故事进行修改。
说明：敏捷思想的基本原则是尽早让开发成员参与项目，以便他们能够获取更多的信息，从而深入理解目标，并对目标达成共识。
尽管本项目因各种因素选择在所有准备工作完成后再邀请开发成员加入，这与敏捷思维略有不同，但仍能实现相同的目的。
■ 召开Sprint启动会
・会议主要包括以下事项：
・讨论完成Sprint的可行性；
・深入理解用户故事；
・将用户故事拆分为具体的任务（task）；有些独立的用户故事可以拆分为多个任务，由两位成员共同承担；
・领取用户故事或任务。
基于敏捷思维，成员自主领取用户故事。对于拆分成多个任务的用户故事，成员之间可以自主协调合作进行开发。
敏捷教练（SM）主持会议，只起辅助作用，推动成员讨论和领取任务，不对用户故事的具体内容发表意见。
注意：在此时间点，架构师已完成所有开发作业的准备工作，包括基本架构的搭建、编码规范的制定及代码库的创建等。
■ 每日站会
敏捷教练（SM）每天召开站会，成员汇报自己的进度及遇到的困难。PO、架构师和SM会协助解决问题。
由于成员均具备敏捷开发经验，因此无需进行敏捷方法的培训。站会结束后，成员会找时间向PO询问或确认业务问题。
-----------------------未完待续-------------------------
【补充信息】
Scrum Master在敏捷项目中的具体职责包括：
促进团队工作：
帮助团队理解和遵循Scrum框架，确保团队成员之间的沟通顺畅，协助解决冲突和障碍。
确保敏捷实践的实施：
确保团队按照Scrum的原则和实践工作，包括规划会议、日常站会、评审会议和回顾会议。
协助产品负责人：
支持产品负责人进行产品待办事项的管理，帮助澄清需求，确保待办事项的优先级明确。
清除障碍：
主动识别和解决团队在工作中遇到的障碍，确保团队能够顺利推进工作。
促进自组织：
鼓励团队自我管理和自我组织，提高团队的自主性和责任感。
培训和指导：
为团队成员提供敏捷和Scrum方面的培训和指导，提高团队的敏捷能力。
与利益相关者沟通：
充当团队与外部利益相关者之间的桥梁，确保信息的透明和共享。
推动持续改进：
通过回顾和反馈机制，持续改进团队的工作流程和效率。
度量团队表现：
帮助团队使用指标和数据来评估工作效果，推动数据驱动的决策。
倡导敏捷文化：
在整个组织内传播敏捷思维和文化，促进敏捷实践的广泛应用。
Scrum Master的角色不仅限于管理，更重要的是引导和支持团队以更高效的方式工作。
用户故事通常由“作为...，我想要...，以便...”这种格式编写。
用户故事的特征有哪些？
以用户为中心：
用户故事通过将焦点放在用户的需求和期望上，确保开发团队始终考虑最终用户的体验，从而提高产品的用户满足度。
简洁易懂：
用户故事通常用简单的语言表达，使得各种利益相关者（包括开发人员、产品经理和非技术人员）都能理解需求。这有助于促进沟通，避免误解。
促进迭代开发：
用户故事帮助团队以小的增量方式工作，使功能的开发、测试和反馈变得更加灵活。在每个迭代周期内可以根据用户的反馈调整优先级。
优先级排序：
通过使用用户故事，团队能更容易地对功能进行优先级排序，从而确保最关键和最有价值的功能首先交付给用户。
鼓励团队协作：
编写和讨论用户故事的过程需要团队成员之间的合作，促进了团队内的交流和知识共享。
衡量价值：
用户故事不仅描述了需求，还明确了实现该功能的商业价值。这有助于团队判断每个功能的优先级以及其对项目成功的贡献。
增强可测试性：
用户故事可以帮助团队定义验收标准，从而为后续测试提供清晰的依据，确保功能符合用户预期。
总之，用户故事在敏捷开发中起到了桥梁的作用，连接了用户需求与开发实施，帮助团队更高效地交付用户想要的产品。
