Manifesto agile development Manifesto

Offical official:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Translation Translation:

Agile Development Manifesto

We are exploring better ways to develop by doing it and helping others do it. Through this work, we learned that:

• Individuals and interactions trump processes and tools

• Working software is superior to comprehensive documentation

• Customer cooperation trumps contract negotiation

• Respond to change instead of following a plan

While the right-hand side has value, the left-hand side has more value.

Wrong Name = Wrong Name = Wrong Name

Agile translation from Oxford English-Chinese Dictionary

(1) (lithe) agile panel of person, animal, movement›; Flexible (fit)

② Attributive (mentally acute) is alert (panel of the intellect)

Agile, pinyin is mǐn jie, explained from Baidu Baike

It means to react quickly and quickly. Quick to jump into a convertible, quick to roll onto a horse, quick to dodge an attack. From “The Book of Han · Merciless Official Biography · Yan Yannian” : “Yan Nian was short and shrewd, and agile in matters.”

Through the comparison of the two translations above, it is not difficult to see that the Chinese and English understandings of the word “agile” are completely different. In Chinese, the word “agile” expresses a more important meaning of speedy

In The English context, however, when aglie is used to describe people, it also means, while when aglie is used to describe thinking, it is more about agility.

Therefore, it depends more on whether the boss, leader, or programmer agree that software development is a physical work, or a process of brainstorming and thinking realization. On the first day when I entered the company, the leader told me a team creed: “Understand, explain clearly” and “Jump to white board from keyboard”. Only by fundamentally recognizing that what I do is thinking rather than repetitive labor, can I deeply understand the meaning of the word “agile”.

However, if we translated Agile development as Agile Development/Agile Development, perhaps the impact of agile development on the industry today would be much less. After all, the four words of agile development will be recognized by the boss or leader, because fast and efficient is exactly the working mode that small and medium-sized companies or large companies need throughout the whole enterprise.

Get back to what agile development really is: a one-person, team-oriented, fast-changing, and working software approach.

The efficiency of agile development does not lie in being fast all the time. What agile development advocates is a positive cycle, through continuous iterations of products, every code review, product review, Requirements review, Standing Meeting Daily to achieve fast, efficient, collaborative and synchronous. The team has experienced constant running-in, and it naturally returns to the needs of boss and leader: fast and efficient.

Therefore, for a research and development team, agile development can level everyone’s understanding of information, so that everyone can confirm that everyone’s design idea is the same at any time, rather than in the middle of the understanding of misunderstanding, so that the final product is not satisfied with the market. I believe those of you who have experienced program rework can imagine that the real low efficiency and slowness is that what you do is not recognized by the boss/leader or by the market, and you are tired of rework, so that the team consensus falls apart and enters an infinite vicious circle.

Waterfall Development VS Agile Development

When it comes to waterfall development on the Internet, it always gives people a sense of diode, more of a feeling of stepping on a holding one, by stepping on waterfall development to promote agile development. This personally feels totally unfair to waterfall development. Is waterfall really overblown by Agile development? It’s not

Waterfall Development means to Waterfall Development

(Photo by Baidu Photo)

1. Requirements/ research
2. Design (Design)
3. Coding
4. For Testing
5. Maintenance (Project operation)

Agile Development

Picture from agile Development introduction – Ruan Yifeng

1. Project initiation (Initial Planing)
2. Requirements Analysis
3. Design (design)
4. Coding
5. Testing
6. Deployment and Evaluation (Deployment/Evaluation)

Contrast contrast

	waterfall	Agile development
