博客补发-敏捷开发学习

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了博客补发-敏捷开发学习相关的知识,希望对你有一定的参考价值。

参考资料:http://baike.baidu.com/link?url=Sr0U52SUMhFl0jdpQQM0BoER5P1gHx8jEul4Rfg518v9SLp0qg4C2c1Twb5KyYTh6B4Ght9m_AVlestiUHploa

 

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

 

价值观

敏捷建模(Agile Modeling,AM)的价值观包括了XP(Extreme Programming:极限编程)的四个价值观:沟通、简单、反馈、勇气,此外,还扩展了第五个价值观:谦逊。 

 

遵循原则

单一职责原则(SRP)
就一个类而言,应该仅有一个引起它变化的原因。
 
开放-封闭原则(OCP)
软件实体应该是可以扩展的,但是不可修改。
 
Liskov替换原则(LSP)
子类型必须能够替换掉它们的基类型。
 
依赖倒置原则(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
 
接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
 
重用发布等价原则(REP)
重用的粒度就是发布的粒度。
 
共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
 
共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
 
环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
 
稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
 
稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。

 

1. 快速迭代
相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年仅发布仅2~3个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。
2. 让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。 同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。
3. 编写可测试的需求文档
开始就要用“用户故事”(User Story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。
4. 多沟通,尽量减少文档
任何项目中,沟通都是一个常见的问题。好的沟通,是敏捷开发的先决条件。在圈子里面混得越久,越会强调良好高效的沟通的重要性。
团队要确保日常的交流,面对面沟通比邮件强得多。
5. 做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档,但人人都会看图。
6. 及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发,测试用例很晚才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。较早地开始编写测试用例,当需求完成时,可以接受的测试用例也基本一块完成了。

以上是关于博客补发-敏捷开发学习的主要内容,如果未能解决你的问题,请参考以下文章

如何敏捷开发 如何快速迭代

博客补发-UML图学习之类图

腾讯敏捷开发及快速迭代

第三次博客

敏捷开发实践:快速迭代让我们的执行力更强

Scrum敏捷开发:迭代计划会议