记首次敏捷开发

  二十天,四个迭代,四次presentation。

  迭代一

    作为前台,其余5人反复确认页面设计需求,需要提供几个参数,变变量名是什么,分别以什么形式传递,使用form表单的话,action路径填什么。第一次会怀疑自己的沟通能力,永远都会有些许出入,后期再重新调整,但至少这还在可调整范围内,有些人独行惯了,对于自己的东西总会有些突发性的新想法,而不顾前台实现情况,“反正也差不多啊,改动又不会很大”,真想呵呵他一脸,可是生气也还是要微笑啊,继续沟通。

    就个人而言,由于沟通耗时长,且经验匮乏,一个系统的基础页面——登录和页面主体框架模板在不考虑美观的情况下算是实现了,也分别完成了后台功能实现者所对应的功能展示页面,同样也是不考虑审美的情况。

  迭代二

    重复上一迭代——沟通,但至少有了一期的铺垫与磨合,后期变动不会太大,只是这一阶段,功能页面较多,涉及到的数据交互比较繁琐,导致后期测试任务繁重,反复输出甚至去断点测试以排查问题。

    沟通耗时不长,但是一个人同时写七到八个页面,经验不足的情况下,还是没有多余的精力去考虑界面风格、细节优化等方面

  迭代三

    因为沟通确实好费时间,且界面设计速度过慢,我组选择改变策略,每个功能实现者完成各自页面Demo,后期统一修改。利用这时的空余时间,我开始大量寻找素材插件等资源用于修改界面风格,其中包括一个粒子背景效果带验证码生成及校验的登录界面,AdminLTE——使用bootstrap包括多种换肤风格的控制面板主题,由于现有资源不匹配需求,又自行编写了table、reason弹出层的统一风格,基本上在这一迭代重构了整个系统界面。期间,修改别人页面代码也是遇到种种困难,每个人都有自己的书写习惯,可能会去使用插件,会用原生js,甚至重新导入不同版本的jQuery等,所以整个webContent变得无比凌乱。而其中最大的问题在于,同组某成员X未经沟通,设计了自己的界面,继而实现功能,但后期我发现前台无法如他那般设计,也就需要修改后台代码,对方表达了抗拒,最终全组协调后,同意前台方案,但最终实现时,他在编码过程中发现缺少某参数否则无法完成功能,就自行添加上代码,而并未与前台进行沟通,最终页面无法实现。

    Presentation时,突发状况,演示电脑突然断网且无法重新连接,而组内外网数据库数据又未及时更新,没有数据,导致暴露出后台许多空指针异常错误未能处理。更换电脑后,该台电脑使用者又未及时更新代码,导致后续成员未能如期演示各自功能。而成员X第三次更换电脑,以演示自己准备的不同版本的Demo。所以,整个第三次迭代演示,被老师评价为“如果你们公司的负责人在场,你们6个当场就会被fire掉”。很沮丧,但至少提前暴露了我组准备不足的缺点。数据库更新不及时,个人代码更新提交不及时,导入文件未备份至每个人,即需要保证每台电脑所演示的都是同一版本。

    而我到现在也没理清楚到底是先自己经过沟通书写功能页面,后期再统一转换风格还是让他们先各自实现页面demo再统一修改会更好,可能后续经验丰富后,处理起来会更加得心应手吧。

  迭代四

    第一次敏捷开发就遇到了人员变动,还是在如此关键的时刻,也不知是幸或不幸。第四迭代刚开始,上述成员X因与前台页面实现沟通未能达成一致,不愿修改自己代码,被另一成员J呛声,前台做自己的页面,写完他来实现功能就行了。成员X宣布罢工,都你们自己做,我不干了!沟通未果,执意退组。公司负责人介入,未能改变局面,宣布我组减少一人。该成员X在我组主要负责数据库创建及维护,后期兼功能实现,故除却功能部分需重新编写,数据库也得派人维护,加重了全体组员的负担与压力。但好歹最终算是有惊无险的完成了最终项目。

    学会了优化界面,人性化处理操作,增强用户体验感。会去纠正js书写规范,合并同类css,以减少对页面加载速度的影响。

时间: 2024-12-08 21:13:49

记首次敏捷开发的相关文章

记敏捷开发——Scrum

前言 首先说说为什么会接触到敏捷开发,因为自己跳槽了,进入一家新的互联网公司,公司用的是敏捷开发的开发模式,进行产品开发的迭代.公司的产品是一个线上平台,说白了就是电子商务,主要做智能办公,其中涉及到一些东西就不一一细说了.回到正题,其实自己也一直想接触这种模式,一来是这种开发模式被越来越多的企业所采用,二来是自己也想学习一些心得东西来提高自己的水平.之前任职于一家科技公司,时间久了就觉得比较乏味.思考良久,还是决定换个环境,换种思维,接下来说重点. 主题 ————以下是我搜集的一些资料————