Working mode	Based on text: 1. Documents will run through the whole project life cycle, from requirement analysis, software design, coding design, test cases, operation and maintenance deployment) each stage will output corresponding documents 2. The output of each phase will be used as the input of the next phase 3. Based on documentation, communication is not necessarily as reliable as documentation 4. After launch, the product can meet 90% of users’ needs, and only a small amount of operation and maintenance costs are required	With text 1. It emphasizes team cooperation, which requires team cooperation and coordination to smooth everyone’s understanding in real time. Of course, it does not mean that documents are not important, but that team collaboration is more people-oriented 2. Iteration is the core thinking of the product. The first launch of the product may not have an optimistic result, but the product needs to be iterated according to the feedback of the market 3. Keep iterating and finally put the product into a positive cycle mode
Project cycle	The first release usually takes half a year or more, and only a small amount of manpower can be put into operation and maintenance after the product is launched	The first launch is usually within two months, followed by repeated iterations to get the product right for the market
advantages	1. Clear objectives, all you need to do at each stage is to complete your own work and finally output the corresponding documents 2. After the launch of the product, a large number of personnel can be withdrawn and put into the development of new projects, and only a small number of personnel are needed for operation and maintenance 3. Very clear allocation of resources in the team, because the goals of each stage are clear	1. After continuous iterations, the output products must be in line with market demand 2. High flexibility. If there is a huge market change or urgent demand, we only need to join a new iteration 3. People-oriented, mobilize the participation of all parties (including the market) in the whole project. Ideally, the development mode will no longer be allotment, but each member will take the initiative to undertake the work
disadvantages	1. High risk. If there is a mistake in each stage, it will be input to the next stage, and the final product may not be able to meet the market demand and needs to be redone 2. If there is a market change that is essentially project death, the insertion of urgent requirements will also affect the entire software development, and may even require the design from scratch 3. There will be a situation of empty staff, because each stage needs to wait for the output of the previous stage before starting work	Putting people first is the biggest risk of Agile development. Can you trust everyone on your team to share the five Agile values (from Agile Scrum) : – Commitment – Be willing to commit to a goal – Focus – Put your mind and energy into the work you commit to – Open – Everything in the project is open for everyone to see and share – Respect — Treat everyone on your team with respect, not judgment Courage Have the courage to make a promise, keep a promise, and accept the respect of others Can you say “You can always trust me” to every team member?
For the project	The requirements are clear and there will be no major market change in the development cycle (one year)	Internet projects, agile development can respond to the rapid development of the Internet changes A project that needs to go live quickly and grab the market

Agile development is not a panacea. If it is forced on the wrong project, it will turn into dumb development, because we will communicate clear requirements back and forth, reducing r&d efficiency. More importantly, whether the people on your team are suitable for Agile development is the core idea of Agile development.

Cultivate agility

The core of Agile development is people-oriented. There are a lot of agile development processes and specific implementation on the network. You can see the examples given on the network at any time, and invite professional agile teams to the company for training. The main topic of this article is how to cultivate the Spirit of Agile, and I hope that you will not feel the article is a chicken feed, but can make you feel the article.

1. Blame can’t help anything

Pointing fingers won’t fix the bug and won’t help anything. It’s a positive cycle when we think about solutions to problems rather than the people who caused them.

Be brave enough to admit that you don’t know the answer and discuss it with each member of the team. If a big mistake is made, it should be treated as a learning opportunity rather than an opportunity to kick someone down the road. The team should help each other, not kick someone down the road. Especially if there is something that most people know is a pit, at this time to induce a person who is not clear to jump, even if he escaped a disaster, then in such a team, how can you know whether he can escape the next pit? If you avoid it every time, you will not become a respectable person, but an industry veteran, is secretly spurned by people, and how will others respect you?

You might say that if a team member is a negative influence over and over again, that person should leave the team, but we shouldn’t blame them over and over again.

Always go along with the trend of changing. Don’t blindly seek of speed

Every company, or every team, has a code code, and if we blindly chase speed, we add a lot of magic to our code and miss comments. The resulting code will be so obscure that even the author himself may not be able to see how to implement it.

Following code specifications, not blindly chasing speed, being responsible for naming new variables/objects, and being responsible for commenting your code blocks is a basic quality of development, rather than thinking of coding as a horse race. If there are issues you are unsure about, especially performance/design issues, be sure to ask your colleagues.

I asked my leader for advice last week

Suppose the same business involves three associated tables. When doing an interface service, do three tables check together and get the result directly, or three tables check separately and isolate, and combine the result into the final result.

