曾经的软件开发，coder们有一个共同的梦想：需求在开发过程中不要产生啥变动。无数次实践，我们得到了一个不争的事实：需求的变动是必然的（比如这几天我在沟通的模块需求，已经出了五版需求规格说明书，周一开发着手撸代码，今天还变动了一版需求）。在这种事实无法改变的情况下，首先我们需要改变自己的心态，拥抱变动的需求。其次，行业的奠基者们就在思考：拥抱变动的需求这心态很好，与此同时我们有没有什么办法可以让coder们更适应这种情况呢？于是伟大的奠基者们成立了一个Agile联盟，也就是现在多数项目、团队在使用的敏捷开发。
第一次接触敏捷，是在大三的课程软件设计上。这是一门很神奇的课程，知识点巨多，考试范围是200页PPT，因此印象十分深刻。课堂上，老师说：敏捷提倡快速响应需求，提倡以人为本（即人与人的沟通胜过人与机器的沟通）。能记住的不算多，大致就是这几句话。第一次真正了解敏捷，是在目前正在做的项目中，当时新入职的QA申请购买了一套JIRA，因此有了一个机缘了解敏捷。
JIRA是一个敏捷管理平台，JIRA留着下次讲，今天还是先讲敏捷开发的概念和应用。
首先来一段经典的敏捷宣言：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。对于以上宣言，我只想说一个字：酷。因为需求变动是必然的，我们选择响应变化（快），通过人与人的直接沟通（快）来完成需求的沟通与理解、通过软件（体现了云的概念）来记录需求并记录项目的成长（快）而非选择冗长（编辑费时）、需要再次阅读（阅读费时）的文档，最终我们提倡和客户直接合作、让客户参与到项目的开发中来（快）而非在项目立项初期来谈判（项目的谈判有可能是半年以前）需求。敏捷宣言中，无不体现着奠基者们心中的时间观念。“快”对于软件开发而言是一个很重要的字眼，敏捷如是。但是与此同时，敏捷同样注重软件的质量。“快”与质量似乎是矛盾的，但是质量是目的，快是手段。（似乎歪楼了）
接下来简要介绍几个词汇：agile，sprint、scrum、product backlog、story board、burn down chart。agile，即敏捷，提倡快速响应需求，快速反馈结果；sprint，短跑冲刺，一段开发周期即一个sprint；scrum，可以理解为大家（团队中的全部角色）一股脑的实现目标；product backlog即需求池，会通过列表的形式来体现需求以及需求的重要性；story board，故事版，故事版说的是一个需求从开发--测试--提交--上线的全流程；burn down chart，即燃尽图，一开始时间和资源（coder）是出于满的状态，随着项目的一步步推进、时间资源的一点点消耗，资源也会呈现一个降低（被消耗）的趋势，这个趋势即燃尽图。
在工作中的应用：一个时长为5个工作日的sprint，在周五下班前交付一个搭载积分功能的应用（移动端app，app本身是存在的）。首先召集团队成员（纯后台开发，暂时不要UI以及前端的coder参与）开会，目前我们叫做需求评审会议。成员们都到场了，产品会将需求一条一条和大家过，确认大家在需求的理解上达到共同认知（尽量保持一致），同时还需要对技术、所需时间、资源进行讨论，尽量避免超过预定周期。随后，将工作进行分配：积分体系搭建--后台，操作获取--移动端（Android、iOS）、测试--测试、部署--运维。大概是这么些工作内容，大家明确之后可以开始愉快的撸代码了。
周一的需求评审打响了战斗的第一枪。此后的每一天，要求相关的同事做到如下几个事情：在项目管理的工具or某一个大家公共的区域（按照任务的状态进行划分）记录自己的任务，基本了解项目进度。将实现的功能落实到每一天的工作中，最终满足需求，实现既定目标~~此后的每一天，也要求站会，利用十来分钟时间召集项目成员沟通需求的完成情况，是否有困难等等，这里也体现了一个快速响应的概念。
关于人与人的沟通这一块，其实我很有欠缺--由于开发团队在北京，因此人与人的沟通（需求评审、站会）缩水到了需求评审，每日站会会通过QQ的方式和大家进行沟通。曾经一度，对变动的需求无法调整心态，后来实践了敏捷项目管理，感觉需求变动也就是那么肥事~~
啊，今天特别忙碌，忙碌到哭泣。充实的每一天，战斗的人生。
网友评论