"Software Development Using scrum" Reading Notes

"Software Development Using scrum" Reading Notes

Part I. Overview

Agile has always been a fresh concept for Chinese software development teams and individuals. Although many excellent Chinese companies have several years of agile practice experience, however, compared with foreign accumulation, it is still a relatively preliminary stage. I recently read a very classic book on Agile practices. I have written some experiences and Reading Notes based on my experiences with agile practices in my company and team, for reference by yourself and others.

First, clarify the concept:ScrumIt is an iterative incremental software development process, which is usually used for agile software development. Scrum in English means football competitions. In the book, there is a piece of very accurate description that people who are new to scrum need to remember: "scrum transformation means a change. In the process of transformation, people's ways of thinking and behavior must change accordingly. It not only refers to the technical transformation, but also to the idea innovation. People need to learn to start working without a big and comprehensive plan. People need to learn to analyze and understand needs through user stories and exchanges without detailed requirement documents, start designing and programming; people must get used to frequently submitting code and continuous integration ......"

Recalling the Orthodox software courses that we have come into contact with in the college age, especially the software life cycle model mentioned in software engineering, from Requirement Analysis to outline design, detailed design, to development implementation and integration testing. All that is mentioned here is the "sequential" software development process. If you are used to sequential development and want to transform to scrum, you must first accept the change of thinking in concept.

So what exactly does scrum agile development look like? My personal understanding is still a pile of scattered fragments: continuous improvement, efficient communication, testing-driven development and early introduction of automated testing, we can deliver and even release some stable functions that can be used in every short period, and then get valuable feedback from users and related personnel in a timely manner, this allows the demand to be refined along with the feedback from developers and customers throughout the software cycle. In this process, the team members work together to establish a responsibility system for product quality. Everyone can continuously feel the sense of accomplishment of developing the customer satisfaction function, in addition, the personal opinions and inspiration are continuously and flexibly integrated into software products, so as to keep the products competitive in the market and even stay at the forefront of the field. This is what I understand as scrum. In short, it is a sentence: through iterative improvements that never end, software products can quickly respond to any changes in the market.

The emergence of scrum and agility comes from some inevitable reasons. The reason for this is that the external business is very public: the market is changing rapidly, and the customer's current demands may become completely invisible within six or even three months; the actions of competitors may also make your original design have to be replayed, and the most valuable information cannot be imagined in the early stages of the project. After all, today's world changes faster than ever before! In addition, the internal reasons may be slightly complicated, because each enterprise has its own characteristics. The common motivation for agile reform includes adhering to the traditional approach, in the high-intensity work, employees cannot feel the sense of accomplishment and realize their own values. Communication between teams is too dependent on cold documents. Everyone always defaults to managers and bosses who are responsible for products, when multiple teams work with each other, they often encounter many misunderstandings because their respective information is one-sided, so that they finally develop products together, return the debt by misunderstanding of quality or even demand.

Part II. What's scrum

What are the implementation of scrum? First, we need to get familiar with several new concepts of scrum and agility: In scrum-based software development, the entire development cycle is divided into several short periods, which are usually calledSprint. The length of each sprint may vary with the company and product, but it is generally 2 to 4 weeks, and should not be too long. The significance of sprint is that in each short cycle, the Team is responsible for delivering some usable but not necessarily perfect functions, the goal is to get feedback from customers and product owners in a timely manner, and to get feedback on potential risks brought about by the integration of these functions in the entire system as soon as possible. In the scrum philosophy, the scrum team should haveSelf-OrganizingEveryone has an open and consistent vision. Based on their personal expertise, they can freely propose ideas for improving product quality through Pair programming and other methods, and jointly take responsibility for the product, this may weaken the authority and implementation management of the so-called project manager in the past, and the entire team is responsible for it. A new role namedScrummasterHis role is not to make any decision to release any command, but to help the team and guide the team to always adhere to the scrum principle and do the most correct thing. Even if he will exercise any power, this power should be always done by the team by granting him.

About an excellentScrummasterThe quality that should be possessed refers to the following points: ability and willingness to take responsibility, which means to maximize the output of the team and support the implementation of scrum by the team members; will not be self-centered, be able to understand the value of all team members, and set an example to lead others to reach such a consensus. Ensure that team members can discuss issues openly and encourage the team to think in a win-win manner; it has a high degree of dedication to projects and objectives. It is best to have a wide range of knowledge and communication skills, and be able to efficiently and correctly convey feedback from the market, customers and even sales personnel to the entire team.

In the scrum-style software development process, the team no longer keeps an eye on the requirement documents (of course, it is not to say that the requirement documents are completely abandoned ), instead, we use an ordered queue to analyze and control the center-of-gravity orientation of the entire development process. Such a queue is calledBacklog. The product backlog includes a list of all functions to be added. It is maintained by the product owner and saved in the order of priority from high to low. It is highly dynamic. With the delivery and feedback of sprint functions, items in the backlog will be increased or decreased, and the items to be implemented may be further refined and modified, of course, these issues will be re-prioritized with more feedback and team knowledge about the product.

