Traditional development teams usually divide their work according to their roles. Developers only focus on development, while testers only focus on testing. Things beyond their responsibilities are either invisible or not my job. Bad has nothing to do with me.
On the contrary, agile software development puts more emphasis on "Whole Team", that is, the entire team makes a commitment to the outside world, and everyone in the team is responsible for all development, testing, documentation and other tasks.
Failure to deliver high-quality software on time is the responsibility of the entire team, no matter how well a Developer/Tester does.
This requires people in the team to help each other, just as Huawei said, "If you lose, you will save your life, and if you win, you will raise a glass to celebrate." Therefore, it is best for people in the team to have a variety of skills, Developer can help with testing, Tester can help write some code, write some documentation...
This way a large number of tasks will not be squeezed into one person and cause the project to fail.
So the question arises: Does everyone on the team have to be a generalist? Can you be a generalist?
I recently read a ppt by Mike Cohn, and one of the examples answered this question. I thought it was very exciting, and I took it out and shared it with you:
Mike Cohn illustrates his point with examples of different types of restaurants:
Meconi's is a deli, it has an order taker and a lot of sandwich-makers, how would you like to go for lunch? We'd see a long queue outside the door -- since there was only one ordering person, she was very busy taking all those orders. But once the order is placed, dude you'll probably have it in no time as 9 people will rush over to make sandwiches. But I don't want to wait so long outside the door, let's go to Bruno's and see
Bruno just thought, it employs 9 orderers and only one sandwich chef, your order will be processed quickly, obviously you have to wait a huge time for your food.
The Ferentinos seem a bit unique, with four orderers, four cooks, and five Floaters—who order meals and make sandwiches. When there are too many sandwich orders, they go to the back kitchen to help -- maybe they can't make it as fast or as good as the chef. When there are too many customers, they also rush to the front desk to help process the order -- they may not be perfect, but good enough.
A lot of restaurants will understand this: It's a good idea to keep mobile crews, but not everyone has to be a Floater.
Going back to the software industry, why don't our agile teams do this: Let some experts have multiple skills, not necessarily all the skills required by the team, as long as these people can balance the workload well.