1. The Ticket System
   
   • Every development happens because there are tasks. These tasks may include: further development, troubleshooting, analysis, or instructions.
   • Each task is given a number and a title. Further parameters are: a product's belonging, a customer order, the urgency of the task, each responsible person, team members to-be-informed, shortcuts to other tasks, resolved in, and conducted tests. Furthermore, task files can be attached to a task.
   • Every task runs through several situations. In our system, there are the following situation:
     
     • Open: Task is unfinished
     • inReview: Task is completed according to the developer and needs evaluation
     • integrate: We do not use this because the evaluation and integration are one single step
     • onDeck: We do not use this situation either
     • Waitcust: We are waiting for the customer feedback which could be either further information or approval
     • Deferred: Shifted, not updated at the moment
     • Obsolete: Outdated, task is no longer required and there is no result either
     • Rejected: Rejected e.g. this task has been issued twice
     • Closed: Completed, there is a result
   • Every task begins in an Open situation and ends in either Obselete, Rejected or closed situations.
   • We have time recording in the task breakdown system. Even interim stages, including failures, have to be described.
2. The Evaluation
   
   • Before the Closed situation, there is the inReview situation. There has to be a positive evaluation in order to finish a situation with Closed.
   • We usually work with bundles that we publish as a whole. We picked up the ideas for the version scheme from Cincom. ^[1]
   • At the end of development, the product and necessary statements are given to the evaluator, e.g. what was changed and which tests belong to the changes.
   • In all of our images, we used the "Always open merge tool before performing merge" (see below) option in Settings.
   • The following tasks usually belong to the evaluation process:
   1. Reading all of the altered code (with the help of the merge tool)
   2. Reviewing the comments
   3. Running the test suite (SUnit)
   4. Implementation of the code critique whereby we utilize an extended version that also reviews comments.
   5. Testing the application
   6. Feedback to the developers if there are problems, with clear desciptions of the problems found
   7. Integrating the changes into the string (also valid if the problems only exist in the comments)
   8. Code changes other than formatting can turn the step into a development step and the task of evaluation will be burdened to another team member. In this case, there will be no integration in the string.
   • Our industry clients have also adopted this procedure and they apply it successfully.
     
     
3. Technical Information
   • We have adopted the task system Mars (Minimal Action Request System) from Cincom and we call our tasks ARs as well.
   • Furthermore, we implemented a store support package for this process that we have delivered to the customers as the adapted version. These customers implemented different ticket systems.
   • At the moment, we implement the following standard resolutions in Visualworks 8.2:
   • Res104181
   • Res106266
   • Res106722
   • Res107008
   • Res107022
   • Res107179
   • Res107211
   • Res107278
   • Res107284
   • Res107302
   • Res107311
   • Res107345
   • Res107477
   • Res107522
   • Res107547
   • Res107701
   • Res106667
   • Among them are some that make working with the merge tool a lot simpler (Res107008, Res107022, Res107179).
     
     
4. Examples and Screenshots
   
   • We use a setting that opens the merge tool whenever changes are merged:
     
     
   • In the published item dialog from Store, the task that is being worked on can be seen. The Blessing level is also present as further reference of the maturity level of the version:
     
   • It is also possible that a developer is working on multiple tasks before they submit all of them for evaluation, which is indicated by the double task numbers. The version number 8.2 - 30 + AR 8887 1 + AR 8897 1 can be interpreted by these following steps:
     1. The developer is assigned to the 8.2 - 30 version, which is the 30th root version of the current version number 8.2
     2. Firstly, he had worked on task 8887 and has already published this work once.
     3. Afterwards, he worked on task 8897 based on his work in task 8887.
     4. On the maturity level 'Integrated', it can be seen that both of these tasks were evaluated together and were integrated into the root.
   • More versions can be seen in another package:
     
     
     It can be seen here by clicking that the MARS Client Report version
     (8.1.1 - 6 + AR 8887 3 + AR 8897 1,georg) by Daniel has been integrated into the 8.1.1 - 7 version.
   • The merge tool displays the changes for the evaluator:
     
     
     In this case, there was a refactoring. The now used reportApplication method appears as a new method on the list.

         5. Our Specialty in Pair-Programming

1. In pair-programming, the programming and evaluation processes can happen at the same time.
2. It has proved useful to publish a so-called AR version and to then perform the integration procedure with the help of the merge tool.
   
   1. This way, it is guaranteed that the task number appears in the version number later, and...
   2. ...that no unwanted changes are carried over into a basic version.

   

^[1] Versioning

• "Trunk" package versions are of the form <versionprefix><space><dash><space><non-negative-integer>. For example: 7.7 - 1.
• Upon starting work on a new release, bundles and packages must be republished whole with version zero.
• All changes must be backed up by an AR, and all ARs must be merged back into the trunk from their specific, AR versioned packages.