2015.7.1, I am in Hangzhou ....
It's really not easy to go all the way. More than a week, the big guys followed a "Psycho Counselor" who went through constant communication, debate, practice, validation, and deep thinking. Finally, embarked on the product-level agile road .....
- From the external customer's perspective, the development of the product can make customers have confidence in the version of the rhythm; PI (program Increment)?
- Pull-through product characteristics leader, development backbone and Test Manager, through the visual demand Kanban and "addition, subtraction" collaboration mode, identify each round PI needs to complete the development and integration testing characteristics of the scene? has enabled each PI to have the least output, but can have the greatest impact on the customer?
- Pull-through Product Owner, develop backbone and test backbone personnel, design each round of pi architecture design and identify risk per round of pi architectures with a lightweight Context Map? Product Owner objectively evaluates the number of User stories for each pi to complete development and integration testing, based on the risk of each round of pi architecture.
- Pull-through development and testers, through a visual "business Scene tree", lightweight yet precisely designed userstory business scenarios, the verification latitude of business entities and business entities? Therefore, through the business scenario tree, development and testing personnel can not only agree on the requirements of userstory, but also in accordance with the concerns of business entities to design the test cases of each point of concern, jointly assess the probability of failure of each concern and the impact of the product in the event of failure? The most important point is that the development and testing personnel can be based on the verification latitude of the business entity, the probability of failure of each concern and the impact on the product in the event of failure, the focus of the User story is only the developer self-assured quality can be. What are the concerns that need to be developed and tested to ensure the quality of the joint? In a highly collaborative model with developers and testers, it will improve the quality of the developer code while significantly improving the testing efficiency and quality of testers.
- In accordance with the software architecture, the developer transforms the "business scenario tree" into a "practice scene tree"? The practice scenario tree will be able to determine if developers have a clear and correct logical idea of developing User stories before they are formally developed? Can developers use the practice scenario tree, combined with appropriate design patterns, to design a simple design that adapts to the changing and easy-to-expand User story?
- The tester will work with the feature owner, developer, and design the "feature business scenario tree" according to the characteristic end-to-end business scenario, and design the end-to-end test case based on the feature business scenario tree.
- Developers and testers will propose the next PI self-improvement program in accordance with product Owner and other team members ' evaluation of their work before each pi is nearing completion.
Product-level agility through the team of highly collaborative and independent, and gradually formed an efficient product development ecosystem? In this ecosystem, team members can not only effectively complete version development, more importantly, can play "collective wisdom" to make the best decision? So that each round of PI, can be the least output, but can have the greatest impact on customers?
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
"Product-level agility" this path; Gradually form an efficient ecosystem of product development
