2017-07-31关于敏捷开发的一些想法

没看过什么相关的书，第一次正式接触这个概念是在上学期的软件工程课上。接下来去了公司实习，用的正是敏捷开发，之后慢慢地开始形成了一些自己的想法。

 

上周去听了青风一号沙龙，嘉宾是王春生，禅道的创始人，主题是软件项目敏捷开发主题讨论及禅道系统实践，内容包括敏捷开发相关、极限编程相关、禅道系统相关。禅道，我们公司也有用，是一个项目管理的软件，不打广告了，刚实习，接触不多，不好说，不过第一个影响还不错。这也是我第一次参加程序员的沙龙吧，可能偏管理了，不算是技术。

 

分享一些我感兴趣的笔记吧，其实就是春生老师的ppt：

如何看待敏捷开发：

1、敏捷开发不是银弹，敏捷项目失败率也一直居高不下。

2、不管喜欢与否，迭代开发成为主流。

3、敏捷的目的是为了快速交付有了价值和质量的产品服务。

4、xp(Extreme Programming), scrum, tdd, ci(Continuous integration，持续集成)等这些都是手段。手段不是目的，我们很多争论停留在手段上的争论，其实是没什么意义上的。关于敏捷开发很多官方概念和标准一直都有争论，在春生老师看来没什么意义。

5、敏捷的产生有其文化背景，在国内实施也要因地制宜。

 

软件开发常见的问题：沟通

1、项目启动后产品经理就小时了，无人解释和确认需求。

2、遇到问题互相扯皮，强调这是其他人的责任。

3、一个人负责一摊，知识难以传承，风险比较高。

4、缺少团队合作，遇到问题时不愿意或不能请别人帮忙。

5、项目内部沟通不畅，每个成员只是埋头做自己的事。

 

敏捷价值观：团队

1、团队的敏捷性依赖于对技术、过程和架构持续的改进。

2、保持简洁，尽最大可能减少不必要的工作。

3、最佳的架构、需求和设计出自于自组织的团队。

4、定期反省总结如何改进研发过程，并制定具体计划改进。

 

反馈：

1、结对编程：质量，减少犯错，集体所有。

2、计划游戏：用户故事，优先级排序。

3、测试驱动开发：测试代码先行。

4、客户加入团队。

 

我们自己的实践，适合的就是好的：

结对编程、代码规范、源代码管理、代码review、每日提交、交叉测试、重构、分享会议、简单设计、自动化、框架。

 

SCRUM特点：

1、团队实施自我管理。

2、产品开发一sprint为单位进行迭代。

3、使用产品的backlog记录产品需求。

4、并没有特定的工程实践。

5、Uses generative rules to create an agile environment for delivering projects.

 

串行工作和并行工作（SCRUM并非小瀑布）

需求-->设计-->代码-->测试，SCRUM不是串行完成这些流程，而是采用并行的方式。

 

SCRUM MASTER

1、对项目的直接管理。

2、领导团队完成Scrum的实践以及体现其价值。

3、排除团队遇到的困难。

4、保证团队的效率和状态。

5、做好团队的协调和沟通工作，跨角色跨功能协作无障碍。

6、保护团队不受到外来无端影响。

 

 

关于燃尽图：https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog。简单来理解燃尽图是一种折线图，x轴是日期，y轴是小时为单位的数字，对应一个个点就是当天估算的项目剩下工时。理想的曲线是随x的推进y在减少，顾名燃尽图。当然燃尽图更多是能反应一个项目的情况。例如某天突然飙升，可能说这天突然新增需求了，或者说昨天估算错了；又比如一直平稳，最后一天突然燃尽，那么说不定是这各项目的开发人员比较保守。总之，燃尽图能直观地反应一个项目的开发进度和情况。个人觉得确实不错。

 

想法最后在谈。今天第一次参与了迭代讨论会，虽然是反省会议，但对于我这种新人来说也是学习的机会。主要是计划上周发版（大改版）但却临时出现了一堆问题。归结起来三个方面：

