Transfer: Code AGRICULTURAL stand (Micro Signal: coderising)
Agility means is responsive, responsive Why? 996 to see so many companies know, the market changes faster and faster, customers increasingly demanding, in order to meet the needs of users, people one week to send a version of We Three months to a Biechu to, it will not be fight Mandizhaoya?
The question is how to react quickly? First look at a scene:
1, the harsh reality
Software development has a major problem is that the customer needs in mind is difficult to describe , we usually way to deal with something like this:
Consolidation needs to take a few months, every day, and customer discussion, draw a flow chart of several hundred pages, written thousands of pages of documents, and finally put the customer almost get confused.
Followed by detailed design, development, testing, our powerful technical team which started everything strictly according to plan, everything looks very perfect, it appears that the successful conclusion of the project right away!
But the customer acceptance tests gave us a blow:
this interface is how less of an option?
How the interface can not jump, that function needs to lead a back door, and I can not change how business rules?
what? Write died in the code? Well, you do system ah, simply can not be used!
Everyone is depressed, months of hard development seems to go down the drain.
From this scenario we can see that we get from our customers needs and requirements described in the document, in fact, from the customer really want the software very much worse.
In the waterfall model of development, acceptance testing found the problem, in order to correct the price is very high.
2. Improve
One idea naturally emerges: in order to avoid the collapse of the last habitual, regular customers can not be allowed to do acceptance testing?
让他们经常性的去使用一个可以工作的软件， 从而告诉我们那些地方还有欠缺 ？ 那些地方做错了？ 这样我们可以迅速的修改， 这样我们就会轻松多了 ！
我们可以把软件开发划分成一个个小的开发周期， 例如每个周期就两三周时间， 在这两周之内我们完成一个或几个功能， 然后就让用户去试用， 有问题立刻反馈，在下一个开发周期马上改掉。 这样就可以逐步逼近客户的最终目标。
这还带来了一个额外的好处， 不用花费巨长的时间来分析，整理冗长的需求文档了。
听起来很美是不是？ 但是仔细想想这里边的问题很多。
1. 抛弃了冗长的需求文档， 但还是得描述需求啊
需要发明一个简单的、主要用来促进客户和开发团队沟通的描述形式， 这个新的形式叫做用户故事， 这里有个用户故事的例子：
这是一个卡片， 背面还会记录下针对需求的讨论和验收标准。
用户故事主要彰显的是： 谁做了什么事， 带来什么商业价值。
2. 怎么决定每个小开发周期（我们称之为迭代吧）要开发的东西？
用户故事得有估算， 得有大小， 太大了一个迭代开发不完 ， 还得拆分一下。
我们需要对需求按照优先级进行排序， 按照优先级从高到低的原则来开发。
3. 不要架构设计了吗？
一上来就按优先级选择需求， 直接进入迭代开发， 把架构师撂在一边，合适吗？
架构工作肯定还是需要的，在正式的迭代周期开始之前需要架构设计， 但是和设计出面面俱到的架构设计不同， 我们更需要演进式的架构， 随着迭代的推进而进化。
4. 那详细设计怎么办？
在每个迭代开始的时候，团队在一起把这些用户故事给拆分成一个个小的任务， 这个拆分的过程就相当于详细设计了。 对于一些特别复杂的，例如算法， 当然可以写文档，帮助大家理解。
5. 由于是迭代式开发， 这个迭代周期修改上一个迭代周期的代码在所难免， 怎么保证不破坏原有的功能？ 总不能每次都手工重测一遍吧？
This is definitely a major difficulty, the answer is automated regression testing, including unit testing and functional testing.
Developers write code, we must also wrote automated unit testing, testers need to develop automated functional testing, so once you have to modify the code, you can run them, examine the existing features have not been destroyed.
Such as continuous integration infrastructure is essential, every day, every hour, even every submission will trigger the code to compile, package, deploy, test this process.
6. such a short development cycle, testers to test how ah?
Development and testing need to go, when a developer when clarifying requirements, the test need to be involved, when developing the coding time, testers to write test cases, until the completion of a user story development, we can immediately put into test.
7. It seems development requires close collaboration between the test, how to communicate between them?
Certainly face to face communication, there are problems went there to ask the other side of the seat, the best seat everyone together, turned to discuss, reduce inefficient use of tools telephone, QQ / micro-letters as possible.
The development team is open every day of about 15 minutes a station will show their progress and plans, so that progress remains transparent, timely expose and solve problems.
8. When the customer acceptance testing can be done?
Always welcome, but we prefer iteration ends after this time the feature will stabilize, we will give customers to do a presentation, tell him the iteration is complete the work, he also invited to test the software, give us feedback.
Of course, customers may find problems, even new demands, we welcome our customers to and cooperation, not confrontation.
In addition to the customer presentation outside our own will reflect and see those places to do good, to continue to maintain; those places do well to continuous improvement.
As you might understand, this looks beautiful iterative development methodology is not very easy to implement, if we give it a name, you can be called: Agile Software Development.