The leader and r&d colleagues all gave their own understanding and solutions, which benefited me a lot. Maybe I would not suffer from this problem until it happened. When the problem happened, I believe my team will work with me to solve the problem and get a more suitable solution

The following is my answer based on the solutions given by my colleagues and the leader:

1. According to Alibaba specification, join is prohibited by association for more than three tables
2. Single-table queries are recommended if they can be cached or reused
3. Although multi-table association can save a lot of business code, in most cases it does not provide much performance improvement, and database associated queries can also increase SQL complexity
4. Single table query is also convenient for later expansion of sub-database and sub-table, SQL layer optimization space is large, business layer for large data volume can use certain algorithm to solve performance problems
5. In a C-side project, we want to avoid federated queries altogether, in a B-side project, we can avoid federated queries whenever possible, and in a G-side project, we can’t avoid federated queries at all

Focus on the issue, not person

Everyone knows the truth, everyone has drunk chicken soup, but it is difficult to do. It will only bring a negative atmosphere to the whole team, where everyone feels insecure and wants to kick someone when they are down.

Negativity kills Innovation:

Each of us can come up with some great innovative ideas, but also some really goofy ones. If you’re afraid of being laughed at, or even criticized, before you come up with an idea, you’ll kill it. Any outstanding product needs a lot of innovation and market insight, sharing their own ideas and integrating each other’s excellent innovative design to make a good product.

“You don’t have to be great to start, but you have to start to be great.” — Les Brown

“It is a learned mind to appreciate ideas you do not accept” — Aristotle

Here are some words for the author himself:

If you don’t have the courage to start, what does excellence have to do with your life?

In the process of expressing everyone’s idea, we are bound to encounter endless discussions, and it is not impossible that the brainstorming will eventually turn into a bullshit meeting. How can we avoid this kind of situation?

• Set a deadline: When the deadline comes, if the best solution can’t be determined, we need to find the most suitable solution instead of endless discussion and thinking collision
• Reverse thinking: look for the shortcomings of the scheme /idea. If there is a scheme whose shortcomings are acceptable to all, is it the best scheme?
• Moderator: The moderator needs to be absolutely impartial. If someone goes from a brainstorming session to a bullshit session, the moderator needs to stop them and keep the meeting going
• Support decision: the implementation of the plan needs to continue, unless you can prove that the plan is wrong, otherwise please respect everyone’s plan

4. Brave heart

The paean to man is the paean to courage from the Wonderful Adventures of JOJO.

Courage, courage this is a concept we have heard since childhood, but want to have courage, have courage, it is really very difficult to do a person with courage, this sentence is really can make people hear cocoon, let alone in an enterprise to do so?

Courage can make people feel a little uncomfortable, and it takes courage to get it up. Sometimes, it’s the only way to get rid of the obstacle, otherwise the problem will get worse and end up going over and over again knowing it’s wrong. Summon up your courage. It will free you from fear. This is, of course, in the case of you already know the correct answer, if you work at this time it is not work after an unprecedented, as the ship’s crew, you don’t know where will the next field is, at this point you courage on earth is the determination of the voyage, or get out, it is a philosophical question? If you’re doing something that no one knows the answer to and envy you, I want to do the same.

5.Tracking changes

The progress of the Internet is really too fast. The most impressive example is jQuery and three front-end frameworks, which even gives me a sense of fault progress. When it comes to Java, if we pay attention to the new features of Java, we will find that from java8 Lambda to JDK14 in the middle of all kinds of syntax sugar, will find that Java is constantly moving closer to functional programming, JS has also introduced a lot of object-oriented concepts, each language is constantly to improve its own features, If we shut ourselves up, unable to follow the changes in our industry, what’s the difference between us and prisoners in prison? In the movie Shawshank Redemption, when the prisoner returned to the city, because he could not adapt to the modern changes, he chose to commit suicide in the hotel, while the protagonist kept up with The Times by writing letters and reading, and finally completed his redemption.

What’s terrible about prison is not that you’ve been there for years, but that you’ve become a prisoner of your own mind. It’s that prison inside you that has imprisoned you.

Remember some time ago in the network to see a very interesting words

