Shulou(Shulou.com)06/03 Report--

The basis of Agile estimation:

Why estimate: the estimate allows the team to understand the project specification calculation ROI and IRR, forming the basis for the executable license, and with the estimate, the market can also prepare for the later product launch in advance; who carries out the estimate? Product owner, Agile Coach; when will the meeting be held? Naturally, the sooner the better, and as more information is gradually refined throughout the project, the estimation will continue. Agile advocates: embrace change, then since embrace change, estimates also need to be adjusted, it is necessary to increase manpower. Do not blindly expect overtime to reduce costs, with the post-90s and post-00s entering the market, this generation pays more attention to the quality of life, after all, work is for life; how to create estimates? There are many ways: start from various dimensions, such as time, labor, materials, etc.; relative size: mainly used for user stories; value points: deliver value and results. Only by delivering the available software and maximizing the customer's benefits will the customer pay us the last payment.

Project scale measurement: consider the code volume, time dimension, manpower dimension and functional complexity.

Story points: relative measurement, relative independence, comparison with each other; allocation of story points should consider: complexity, input, risk and other factors; story point estimation steps: the story should be divided into small, independent. Each story should be completed by one person in no more than two days, otherwise, it will be stuck, and the cost is often huge. At the same time, if the team wants to reach a consensus, Agile is a kind of thinking, which requires team members to change their minds. If a person is offline, it will affect the speed and stable direction. Constant dialogue, coordination and improvement are needed in the process (unknown factors such as annual leave and personal leave often affect the progress of the team and the integrity of the story point).

Story point ratio estimation: compared with other stories, if the story is similar, its accuracy and completion time can not be too different. At the same time, it is suggested that the R & D team evaluate together to avoid arbitrariness.

Ideal day: no one interrupts, all the information is available to focus on the only job; many enterprises advocate versatile, that is, a person can do A position or B position, think this is efficient? This is wrong, just imagine, coding 10 minutes for an hour of meeting, meeting thinking about coding, coding thinking about preparing for the meeting speech. Hey, hey. The price is also quite high, and it is strange that many senior executives choose to turn a blind eye to this bad phenomenon to CEO. "programming for 10 minutes, blowing water for an hour" through this joke, we can see that R & D personnel are not mechanical work, but creation, it is necessary to maintain a relatively private space, not disturbed by the outside. Here is a few more words: "many R & D brothers who take up management positions for the first time often make a mistake and fight in person; they are dismissive of various evaluation meetings and regard them as nonsense. In fact, this is that the thinking has not changed, and the height of the post determines the focus of the daily work of the post. The focus of the management position is to plan, coordinate, avoid risks and control progress, rather than getting involved in development. To sum up in one sentence: evolve into adults, stop thinking like monkeys, you should focus on a banana forest, not one or two bananas.

Comparison of story points and ideal days: it is more helpful to drive cross-functional behavior (coordinating resources, answering questions, etc.); the estimation of story points does not decay: unifying ideas through constant dialogue; story point characteristics: hijacked the growth of estimated time. The latter: there are differences, from team members; the uncertainty of the ideal day will make the outside world think it is reliable, in fact, it is unreliable.

Estimated size: agile assessment is based on reasonable predictive estimates and should not pursue 100% accuracy. There are several ways to do this:

Broadband Delphi: used to collect accurate estimates of the project, discuss only the problems that may be encountered in the meeting, but not the estimate itself and the cost. At the end of the meeting, each member of the team makes a separate estimate, must be independent, and rejects paired estimates. After the team members have finished their estimates, collect all the estimates, draw them in the drawing table, show the differences, and discuss them. It should be noted that this is anonymous, that is, do not show their names. I remember that once, the group conducted a satisfaction survey, and there was a name column on the survey volume, and as I expected, the administrative department collected 100% satisfaction. On the contrary, the real problem is covered up and lost the role it should have played, which is a waste. Steps: the team chooses to form members, start meetings: explain the rules of the game and procedures, personal preparation, estimation meetings, configuration tasks: collect estimates, summarize, task review: find differences and reach consensus. Plan poker: because I am extremely disgusted with poker and mahjong, I am not introduced here, I am Baidu.

Affinity estimation: mainly used for large-scale estimation, advantages: speed, simplicity, transparent and visible decision-making process, active cooperation rather than confrontation

Steps:

Silent relative size: the product owner provides the product to-do list, which is arranged on the wall, and the team members consider the time and effort spent on the implementation of each item. Do not discuss the technology; edit the wall: move the size according to the consistency of the size; classification; the challenge faced by the product owner: based on the estimated size, it may not meet the ideal state of the product manager. Then you need to re-estimate or take other measures according to the actual situation; store the data: the last step, all the above steps, is for one result: store the data.

Compassionate size: the advantage is similar to that of affinity, that is, team members determine the benchmark of each size; the benchmark of L, XL and XXL should be unified.

Plan Poker: do not introduce, own Baidu

Determine the size of the project: it mainly depends on how many items are in ProductBacklog. Remember that ProBacklog is dynamic rather than static; it needs to be constantly viewed and adjusted throughout the life cycle of the project; it is precisely because of the dynamic that we determine the size of the team, the number of teams, the duration of the sprint, the number of sprints in the version and the target upper limit.

Estimation is to assist our work, not the assessment of KPI\ KBI. The Agile Manifesto's characteristic of "adapting to change rather than following norms" determines the time cost of our estimation. It is the only choice to invest in research and development as soon as possible. Spending too much estimation time to determine its 100% accuracy is actually a waste.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.