Here are my successful practices in project development and management using agile ideas in a long-term project development process for your reference
I. Background of the project1, this is a long-term maintenance, need to expand the functionality of the platform, the system itself contains up to 13 subsystems, and also in the continuous increase of 2, the system adopted a "component architecture", the implementation of the decoupling between the components can be independently expanded 3, the development of scarce resources, serious shortage of programmers, And the proportion of programmers who can work independently is very low.
second, the Agile development Practice1, each iteration includes: requirements---design----------the delivery of four stages 2,Standardized management of the whole process of development with Zen Road
3, each iteration of the version of the cycle is 2 weeks
Job Division:1, Product/project manager pm (product/project Manager) 2, Technology Manager TM (Technical manager) 3, Test Manager QM (Quality Manager) 4, senior programmer (generally as development team leader) MC (Master Coder) 5, programmer GC (general coder) 6, front-end engineer Fe (Front Engineer) 7, Tester QE (quality Engineer) above 2, 4, 5, 6 belong to the development group, 3, 7 belong to the test group
a few tips for using Zen Trails:The "project" in Zen is the definition of a certain stage of work in a product life cycle. My approach is to define a large version as a project, V2.0 is a project, V3.0 is another new project--the definition of the version in detail if you can pay attention to, will make the programmer, testers in the use of the process more smoothly, for example: the current online normal operation is "xxxxx system V2.0.0" Version, is developing, will be on the line is "xxxxx system V2.0.1" version, then in the integration testing phase, you should edit the name of these two versions, instead: "XXXXX system V2.0.0 (current version)", "XXXXX system V2.0.1 (coming soon)", so that testers, Programmers in the process of selecting a version when dealing with a bug do not have to think of the brain-in the Zen Tunnel configuration of asynchronous automatic alert email, to achieve "work chasing people"
The specific development work flow is as follows:
1. Demand discussion
using static Prototyping method to discuss with party A in the pre-requirement
person in charge: Product/project Manager
Participants: Technical manager, Test Manager and front-end engineer, senior programmer
The external requirement discussion stage does not need to enter the Zen Road, uses the Excel format meeting minutes, the mail and so on communication, after the demand is relatively clear,
arrange the front-end engineer to make static prototype, with static prototype + document to communicate with party a repeatedly to confirm, until the final determination of demand
2. Demand ConfirmationWork with party A to determine the needs and priorities for the next release
person in charge: Product/project Manager
Participants: Technical manager, Test Manager, senior programmerThe final definition of the next edition of the needs of refinement, and the detailed requirements into the Zen Road and set a priority of 3 (in the follow-up process, party a very likely to temporarily put forward urgent needs, those needs can be set priority to 2 or 1), here to pay attention must be refined demand, such as: The original demand is "support multi-city Scheduled for April 15, the other 4 cities in the district ", from this demand should be specific to the needs of the page, such as: Multi-City _ Modify the Order List page to support multi-city ... After determining the requirements to be completed after the next release, the project team will open a plenary meeting to inform all requirements,
The Test Manager begins to prepare the test case
3. Assigning TasksRefine and assign development tasks to your needs
person in charge: Technical managerZen Road Path "project-task", when doing development task allocation, generally will be separated from a demand for multiple development tasks,
A task is the most atomic transaction, and a task can only be assigned one executor .Such as:
Requirements: Modify the XXX page to support different city operators can only show the city's information allocated 3 tasks: 1) Modify the XXX page to support different city operators can only display the city's information-detailed design 2) modify the XXX page to support different city operators can only display information of the city-back-end Code 3) modify the XXX page Operators in different cities can only display information in the city-front-end code
4. Detailed DesignDesign documentation according to development requirements
Person in charge: the appropriate person for the development group assigned the task
Supervisor: Technical ManagerAccording to the circumstances of the coding programmer to do design documents (not too difficult to function) or by a senior programmer or technical manager to do design documents (some difficult features), unified into the svn/git, if it is a very simple algorithm design, can be placed directly into the Zen Road-task notes. Document title Format: Design Document _ Requirements Id_ requirements title, such as: Design document _ Requirements 001_ Modify the XXX page to support different city operators can only display the city's information
5. Coding and Unit Testing
Person in charge: the appropriate person for the development group assigned the task
Supervisor: Technical manager, development team leader.1) Programmers according to the task on the Zen Road according to the plan code and do unit Test 2) every morning the programmer to "open" the task assigned to their own, after the completion of the task, click "Finish" here to special emphasis: the use of Zen Road to assign the task is not to say that no need to communicate in person, in-person communication is still Git integration allows technical managers to review code directly on Zen Trails (Community edition without this feature) 3) Technical manager responsible for daily code review and solve technical problems 4) the Product/project manager is responsible for monitoring the progress of the development every day, finding the situation timely communication process, product/project manager according to the completion of the task , timely modification of the progress of the requirements, so that the party can keep abreast of progress, the progress of the requirements of the unified written in the notes, the format is as follows: research and Development completed: 2016-04-08 7 o'clock Test completed: 2016-04-19 Night 7 O'Clock release time: 2016-04-20 2 o'clock in the morning
Special Note: The script for database changes, to be unified into the Svn/git "Development Document-version directory", such as: \01 Development document \V2.2.0, naming format: script file _v2.2.0.txt, this script file is maintained by the technical manager
6. Version definitionSet up versions of each component before the integration test is ready to be submitted
person in charge: Product/project managerThe version number specification for each distribution is as follows: 1) version number the second digit plus 1, the third place is 0, such as: V2.2.02) after the official release if there is a small change, then the third increment, such as: v2.2.1,v2.2.2 ... Define the version in the project-version and associate the version with the corresponding requirement for this release (a requirement can be associated with multiple versions, such as: Requirement 002: Order List page support for multiple cities the different operators can only see orders from the city, this requirement involves: Order Center component V2.2.0, Commodity Center Components V2.2.0, Micro-mall/PC Mall components V2.2.0 These versions, all should be associated with) it is important to note that in order to define versions of components, it is required that the version number of all components be consistent, such as: To define the version of such a few components: 1) Micro-mall/ PC Mall component V2.2.02) Order Center component V2.2.03) Commodity Center component V2.2.04) store system components V2.2.05) call center component V2.2.06) store app components V2.2.0 in Project-version-view bugs to see a list of bugs under this release
7. Integration TestingCode completion, submit integration Test 1) The technical manager after self-test that can submit integration testing, in the Zen Road Path "project-version", submit test 2) Technical Manager to deploy the code on the test server 3) test Manager to schedule the test and submit the bug (when the issue is submitted, the issue is the version to be fixed, The severity is set to 1, the other does not belong to this version of the bug, set to 2 or 3, each time you submit a bug, you have to set the "CC person" as the project team management, so that everyone in the management can understand the progress of the test) 4) If the test enters the final stage, will be finalized, The technical manager puts the code currently submitted for testing on SVN with a corresponding version of the branch branch (name format: v2.2.0_testing), and the person who fixes the bug concentrates on several core programmers, reducing the chance of triggering a new bug. After notifying the core programmer switch to this branch, immediately modify the permissions settings on SVN remove the core Programmer's read and write permissions from the trunk to avoid human error, other programmers continue to follow the development on the Trunk Branch Note: 1) When the bug was submitted in the Test-bug, Be sure to select the corresponding version number 2) each time the Technical manager updates the file to the test server, we will notify you in the nail group, and attach the bug list of this update fix
8. Acceptance TestIntegration testing completed, before the release of the final audit and acceptance testing,
Note: Here are the branch branches for this release (e.g., v2.2.0_testing) for the 7.After the Test manager returns to all 1 levels of bug, think can go online after 1) Test Manager report product/Project manager can issue version 2) product/project Manager to do another test, to ensure that the quality of 3) Product/project Manager testing also considered that no problem, submitted to party a before the release of the acceptance test (if necessary, Also allow party A to participate in the test phase 7)
9, the release version on-lineParty a confirms that it can be issued, the official version,
Note: Here are the branch branches for this release (e.g., v2.2.0_testing) for the 7.In the acceptance test of party A can be issued after the release of the day: 1) Test Manager, the Zen Road Path "test-version", modify the tested version, set to "completed" 2) the Technical Manager to update the version of the Code, database SQL script to package 3) products/ Project manager from the Zen Road project-Requirements list to export (copy out) the need for this release is an Excel file, which is a release note (Changelog) document that is provided to party A, each of which adds a new version of the content to the front of the original document 4) products/ Project manager to provide party A with changelog documents, and let party a sign on line confirmation 5) Technical Manager to release the files to be published carefully to the production server 6) Product/project manager in Zen Road "product-release" set the same as the project-version of the release, notes the release time and the content of the release, And the release and release one-to-one connection to the second to third day of the issue: 1)
Technical Manager on the second day of the release, on SVN, export a tag from branch, name format: V2.2.0_release2) Technical Manager in the release of the second day, finishing Zen Road-tasks, belong to this release has been completed tasks, all do
Close Processing, previously planned to do, but not completed, can be linked to the next version 3) Product/project manager after technical Manager completed 2), to the corresponding version of the requirements, do
Close Processing
10, version maintenanceAfter the release, in general, you will still find some of the previously unnoticed bugs need to be modified, so before the next large version of the release, you need to continue to maintain the current version, as follows: 1) The technical manager from the previous version of the release of the tag to export a branch, such as: v2.2.0_ FIXBUG2) The Test manager continues to issue a bug to the Zen path based on feedback from the customer, with a severity of 1 and a version number of V2.2.0
3) The technical manager arranges the relevant personnel to modify the bug under the V2.2.0_fixbug branch (in general, only the programmer who is responsible for the old version maintenance to deal with these bugs, preferably the technical manager is responsible for processing), here to pay attention to the SVN permissions, This Fixbug branch only assigns read and write permissions to the specific modified programmer 4) The Test Manager arranges to do regression test 5) 2, 3, 4 step loop, until it is considered to be available, then determine the version number, for example: V2.2.1, and export a tag from v2.2.0_fixbug to v2.2.1_ Release, updated by the technical manager on the production server (before the release also to export the modified bug list to party a confirmation) above the 2, 3, 4, 5 step iteration cycle, until the maintenance of this version is stopped
11. Discontinue MaintenanceOn the eve of the new release, typically within 5 days, stop the maintenance of the previous version 1) The technical manager tells the programmer to switch the local working directory to the trunk, turn off the old version of Branch's programmer's Read and write permission on SVN 2) the product/project manager closes the release of the old version, Zen Road Path "product-release", set the corresponding release of this version as "Stop Maintenance" (this step can not be forgotten, otherwise in the bug in the selection of the version, the release is not stopped maintenance of the corresponding version will always be displayed)
It is important to note here: Not that this time the release has been completed before the start of a new version of the journey, generally speaking, after step 2, the product/project manager will start to communicate with party a next time the needs of the release, and then the technical manager from the requirements of the task, the programmer began to understand the need to use the technology , the test group begins to become familiar with the specific business processes and details to begin a new journey of the release. This is the path of agile iterative development of spiral-shaped ascent ....
PS: Supporting this development process and corresponding to the various positions of the "job book", further refine the specific work of each post, I will be released in the following blog post
welcome all of you together to explore the agile development of practical methods, everyone good, is really good ^_^
interested in exploring together, please add scrum Dry Q Group: 302304689
The following is my original software enterprise using Agile Development series articles:"Original" Agile software project development and management process (i) "original" Job book-product/Project Manager (ii) "original" job book-Technical Manager (iii) "original" job book-Test Manager (iv) "original" job book-Senior Programmer (v) "original" Job book-Programmer (vi) "Original "Job book-Front end Engineer (vii)" original "Job book-Testers (eight)
"Original" Agile development Management practice based on Zen path