Any technology that existed when I was born was part of the normal natural order of the world.

Any technology created between the ages of 15 and 35 is a revolutionary product that will change the world.

Any technology created after I’m 35 is against nature and damned.

— Douglas Adams, British science fiction writer

Anyone who was born 10 years or more before me is an old fogey.

Anyone born within 10 years of me is a pillar of society.

Anyone born 10 years or more after me is a hopeless broken generation.

— Nash Warschall Sauder

Was the prisoner imprisoned in a prison? Or did he imprison himself?

How do you track change?

• Iterative and incremental learning:

The same is true of knowledge investment. You need to invest a minimum amount of time on a regular basis. Create a habit if you need to. Retreat to your home office or go to a coffee shop with Wi-Fi. Not every study session is equally productive, but regular study sessions are sure to be successful in the long run. If you keep waiting for idle time or inspiration to strike, it will never happen.

Schedule regular study sessions for yourself. When you hear unfamiliar terms/new things, write them down and plan time to delve into them

• Browse forums, Zhihu, Nuggets community, Jane book, Github: community is always the most popular place, the trend of books will be lower than the community, but the degree of rigor of books is higher than the community

• Reading voraciously: Reading, reading, reading!

I lay upon my books like a hungry man upon bread! — gorky

• Keep track of technology changes: You don’t need to be a master of every technology, but you do need to understand what’s going on in your industry and plan your career

Personal Imagination: What would I do if a language emerged that completely replaced Java? Could I be the beneficiary of a technological revolution by spotting the signs of it?

Invest in your team

Always be the worst player in the band you’re in. If you are the best player in a band, you need to choose a new band – jazz guitarist Pat Methany

Catch up with the team, form a positive complement with each member of the team, have the courage to share with the team members with an open mind, respect the opinions of the team members, and undertake the task of the team. Build a learning platform that belongs to the team. If you think you’re at a disadvantage by sharing your knowledge, unless you’re a national scientist who has to sign a strict confidentiality agreement, we need to think about whether we’re a frog in a well. When something you hold dear to your heart is discovered and everyone knows it, and there is a better plan, will your face begin to rage as if it had been kicked with a shoe? “Any technology that comes out after I’m 35 is against nature and damned.” Anyone born 10 years or more after me is a hopeless broken generation.

7. The Reduce subtraction

The side of the boat thousands of sails, sick trees before the spring

When we are in the process of work and realize that some things restrain your design, and you can find communities now have technology can solve these problems, we should make tough subtraction, after a thorough investigation, embracing new technologies, your valuable work experience should not be subject to the code, or subject to their own laziness, Keep up with the tide to become a “thousand fan” and “ten thousand wood”

Get to the Root of Things

Amazon’s internal troubleshooting of S1 and S2 required the manager of that team to write a document called Correction of Errors (COE).

The COE document basically covers the following aspects.

• The whole process of troubleshooting: just like a log, it is necessary to record in detail what has been done, from the occurrence of the fault to the solution of all the details of the process are recorded. –
• Fault cause analysis: You need to describe the fault cause and analysis report.
• Ask 5 Whys: Need to reflect and Ask back at least 5 Whys and find answers to these “Whys”
• Follow-up corrective action plan: The above “Ask 5 Whys” need to explain how to solve all problems from the root.

In addition to the attitude of asking questions when facing accidents, we should also be bold to ask why in our work discussions. Just like doctors, they always ask us where we have been, what we have eaten, what symptoms we have, and then they will make a judgment about our symptoms after testing. If we approach the project with doubt, it will remain a landmine in the project until it explodes.

When we ask why, please pay attention, do not stray from the topic, you need to make sure that you ask why is meaningful, because when you ask others why, others will also ask you, why do you ask this question, so please be responsible for your speech and questions.

Keep Control of your rhythm If you Can.

• If you did any coding today, don’t forget to test your code and submit it to the Version Control Tool before you leave work
• Try not to work overtime if you can. There is no need to burn yourself out. In the long run, this is not good for your physical and mental health or career planning. Many people think that working overtime can improve your work schedule, but it is not. Please try to make sure that your work is simple manual labor and copying code when working overtime. Not something that really requires a lot of thought to make a decision.
• If the project is successful, don’t forget to attend/organize a team gathering to savor the fruits of the victory

