Li Zihua — Technical Director of graphite document.
A product has the phases of requirement proposal, review, confirmation, and actual development, testing, and delivery. Since agile was first proposed in 2001, there have been more and more projects using Agile. Now that Agile has become the norm, it makes sense to discuss the overlooked aspects of agile practice.
Today we’ll focus on two key points: focusing on non-functional requirements and devOPs-related strategies.
Focus on non-functional requirements
This is a screenshot of a website with two blocks of text, the first for the title and the second for the answer.
When you look at this picture, first of all, you wonder what it is, and second, why anyone would ask this question.
This is the core algorithm of the next generation of the most popular front-end development framework React. Fiber was proposed for two background reasons.
The first reason is that more and more products and websites are very complex, especially in terms of interaction and functionality. Graphite documents, for example, allows many people to write Word documents online at the same time, which is different from traditional Web applications like blogs and news. Now we have more complex interactions, so what does complex interactions bring? More and more users are finding that while websites have more features, they seem to be getting more congested. There will be some lag in scrolling, and opening a web page will get slower and slower. Fiber is specifically designed to solve this problem, which means it will make your site faster and more responsive when your site is complex.
What’s the second reason? React is one of the most popular frameworks, with users around the world asking for it: I want to add this function and want that function, but they have accumulated a lot of technical debt in the long-term development process, and there are also many unfinished reconstruction things, so they also hope to pay off these technical debt through the development of Fiber, and make it easier to maintain.
By now, Fiber has been in development for a full two years, and it has been rolled out. After the launch, people were surprised to find that my website seemed to be faster. We can also see that React market share is gradually increasing, and the frequency of iteration is gradually accelerating. Fiber was an obvious non-functional requirement, and we received a lot of feedback, but ultimately the team chose to develop a Fiber tool.
So when we talk about non-functional requirements, there are several common categories, including speed of response, load capacity, and test coverage. According to different situations, each team will have different processing methods. Non-functional requirements can be included in Acceptance Criteria or Definition of Done as the standard for the completion of the user story.
In fact, different methods have their own advantages and disadvantages. For example, in the process of developing graphite documents, we support more than one person to write content in a document in real time, and at the same time, each person can see what is edited. This is a very clear functional requirement.
How do you agree on the non-functional requirements behind it? In most cases it should be in our acceptance criteria, which means we can agree on some common performance requirements. For the example of multiple people writing in real time, you might agree on a number of people, for example, you want to be able to write in real time for ten people, and then the save time of each person can be controlled within a second. So when we go to finish the user story, we look at the acceptance criteria, and if it supports saving in less than a second, then we know it’s done, so it’s a very clear quantification of whether something is done or not, and it doesn’t allow people to ignore non-functional ways.
But there’s another way to do it. Some teams treat these non-functional requirements as a standalone project and stuff them behind the Backlog. What is the problem with this? When time is loose, it’s fine, but what happens when development hits a few snags? We tend to prioritize what the customer can see. Because when I went to deliver this project, the client saw this feature and thought it was great, you guys worked very fast, and then you worked very hard, and these features were very useful to me.
But the underlying non-functional requirements are very important: how many people we can carry, whether we can use our product company-wide, how secure we are, etc., and how maintainable the project is is easily overlooked.
In the long term iteration, Agile emphasizes more and more frequent communication with customers to understand their needs and respond to their needs, so the development speed is very fast and the interaction cycle is very short.
At this time, it is easy to find that we will ignore the maintainability of our products, for example, we will introduce a lot of technical debt, there will be a lot of opportunistic methods to put this thing online quickly. In the next iteration, they continued to care about other requirements from customers and did not solve the previous technical debt. This can lead to a product that starts out fast, but slows down toward the end, until it’s no longer necessary to stop and sit around and solve the problem.
Two “principals”
The person in charge is in quotation marks. Why is it in quotes?
Recently a very popular movie “Green Book”, the students who have seen this movie should know that “Green Book” has two male protagonists.
The man in the back row won the best supporting actor award. In fact, it’s hard for us to imagine him as a supporting actor, because without him, it’s hard for us to imagine how the movie could go on, how the story could be told. So, although we have protagonists, we have supporting actors, but in fact it’s very possible that both of them are indispensable, and we should not ignore either of them.
In an Agile team project, we pay a lot of attention to the PO’s decisions, the PO’s tendency to prioritize what we do. In fact, we needed another person in charge, who had a clear understanding of where we were, where our team was, how fast we were developing, and how well we understood non-functional requirements.
Whether you need to stop and do some refactoring or move on.
For graphite to the “head” is not a character, because we don’t set a job to do this thing, if a position specifically set the thing, the whole team others is easy to say: “if this position he do the things is ok, as long as we don’t need to care about others.” This is a step backward in the understanding of non-functional requirements as a whole, which is counterproductive. It is more important to me that the cultural inculcations of non-functional requirements are instilled into the team to transparently understand and drive NFR, non-functional requirements.
What do you mean transparent? Simply setting aside a percentage of NFR time does not help transparency. A lot of teams have another approach, which is I can have a lot of functional requirements, I can have a lot of user feedback, but I also have to do some maintainable things, I have to do some refactoring, I have to pay off some technical debt, I have to do some team improvement, I have to do some things that are easy to deploy. To do this, I need to set aside a fixed 10% or 20% of my time per iteration to do these things.
What’s the problem with that? As an Agile team, or as a normal team, we care most about self-growth, self-improvement, self-improvement, and self-feedback. So when discussing non-functional requirements, it was a good opportunity for the whole team, including our PO, including our entire development team, to sit down and talk about why we were spending the time doing this refactoring; Why do it now and not in the next iteration; What is the value to our users, to our business. We find that these discussions allow the team to get feedback faster and know what our capacity is, rather than trying to get everything done as quickly as possible until we have to stop because of all the technical debt.
So it’s important to discuss this transparently with the team so that the team can improve.
Left the conversation
When it comes to non-functional requirements, DevOps is a natural correlation.
DevOps moves to the left, just look at this graph:
We know that most agile frameworks or agile methodologies focus on the iterative part of software development, which is on the left, where we have agile teams, where we have development teams and business teams sitting together, where we can understand customer needs in real time, where we can make changes early for different environments, We want to deliver working software to customers as soon as possible and as often as possible.
But what’s on the right? On the right side is our traditional IT operation and maintenance. What they care most about is stability. If there is no problem with this thing, they should try not to do IT, and the online times should not be too frequent. Every time we go online, there may be risks. We have to keep an eye on the process of going online, and the operation and maintenance students also have to go there. Therefore, going online is a very painful thing for operation and maintenance.
So, as you can see, the green one and the yellow one seem to have a conflict, the left one wants to be more frequent and deliver as soon as possible, and the right one wants to be calm and not so fast. So, you can see that when we adopt Agile, if we don’t make any changes at the operations level, the overall delivery time to the customer may not be shortened.
What am I going to do? That’s what the title says, we’re going to move operations to the left, which brings me back to the topic of my talk, the extension of agile thinking in the product cycle, when we extend it, when we’re agile it’s all about communication, that we’re going to communicate with the environment, we’re going to communicate with the customer.
That’s the same thing. What does the development team do? What does the operations team do? This also requires early communication, as in this picture, we can have people sit down and communicate earlier, like on the first day of development, or before we start development.
It’s hard to define exactly what DevOps is most important.
We can say it is a way, a tool, and a culture, so the most fundamental thing is communication. That is to say, we’ve proven in Agile that communication is important, that we can deliver software to customers faster, that we can make sure that we have something that meets their needs faster. I’m not going to do that for a year or two, throw it to the user, and the user says this is not what I want. So it’s the same thing with project deployment, like in the old days if we were doing development and we left it to the operations team, the operations team said this might not be what we want, we might not be able to deploy it. In fact, graphite often encountered such a problem before, that is, we will be very frequent iteration, customer demand will be very much. So one of the most painful times for us at the time was when an iteration was over and it was time to deploy, and it was a horrible thing to deploy. We often found that the deployment script was broken, the code seemed to be broken, the deployment went live but all kinds of errors came in, and the operation phone was ringing off the hook.
Practice: Graphite service development process
Before I look at it now, I think one of the most important fundamental products for graphite development is the delivery platform that we use internally. With it, we can have shorter iterations, faster delivery times, and a more stable rollout process.
Because graphite is software for enterprise online collaboration, we write some of our own documents in graphite. You can see from this screenshot that we will use graphite to write some cases, some shift plans, some work logs, technology sharing and holiday arrangements.
Every graphite employee is a heavy user of their own products. With agile, one of our biggest concerns is being able to accept feedback. In fact, internal employees often get feedback faster than users or even seed users, because everyone is sitting in the same office, seeing each other every day, and getting to know the product better.
So, we were thinking about two things:
The first thing is how we can get feedback from our internal staff as early as possible; The second thing is how to solve the problem that we fear the most, the deployment problem.
So, we made a feature that looks like this.
How does “test and deploy every feature at any time” work? Graphite creates a feature branch for every project, every team creates a feature branch for every project, and then all of our functions are developed in that feature branch. Each graphite employee, when accessing graphite, has a special page, as shown in the screenshot, through which each person can configure which feature branch each microservice uses for their own request.
Let me give you a concrete example
Going back to the diagram, a few months ago we didn’t have a tree on the left, but many internal employees reported that it would be easier to find and manage their documents if they had a tree on the left. So we decided to add this feature. By day five of development, we were able to make the tree directory we were developing available to our internal staff through the platform, and we would send out various invitation links telling people to go here and select branches of our features, and then refresh to see the tree structure for practical experience.
Before we develop, in fact, everyone should know that we will reduce the blueprints to stakeholders, will look for the boss, but this diagram to show the customer, the customer said not bad,, but we give the software to the customer, often find that they said this with at the beginning don’t look the same, can not meet your requirements. In fact, everyone is the same, people look at the design and use this thing in the actual work scenario, the feeling is completely different.
Picture may ignore a lot of things, but when you use every day products appear such changes can real feel this thing is very not good with, any improvement, the fifth day of the time can send the left tree directory of products to our staff, they can put the information on the graphite, they will be daily experience, Because they use these documents every day, they can find out very quickly whether something is appropriate or not, whether it meets their needs, so we can collect feedback from our users very early.
Compared with the previous strategy, we will spend a lot of money on AB testing and various experiments to analyze our user usage scenarios. Then it takes two or three weeks to put the data together.
Through such a function, we can very low cost, the fastest speed to collect the most real needs of customers.
The second problem is that, as mentioned earlier, the most dreaded day of each iteration is deployment day. I experienced some deployment issues before. Now what can we do with this platform? Deployment is as easy as switching tabs! Internal staff can use this platform to choose which branch to use for each module, and the same is true for releases.
We can set a ratio of, say, 2% or 10% of users to one branch, and then the remaining percentage of users to another branch, and the rest of the users to the online branch. It’s a very fast, flexible way to get online.
Worktile’s website: Worktile.com
Contents: Worktile
This article was first published on Worktile’s official blog.