Agile means being responsive, so why be responsive? If you look at so many 996 companies, you can see that the market is changing faster and faster, and customer requirements are getting higher and higher. In order to meet the needs of users, people send a version a week, and we can only get one in three months. Beating all over the place to find teeth?
The question is how to react quickly? Let's first look at a scenario:
1. The cruel reality
A major problem in software development is that it is difficult to describe the needs in the customer's mind. Our usual response method is this:
spend a few months sorting out the requirements, talk with customers every day, and draw Hundreds of pages of flowcharts, thousands of pages of documentation, and finally the client is almost dizzy.
1. The cruel reality
A major problem in software development is that it is difficult to describe the needs in the customer's mind. Our usual response method is this:
spend a few months sorting out the requirements, talk with customers every day, and draw Hundreds of pages of flowcharts, thousands of pages of documentation, and finally the client is almost dizzy.
Then came the detailed design, development, and testing. Our strong technical team started. Everything was carried out strictly according to the plan.
But the customer's acceptance test gave us a blow: why is this interface missing an option? Why can't the interface jump, that function needs to give the leader a backdoor, and why can't my business rules be changed? What? Dead in the code? Alas, the system you made is simply unusable!
Everyone was depressed, and months of hard development seemed to be in vain.
What can be seen from this scenario is that the requirement descriptions and requirement documents we get from the customer are actually far from the software that the customer really wants.
In the waterfall development model, the problems found by the acceptance test are very expensive to correct.
But the customer's acceptance test gave us a blow: why is this interface missing an option? Why can't the interface jump, that function needs to give the leader a backdoor, and why can't my business rules be changed? What? Dead in the code? Alas, the system you made is simply unusable!
Everyone was depressed, and months of hard development seemed to be in vain.
What can be seen from this scenario is that the requirement descriptions and requirement documents we get from the customer are actually far from the software that the customer really wants.
In the waterfall development model, the problems found by the acceptance test are very expensive to correct.
2. Improvement
An idea naturally emerged: In order to avoid habitual collapse in the end, can customers be allowed to do acceptance tests frequently?
Let them use a working software on a regular basis, so as to tell us what is missing? Where did it go wrong? This way we can make changes quickly, and it'll be a lot easier for us!
We can divide software development into small development cycles. For example, each cycle takes two or three weeks. Within these two weeks, we will complete one or several functions, and then let users try them out. If there are any problems, they will immediately feedback. Change it right away in the next development cycle. In this way, the final goal of the customer can be gradually approached.
This has the added benefit of not taking a huge amount of time to analyze and organize lengthy requirements documents.
An idea naturally emerged: In order to avoid habitual collapse in the end, can customers be allowed to do acceptance tests frequently?
Let them use a working software on a regular basis, so as to tell us what is missing? Where did it go wrong? This way we can make changes quickly, and it'll be a lot easier for us!
We can divide software development into small development cycles. For example, each cycle takes two or three weeks. Within these two weeks, we will complete one or several functions, and then let users try them out. If there are any problems, they will immediately feedback. Change it right away in the next development cycle. In this way, the final goal of the customer can be gradually approached.
This has the added benefit of not taking a huge amount of time to analyze and organize lengthy requirements documents.
Sounds beautiful doesn't it? But think carefully about the problems here.
1. Abandon the lengthy requirements document, but still have to describe the requirements.
Need to invent a simple description format that is mainly used to facilitate communication between customers and development teams. This new format is called user stories. Here is an example of a user story:
Need to invent a simple description format that is mainly used to facilitate communication between customers and development teams. This new format is called user stories. Here is an example of a user story:
This is a card with a discussion of requirements and acceptance criteria recorded on the back.
User stories mainly demonstrate: who did what and what business value it brings.
User stories mainly demonstrate: who did what and what business value it brings.
2. How do you decide what to develop in each small development cycle (let's call it an iteration)?
User stories have to be estimated and have a size. If they are too large, they cannot be completed in an iterative development, and they have to be split.
We need to prioritize the requirements and develop them according to the principle of priority from high to low.
User stories have to be estimated and have a size. If they are too large, they cannot be completed in an iterative development, and they have to be split.
We need to prioritize the requirements and develop them according to the principle of priority from high to low.
3. Don't want to architect?
As soon as it comes up, select the requirements according to the priority, directly enter the iterative development, and put the architects aside, is it appropriate?
Architecture work is definitely still needed, and architecture design is required before the formal iteration cycle begins, but instead of designing a comprehensive architecture design, we need an evolutionary architecture that evolves as the iteration progresses.
As soon as it comes up, select the requirements according to the priority, directly enter the iterative development, and put the architects aside, is it appropriate?
Architecture work is definitely still needed, and architecture design is required before the formal iteration cycle begins, but instead of designing a comprehensive architecture design, we need an evolutionary architecture that evolves as the iteration progresses.
4. 那详细设计怎么办？
在每个迭代开始的时候，团队在一起把这些用户故事给拆分成一个个小的任务， 这个拆分的过程就相当于详细设计了。 对于一些特别复杂的，例如算法， 当然可以写文档，帮助大家理解。
在每个迭代开始的时候，团队在一起把这些用户故事给拆分成一个个小的任务， 这个拆分的过程就相当于详细设计了。 对于一些特别复杂的，例如算法， 当然可以写文档，帮助大家理解。
5. 由于是迭代式开发， 这个迭代周期修改上一个迭代周期的代码在所难免， 怎么保证不破坏原有的功能？ 总不能每次都手工重测一遍吧？
这个绝对是一大难点， 答案就是自动化的回归测试，包括单元测试和功能测试。
开发人员写代码的同时，也要写下自动化的单元测试，测试人员需要开发自动化的功能测试， 这样一旦有了代码的修改，就可以运行它们，检查现有功能有没有被破坏。
像持续集成这样的基础设施是必不可少的，每天、每小时、甚至每次代码提交都会触发编译，打包、部署、测试这样的过程。
这个绝对是一大难点， 答案就是自动化的回归测试，包括单元测试和功能测试。
开发人员写代码的同时，也要写下自动化的单元测试，测试人员需要开发自动化的功能测试， 这样一旦有了代码的修改，就可以运行它们，检查现有功能有没有被破坏。
像持续集成这样的基础设施是必不可少的，每天、每小时、甚至每次代码提交都会触发编译，打包、部署、测试这样的过程。
6. 这么短的开发周期， 测试人员怎么测试啊？
开发和测试需要同步进行， 当开发在澄清需求的时候， 测试需要参与， 当开发在编码的时候， 测试人员在编写测试用例，等到一个用户故事开发完，马上就可以投入测试。
开发和测试需要同步进行， 当开发在澄清需求的时候， 测试需要参与， 当开发在编码的时候， 测试人员在编写测试用例，等到一个用户故事开发完，马上就可以投入测试。
7. 看来开发、测试之间需要紧密的协作， 它们之间怎么沟通？
肯定是面对面的沟通，有问题就跑到对方的座位那里去问，大家的座位最好在一起， 扭头就可以讨论，尽可能减少效率不高的电话、QQ/微信等工具的使用。
开发团队每天都开一个15分钟左右的站会， 展示自己的进展和计划， 让进度保持透明， 及时暴露问题，解决问题。
肯定是面对面的沟通，有问题就跑到对方的座位那里去问，大家的座位最好在一起， 扭头就可以讨论，尽可能减少效率不高的电话、QQ/微信等工具的使用。
开发团队每天都开一个15分钟左右的站会， 展示自己的进展和计划， 让进度保持透明， 及时暴露问题，解决问题。
8. 客户什么时候可以做验收测试？
随时欢迎，但是我们更倾向于迭代结束以后，这时候功能会稳定下来，我们会给客户做一个演示，告诉他这个迭代完成的工作，邀请他也测试一下软件，给我们反馈。
当然客户可能会发现问题，甚至提出新的需求，我们表示欢迎，我们要和客户合作，而不是对抗。
除了给客户演示之外，我们自己还会反思一下，看看有那些地方做的好，要继续保持；那些地方做的不好，要持续改进。
估计你也明白了，这种看起来很美的迭代化开发方法实施起来挺不容易的， 如果我们给它起个名字的话， 可以叫做：敏捷软件开发。
随时欢迎，但是我们更倾向于迭代结束以后，这时候功能会稳定下来，我们会给客户做一个演示，告诉他这个迭代完成的工作，邀请他也测试一下软件，给我们反馈。
当然客户可能会发现问题，甚至提出新的需求，我们表示欢迎，我们要和客户合作，而不是对抗。
除了给客户演示之外，我们自己还会反思一下，看看有那些地方做的好，要继续保持；那些地方做的不好，要持续改进。
估计你也明白了，这种看起来很美的迭代化开发方法实施起来挺不容易的， 如果我们给它起个名字的话， 可以叫做：敏捷软件开发。
华为已经推出了一款基于敏捷开发的平台—— 华为软件开发云 ，它能在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。对于各个企业来说，可以利用软件开发云的互联网连接能力，能基于需求在云端进行交流、沟通、分析，实现跨区域协同开发，实现DevOps研发模式的落地应用，可大幅度提高开发效率，缩短交付周期、提高代码质量，有效避免了项目返工。实现项目的团队评估能力，提升业务接单的可度量性。
了解华为软件开发云 ，可扫一扫下图，关注回复“ofo”还可领取小黄车90天月卡（30+30+30）+定制超大竞技游戏鼠标垫+华为小天鹅蓝牙音箱！！
了解华为软件开发云 ，可扫一扫下图，关注回复“ofo”还可领取小黄车90天月卡（30+30+30）+定制超大竞技游戏鼠标垫+华为小天鹅蓝牙音箱！！