Part III. How to scrum

In the several companies I have worked for, everyone seems to be aware of the concept of moving scrum together and come up with some ideas that coincide with scrum. Even at that time, we never even heard of agility or scrum. For example, a team can create an atmosphere for sharing continuous learning with each other, review code with each other to put forward different ideas, and check in code more frequently, to achieve product integration every day and quickly check the health of the entire system; to weaken the mythical Effect of Early-rising demands, so that user feedback and market competition can guide the priority of function release... And so on.

Even so, because I have no system understanding of scrum, there are still some aspects that cannot be done well. One point that I have to mention here is: to maximize the team output, a very important step is to introduce it as soon as possible throughout the development process.Automated Testing. Countless facts have proved that the last test won't have much effect, because at that time, there were often some errors that had to be abandoned or delayed to take into account the overall situation of the product architecture, you have missed the best feedback time. In each sprint promoted by scrum, when Stable functions are delivered on time, continuous integration will generate a new build or installer, at this time, we should conduct comprehensive integration tests on the entire system, and unit tests should also play an early role during coding development, the core of the entire sprint is to ensure that the delivered functions are stable and healthy, and try not to affect other parts of the system. Imagine that if these tests are handed over to the manual team, I don't think any company can afford this cost. If automated testing can take effect earlier, including automated unit testing and integration testing, you can get feedback quickly and devote most of your energy to improvement, iteration, and reconstruction, focusing on achieving the goal of each sprint. The sentence mentioned in the book makes sense: "There should be the same number of test activities on the first and last days of the sprint" until the last sprint product is successfully released. In contrast, manual testing should be primarily used as "exploratory testing", featuring short, the generation cycle is similar to the test-> write code-> refactoring short-cycle style that should be available for test-driven development.

One of the most important aspects of scrum is to keep the information transparent and efficient communication. My current project team will stick to a series of meetings based on scrum ideas, including two-week sprint Planning Meeting (because our sprint is two weeks in length ), there is also standup meeting for the team every day (about 15 minutes ). In sprint planning meeting, we focused on the top (higher priority) issues in the product backlog, the review of the previous sprint delivery function, and some suggestions for continuous improvement. What we do here is that every member of the team does not have the opportunity to see the backlog changes at all times, in this way, I missed a lot of good ideas and good questions. In standup
At meeting, we will briefly describe the progress of each person and the question of collaboration between modules, so that everyone can maintain a global understanding of the changes in the entire sprint product.

It is worth noting that the book mentions that experienced scrum teams must always maintain in-depth collaboration and work together across functional teams, rather than handing over work from one group to another. Discard the concept that a task must be completed before the next start, and replace the "finish-start" relationship with the "finish-finish" relationship.

In addition, many enterprises introduce some tools when implementing scrum. In my company, we use traditional Jira to manage projects. by purchasing a Jira plug-in called greenhoper, we can build our backlog, burn-out diagram, and manage every sprint. I have always thought that JIRA is an outstanding sequential project management software, but it cannot well convey the scrum idea. An unchangeable concept is that Jira assigns tasks in the form of issue. Each issue can only have one assignee, which seems to be against the team responsibility system advocated by agile. The ideal state is: code is the code of the team. Anyone who gives enough reason is obligated to make the quality of the Code better.Pair ProgrammingThis is also the concept. The two people face the same Code, each operating on a keyboard, writing a paragraph in turn, integrating their own product and technical experience, ultimately, code with higher quality and higher stability will be produced.

Part IV. Guide of scrum

After reading this book, I have reflected on many past experiences and lessons, and recorded the Guiding Opinions of the book on implementation of scrum. Here we will list them separately, hoping that some or some of them will be able to inspire ourselves or others in the future:

It is best to use scrum itself to manage the implementation process of scrum. Due to its iterative nature, fixed time boxes (sprints), and the emphasis on teamwork and actual actions, this makes it seem particularly suitable for large-scale agile projects that implement scrum.

There are many misunderstandings about scrum and agility: "scrum requires everyone to be general, scrum teams do not plan, scrum ignores the global architecture of the system, and scrum is not applicable to systems that are too complex ." These misunderstandings are sometimes caused by the belief in waterfall and sequential processes, or fear of changes. In fact, these misunderstandings only need to be implemented: rational task division, establishment of a shared responsibility system, delivery of valuable results for each sprint, continuous integration, and end-to-end programming andTDD (test-Driven Development)And other methods to improve the code quality, these problems and misunderstandings will not be cracked.

A good team requires two roles to succeed: The product owner points out the correct goals for the team, and scrummaster helps the team achieve the goal as effectively as possible. Product owners should share attractive visions and create a passionate atmosphere. Excellent product owners should have the following qualities: always available, familiar with business, good at communication, and act decisively.

The self-organization of the scrum team removes the role of team technical leader. Individuals need to span their profession and try to help other members of the team as much as possible (this effectively refuted the fact That Scrum requires all team members to be talented ); the Team has also switched from focusing on writing demand documents to extensively discussing requirements; the team needs to generate some practical deliverables at the end of each sprint. Selecting a task for a person is the most fundamental factor for a team member to be self-organized and must be left to the team for decision-making.

