Waterfall development , iterative development, the difference [all belong to, life cycle model]
Both are a development mode
, just like the design mode, they are considered from different angles, and I personally feel that it is impossible to replace them.
The traditional waterfall development
, that is, the process from requirements to design, from design to coding, from coding to testing, and from testing to submission, requires each development stage to be the best. Especially in the early stage, the more perfect the design, the less cost loss after submission. The outsourcing project I am currently working on is such a process.
Iterative development
does not require each stage of the task to be the most perfect, but clearly knows that there are still many shortcomings, but does not improve it, but builds the main functions first for the purpose, with the shortest time, with minimal loss, to complete an "imperfect result" until submission. Then through the feedback information of customers or users, it is gradually improved on this "imperfect product".
Both of these two development modes have their own characteristics. Iterative development is suitable for some projects with unclear requirements information, so that the impact of changes in requirements during the development process is smaller than that of
waterfall
development . In many projects now, it is common for requirements to change during the project, so it seems that the advantages of iterative development are more obvious.
However, in essence, both are just a development mode. Even if it is iterative development, in each iterative link, isn't it the same as from requirements to design, from design to coding, and from coding to testing? ? Isn't this also the embodiment of the waterfall model? It's just that each stage in this waterfall does not need to be optimized, and some tasks are reserved for the next iteration.
Therefore, I think that different models are used in the face of different problems. The model is for the convenience of our development and does not require us to follow a certain model from beginning to end.
Like iterative development, we actually use this pattern a lot. For example, a module in the development project. Let's first write the code that can achieve the main function. For example, a query module, first from the concept of the module to the design and then to the coding, first query the code of the function, and test the query successfully. This is the completion of the first layer iteration. Then we have to consider some unfinished details in the first layer of iteration, such as query check, display of query results, and optimization of query algorithms, etc. This is the second layer of iteration.
Waterfall development , agile development, difference [a life cycle model, a collection of project management methods]
Characteristics of the waterfall model
(traditional development method)
1. Emphasize the documentation
The output of the previous stage is the input of the next stage, and the document is the only information connected to each stage. Therefore, many developers seem to be developing documentation, not software, because the "look" of the software cannot be seen until the later stages of development.
2. No iteration and feedback. The waterfall model does not involve feedback, so it is very difficult to adapt to changing customer needs. A waterfall means there is no turning back.
3. The reason why managers like the waterfall model is that the documentation is understood as the speed of development, and the milestones of different phases can be easily defined.
Agile development
The idea of extreme programming reflects the rapid changes in adapting to customer needs, stimulates the enthusiasm of developers, and is also an important supporter of the current agile development thinking.
Agile software development is a new management mode for developing software, which is used to replace the waterfall development mode of file-driven development.
Agile development integrates the common characteristics of the new development model, it emphasizes:
1. Agile is "fast". Only fast can we adapt to the fast pace of the current society, and if we want to be fast, we must give full play to the individual's individual thinking and increase the number of individual thinking.
2. Customer engagement. People-oriented, customers are software users and experts in business understanding. Without the participation of customers, it is difficult for developers to understand the real needs of customers.
3. Emphasize that the product of software development is software, not documentation. Documentation is for software development, not the subject of development.
4. Careful design is for the quality of the final software, but does not mean that design is more important than implementation.
5.迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。
6.小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
迭代开发，敏捷开发，区别【一种生命周期模型，项目管理方法集合】
迭代开发是
一种软件开发的
生命周期模型,与其对应的还有瀑布模型、螺旋模型等等
敏捷开发是
多种软件开发
项目管理方法的集合,其中
包括了XP、Scrum等十几种开发模式,这些开发方法有些共同点,比如重视响应变更,重视实现客户的价值,重视开发人员的自身发展等等,其核心体现在他们著名的四句原则中.这些开发方法基本都倾向于采用迭代的软件开发生命周期模型.
简单来说,
迭代模型是敏捷开发普遍使用的软件生命周期模型,
敏捷开发所包含的内容比迭代模型宽泛的多.
敏捷开发中，XP与SCRUM的区别
区别之一： 迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。因此，原作者认为， 这点上，XP的做法值得认同的，但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织， 但你必须要实现TDD, 结对编程, ...等等”
不难发现，这四个区别显见的是： Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束
作者建议， 在管理模式上启用Scrum， 而在实践中，创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)
SCRUM介绍
回顾一下我所认识的scrum，算是对自己知识的一个梳理。
scrum到底是什么，书中都说，它不是方法学，不是过程，而是一个框架。我并没有太理解这句话，所以先把scrum中都有些什么来说一下。
时间：scrum把时间分成一个个的sprint，也就是迭代周期。这个周期以2-6个星期为宜，但目前使用的最多的，是一个月，即四个星期。
每一个sprint的开始和结束都会有一个会议，叫做sprint计划和sprint演示，这很好理解，计划时计划做什么，演示时演示做完的东西。然后，并不是演示完了就完事的，sprint还有一个回顾会议，用来对这个sprint进行回顾，哪些做的好，哪些做的不好。这就是改进。
组成sprint的每天中，都会有每日例会，叫做每日站会，所以谓站会，即是时间非常短的会议，众所周知的，没完没了的会议总是让我们，厌倦不已。而这种站会，我想差不多是从这方面来考虑的。
人物：scrum中有scrum master, product owner和scrum团队。我理解scrum master就是project manager，而product owner就是product manager，团队还是那个团队，只是这里的团队，在规模上有一定的限制，它要求人员不要太多，不要太少，3-12个，通常4人团队比较多见，当然这个具体还得看实际情况来定。团队中开发测试人员比是1：1，即pair work。
scrum中的需求，采用story的形式进行描述，整个产品的需求，被列成product backlog，而每一个迭代周期要做什么，是在每个sprint的计划会议上进行挑选的，根据po对backlog标记的优先级，团队对其进行estimate并挑选出这个sprint里能完成的story，scrum master把它们列入计划中。
backlog有一个用于统计的东西，叫做燃尽图。从字面理解，就是燃烧掉多少的图，即sprint backlog中的被完成了多少，每完成一个story，就燃烧掉一个story。产品backlog有产品燃尽图，sprint有sprint燃尽图。
以上基本就是我了解的一些scrum知识点，其中忽略了工具部分和工作开展方式部分。因为采用什么工具或采用什么方式来实现，我认为是根据实际情况来定的，而且，在每个sprint回顾会议中，这些东西都会被改进。使用excel或白板来记录story或backlog并不重要，重要的是，你是否有story或backlog。
所谓框架，是不是就是一种模式？真的很想理解这里的这个词。有知道的，请赐教。