首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于敏捷的一点思考

关于敏捷的一点思考

作者头像
小端
发布2018-04-16 11:48:05
5890
发布2018-04-16 11:48:05
举报
文章被收录于专栏:java架构师java架构师

最近公司研发部在注重流程化、标准化的基础上,引入了敏捷的概念,并在刚刚做完的一个小项目中做了初次的尝试。

同时,最近自己在看《敏捷软件开发:原则、模式与实践》,研究关于敏捷的东西,有一些基本的想法,在此分享。

角色:

1、客户:定义产品的特性并排列这些特性优先级的人或者团体。

2、开发人员:响应客户的需求,实现这些特色的人或者团体。

个人认为敏捷开发中适宜采用的几个方式为:

一、和客户在一起工作,让客户融入团队。

      彼此知晓对方所面临的问题,并共同去解决这些问题。

      最好的交流方式,就是面对面的交谈。

      客户合作胜过合同谈判。

      我们项目中做的就是:固定的每天早晨有一个小型的、简短的、但是保证有效的沟通例会,

       共同的任务:先跟踪前一工作日若干问题的解决情况,并标注那些尚未能解决问题的原因、并提高其优先级。

     产品人员:提出对需求的新的想法、对已有功能的修改要求以及一些需要从技术角度进行解释的疑问等。

     开发人员:确认对变化的理解,并给出对应的响应。然后提出在开发过程中对需求的疑惑,或者说是不看明确的地方,由产品人员确认。最后,给出具体的计划。 

二、尽早的、频繁的交付软件,哪怕是未成形的,存在着很多bug的初级版本。

     根据XP理论,初期交付的系统包含的功能越少,最终交付的产品,质量也就越高。个人理解,这句话是提醒我们,应该尽早的让客户完全融入到系统的形成流程中来。

     由于项目较小,迭代周期保持在三到四个工作日。初期未形成可堪使用的图形界面时,开发人员用图表、简易图的方式向开发人员尽量描绘清楚设计的基本框架,

     并得到双方确认。图形界面开发出来后,及时提供给产品人员,与之前的心里预期进行比对,并在每次晨会提出修改意见。

这样,在项目完结时,我们提供的产品是倾注了开发、产品人员的共同思考的,基本是符合双方心理预期的。

三、欢迎需求的变更

    需求的变更,一直是被开发人员所深恶痛绝的事情,但是,随着客户对需求有了更深刻的认知,甚至开发人员对需求有了更清晰的理解,都有可能带来需求的变更。躲不掉!

而XP的精髓,恰恰是,欢迎变更需求,敏捷过程的参与者不惧怕变化。因为那些改变意味着团队已经学到了很多如何满足市场需求的知识,那么我们该怎么做?

    保持软件结构的灵活性(这个正在研究,以后补充)

    欢迎,并不是意味着毫无原则,而是,和客户一起来分析变更的需求,评估变更所带来的预算、工期等一系列影响,制定变更与否、甚至变更程度的计划。

待续......

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2011-11-25 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档