Case Study: Apply ZenTao in a large-scale project - usage

ZenTao has been well-known among small and medium sized companies and help them to manage software development projects. For large-scale projects, ZenTao is also capable of doing the Scrum tool job. Below is a case study of implementing Agile in a large-scale project via ZenTao.

Background

This project is about a long term O2O platform which features will be continuously developed. It contains 13 child systems and more to be added.
Componentization architecture is how this platform is designed, which means each component is separated and can be extended independently.
Developers are not sufficient, especially ones who can work independently.

Agile Practice

Each sprint should have four phases: Story writing->Designing->Coding->Testing.
Apply ZenTao for all lifecycle management
Each sprint last two weeks.

Roles in the project

Product/Project Manager
Technical Manager
QA Manager
Master Coder (usually the Dev team leader)
General Coder
Front Engineer

Role 2, 4, 5, and 6 belong to Development Team; Role 3 and 7 belong to QA team.

Tips for using ZenTao

Project in ZenTao is a definition of a periodical work done in the lifetime of a product. A version is defined as a project for this large-scale project, e.g. V2.0 is a project, so V3.0 is another one.
Define the version names with care and details, so it will be more intuitive and self-explaining for Developers and QAs to understand.E.g., there is a online version named 'XX System V2.0.0', and a version named 'XX System V2.0.1' is in developing statue and will be online soon. So Developers and QAs would not have to think about which version they should choose when reporting a bug, because it is obvious just checking the version number.
Set Email notifications as Asynchronized Sending, so ZenTao can help make a 'work-chasing-worker' team.

Development Workflow

1. Discussion of user stories

Adopt static prototype to discuss user stories with party A as defined in the contract.

Responsible: Product/Project Manager

Involved: Technical Manager, QA Manager, Master Coder, Front Engineer

Discussion of stories with party A is not recorded in ZenTao. Use Excel for meeting minutes and emails to communicate with party A. When the stories are clearly defined, front engineers use static prototype and documents to confirm stories.

2. Confirm stories

Confirm stories that will be developed in the next release and prioritize them with party A.

Responsible: Product/Project Manager

Involved: Technical Manager, QA Manager, Master Coder

Detail confirmed stories of next release and record the stories as level-3 priority. If party A add urgent stories during the project, mark it as level-2 or level-1. Stories have to be detailed, e.g. the original story is 'support multi-city and release on April 15 for other four cities. The detailed stories should specified for each page, such as multi-city_support multi-city on the page of Edit Order.

After all the stories are confirmed, the project team will have a meeting and keep everyone on the same page. Meanwhile, QA team start to prepare test cases.

3. Assign tasks

Decompose stories into tasks and assign them.

Responsible: Technical Manager

In ZenTao, go to Project->Task. When decomposing stories into tasks, a story is decomposed to several development tasks. A task can be assigned to only one coder. For example,

Story: Change the page of XXX to display the information of his city for the operator.

So the three tasks of this story should be,

1) Change the page of XXX to display the information of his city for the operator-Detailed design.

2) Change the page of XXX to display the information of his city for the operator-Back coding.

3) Change the page of XXX to display the information of his city for the operator-Front coding.

4. Design stories in details

Prepare the design document according to stories.

Responsible: Coders that have been assigned with tasks

Supervisor: Technical Manager

Coders prepare the design document for features that are not too challenging and master coders or technical managers prepare the document for challenging features. Then upload both to SVN/Git. If it is a simple algorithm design, just add it as a comment in ZenTao.

Document title format: Design Document_Story ID_Story Title, e.g. Design Document_Story001_ Change the page of XXX to display the information of his city for the operator.

5. Coding and unit testing

Responsible: Coders that have been assigned with tasks

Supervisor: Technical Manager, Master Coder

1) Coders refer to the tasks in ZenTao and start coding and unit testing.

2) Coders log in ZenTao every morning and 'Start' tasks and click 'Finish' when they finish a task.

Note: 1. Face-to-face communication about assigning tasks is not necessary, but it is always better if you could do it face-to-face. 2. SVN/Git can be integrated in ZenTao, so technical managers could review codes in ZenTao( community version has no such feature).

3) Technical managers review codes each day and solve challenging problems.

4) Product/Project managers monitor the progress of development and deal with problems if any in time. They can update the status of the stories according the finished tasks, so party A could know the progress of the project. The progress of stories can be added in the comment of ZenTao, and the format is,

Development Finished Time: 7PM, 2016-04-18

Testing Finished Time: 7PM, 2016-04-19

Release Time: 2AM, 2016-04-20

Note: Scripts for changing the database should be upload to the directory "Development Document-Version" on SVN/Git, e.g. \01 Development Document\V2.2.0. And the name format is Script_v2.2.0.txt. This script is maintained by the technical manager.

6. Define version/build numbers

Before testing, set version/build numbers for each component.

Responsible: Product/Project Manager

The version/build number specification is

1) The second digit is +1, so the third digit is 0, e.g. V2.2.0

