# 敏捷式开发管理 [toc] ## 1.背景 在现代软件开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷式开发管理概念应运而生。 ## 2.敏捷开发管理的由来 2001年，一群大师聚集在美国犹他州，吃吃喝喝头脑风暴，搞出了一个敏捷宣言，阐述了5条价值观，如下图所示。  ### 2.1 文档能省则省 描述类属性文档、接口说明文档（利用swagger自动生成）。而一些有价值的文档，如设计方案文档、架构体系文档等仍然是必须的。 ### 2.2 敏捷的初心 敏捷的初心是建议我们通过一系列方法来让我们的研发工作更加高效、灵活和有序，所以它强调团队成员的能动性和相互之间的协作，也更重视应对变化。 ## 3.敏捷的原则 1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3. 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7. 工作的软件是首要的进度度量标准。 8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9. 不断地关注优秀的技能和好的设计会增强敏捷能力。 10. 简单——使未完成的工作最大化的艺术——是根本的。 11. 最好的构架、需求和设计出自于自组织的团队。 12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 随着时代的变迁，里面的内容有些会变了，如第4点社会分工越来越细，提需求的是跟客户一起的售前通过工具更新到teambition平台以下五个步骤。 需求分析（requirements analysis） 设计（design） 编码（coding） 测试（testing） 部署和评估（deployment / evaluation） ### 6.2 任务管理 #### 6.2.1 需求管理 PO(Product Owner): 产品负责人，核心是产品，提需求者可以是产品经理，项目经理，测试人员(适用我司)，最终用户，集成商，代理商； 现代化需求：需求变更快，早上提了，下午就改，敏捷是为了更方便地变更需求，我司非常适用敏捷式开发。 需求管理：关键是要写下来，写到统一的品台teambition里去。写的过程，考虑问题会全面，能溯源。需求文档和开发的代码一样，都要有完整的历史记录，能够追溯到何时什么人做了什么修改，这样可以追责到每一次需求变更。 ##### 6.2.1.1 一次具体的需求管理 * 什么时候开始？ * 什么时候结束？ * 负责人是谁？ *