Let customers make decisions

Don’t isolate the customer, pull the customer closer to the project, let the customer make the decision to ensure that the product is what the customer wants. R&d and product managers should not make business decisions; the product owner must make them after full communication with the customer. If the product owner’s answer to your question is “no,” that’s actually a good answer. Since their vision may not be as long as yours from a technical point of view, make as useful a suggestion as possible, and after the product is made, they may give a good answer

11.Design guidance development

The role of design should be to guide development, not to operate it. The design here needs to be divided into two kinds of design

• Product Design:

If a product designer to design documents in detail to the extreme, it will interfere with the technology of implementation, the depots table, for example, database field, micro service split, etc., so this time researchers if know such a design is not reasonable, also to develop completely in accordance with the design document, the result will be how? I think you can already guess

• R&d design:

Draw key business sequence diagrams, UML diagrams. Don’t start coding. You need to map out the core process of your current business so you can figure out if there is a problem with the business process.

It’s impossible to describe exactly what you’re talking about if you don’t know it yourself.

— John Von Neumann

Planning is worthless, but the process of planning is essential.

— Eisenwehauer

A good design is a map, and he probably started with a prototype, a compass. The map just needs to make sure we’re doing the right thing, it doesn’t need to be accurate.

Don’t be bound by technology

Before adopting a new technology, it is necessary to do sufficient research and find out whether there are frameworks with similar functions and forms in the community, compare the advantages and disadvantages, and finally make a decision on which framework to use, rather than seeing an official account or forum post and just blindly using this technology without any reason. Technology is to serve the final product, if the r&d personnel are bound by technology, then the final product is really to meet the needs of the market product?

Every technology has its pros and cons, whether it’s open source or a commercial product, framework, tool or language, be sure to understand the pros and cons

13. Show to Customers&Get feedback

During development, keep the application visible and demonstrate new features to customers and get feedback after each iteration. Make sure that what you do is what the customer wants.

• Instead of publishing to all end users, grayscale publishing is possible
• Treat the customer with respect. If the customer decides to do a demo once a month, do it once a month, but make sure there is a reasonable cycle to do the demo and gather feedback
• Make sure the feature is complete. If it’s half-baked, don’t demonstrate it. It’ll just piss off the customer. Can outline features and communicate with users.

14.Unit Testing

A lot of developers have a kind of blind confidence that there’s nothing wrong with my code, including me, but at the end of the day, I’m just too lazy, and we should rely on unit testing and respect it. Unit testing is a good stock to invest in. Unit tests need to have good code coverage to be useful, so make sure that your unit tests have good code coverage. You need effective testing, not as many tests as possible.

15.Different Environment Different Problem

It works fine on my machine

This is probably one of the most common words spoken or heard by every developer, but it is important to note that different environments have different problems.

If in the past we had to deal with each environment to make sure the system worked in each environment, now we can use container technology to solve this problem.

16.Measuring the real workload

In percentage terms to measure workload is meaningless, of course, sometimes, the boss or the boss is hoping to get a percentage of the number, but the number he itself does not have any meaning, because the remaining 20% effort if there is a difficulty or confusion points, so that 20% of the workload is not made within the time they expected.

On the project management software of the company, write clearly ToDoList, write clearly each function point that each person is implementing, not the percentage that each person has achieved. By function point realization, it is actually more reassuring and makes the estimated workload closer to the actual workload.

17.For Customer Listen to the Customer

Behind every complaint lies a truth. Find out what you really want and fix the bug

Listen to the voice of the user, the user’s complaint is not necessarily meaningless, maybe there is a bug hidden behind this complaint, an unreasonable business process. The goal of your product is to be used by users, not to be an inviolable work of art. Ensuring that your users have an easy and satisfying experience on your product is Paramount. For example, The user experience of Douyin APP is excellent, at least it can satisfy the majority of people. The biggest disadvantage of Douyin APP is that it has no disadvantage when I use it. The powerful recommendation algorithm can always give you an interesting new video when you are bored, so that you can unconsciously consume your time. Of course, some users’ complaints may be ignored, after all, we have also received, account name and password input error, but users insist that this is a bug complaints.