2) After the release, add 1 to the third digit if any small changes, e.g. V2.2.1, V2.2.2.

Define the version number in Project-Build, and link relevant stories to this build. One story can be linked to several builds, e.g. Story 002: Change the page of Order List to display the information of his city for the operator. This story involves and should be linked to Order Central Component V2.2.0, Product Central Component V2.2.0, and WeMall/PC Mall Component V.2.2.0.

Note: The version/build number for the components should be defined separately, including

1) WeMall/PC Mall Component V2.2.0

2) Order Central Component V2.2.0

3) Product Central Component V2.2.0

4) Shop System Component V2.2.0

5) Call Center Component V2.2.0

6) Shop APP Component V2.2.0

Go to Project-Build-Bug in ZenTao to check all the bugs that are linked to this build.

7.Integration testing

After the coding is done, submit a test request.

1) Technical managers verify that it is OK to be tested and submit a Test Request in 'Project-Build' of ZenTao.

2) Technical managers deploy the code to testing server.

3) QA managers arrange testing tasks and report bugs. Note: When reporting bugs, set the bugs that has to be fixed in this release as Priority 1 and other bugs as 2 or 3. Also set Mailto project managerial staff, so every manager will know how the progress of the test task.

4) If the testing is going to be finished and the release is getting ready, technical managers could branch for the code that has been submitted for test on SVN (name it as V2.2.0_Testing). Bugs should be fixed by senior coders so to lower the possibility of causing new bugs. Notify those senior coders to switch to this branch, and edit their read/write privilege to Trunk on SVN so to avoid errors caused by read/write privileges. Other coders could code on Trunk meanwhile.

Note: 1) Select the build when reporting a bug in Request-Bug. 2) Notify everyone of the update on files that is uploaded to the testing server, and attach a list of bugs that needs to be fixed in this build

8. Acceptance testing

After the integration testing is done, review and do the acceptance testing. Note: All works here are for the Branch (V2.2.0_Testing) mentioned in Section 7. When QA managers reviews all the level-1 bugs, and confirm it is ready to release,

1) QA managers report to Product/Project managers that it is ready to release.

2) Product/Project managers should test it again to ensure the quality.

3) Product/Project managers confirm that it is OK to release, then submit it to party A for acceptance testing( If necessary, party A can involve in the testing mentioned in Section 7 ).

9. Release

After party A confirm that it is OK to release, release it. Note: All works here are for the Branch (V2.2.0_Testing) mentioned in Section 7.

On the day that it is release,

1) QA managers go to 'QA-Build' and change the status of the tested build into 'Finished'.

2) Technical managers package all the code that has to be updates, as well as the SQL scripts.

3) Product/Project managers export stories which have been linked to this build in Project-Story as an Excel file, and this file is the changelog sent to party A.

4) Product/Project managers send the changelog to party A and party A should sign the release confirmation.

5) Technical managers deploy the released files to the production server.

6) Product/Project managers create a release in Product-Release and add the release time and description. Like the release with the build.

On the following day that it has been released,

1) Technical managers export a Tag from the branch on SVN, and name is as V2.2.0_Release.

2) Technical managers go through tasks in ZenTa, and close all the tasks that have been included in the release. For unfinished tasks, link them to the next build.

3) Product/Project managers close stories released in this build after technical managers finish step 2.

10. Version maintenance

Usually, there are bugs that were not found before have to be fixed after it is released. Therefore, the current version has to be maintained before the next big version is released. So

1) Technical manager export a Branch from Tag-Release on SVN, e.g. V2.2.0_Fixbug.

2) QA managers get feedback from party A and report bugs in ZenTao. Set priority as 1, and the build version number as V2.2.0.

3) Technical managers fix bugs on the branch of V2.2.0_Fixbug. Pay attention to the privileges on SVN and assign privileges to the coders who are responsible for this branch.

4) QA managers arrange the regression testing.

5) Repeat step 2, 3, and 4 till it is ready for another release. Confirm the version number, e.g. V2.2.1, and export a Tag named V2.2.1_Release from V2.2.0_Fixbug. Technical managers update it to the product server. Export the list of bugs that have been fixed and send it to party A to confirm.

Repeat step 2, 3, and 4 till this version is not maintained any more.

11. Stop maintenance

Generally speaking, the last release is not maintained five days earlier before the new one is released.

1) Technical managers inform coders to switch local directories to Trunk, and close their privilege to the Branch of the last build on SVN.

2) Product/Project managers close the last release in Product-Release and set the release as terminated. Note: Do not forget to terminate a release, as it will be display in the drop-down of linked build when reporting a bug in ZenTao.

Product/Project managers should start to discuss stories for net release with party A after step 2 is finished. Then the technical manager can decompose stories into tasks and assign to coders, and coders start to get familiar with techniques required to finish the tasks. Then QA team start to understand the workflow and details, so the whole new sprint begins. It is also called the spiral Agile iterative development.