table of Contents
We still to this figure as a beginning has been talked about before, Project created problems related to the relevant field, interface-related content. The next step is the most important and complex workflow-related content.
Previous articles have introduced the idea of workflow, primarily 2:00:
- Subtasks drives the main task of the state of flow.
- Simplify and automate the flow field and flow.
Workflow Overview
Workflow Service is the main problem (Issue), Jira is among the core carrier. Workflow has two core concepts: Conversion (Transition) and state (State) .
We use a simple workflow to explain.
In the figure above, TO DO, IN PROGRESS, DONE indicates three state , also represents the three colors noted that the meaning of, blue is not started, for the yellow, green completed.
When you need to add a new state in the process, you will need to choose one of three colors.
The line connecting the two states, that is, conversion, meaning that through this act, the question from the state 1 to a state 2.
State is a result of that, we can define the number of operations performed by the results obtained by the conversion performed at the time of conversion, the workflow figure is operable when selected content conversion.
Figure I chose " Go in progress " this conversion, appears on the right five choices, we in turn explain:
- Attributes
- trigger
- condition
- Validator
- Post-processing functions
Attributes
Look at an example
Here is the usage of the title and the internationalization of the submit button keys
trigger
Fisheye Crucilbe and can be associated with the branch and code conversion is performed automatically CodeReview.
condition
Only condition is satisfied, the conversion can be performed
Some of the conditions contained herein and Jira plugin comes with increased
Validator
Validation script similar to the form is submitted, you can fill out to confirm the validity of the
Post-processing functions
After the successful execution of the conversion, the custom of some operations.
Our automated processes after processing functions are to promote the need for intervention.
For everyone to see a sub-task of post-processing functions to automatically trigger an example workflow:
Workflow type
Custom workflow needs from our actual management needs, different ways each team management, nature and type of workflow issues is not the same. I am here to make the actual process of sorting out the R & D management in four workflows.
- The main task workflow
- Sub-task workflow
- Bug workflow
- Default workflow
This four working stream, basically covering the relevant processes and the role of R & D management work.
The main task
The main task concept includes the story (Story) and tasks (Task), the story is normally provided by products launched correspond to the usual concept of demand (mainly functional requirements, of course, may also contain non-functional requirements, but generally will allow users to perceive ), the task is usually driven by the development work initiated (such as code refactoring, split service, performance optimization, the user may not be aware of significant content).
The main task is the core content of the work summarized in a research and development team, so the workflow is a need to include all roles, products, design, development, testing, operation and maintenance in the R & D team and so on. General tasks also order various roles from circulation, so the workflow can be divided into these roles, each role are set to-do, in progress, completed the three states. Which can be set to complete the next part of the to-do, consider these two states can be combined into a single.
Subtasks
Remember one of our principles is to simplify the management of research and development operations, the actual mandate holders do not need to understand the overall complexity of the design and logical, simple operation will be able to drive the overall process forward. That is to rely on the concept of sub-tasks.
In our R & D team, all staff specific items can only be performed with one type of record is subtasks. Subtasks streamline field, must contain only content. The process is simple, only need to include to-do, in progress, completed. Since the default is to be run after the new sub-task, so normal operations can only contain two acts, ongoing and completed. With prior art labeled packets, and by switching the state of completion is simple, it is possible to push the main flow state change their roles.
Bug
Bug is an important form of R & D Quality Management, Bug of the submitting party general QA, the recipient is most developed, it could be the product. Bug in the workflow process, the process is actually quite clear, it is to focus on solving and verifying the Bug, the proposed transfer between recipient. We want to optimize the point that people can realize automatic conversion process, no manual assignment.
default
As we write the code will need to select a default cycle time branch, as long as the default choice is the simplest to-do, in progress, can be completed, or even just need to do and to be completed, we can confirm the actual situation.
Workflow Designer
Design workflow there is an important prerequisite is that the user group is divided, for the distinction between roles.
The next four above will be described in detail workflow involves some settings or script places will try to put up a clear illustration or code.
The main task
Workflow primary task to cover all the roles, it is a most states first look at Fig.
This process in 11 states, began as a default to-do state (TO DO), the next we actually can see, based on the roles divided into several blocks, the far right is the product, followed by the next left UI design, development, testing, and ultimately complete.
Here are a few design points and we can discuss about:
- TODO state can be converted into a role of any state.
Due to the different circumstances in different Story or Task, the role of actual participation is a difference, if we limit the flow of all the characters must have processes may not be so flexible. So each role performed in the state can all be converted directly from TODO over, but the completion status can only be converted from in progress. - All conversions are named in a uniform format.
Conversion can see all the two main types of prefixes: Go and completed , respectively, corresponding to the progress to be done, and the progress to completion. The reason for this, first of all when naming a unified model is relatively simple do not think a lot of names, because the same scheme, the same state may have multiple states can be reached, in order to facilitate follow-up automated workflows are designed so that we helpful (this sentence later in the workflow of subtasks which can be well explained). - Different stages of pre-nodes of different
products is the initial stage, a start must be the product needs to sort out and organize prototyping and design.
Front I are generally designed products, but also independently initiate some requirements (such as UI design revision reconstruction, etc.)
research and development stage, pre-nodes may also be the product UI, because the normal process is finished prototype to product to design, UI design done research to develop together. Of course it is also possible to deliver the product directly without additional R & D to develop the design. So the design can be used as input and product research and development.
Enter the test must be developed, because there have been developed to change the system, only need to be tested.
The finished node, in most cases the results should be published on-line after the test confirmed guarantee, a small number of cases the test may not be able to verify the confirmation directly after the release development.
Post-processing functions
State of the main tasks of the lot, but special configuration in fact very small, I am here only a special post-processing features designed scenario is as follows:
We have research and development centers and customer support centers, customer support centers may have some suggestions or external customers Bug It will be converted into internal research and development tasks. We will use the work order associated with "work orders associated with" R & D center Story and Support Center, when the implementation of internal R & D Story " go to complete the" Change status associated with work orders.
This feature requires a plug-in JMWE, provided Transition linked issues such method.
Configuring here is relatively clear
first row select what you want to trigger the conversion related issues (by name or ID), the following is selected link type.
Transition screen section below, we will "managers" to "Speaker", meaning that the work order has been released on the line, who reported this issue has to do subsequent follow up.
Will make a final comment in the corresponding work orders: internal R & D process has been completed and published.
The main task summary
Main task itself is a manifestation of management methods, in order to process the various roles in series, and can stand a higher perspective speedy follow-up related tasks to promote the process of convergence.
Therefore, the main task is no one to maintain normal, that is, no one will take the initiative of the main tasks of state management, we are just watching.
Subtasks
If the main task is complex and simple (state are many and complex, but the logic behind it simple), sub-task is simple and complex. How to understand this sentence, let's look at the workflow of subtasks.
Look at this chart basically understand, I did not adjusted the simplest workflow, but the workflow only three states, ruled out the initial to-do state, the normal state can be switched only two. So subtasks are simple.
Next we look at the complexity of meaning
From this conversion process to be done, we have a total post-processing functions 15, the system comes removed, we have nine custom post processing function.
Similarly, we together to talk about some of the design point of which:
- Subtasks are part of the main task, so it should be is a collection of subtasks main task of the personnel staff.
Our design, or at the start of the new sub-tasks will be added to the report and the managers responsible parent task of field, table name associated personnel throughout the mission which, faster communication.
Post-processing functions
The main task is to convert the sub-two, the processing to be done, and the process to completion. All of our post-processing functions on both the conversion.
Processing to be done
Do to be carried out in a total of nine custom rules we look together:
Date Rules
Rule 1 is used to set the field value this feature, meaning you want to click on the start time, the start date will be set the task of the current time.
The purpose is to keep the start time of the subtasks actual time, does not require the operator to manually adjust the time.
Solve results
Rule 2 is also used to set field values , it is to solve the result of sub-tasks set to the parent task.
The purpose is to result subtasks can be reflected in the parent task, so that manages to find out if there is a special solution results.
Responsible
Rule 345 is also used to set field values , it is responsible for the maintenance of the field.
The purpose is to add sub-tasks or persons responsible for field current main task of personnel involved, responsible for field primary task is to preserve all participants to quickly identify the range of persons. More sub-tasks is to clarify the responsibility.
Main task flow advances
The 12-15 rule is the use of Transition parent Issue (JMWE the Add-ON) , which is provided by the plug. The main task is to trigger the process flow.
The purpose is to promote the primary task flow by flow subtasks. Here would be more complicated, we look at the specific implementation, the following figure
Here we are divided into four parts:
- Set the trigger main task flow
- Set field values
- add comment
- Set the execution condition
Set the trigger main task flow : the role we want to address here in the name of principle. The premise here is triggered main task flow, or the requirements of the current main task of the state is the starting point of the target circulation. This means that if the current workflow is A → B → C, if we expect the implementation of A → B, that the status of the current main task must be to successfully reach the A to B, it would not be effective. Our naming convention where all are turned to a state of flow named "Go xxx", such a method can trigger a variety of circulation in the initial state.
Set field values : this is already a more conventional design, this process does not need to set the contents of
Comment : All automated process execution, automatically add a comment next to the main task, recorded by a who advance to what state. Track record for later
Set the execution conditions : This is actually the core of the post-processing feature all in accordance with the order, which should be able to perform the main task to promote the smooth process flow, it can only be judged by the execution condition. There mainly to determine the role of the current user by user group, to decide what to promote circulation of the main tasks. The following is from product design, development, test scripts four subtasks start roles:
- Product Manager role
(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm") && issue.getAsString("任务类型") == "")This is determined whether the current user is a system user group org-pd-product-pm words (Product Manager) in, and the task type is not particularly provided.
Hello everyone understand user group, the type of task What does it mean?
We found that because everyone must work floor becomes subtasks, some subtasks are not actually advance the process state changes. For example, demand for the product manager of pre-research, feasibility analysis, demand actually did not advance alone, temporarily should not be the main task to promote the product design in such a state. This situation can be remedied by the main task completion status process, we are another way it is to set up a special sub-type of task to advance the process to avoid the wrong state. So we formed an internal agreement, once the task type sub-tasks set value, it will not promote the process flow.
- UI design role
(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui") && issue.getAsString("任务类型") == "")- R & D role
(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder") && issue.getAsString("任务类型") == "")- Test role
(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa") && issue.getAsString("任务类型") == "")Process to completion
Here there are five custom rules:
Main task flow advances
Rule 6-10 using the Transition parent Issue (JMWE the Add-ON) , the contents of the above does not repeat
here only the main post-processing functions, we will explain about dismantling
- Products complete
this part of the logic first determines whether the user is currently operating the product role, if not outright ignored. If so, will cycle all sub-tasks under a parent task, and it is determined whether or not the product is attributable to the role of the task. If the mission is the type of product, whether or not been completed. Only in addition to the current task, all other products tasks are completed, it will advance to the main task completion status of the corresponding role.
if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm"))){
return false;
}
boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm")){
if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
return false;
}
}
}
return result;- UI design is completed
if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui"))){
return false;
}
boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui")){
if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
return false;
}
}
}
return result;- R & D is completed (there are test)
developed to determine the conditions will be a little special number, there will be a complete analysis of diverting R & D has two branches, the need for testing.
The logic is actually very simple, is circulating all sub-tasks, determine whether there is a group of users to test the sub-tasks, if you have turned to " developed the test ," if not to " develop complete without testing ."
if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder"))){
return false;
}
boolean result = true;
boolean hasQA = false;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder")){
if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
return false;
}
}
if(!hasQA && (issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
hasQA = true;
}
}
if(!hasQA){
result = false;
}
return result;- R & D is completed (no test)
if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder"))){
return false;
}
boolean result = true;
boolean hasQA = false;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder")){
if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
return false;
}
}
if(!hasQA && (issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
hasQA = true;
}
}
if(hasQA){
result = false;
}
return result;- Finished test
if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
return false;
}
boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa")){
if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
return false;
}
}
}
return result;Subtasks summary
The core sub-tasks, is simple and complex. Simple process in order to better team in the implementation of complex logic backstage to meet the management needs of management.
Bug
Bug is the development of quality defects in the testing process, the process is not complicated, mainly automated circulation and control requirements.
Only four states, and sub-tasks compared to, in fact, only one more state "has been resolved." Bug testing is proposed by default, after a new state is the " to-do " research and development begin processing translates to " in progress ", R & D translates to "after the completion has been resolved ," the test will follow " has been resolved ," the Bug, if confirmed solve it is converted to " complete ", if not resolved then converted to " progress ."
Post-processing functions
About Bug, the most important fact is that post-processing functions " in progress " and " resolved " direct back and forth, so we look at the " problem solving " and " unresolved " after dealing with two conversions.
Solve the problem
It should be of interest mainly responsible for processing. Only in solving the result is "Done" (other general can not be reproduced, abnormal network environment, the demand for such a design, etc.) when we come to the current operating as a responsible person. This is to confirm that the development of accountability, there is actually only the development and approval process only requires Bug responsibility attributable to research and development.
Managers will be automatically assigned to the speaker, thus avoiding manually specify the R & D managers.
unsolved
Unresolved conversion significance is to say, Bug research submitted to the test does not actually repair, need to return to research and development. Here is the need to accumulate "to return the number of times" this custom field,
<%
int i = issue.get("退回次数") >= 0 ?issue.get("退回次数"):0;
i=i+1;
println(i)
%>Managers also need to be assigned directly to the current staff turnover over the previous R & D personnel. Using the "Assign to last role member (JMWE add-on)" plug-in provides.
The Project Role, we need to set up the project.
It can be set in the project settings in this menu.
Bug summary
Bug overall logic of many relatively simple, mainly to facilitate the transfer between R & D and testing, and try to ensure that automated personnel assigned to the conversion.
Default Task
The default task here will not belabor normal "to do - in progress - finished" process to meet.
to sum up
At this point, all of the workflow design introduces complete, some of which involved the use of Groovy scripts are written in languages, the hardest part is still the need to identify how to get the field in acquisition mode in Groovy.
Mainly through here to explore some tools to help.