一、代码健壮性：除以0？值为null？尤其是从数据库取出来的时候，对象是否为null？然后就直接引用了？或者说值类型为空默认值为0由用在了被除数？很多问题的出现是因为想当然。虽说就IT行业，出来实战学到的要比本科在学校课堂学的多，但是我想目前普遍的一线开发人员写代码写着写着就想当然的去写代码，也许大逻辑错误不会犯，但这种语法上的小细节逻辑错误倒不一定了。目前的我也是，上面说的情况在前三年的实验课中几乎不会发生，但是现在工作了，很多代码都是复制粘贴修改，或者说是简单地模仿，这种跟着别人走的行为很容易会掉入思维陷阱。再者就是谁都无法保证新迭代会不影响旧代码。健壮性还体现在能否兼容老数据或者说不至于让老数据卡程序，这个事关新代码和老代码的健壮性了。

 

二、测试方面：

1、测试一般只测新功能而不测老功能。那么问题来了，如果老功能因为新功能的存在而影响了呢？产品研发初期会考虑扩展性和保留不少可拓展的特性。例如数据中保留一些属性但暂时不用，由于没有维护所以阶段性不使用该属性作为业务逻辑，但后期迭代新增功能后维护上了该属性，且会影响旧的业务逻辑，那么老功能也得测试。但是如果每次测试都是整个产品每个细节测试，显然不是不划算的。

2、解决方法一：从分支管理入手。依然是尽快交付有价值的产品。当在测试完后的环节中发现bug，如预发版，那么再出现bug就从这个预发版分支上打分支修行修复bug，以防代码混淆。这种方法适用范围很广，也很好地发挥版本管理的作用。

3、解决方法二：让客户和产品经理加入测试。产品经理对产品功能的迭代是十分了解的，一个好的产品经理理应能在加入新功能后想到可能会影响到的旧功能，那么他们测试时就更大概率发现这种老功能的bug。

4、解决方法三：时间放宽，这个其实很不靠谱哈哈哈，毕竟很多事情不是我们开发人员能决定。但是如果真的在测试中发现重大bug若坚持边发版边修复会大大降低产品价值，此时应当大胆提出延迟的请求，SCRUM虽说要尽快交付，但交付的是有价值的产品。

5、解决方法四：开发和测试服务器权限分离。开发时不应当使用测试服务器。这种情况可能是少数，我以我遇到的情况为例。写sql有时候逻辑稍微长一点，很难从代码上核实逻辑正确与否，希望从结果上判断。但是开发数据库往往有很多无效数据和脏数据（开发初期还好，毕竟每次迭代都会还原数据库），会影响判断结果，那么有时我们会改用测试数据库试一下。无意中修改了测试数据库造成测试人员在测试时没法发现错误。

6、附：开发人员要对自己写的代码负责！多试试再提交。以为重复工作（修复无畏的bug）。

记得进入公司刚培训的时候，存哥就说一个产品交付后出问题了，测试肯定是要背锅的，在国内测试氛围不如国外。这次会议我感觉出来也是测试要大部分责任，很多东西为什么没测出来？是方法的不对还是思维的缺陷？一个很奇怪的现象是很多时候一开始出现的问题都不是什么很难测出的问题，这些问题在测试时不会出现，一到了真实的环境就立刻出问题，奇怪的又是测试的一个环节就是基于真是环境测试的。

 

三、第三方服务对团队的影响：程序员不重复造轮子，不免会用一些第三方服务，例如腾讯云阿里云什么的（12306不也用阿里云嘛~），随时更新，说不定一些api就是我们用到的。这次发版前就是遇到这种，突然发现用到的一个腾讯云借口更改了，让我们“措手不及”。像这种其实没有根本性的方法，使用第三方服务就意味着要跟着别人走，只不过我们可以尽量避免不可控。如果常去开发文档看看，起码能有效避免这种“措手不及”。

 

 

