Background
how to develop a team management trivial, sudden work?
Some business software development teams often similar training support and other unexpected work, do not know how the development team to manage customer training similar to this sudden support work.
Problem solving unexpected work is valued by many development teams, which directly affects the rate of progress and development team, and indirectly influence whether the iteration goals to complete, and even the success or failure of the project. So sudden decrease or resolve interference with the development team work is very important.
Analysis
mixed support work and development work, there is no obvious priority to support the new task requires complete and ready to accept. From the management, these bursts of trivial tasks and development tasks while managing increased a great deal of difficulty.
When another case, the development team to develop normal work, the customer will often interfere with the development team to make some conflict tasks. And sudden work is the focus proposed by the customer and requiring priority treatment, so development teams often pay extra to handle the workload, the risk of iteration goals can not be reached.
The main development team to solve the problem how to deal with trivial, unexpected support work, how to improve work efficiency.
We first case broadly categorized as follows:
Types of
Feature
analysis
One
Support the work of mixing work and development, the sudden emergence of the work is the norm.
Support work and normal development work mixed together, developers will often work temporarily switch the content, will inevitably increase the difficulty of management, frequent switching of job content can also cause waste of time, because developers need to sort out a new job, a new job is completed after the recall will continue where the previous work done. Therefore, the root of the problem lies in the development team mode, in this mode need to consider the time to deal with the problem, risk.
two
Development-oriented, with the sudden emergency occurs, that is, the normal requirements change.
With the new emergency work, team members do not know how to deal with, when to take the job, who will decide whether or not to do, who do not have an open, transparent rules. There is no place that can carry these new jobs. The root problem is how to manage Backlog. Further understood that when a new work item add to the mix, how to update Backlog, that is, we often say that demand has changed (temporary increase in the mission also considered changing requirements) how to do?
Remedy
agile way is the trend, more and more came into contact with the development team and use, DevCloud product is also based on the design of quick thinking, agile following are described, including but not limited to the Scrum framework.
A mixed type of work, you can think from the perspective of the division staff recommended the development team who has the best focus of the division of work. Part of the energy used for staff development, staff focused on another part of the emergency response work. Deal with unexpected work of staff ready to issue the corresponding risks (such as development work as much as possible to receive simple, loosely coupled). Personnel should concentrate on completion of the development work to develop content. No matter what type of division of work teams, no new work coming in, we need to follow the rules established by the development team, which is good management rules work items.
The main development, along with the sudden emergency type two, a lot of our development team often met, but also solve this description of the program focuses on surgery. Working to address priority items from the root system to learn how to cope with the demand for change is fundamental.
Solutions ideas
that we know to manage work items is the core problem, then before the formation of a work item, we need to solve the problem or who is responsible for the work item source of the work item, and then to do the work plan for the work items, such development team to perform well. First of all, a clear product manager, so the only source of demand. Secondly, the sort of products to-do lists, high-priority work items do first. Then, re-set plans to ensure that the development team capacity for rational iterative update target. Then again, reviewed elect improve point, the next iteration better. Finally, several iterations down, measurement and analysis, continuous improvement. In addition, the need for synchronization is to cultivate talents, efforts to cross-functional team. Solutions ideas diagram is as follows:
Clear demand responsible person
clearly needs responsible, so the only source of demand. In DevCloud generally refers to the product manager fill that role.
Let's clear responsibility under demand in the end who is responsible for what. Demand responsibility at the same time people have to face at least two directions.
On the one hand, those responsible have a good understanding of the needs of the project stakeholders, customers and users need (including emergency work items mentioned above) and priority in order to act as their spokesman. From this point of understanding, general product manager needs to act as responsible.
On the other hand, demand responsible must exchange properties to be built with the development team and build order. Demand responsibility must also ensure that the characteristics of the acceptance criteria have been clearly explained, so the development team can determine the needs of persons responsible for the circumstances under which the characteristics can be considered complete. At this point of understanding, the general role of business analysts and testers.
At the same time, demand for those responsible but also in the version, iterative and Backlog levels are able to continue to make good economic decisions and economic management. In order to unify called, ease of understanding, followed by the demand for responsible product manager acts as a (Scrum Product Owner similar framework).
Plotted bright portion of the product manager role these work-related sudden the corresponding iteration. Product managers need to fully communicate with stakeholders who determine these bursts of work priorities, taking into account the value of the business and management of economic and other dimensions, whether explicitly must be completed in this iteration. Once these emergency work is a high priority, must be done in this iteration, it would need to sort out a work item.
Backlog carding
carding Backlog, high-priority Backlog into the iteration to-do list that is iteration (more about iteration to-do list, refer to "learn more" below) in do first. Together we first take a look at what is Backlog. Backlog is a prioritized, the list of expected product features. Come to understand what is the work item. Work items are in Backlog backlog. Users and customers, most of the work items are of real value features and functionality, of course, include a number of bug fixes needs, technology improvements, and product knowledge acquisition work person in charge of any valuable work (of course sudden value of the work is also part of the work item).
What is the comb? Comb refers to the three most important activities. First, to establish and refine the work item; second, work items to estimate; third, prioritize work items. The following figure
Backlog shows the change in the structure by combing activities:
After carding, the corresponding DevCloud embodied in, as shown in FIG DevCloud combing event result.
经过产品经理梳理后，如图高亮部分，突发性培训任务的工作项得到了合理的优先级，同时它是被细化的，而且是经过工作量估算的。产品经理是梳理活动的最终决策者，也就是说突发性的工作由产品经理主导梳理，优秀的产品经理能够充分协调利益干系人安排足够的时间，根据开发团队的特点和项目类型来开展梳理活动。同时开发团队还要估算新加入突发工作的工作量，帮助产品经理根据技术依赖关系和资源约束来排列工作项的优先顺序，如果新加入突发性培训任务的工作项优先级高，那么就会纳入本迭代代办列表中。
重新定计划
重新定计划，确保开发团队容量适合，合理更新迭代目标。在重新定计划之前，我们一起来了解下什么是敏捷下的计划,或者说敏捷提倡的计划和传统瀑布开发模式下的计划有什么区别。
我们知道敏捷宣言中提倡“响应变化高于遵循计划。”，它与传统瀑布开发模式或者说计划驱动的顺序开发模式的计划不同点就是一个是偏向响应变化，一个是偏向遵循计划。在计划驱动的顺序开发过程中，计划是工作如何开展、何时进行的权威信息源。因此，计划是需要遵循的。相比之下，在敏捷中，根据实时信息关注适应重新制定计划胜于遵循计划。我们认为盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。
在敏捷开发过程中，我们的目标不是满足某个计划或者某个事先认为事情如何进展的预言。相反，我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。因此，通过梳理以后的工作项,可以对应的调整计划。原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是“等价交换原则”，意思是用优先级高的突发性工作项，替掉同等工作量的其它工作项，这也是为了保开发团队按照一个稳定的节奏交付。因为固定的开发团队一个迭代中容量是不变的，新加入突发工作项而不移除其它工作项势必会给开发团队交付带来压力，破坏开发团队的交付节奏。等价交换示意图如下：
具体在DevCloud中的体现，如等价交换图一和等价交换图二所示。
等价交换图一
等价交换图二
最后，从迭代中选取差不多工作量的低优先级工作项移回到Backlog中，即在DevCloud中完成了工作项的等价交换。
迭代回顾，识别改善点
迭代回顾是一个会议，目标是持续改进流程，根据开发团队的需要改进和制定流程，以提高士气，提高效率，提高工作产出速率。几个迭代下来，需要对这类突发工作进行度量分析，识别改善点，持续改善。虽然我们提倡响应变化高于遵循计划，但同时执行迭代的时候也需要开发团队在不受干扰的情况下全力以赴的迭代。因此，就应该思考为什么每个迭代中都有外界的干扰（突发工作）存在，开发团队共同学会分析和找到解决办法才是真正的解决问题之道。
这里给出一个DevCloud产品很好的小实践，可以提供客观数据帮助回顾。新纳入迭代待办列表的突发性工作项可以在DevCould的“模块”下进行管理。也就是说，在新建User Story之前建立一个“突发任务”模块，然后将User Story中的“模块”属性选中它。这是为了在后续几个迭代中对这类突发性工作进行度量分析（可以按模块排序，方便度量分析）以便持续改善做准备。如下新建突发模块图和新建User Story图所示：
新建突发模块图
新建User Story图
选择报表—新建报表—自定义报表—增加筛选条件（模块）—按迭代维度—保存。然后对统计出来的数据进行分析。可以以图和表两种方式展示，具体如按图展示图和按表展示图所示：
按图展示图
按表展示图
同步进行人才培养
同步需要进行的是人才的培养，向跨职能型开发团队努力。不仅仅是应对处理突发性工作，而是让开发团队更高效。
每个任务应该由谁来做，或者说突发性工作应该由谁来做？答案很明显，应该是能够最快且正确完成这个工作的人来做。如果这个人不在了怎么办？或者他正在做其他工作，抽不出时间，但这个任务需要马上完成。开发团队成员都有责任考虑各种不确定因素，做出最好的选择。如果开发团队成员都是T型技能的时候，每个任务都有好几个人可以做，那么开发团队就能够在迭代执行期间几个人全力完成制约工作项流程的任务，更灵活地平衡资源，使开发团队更高效。
了解更多
什么是迭代待办列表？
迭代待办列表在DevCloud中称“迭代”，它是一组为当前迭代选出的产品待办列表项，同时加上交付产品增量和实现迭代目标的计划。迭代待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能能到“完成”的增量中所需要工作的预测。
当新工作出现时，开发团队需要将其加入到迭代待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。在迭代期间，只有开发团队可以改变迭代待办列表。迭代待办列表是高度可见的，是对开发团队计划在当前迭代内工作完成情况的实时反映，该列表由开发团队全权负责。
迭代待办列表在迭代计划会议中形成，其中开发团队不会被动分配任务而是由开发团队成员主动认领他们擅长和喜爱的任务。任务被分解为以小时为单位，建议任务不要超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。每项任务信息包括其负责人、工作量、承诺的完成时间及其在迭代中任意一天的剩余工作量，且仅开发团队有权改变其内容
HDC.Cloud 华为开发者大会2020 即将于2020年2月11日-12日在深圳举办，是一线开发者学习实践鲲鹏通用计算、昇腾AI计算、数据库、区块链、云原生、5G等ICT开放能力的最佳舞台。
欢迎报名参会（https://www.huaweicloud.com/HDC.Cloud.html?utm_source=&utm_medium=&utm_campaign=&utm_content=techcommunity）