One of the major changes for the scrum team is that they will not be able to stay in their own compartment and wait for someone to tell them what program to rewrite. They need to actively understand the product requirements. In an agile team, test engineers will have more influence on the development process, and more importantly, the impact on the final product itself.

PersistenceTDD (test-Driven Development), You will get a huge benefit: All the code in the system can be tested. It helps Programmers think about their designs comprehensively.ReconstructionIt refers to changing the code structure, rather than code behavior. refactoring is not only crucial to TDD's success, but also helps prevent code corruption. The more complex the code module, the more you should consider usingPair ProgrammingTo complete it. These are the concepts of Agile programming. Agile programming is designed for changes. Its goal is to design programs that can accept or even expect changes. Ideally, Agile programming allows you to adapt to changes in a simple, local manner to avoid or significantly reduce major refactoring, retesting, and system building.

Two key factors for the scrum team: maintaining a small team and positioning each team can basically deliver end-to-end, user-visible features. The larger the team size, the larger the communication overhead, and the smaller the space for individuals to exert their strength. Therefore, a scrum team should basically maintain 5 ~ 9 people. The SCRUM team is successful and defeated. There is no job for me or you, but only for us.

The Daily website will disseminate information among team members and other participants. The Wiki and big visual charts provide an overview of the sprint and project progress, team members or others can easily understand the project status. The team should be open to new ideas, encourage mistakes, and continue to do so in an improved way. Agile transformation is actually trying to strike a reasonable balance between foresight and adaptability. The goal of agile development is to find a reasonable balance between documents and discussions. For example, user stories are the best way to shift the team's focus from writing functional requirements to talking about them. A good user story should be detailed and accurate, so that real user needs can emerge and be updated at any time to adapt to changes in external factors (including its priority ).

The definition of the deliverable generated by the sprint is that it is tested and runable, not necessarily complete, but can be successfully integrated into the entire system. Quick provision of working software is better than comprehensive documentation. Users can intuitively feel whether this is what they want. Do not easily change the sprint length and maintain a relatively fixed pace. Although different teams, especially cross-region teams, can develop a project together, the start time of each sprint can be 2 ~ 3 days. At any time, do not extend the length of the sprint, because it will give the planned work can not complete this sign. Unless for a special reason, do not easily change the target of the sprint. Although its external world may be changing, the short term of the sprint is formal in order to adapt to external changes, however, it emphasizes the implementation of the goal.

It is better to increase energy for the team than to work overtime. One of the best ways to increase energy is to increase enthusiasm. To this end, the product owner needs to convey a compelling vision, so that the team developing this product can work with enthusiasm. Every day, we stick to a long spirit of relaxation, and twice a day meets the subrhythm of human beings. The person's body gradually changes from vigorous to physiological low valley, which is about 90 ~ 120 minutes.

Keeping the product's backlog size reasonable, an expert said the human brain has a limit of about 150 people for people who maintain normal social relations. We can only remember up to 150 people. Similarly, a product backlog that is too detailed and large will become unmanageable and cannot be familiarized with team members. You can use (Epic) Or theme story (ThemeIn short, the size of the backlog cannot exceed 100 ~ 150. In addition, different modules or component teams can derive multiple different views from the backlog to ensure that each team is paying close attention to the features they are developing.

CmmeStandards do not conflict with scrum. when pursuing a particular cmme level, many companies forget that the ultimate goal is to improve their software and deliver products. On the contrary, they focus on filling in hypothetical defects as described in the cmme document, but do not care whether these changes can improve the process or product. However, when the cmme goal is combined with the inherent focus value of scrum and the consciousness of "What have you done for me recently", this issue will be eliminated.

ScrummasterAs the evangelist and protector of the team, you should sit next to the main entrance to the team area. Fully ensures that the team can continue the correct scrum action without interference. At the same time, in the workspace, scrum team members should be able to clearly see things including: Large, visible charts, and additional feedback devices (if possible, developed by themselves ), each person in the team also has the most important sprint list and product backlog. A good suggestion is to have a large whiteboard that encourages sudden meetings and discussions among team members in any range to use this whiteboard to record creative and discovered problems. As for food and drinks, it depends on the culture of each company. (In my team, I encourage you to buy some of your favorite snacks and stop and eat when your attention begins to drop, A chat about topics outside of work to help everyone relax)

Part V. End

The conclusion is that the scrum and agile concept came into being in this ever-changing world. In fact, it is not unique in the IT industry. Everyone who learns and implements scrum should keep in mind that:Continuous improvement of scrum has no end point!Today's theories and experiences may evolve and evolve as the world changes, and there is no perfect theory or process in the world, we must review and summarize the scrum version that best suits our team based on our company culture, Team status, and project situations. No matter what name we give it, it doesn't matter, the most important thing is that it allows team members to deeply collaborate and work happily, so that the team can shoulder the responsibility for projects and products, and develop highly-efficient and high-quality products that are competitive in the market.