Scrum gathering open sharing: Early estimation of agile development by Chen Yong, Martian, Beijing, 6.30!

I am invited to participate in the scrum gathering Beijing site and share the most controversial topics of this Conference in open space. Welcome to participate in the field: Early estimation of agile development (open sharing)

7. Lecturer: Chen Yong | June 30 ~ October 14: 00 Beijing Ziguang International Building-Main Venue subject: Open Space Conference

 

Order:

By topic Producer: Li Zhongli

"Responding to changes is better than following the plan ",Therefore, the estimation process in Agile development mainly refers to the process in each iteration plan,Developers can independently estimate the work content of this iteration. However,As iteration ends,Developers may gradually feel that the entire project takes one year. In fact, senior leadersThe entire project must be completed within half a year after a long contract or project establishment has been signed....... And if the projectIt is twice as late, so it is the decision-making mistake of senior leaders,Or team productionIs the rate half that of others?

This makes us wonder:

Is there a way to sign a contract or establish a project,With only a few pages of word and limited interaction, we can calculate the project of more than a decade.20% accuracy?

Is there a way to not only make an estimation in the early stage, but also directly transform the estimation result into an epic story and a user story in Agile development?

Is there a way to not only make developers aware of the continuous growth of code, but also allow customers and leaders to understand and recognize the spread of demand simultaneously?

Is there a way to simply count the number of epic stories and user stories at the end of a project,You can vertically compare the project completion with the team's history,It can even make horizontal comparisons with data from other teams and even the industry,And convince the customer and the boss?

......

This is destined to be a highly controversial topic. from the beginning to the end,The opinions of the topic creator and review team have been quite different. We have seen controversial topics,But there has never been such a big difference!

In the open space of scrum gatheing in Beijing, Chen Yong, founder and chief architect of "Martian,We will show you how to use this method.

06/29-06/30, Beijing scrum gathering! Topic introduction:

As we all know, the estimation process in Agile development is mainly concentrated in the iteration plan meeting, where developers can independently estimate the work content of this iteration. However, if a developer estimates that the entire cycle takes one year, and the entire project has been established within six months, what should I do?

The early estimation method involved in this lecture introduces the concept of Feature Analysis FPA, which allows the product manager to outline the functional outline at the beginning of the project, based on a small amount of information and text, you can roughly calculate the required work hours. The description of this feature outline can also be directly evolved into an epic or user story with a relatively fixed granularity during further development.

This early estimation method mainly comes from the experience of the iiom (International outsourcing Management Association) R & D process of the Martian agile development platform.

Target Audience: Product Manager/PO, Project Manager

The discussions involved in this link are described in detail (three online discussion summaries at the invitation of pmbar) http://blog.csdn.net/cheny_com/article/details/7692917

The overall context is as follows:

1. Developers only need to select a few stories for a small amount of precise estimation before iteration, and the product manager needs to make rough estimation in the very early stages (project initiation and quotation) when facing a large number of stories. What should I do?

2. user stories (from the third blue bar below) span from 1d to 2 m, which cannot be easily estimated by counting; however, the business operations (Ei/EO/eq) and business data (Ilf/EIF are commonly referred to as information points and entities) of Function Points) there is a very consistent absolute size.

3. Early estimation can be made by counting business data Ilf (this is the second-level Simplified Method of nesma)

 

4. Business Data Judgment Rules and correction coefficients (used for applications with different difficulty). This rule is more popular than ifpug and nesma rules, but the result is.

5. The evolution of business data (Ilf/EIF) into an epic story is also called a data story. Business Operations (Ei/EO/eq) evolve into a traditional user story (as ...... Yes ...... So that ......)

6. enhancement/reconstruction/defect/debt is a story with a smaller granularity. It does not belong to the "business functions of Products" that the customer understands"

7. Associate sub-stories such as enhancement/reconstruction/defect/debt to data stories (epic stories) or operation stories (that is, "as ...... Yes ...... So that ......") To manage

8. This method can use seven management methods or practices in the same data set.

 

Guest sharing: Chen Yong has rich practical experience in engineering technology and project management, first-hand experience gained from various technical and management positions such as programmers, project managers, cmme/FPA Function Points estimation/agile consultants, business department directors, and deputy general managers, it allows enterprise managers to understand agile development from a broader perspective, and to coordinate and promote non-R & D department collaboration to promote agility.