互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?

作者:暗灭 第一   为什么需要敏捷开发. 在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多.总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求. 怎么办?继续改.这一改又是半年多的时间过去了.马丹用户的需求还再改,怎么办? 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大.文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多.

从瀑布模型到敏捷开发——认识论决定行为

技术交流会中,让我印象最深的是:大勇学长和丹姐在切磋实际项目中用到的"敏捷开发",后来由向阳学长对比两人的观点发问"敏捷开发和瀑布模型的优缺点?人员要求?流程?"最终由我们敬爱的米老师做高层次的总结. 下面,本人根据学长们的建议,并参阅网上资源对"敏捷开发和瀑布模型做对比分析" 软件开发模型的由来 20实际60年代中期,人们在软件开发过程和维护中所遇到的问题被称作是"软件危机". 1968年,在德国召开的NATO(北大西洋公约

谈谈敏捷开发

我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣.从那时开始有了迭代开发的概念.随着项目经验的增加迭代的重要性也越发觉得明显.随后进入了提倡敏捷开发的公司,被迫式的接触了许多"敏捷开发",随着项目经历越来越多,慢慢的就开始有了更新的认识和想法. 但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是: 1.项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发

浅谈敏捷软件开发与传统软件工程的对比与敏捷开发产生的原因

引言 在"计算机程序的蛮荒时代",人们对于程序的设计.编写是随想随写.灵活变化的.正如我们初学各种编程语言时那样,似乎把程序写对也不是什么很难的事情.然而,这种程序设计模式或许适用于几百行至几千行的小程序,而当我们面对更大的软件规模.更多的代码行数以及更复杂的人员架构时,这种随想随写的程序开发模式似乎不再适用,于是使人们遇到了「软件危机」,进而促使了软件工程这样一门学科的产生. 在我上一门程序设计的课程的时候,老师讲过,当我们学习各种语言.算法和数据结构时,我们学习的是怎样进行&quo

杨学明老师推出全新课程--《敏捷开发&IPD和敏捷开发结合的实践》

课时:13小时(2天) 敏捷开发&IPD和敏捷开发结合的实践 讲  师:杨学明 [课程背景] 集成产品开发(IPD).集成能力成熟度模型(CMMI).敏捷开发(Agile Development)是当前国内外企业产品研发管理的最常用的3种模式.随着创新环境的快速发展,许多企业都会面临这样的问题:如何快速响应市场的变化?如何推出更有竞争力的产品?如何在竞争中脱颖而出?……是大部分研发型企业普遍面临的核心问题.另外,软件项目在产品开发中位置越来越重要,逐渐占领主导地位,这时传统的IPD流程和CMMI

读书笔记 -《高效程序员的45个习惯-敏捷开发修炼之道》

<高效程序员的45个习惯-敏捷开发修炼之道> 一本2010年出版的书,当时敏捷还只是在国外开始流行,像我这种菜鸟级根本听都没听过.这次通读了这本书,受益良多,回顾自己的职业生涯,多是漫无目的的瞎混,为了生活而生活而已.通过这本书才算对敏捷有了初步的了解,并有意向敏捷进行实践.愿此文可结识更多敏捷的先行者,带领我进入敏捷的世界. 第一章. 敏捷--高效软件开发之道 名言:  不管路走了多远,错了就要重新返回   -- 土耳其谚语 敏捷开发宣言  个体和交互 > 过程和工具 可工作的软件 &

敏捷开发 之 计划、测试 与 重构

前言 本系列内容为 Robert C. Martin 敏捷开发一书的读书笔记,上一篇概述了敏捷开发的一些基本原则,这一篇 针对其中较重要的 计划.测试 和 重构 分别做介绍. 一. 计划 1. 初始探索 项目开始阶段,开发人员和客户要尽量确定出那些真正重要的用户素材,不要试图去找出所有的用户素材. 开发人员共同对这些素材进行估算.用“点数”来表示实现素材所需要的相对时间. 过大或过小的素材都是难以估算的. 随着项目的进展,由于可以度量每次迭代中已经完成的用户素材点数,所以对于速度的度量会越来越准

敏捷开发 之 理论概述篇

一. 敏捷实践 1. 敏捷宣言 个体与交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作   胜过 合同谈判 响应变化   胜过 遵循计划 1.1 个体与交互胜过过程和工具 合作.沟通以及交互能力要比单纯的编程能力更为重要. 工具要选用合适的,不要一开始就盲目选择所谓强大的.要从小工具开始尝试,直到无法适用再去更换. 1.2 可以工作的软件胜过面面俱到的文档 面面俱到的文档需要花费大量的时间成本来编写和维护.过时的文档比没有文档更具危害性. Martin文档第一定律:直到迫切