做敏捷开发的步骤:一、将大的系统拆分成子项目;二、团队与客户呆在一起;三、用建模方式沟通;四、敢于迎接变化;五、尽早、持续的交付可运行的阶段性成果;六、面对面的沟通;七、可工作的软件是最主要的衡量标准;八、保持恒定的开发速度;九、定期团队优化。
一、将大的系统拆分成子项目
敏捷方法是会将大的系统拆分成一个个子项目,再把子系统拆分成子模块,尽量减少模块间的耦合性、增加其内聚性,这样我们可以把团队分成多个小组,各组可以同时作业。另外,当一个模块需求发生变化时,对其它模块的影响也不会太大,以实现降低开发难度的目的。
二、团队与客户呆在一起
为了降低沟通成本,我们团队所有人员直接开到客户现场,随时与客户沟通,通过面对面的沟通,减少了理解偏差。在项目的各个阶段,我们一直与客户保持零距离接触,随时交流、沟通。通过这种办法,可以第一时间获取需求、第一时间解决问题,减少出错的可能性,提高开发效率,保证开发质量。而且,通过这种方式会更容易取得客户信任,客户能够随时了解到项目的工作状态、工作进度。当相互间具备了信任关系后,余下的工作也会变得轻松、愉快。
三、用建模方式沟通
利用模型与客户沟通,用模型来获取用户需求,而不是通过大量的文档,编写文档费时费力,而且效果不好。实际,对于我们大多数人来说并不喜欢花大量时间看各种文字和参数,而模型则会更直观和立体。这里我说的模型不是单指我们平时设计的原型,它包括用例图、类图、部署图、状态图、活动图、包图、对象图、原型图、效果图、E-R图等,利用不同图形表达出产品的不同维度,使产品丰富而立体。
四、敢于迎接变化
市场环境是产品的风向标,我们要随时关注市场。为了迎合市场,产品也要随时变化。需求变化、设计变化……各种变化让我们焦头烂额,但做为产品人的我们同样也应该接受改变,只有产品的快速变化,才能很好的迎接未来。我们欢迎变化,只要是合理的,哪怕是开发阶段,需求也同样可能发生变化。
敏捷开发允许变化,通过变化给客户带来更大的竞争力。敏捷开发利用图表来记录需求,所有代码都采用模块式设计,将不同功能尽量分割,减少关联。这就是它能够、也敢于迎接变化的原因。
五、尽早、持续的交付可运行的阶段性成果
之前我曾经说过,一个项目的失败,一般不是技术原因,多是因为客户对我们失去信任。我们需要持续的、不断的给客户以信任感,一种是我们在客户现场不断的交流、沟通,让客户感受到我们的热度。同样,还需要尽早的、持续的给客户提供相应的成果物(可运行的产品),让客户看到我们的能力。
当然,这样还有另一个好处是,能够把问题提早的暴露出来,不要羞羞答答像个小女人,不敢见人,只有提前暴露,才能提早解决,问题越晚暴露越难解决。
六、面对面的沟通
最快的交流方式就是面对面的沟通,在敏捷开发中,最提倡的方式是减少哪此冗余的、效率低下的沟通方式,用最快速的方法来直接沟通。让技术人员、设计人员、客户等所有团队成员都在一起办公,减少信息交流的断路,让沟通变得顺畅。
七、可工作的软件是最主要的衡量标准
出再多的文档、再多的中间产物,都没有出结果来得真切。客户最观心的不是中间物,而是成果物。对于敏捷软件开发来说,可以工作的软件是评测开发进度的最主要衡量标准。唱的再好,也不如做的好,做事要落地,实实在在、踏踏实实是敏捷开发的核心,不玩花拳绣腿。
八、保持恒定的开发速度
项目开发是一次长跑,短期内迅速的加速,并不是长跑的方式,我们应该持续的、匀速的跑步方式,这样才能保证团队成员能一直坚持到最后。敏捷开发提供可持续的开发速度,这样不仅团队成员不至于疲惫,也有利于制定项目开发进度,控制开发周期。
九、定期团队优化
我们会每隔一段时间进行一次团队建设,进行批评与自我批评,找出工作中的问题及影响个人与团队发展的瓶颈。我们通过交流、沟通方式找出团队及成员间的问题,然后进行自我调整,通过不断的优化、升级自有团队,打造出一个能战斗的队伍。
延伸阅读:
什么是敏捷开发?
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷建模(AM)定义了一系列的核心原则和辅助原则,它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们的而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于XP的原则,我们可以从另一个角度来看待。
文章标题:如何做敏捷开发,发布者:Flawy,转载请注明出处:https://worktile.com/kb/p/47366