Agile Development
Agile development, and now most respected teams in agile development model
when I beginning to understand, but also wondering what in the end is agile development, and what the benefits are?
It also just a novice entrants did not take long, but the author himself for some understanding of agile development, not comprehensive, if different understanding / or deeper understanding can reply learn from each other. Precipitate a deeper understanding of the practice still takes a long time
1. What is Agile development is?
Agile development is a human-centered, iterative, incremental development methodology.
2. how to understand it?
First, we must understand that it is not a technology, it is a development methodology, which is a software development process, it will guide us to use the provisions of part one step by step development of the project; and the main way of such development the core is driven person; it uses iterative development;
3. Agile and Scrum representatives Devops
In fact, a large number of respected Scrum and agile development mainly based Devops
Scrum literacy articles https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html (Thanks for sharing bloggers)
Devops literacy articles https://www.cnblogs.com/jetzhang/p/6068773.html (thanks for sharing bloggers)
Both were 3.1 What is the role of it in agile development?
Personal understanding is:
Scrum is a development process that by the demand from the produce - produce a closed loop in the form of new requirements, a product broken down into a number of interacting closed - Review - R & D - test - on-line - Feedback is a version of iterations.
Devops delivery is a concept, advocate / CD tool-chain to an iterative version of each link is automatically connected through the use of CI through tools to complete every aspect of the delivery of work until the delivery of on-line users.
The two are a complementary relationship, Scrum provides development process, Devops provide CI / CD tool chain
3.2 For the understanding of Scrum
(Picture from the network)
Scrum for personal understanding is: standing on the perspective of product / project, how to make the demand to get faster / better / more accurate implementation.
For product staff , want to design the product functions can be realized fast, on-line, verify, update. The traditional waterfall development is often the time to complete all the requirements, if the on-line market again found it impossible to meet the new adjustment, may already be on the line again after six months, products for the Internet is simply a fatal injury. For planing analysis of decomposition characteristics of the product, will focus on the characteristics extracted, the rapid development achieved by the market on-line user authentication, and then continue to feature-rich Internet products is undoubtedly the best way to occupy the market.
So in Scrum product requirements become stringent personnel, product requirements will be able to product characteristics, rich and accurate analysis of the plane decomposition (product positioning, decomposition user's portrait, analysis of data, characteristics, respond to market response demand management is a big challenge)
For developers , understanding the needs of deviations / changes in demand / Bug fix problems should have always been a headache. If there is a deviation for researchers to understand the needs, it was only until the testing phase needs to achieve in order to find the deviation, this time again will lead to rework the entire product line extension (if it is waterfall model, a longer delay time items cost more) . If demand changes occur in the development process (because the product / market / policy factors, etc.), researchers will need to understand the requirements, if requirements change before the larger coding will be re-written for the entire product line is also a extension (if changes in demand as the main business streams, in waterfall mode may cause the whole project stopped redesign). If the tester can not quickly and accurately identify the needs of deviation / discovery system Bug, it will lead to the delivery of delayed delivery even bring hidden dangers, consequences can not be expected at any time.
So Scrum promote rapid iterative version rather than the waterfall model, the purpose is to minimize the loss of the project costs;
Scrum while also focusing on R & D staff to understand the needs, the purpose is to allow researchers to conduct a detailed understanding of the needs, carried out according to the needs of the decomposition products so that people understand the review to check whether the deviation missing;
And the need to test personnel involved throughout the product / R & D areas, detailed knowledge of product development to achieve a logical quick analysis / positioning meets the requirements / the existence of Bug, but also to promote the traditional manual testing automation, speed up the efficiency of the test part of the reduction in work cost.
Scrum Team Fusion 3.3
For Scrum, its own R & D process does not necessarily apply to all teams, as each team's product direction / staffing / team atmosphere is different.
Scrum personally think that for learning, not for copying the Scrum process, but rapid iteration understand delivery and then combined according to their own team of various other factors, for the output for their own team of research and development process .
Of course, there are many aspects of Scrum / learn mode can be directly used to come in, such as task Kanban / Daily station will / workload assessment / demand decomposition sessions. Task Kanban can help you quickly sync task progress, facilitate the next step to prepare; daily station will be, so that we can sync progress and ask questions of risk; workload assessment, so that we can continue to work on their own to quantify the performance of combat; Review conference on the speech improvement and common progress.
Personally I think Scrum team for the integration of (1) According to the status and other factors team, develop a set of R & D process (2) to carry out full universal concept of agile (3) explain the process in detail various aspects of the role, after a trial full version iteration convened review will discuss the collective wisdom of taking a step forward to optimize processes (4) to determine the appropriate R & D processes were forced to promote the implementation problems arise in the middle of each version of the discussion will review records (5) for each version or monthly or quarterly, once the process optimize and continue to implement
Let the team to adapt to a new development process is a very difficult thing to learn to develop a suitable agile development process is not difficult after thought, the difficulty lies in the implementation of the monitoring process need to consume a certain amount of time / energy, mainly because of agile development The core is driven person. Scrum team integration may increase some of the links / meetings, etc., we want to accomplish real integration must strengthen supervision of enforcement, so that we develop the habit of real integration into the new R & D process
3.4 For DevOps understanding
(Picture from the network)
(Picture from the network)
个人对于DevOps的理解是：站在集成/交付的角度，怎么让研发流程各个环节无缝连接，同时推动工具链减少人员操作（当然DevOps是一种理念，理解起来肯定不仅如此，只是在落实方面CI/CD思想比较着重）
对于研发流程而言，一个好的研发流程就是一个完整的闭环，每个环节都有其存在的意义并且每个环节的完成都意味着工作交付（产品人员将需求交付给开发人员编码，开发人员将系统交付给测试人员测试，测试人员将系统交付给运维人员上线，运营人员将系统交付给客户使用，客户将使用意见交付产品人员分析）。完整闭环就需要产品／开发／测试／运维／客户等角色共同参与，闭环的形成、多种角色的参与都意味着每个环节、角色的交付都是一个重点。更好的交付将减少下游环节、角色的工作成本；更好的交付将提高研发流程的流畅度（对于研发流程的推进也有帮助）；更好的交付将提高产品的市场、乃至提高产品的收益。
笔者接触到的大多数DevOps的讲解，DevOps是将开发、测试、运维融合起来，但是笔者认为DevOps并不仅仅是这３者的融合，而是整个产品至上线所有环节／角色的融合
DevOps提倡使用工具链，将所有的交付／监控等等环节操作工具化，并通过工具之间的API互相关联形成一套完整的工具链体系。通过工具减少人员的操作，即减少了人员成本又极大的避免了人为操作失误带来的损失。
笔者之前看到过一个比较完整的DevOps工具链概览，分享给大家（同时也感谢作者的分享）https://blog.csdn.net/qq_31977125/article/details/82796739
顺便再分享一个 DevOps BookMarks ，涉及了DevOps方方面面的工具和内容，有兴趣的同学可以去学习下。http://www.devopsbookmarks.com/
（笔者也有简单分享过一些工具相应的介绍／安装／配置文章，后面笔者也会继续学习继续补充）
3.5 团队融合DevOps
对于DevOps，它是一个理念。个人认为对于DevOps的学习，首先是真正的理解集成／交付的思想，然后就是工具链的学习使用（硬核技术）。
团队对于Devops的融合是需要全员参与的，也是对团队整个技术栈的全面提升。首先是组织推广CI/CD的思想，让大家理解交付的意义；然后团队整体寻找适合团队的工具链，进行技术栈的全面提升。
4. 团队走向敏捷开发
个人认为团队想要真正的走向敏捷开发，需要对于Scrum和DevOps进行一个完整的融合。
通过DevOps闭环的思想、Scrum迭代的思想，结合Scrum可以借鉴的环节／方式，制定一套闭环、适合团队的研发流程。
通过JIRA等项目管理工具将研发流程工具化管理，再将研发环节交付工具化执行，然后打通项目管理工具、研发各环节交付工具形成一个完整的工具链。
最最重要的一点还是人，一个团队想要真正的走向敏捷开发，首先也是必须要让团队人员都认同迭代、闭环、集成、交付思想。只有思想上的认同，才会让整个团队共同努力向着敏捷开发的方向不断前进
