背景
チーム管理些細な、急な仕事を開発するためにどのように？
多くの場合、いくつかのビジネスソフトウェア開発チーム同様の訓練支援やその他の予期しない仕事は、開発チームは、この突然の支援作業に似た顧客のトレーニングを管理する方法がわかりません。
予想外の作業を問題解決には直接の進歩と開発チームの速度に影響を与える多くの開発チームによって評価され、間接的に反復目標が完了し、プロジェクトのさえ成功か失敗するかどうかに影響されます。だから、突然の減少や開発チームワークと決意干渉が非常に重要です。
分析
混合サポート作業と開発作業、新しいタスクが完了し、受け入れる準備が必要です裏付ける明確な優先順位はありません。管理から、管理しながら些細なタスクや開発タスクのこれらのバーストは、難易度を大いに増加しました。
別の場合、開発チームは、通常の仕事を開発するときに、顧客は多くの場合、いくつかの競合のタスクを行うために開発チームを妨害します。開発チームは、多くの場合、ワークロードを処理するために余分を支払うので、急な仕事が焦点は、顧客によって提案され、優先処理を必要とされると、反復目標のリスクは到達することはできません。
作業効率を向上させる方法、些細な、予想外の支援作業に対処する方法の問題を解決するための主な開発チーム。
私たちは最初の場合、以下のように大別：
タイプ
機能
分析
A
ミキシング作業と開発の仕事をサポートし、作業の突然の出現は当たり前です。
開発者は新しい仕事を整理する必要があるため、サポート作業と混合し、通常の開発作業は、開発者は多くの場合、必然的に管理することの難しさを増加し、コンテンツを切り替える一時的に動作しますが、仕事の内容の頻繁な切り替えも時間の無駄原因、新しいジョブが完了することができます前作が終わっどこリコール後も継続されます。したがって、問題は、リスクに対処するための時間を考慮するために、このモードを必要としている開発チームモードで問題の嘘のルート。
二つ
開発志向の、突然の緊急事態が発生するとは、それは、通常の要件の変更です。
新しい緊急作業では、チームのメンバーは何をするかどうかを決定する仕事を、取るとき、誰が開いて、透明性のルールを持っていない、に対処する方法がわかりません。これらの新規雇用を運ぶことができない場所がありません。根本的な問題はバックログを管理する方法です。さらにミックスに新しい作業項目の追加は、どのようにバックログを更新する際に、あること、私たちは多くの場合、どのように行うには、その需要は（も要件の変更とみなさミッションの一時的な増加を）変更されたと言うことを理解？
救済
方法アジャイルがトレンドで、より多くの開発チームと使用との接触に入って来た、DevCloud製品はまた、迅速な思考の設計に基づいており、アジャイル以下は、スクラムフレームワークを含むがこれらに限定されない、説明されています。
あなたは部門のスタッフの観点から考えることができ、作業の混合型は、仕事の部門のベストフォーカスを持っている開発チームをお勧めします。スタッフの開発に使用されるエネルギーの一部は、スタッフが緊急対応作業の別の部分に焦点を当てました。（そのような疎結合、シンプルを受け取ることが可能な限り開発作業など）に対応するリスクを発行する準備ができて、スタッフの予想外の仕事を扱います。担当者がコンテンツを開発するための開発作業の完了に集中する必要があります。新しい仕事が入って来ていない作業チームの分裂の種類、どんなには、我々は良い管理ルールの作業項目である開発チームによって確立されたルールに従う必要があります。
主な開発は、突然の緊急タイプ2と一緒に、私たちの開発チームの多くはしばしば会っただけでなく、手術上のプログラムの焦点のこの記述を解決します。変更の需要に対処する方法を学ぶために、ルートシステムからアドレス優先項目に働くことは基本です。
ソリューションのアイデア
など、私たちは、コアの問題で、その後、作業項目を形成する前に、我々は問題や人の作業項目の作業項目のソースに責任があるを解決するために、その後、作業項目のための作業計画を行う必要がある作業項目を管理するために知っていること、開発チームはよく実行します。まず第一に、明確なプロダクトマネージャー、その需要の唯一の源。第二に、優先度の高い作業項目は、最初に-Doリストの製品の並べ替えを行います。その後、再設定し、合理的な反復更新対象のための開発チームの能力を確実にする計画。その後、再び、当選者は、次の反復より良いポイントを向上させる検討。最後に、数回の反復測定と分析、継続的な改善、ダウン。また、同期の必要性は、クロスファンクショナルチームの才能、努力を育成することです。次のように解決策のアイデア図です。
クリア需要責任者は
明らかに需要の唯一の源ので、責任を負う必要があります。DevCloudでは、一般的にその役割を埋めるプロダクトマネージャーを指します。
何のために責任があるエンドでの需要の下での明確な責任をしてみましょう。人々は、少なくとも二つの方向に直面していると同時に、需要の責任。
1の一方で、責任者は、プロジェクトの利害関係者のニーズをよく理解している、顧客やユーザーは自分のスポークスマンとして機能するため、および優先度（緊急項目は、上記の作業を含む）が必要です。理解のこの点から、一般的な製品のマネージャーは責任として行動する必要があります。
一方、責任必見交換特性は、開発チームとビルド順序で構築することが求められています。開発チームは、特性を完全に考慮することができるれる状況の責任者のニーズを決定することができるように需要の責任も、受け入れ基準の特性が明確に説明されていることを確認する必要があります。理解、ビジネスアナリストやテスターの一般的な役割のこの時点で。
同時に、責任だけでなく、バージョンのものの需要は、反復とバックログレベルは良い経済的意思決定と経済運営を継続することができます。呼ばを統一するためには、理解を容易にするには、責任のプロダクトマネージャーは、（スクラムプロダクト所有者と同様の枠組み）として動作するため、需要が続きます。
プロダクトマネージャの役割のプロット明るい部分これらの作業に関連した突然の対応反復。プロダクトマネージャーは、明示的に、この反復で完了しなければならないかどうか、考慮に経済的、他の寸法のビジネスや経営の値を取って、完全に仕事の優先順位のこれらのバーストを決定する利害関係者と通信する必要があります。これらの緊急作業の優先度が高いになると、この反復で行う必要があり、それは作業項目を整理する必要があります。
バックログは、カーディング
最初にやるにおける反復（イテレーションの詳細to-doリスト、下の「もっと学び」を参照）である反復to-doリストにバックログ、優先度の高いバックログをカーディング。一緒に私たちは、最初のバックログが何であるかを見てみましょう。受注残高は、予想される製品の機能のリストを優先させます。作業項目が何であるかを理解するために来ます。作業項目は、バックログバックログです。ユーザーと顧客は、作業項目のほとんどは、もちろん（、実際の値の特徴や機能はもちろんの任意の貴重な仕事を担当するバグ修正の数ニーズ、技術の向上、および製品知識習得の作業者が含まれていますワークの急激値は、ワークアイテムの一部）です。
櫛は何ですか？櫛は、最も重要な3つの活動を指します。まず、確立し、作業項目を絞り込むために、第二の、作業項目を推定するために、第三の、優先順位付け作業項目を。次の図
バックログは、活動をコーミングすることにより構造の変化を示しています。
図DevCloudに示すように、カーディングした後、対応するDevCloudは、イベント結果をコーミングで具現しました。
经过产品经理梳理后，如图高亮部分，突发性培训任务的工作项得到了合理的优先级，同时它是被细化的，而且是经过工作量估算的。产品经理是梳理活动的最终决策者，也就是说突发性的工作由产品经理主导梳理，优秀的产品经理能够充分协调利益干系人安排足够的时间，根据开发团队的特点和项目类型来开展梳理活动。同时开发团队还要估算新加入突发工作的工作量，帮助产品经理根据技术依赖关系和资源约束来排列工作项的优先顺序，如果新加入突发性培训任务的工作项优先级高，那么就会纳入本迭代代办列表中。
重新定计划
重新定计划，确保开发团队容量适合，合理更新迭代目标。在重新定计划之前，我们一起来了解下什么是敏捷下的计划,或者说敏捷提倡的计划和传统瀑布开发模式下的计划有什么区别。
我们知道敏捷宣言中提倡“响应变化高于遵循计划。”，它与传统瀑布开发模式或者说计划驱动的顺序开发模式的计划不同点就是一个是偏向响应变化，一个是偏向遵循计划。在计划驱动的顺序开发过程中，计划是工作如何开展、何时进行的权威信息源。因此，计划是需要遵循的。相比之下，在敏捷中，根据实时信息关注适应重新制定计划胜于遵循计划。我们认为盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。
在敏捷开发过程中，我们的目标不是满足某个计划或者某个事先认为事情如何进展的预言。相反，我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。因此，通过梳理以后的工作项,可以对应的调整计划。原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是“等价交换原则”，意思是用优先级高的突发性工作项，替掉同等工作量的其它工作项，这也是为了保开发团队按照一个稳定的节奏交付。因为固定的开发团队一个迭代中容量是不变的，新加入突发工作项而不移除其它工作项势必会给开发团队交付带来压力，破坏开发团队的交付节奏。等价交换示意图如下：
具体在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）
