江苏龙网

  1. 首页 > 资讯 > 科技 > >

■如何实现敏捷软件开发？( 二 )


在房产项目里 ， 我们用原型与客户讨论需求 ， 用ER图沟通数据库设计 ， 用类图来表达产品的对象 ， 用部署图确定硬件部署环境及网络结构 ， 用活动图来说明信息交互流程 ， 用时序图来表达在时间轴下对象间的交互 。通过各种图表来表达产品 ， 利用这种方法会比较直观 ， 而且当发现错误修改起来也容易 ， 不像利用文档方式 ， 修改不方便、维护困难 ， 也不利于阅读、理解 。
总结：利用模型来代替文档进行交流 。
4. 敢于迎接变化
市场环境是产品的风向标 ， 我们要随时关注市场 。为了迎合市场 ， 产品也要随时变化 。
需求变化、设计变化……各种变化让我们焦头烂额 ， 但做为产品人的我们同样也应该接受改变 ， 只有产品的快速变化 ， 才能很好的迎接未来 。
我们欢迎变化 ， 只要是合理的 ， 哪怕是开发阶段 ， 需求也同样可能发生变化 。
敏捷开发允许变化 ， 通过变化给客户带来更大的竞争力 。敏捷开发利用图表来记录需求 ， 所有代码都采用模块式设计 ， 将不同功能尽量分割 ， 减少关联 。这就是它能够、也敢于迎接变化的原因 。
提到了敏捷的一个很重要思想就是“勇于迎接变化” 。
就有人说了 ， 你一定不是技术出身的吧 。做技术的就讨论变化 ， 最不允许的就是确定的需求再修改 。当产品经理与技术人员沟通时 ， 当谈的一个复杂性操作时 ， 经常说：“你确定不会修改了吧 ， 如果你确定需求不变 ， 我就做！” ， 你要答应了 ， 再找技术修改时哪就等于堵死了自己的后路 。
实际 ， 哪能一定有不修改的需求呢？我们做产品不也是时刻在迎接市场的考验吗？
在大海上航行 ， 当风向变化 ， 我们的大船不也得时刻准备掉头 ， 准备调整 。变化 ， 本身就是为了适应 ， 没有变化 ， 就等于没有进步 。
但作为产品经理的我们 ， 能做的应该是利用自己的智慧和敏锐的市场洞察力 ， 尽量的去感知风向 ， 尽量的控制需求 ， 在需求发现初期就做好充足的调研 。
怕变化 ， 不是办法 ， 在项目初期就要做好灵活可调整的方案 ， 如果需求真的变化了 ， 我们应该怎么办 ， 这才是敏捷的思想 ， 需求的变化 ， 我们谁能阻拦得了呢？
5.尽早、持续的交付可运行的阶段性成果
之前我曾经说过 ， 一个项目的失败 ， 一般不是技术原因 ， 多是因为客户对我们失去信任 。我们需要持续的、不断的给客户以信任感 ， 一种是我们在客户现场不断的交流、沟通 ， 让客户感受到我们的热度 。同样 ， 还需要尽早的、持续的给客户提供相应的成果物（可运行的产品） ， 让客户看到我们的能力 。
当然 ， 这样还有另一个好处是 ， 能够把问题提早的暴露出来 ， 不要羞羞答答像个小女人 ， 不敢见人 ， 只有提前暴露 ， 才能提早解决 ， 问题越晚暴露越难解决 。
在房产项目中 ， 当天完成的内容在编译没问题后 ， 会把修改的功能部署到平台服务器上 ， 以便于客户随时能够看到变化 ， 了解项目进度 。如有问题的话 ， 也能够尽早暴露出来 。
总结：为了降低项目风险 ， 尽早交付可运行程序
6. 面对面的沟通
最快的交流方式就是面对面的沟通 ， 在敏捷开发中 ， 最提倡的方式是减少哪此冗余的、效率低下的沟通方式 ， 用最快速的方法来直接沟通 。让技术人员、设计人员、客户等所有团队成员都在一起办公 ， 减少信息交流的断路 ， 让沟通变得顺畅 。
在房产项目中 ， 当有问题不理解 ， 需要交流时 ， 都是直接找我 ， 我不清楚的直接找客户 。当我不在时 ， 同事们也会直接与客户进行沟通 ， 任何人都可以直接获取需求 。
总结：直接沟通 ， 减少中间环节
7. 可工作的软件是最主要的衡量标准
出再多的文档、再多的中间产物 ， 都没有出结果来得真切 。客户最观心的不是中间物 ， 而是成果物 。对于敏捷软件开发来说 ， 可以工作的软件是评测开发进度的最主要衡量标准 。唱的再好 ， 也不如做的好 ， 做事要落地 ， 实实在在、踏踏实实是敏捷开发的核心 ， 不玩花拳绣腿 。


推荐阅读


上一篇：『』出乎意料，5G早来了，原来与4G大不同

下一篇：「Pro」美！vivo X30 Pro果然不一般，轻松记录春分落日，尽显专业实力