One of the agile practices for small and medium projects (about project owners and responsible persons)

**The development method is a systematic project that requires the cooperation of all project activities. **

This experience is based on the practice summary of two small and medium-sized projects (one 2000 Manday, one 1500 Manday) in the past two years, and I hope to discuss and make progress with you.

- Have a clear project owner
- The project owner is willing and available to participate in project discussions and help the team to make decisions, such as regular problem discussions, major issue decisions
- The project owner can actively provide feedback on the project
- Each module There are designated responsible persons, each performing their own duties, sharing success and failure together

.

If the project owner corresponds to the theory of CMMI, the project owner is the project stakeholder.

The so-called project owner refers to the beneficiary of the project, and refers to the person who benefits from the success or failure of the project (economic benefits, honor halo, etc.) or is unlucky . On the other hand, if the success or failure of the project has no effect on a person, do you still think he will still care about the project?

The project team needs to make good use of the project owner. Don't blame yourself, because a true agile project owner is more actively involved in the project than you think, and is more than happy to be "exploited". Take our project as an example, our project owner took the initiative to tell us that if any customer and you put forward unreasonable or inappropriate demands, you can ask me to help you coordinate!

An important responsibility of project managers in agile projects is to find and identify project owners, and project owners need to use "our project" instead of "your project" when communicating. Even to change the concept of project managers who were not very agile. But I have to admit, it's hard.

Ideally, the project owner and the project team can be in the same working environment, or at least have regular project discussions.

Project Responsibilities

Project responsibilities are often referred to as Ownership.

The agile team emphasizes that each team member has a clear responsibility, the project is shared by the team, success is the success of the entire team, failure is the failure of the entire team, and we will advance and retreat together. Therefore, an agile team should be a team that helps and loves each other.

In an agile team, the culture is more important than the system.

This seems a bit contradictory, so let's analyze it separately.

Let’s talk about responsibilities first. This will require each team member to do their job well. When everyone does their job well, the entire project can be successful. In fact, this is not necessarily, and who can guarantee that there will be no gaps between the borders. Simply managing with "responsibility" is a management with clear boundaries, a management with only "yes" and "no", and a very "blunt" management.

Besides, agile, agile is a kind of management that goes further than pure responsibility management, wrapping those blunt responsibilities with a "flexible" culture. Make modules communicate with each other, communicate with each other, cooperate closely, and integrate with each other (milk *interaction is a keyword, and you have long knowledge ). And these flexible parts are the most difficult parts of the project to be solved through management.

Of course, these flexible characteristics give people a feeling of being uncontrollable or chaotic, and it is precisely because of these flexible characteristics that two major misunderstandings of agility are caused.

1. Agile is only suitable for teams of good programmers.
2. Agile is not suitable for big projects.

In fact, it is not. We will see that the following two examples do not require how good agile members are, but they have achieved a lot of things that each other excellent programmers can't do.

For example, an agile team will have the following scenarios in their usual communication or Daily Meeting.

quote
Programmer A: Hey, Programmer B, the output of my module has been changed from NUMBER(18,2) to NUMBER(18,5), have you noticed this change?
Programmer B: It’s over, I just noticed that the data type you output has not changed, but I didn’t expect the accuracy to change, thank you so much.


quote
Programmer A: Hey, Programmers, I wrote a very common calculation method today, is it useful for you?
Programmer B: Great, I'm going to write a similar method tomorrow. Let's study it and see if it can be shared.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326588460&siteId=291194637