标签：提交 重构 功能 reason 代码 这一 评价 能力 admin
二十天，四个迭代，四次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，以减少对页面加载速度的影响。
标签：提交 重构 功能 reason 代码 这一 评价 能力 admin
原文地址：http://www.cnblogs.com/teLumy/p/6188982.html