小小的拙见：

    公司用的也算是敏捷开发吧。那天去青风一号的沙龙，感觉敏捷开发最佳的定义就是适合自己的能尽快交付有价值的产品的开发方式就是敏捷开发。沙龙中不乏公司的一些技术高层来参与，他们正在转型敏捷开发，但很苦恼。在学术界敏捷开发没有一个统一的标准，倒是提供了不少方法论和工具，像每日站立会议、燃尽图等。刚转型的公司可能会拘泥于这些工具和方法，有时看不到希望而苦恼，所以就来听听过来人的经验。也是就是太纠结了，所以会死扣某些方法，对号入座，不结合公司实情。有个兄弟就坦言自己还是不理解小瀑布和敏捷的区别，他总是努力地让团队不要陷入小瀑布，但是这个团队用了所谓的敏捷方法后也没有敏捷的效果。还是得承认敏捷开发不是银弹。

    再者是沟通成本。团队的内的信息一定要相互沟通，尽可能减少信息不对称。这样也能避免传承问题。产品测试开发虽说是三对头，但其实也是要多沟通。我在公司里就常看到开发和测试两人走得近，会多交流。产品迭代会会让开发测试的人都来开，有什么不懂直接在群里问而尽量少地私聊。代码审核的信息可见的，一个pull requests会通过企业邮箱通知到所有人。就拿上周发版说事，如果说发版时突然发现bug，这时修改bug，无论是谁都应当通知开发和测试的所有人，以免改了一些有用的代码。开发人员在开发时会不停修改配置文件，也应当记录好。云协作是个好东西，通过文字记录好各种文档和脚本等文件，减少沟通成本。在一个开发团队里，并不是多人效率就高，因为多人同时多沟通成本。一般敏捷开发的团队也就7±2人。每日站立会议等会议就是沟通的一种很好的方式。

    可控。我记得这个概念最初深入我心的是在操作系统这门课上。磁盘调度算法中CSCAN（单向循环扫描）调度算法其实并不比SCAN（循环扫描）调度算法快，但我们却认为CSCAN调度算法更优，原因是它有较好的预估性。不可控的东西是很可怕的。

    节奏感：敏捷开发的一个sprint大约是3-4周，而极限编程大概是1-2周。好的团队应当有一个好的节奏感，不快不慢，归根到底就是一种可控。要避免同一时段多人请假这种情况也是一个敏捷开发团队需要注意的细节。发版完后的这一周，我竟然问一个同事发完版有什么做？典型的非学霸学生思维，考完试就浪。迭代开发的关键是迭代，发完一版自然要有下个迭代周期，而且还要跟踪用户反馈的bug。显然我得转换我的学生思维了。这个和节奏感也有关系，学霸之所以为学霸大概就是学习的节奏感强吧？扯远了。我所在的团队节奏感还是可以的，不会说出现大批量请假的情况，也不会说一个人请假就整个项目耽误的情况。我在想燃尽图能否反应一个团队的节奏感呢？上面说的可控和节奏感也是有关系，失去节奏感，项目就变得不可控了。

    文档最小化是我接触敏捷开发时最深刻的概念。大一大二写些小程序不需要文档，大三开始有课程设计，需要写比较详细的实验报告，其实这就是文档了。接触github后发现好的项目不乏readme文档；自己强迫症会保留很多课程资料，整理时发现很困难。基于此，我慢慢地给每门课的资料写readme文档方便自己日后管理，而且很快我也感觉到文档的优势。在课堂上听过老师说开发文档不可缺少，传统的瀑布模型会有详细的开发文档。那么敏捷开发的文档最小化究竟是什么？我进入公司后，师傅先让我进入了一个云协作的笔记群，里面有很多规范文档。慢慢地开始进入项目开发，会写设计文档，会有接口整理文档，产品那一块会有需求文档，好像文档也不少？究竟是不是敏捷开发呢？我无从而知。但我会去试想没有这些文档会怎样？刚才也提到一个沟通问题，面对面沟通效率是高，但无法查阅，因此有些会议会有会议记录。因此文档最小化这个定义很虚，还不如用合适这个词来形容。必要的文档能有效地降低沟通成本。

   价值观的问题。这个就玄乎了，志同道合才能写好代码。如果有人不认同敏捷开发的价值观，那让他配合就扯淡了。

   还有同行认为敏捷开发要发挥优势，不止要团队所有人认同这个价值观，还需要都是有不少开发经验的人。其实我是赞成的。虽说目前开始为项目做贡献了，但总觉得没完全融入这个团队，心里总缺些东西。也可能是我自己刚步入职场，很多东西没能适应。反正如果团队中的人都是有开发经验的人，必定会更上一层楼。还需努力。