Respect and Implement code specifications

Please respect and enforce your company’s code specifications, be responsible for your own variables, be responsible for each method name, and don’t wrap your code in obscure comments and confidently tell others I wrote them. If they tell you in no uncertain terms that you can’t understand it, it may not be that your code is awesome, but that you’re coupling a lot of functionality together, that your variable names are bad, that they have to guess what the variable means, etc.

Use carefully chosen, meaningful names. Use comments to describe code intentions and constraints. Comments are no substitute for good code.

Comments explaining what the code does are of little use. Comments explain why the code was written the way it was, your intentions, and constraints.

Be respectful and happy to implement code specifications that will benefit everyone in the long run.

19. The Trade off

Learn trade-offs, considering performance, convenience, productivity, cost and time-to-market. If performance is good enough, focus on other factors and don’t complicate the design for perceived performance gains or design elegance

Premature optimization is the root of all evil

Solutions used in the past may or may not be used for the current problem. Don’t draw conclusions in advance. See what’s going on.

20.Simple is not self-defeating

The most typical example lies in apple’s design thinking. Simple is not simple, and it is the same in our code. We do not deliberately pursue design patterns or difficult technologies.

Simple, readable code is the goal

What one person thinks is simple can mean complex to another. There is a balance to be struck

21. I Cohesive code

The internal class is used to evaluate the functional dependencies of members in a component (package, module, and accessory). A high degree of cohesion indicates that members have jointly completed a feature or set of features. A low degree of cohesion indicates that the functions provided by individual members (methods, attributes) are unrelated to each other.

Keep your classes focused and your components small.

Code with good cohesion may change proportionally as requirements change. It’s not a modification that affects everything.

22.Record the required logs

Log what you need, log what you need, log what you need.

Log so you can troubleshoot problems, not just because you need to log

23.Execute Exception Handles exceptions

Handle every exception. Don’t eat the exception. Handle the exception. Handle or propagate all exceptions up. Don’t ignore it, even temporarily, because if the exception happens now, it will happen later. Exceptions are handled to ensure the production environment

Provide useful error information

We are afraid that the user will see an exception message, so we wrap each exception as “please wait, server error, please try again later”. We need to compile the specific error code and classify each call of the third party. When the server itself is regarded as a classification, when reporting an error, We need to quote us devices connected to the [001] we should not put the error information was not found intact printed display to the user, but their meaningful error message displayed after encapsulation, so the advantage of user feedback to you when there is an error, you just need to get classification and error code, can quickly troubleshoot problems.

Enjoy Code

Hopefully, you’re in the programmer business because you love coding, and even if you become an architect, you’ll want to code yourself. Architects can’t program in powerpoint. Especially when it comes to using new technologies, new frameworks, you need to be there. Only your own experience is true, and I hope you enjoy the process of coding. There are many open source projects on Github, and many people make many pull requests every day. These open source project developers will no longer have time to code themselves, but instead will have to deal with numerous pull requests. As a result, many coders of open source projects quit because they no longer enjoy the process of coding.

26.Share&Teach

A good idea is not diminished by many people knowing it. When I hear your ideas, I get the knowledge, and your ideas are still great. In the same way, if you light mine with your candle, I gain light without darkening your surroundings. Good ideas, like fire, can lead the world without weakening themselves.

Being a mentor means sharing — but not clinging to — your knowledge, experiences, and experiences. It means being interested in what others are learning and working on, and willing to add value to the team.

Give others a chance to solve their problems. Point them in the right direction rather than offering solutions. Everyone can talk and brainstorm. If someone is stuck, I think it’s time to give them an answer. At least they’ve thought about it.

Reference documentation

45 Habits of Effective Programmers: The Path to Agile Development

Introduction to Agile Development – Ruan Yifeng

Making the address

Geek Time – Wind in your Left Ear