アジャイルチームワーク：引き継ぎを最小限に抑える 3 つの方法
引き継ぎを最小限に抑える 3 つの方法
アジャイル的なチームワークは、引継ぎを最小化するのにとても役立ちます。逐次開発プロセスを採用しているチームは、専門家同士のハンドオフに慣れてしまっています。アナリストがデザイナーに仕事を渡し、デザイナーがプログラマーに仕事を渡し、プログラマーがテスターに仕事を渡す。例えば、プログラマーは製品バックログを書き終えてからテスターに渡すべきだとか、アナリストは他のチームより少なくとも1スプリント先に仕事をするべきだとか、色々な思いがあると思います。
しかし、パフォーマンスの高いスクラム チームは、スプリント中に常にすべてのことを少しずつ実行することを学習しており、それによって引き継ぎをできるだけ余分なものを取り除いて行っています。これを効果的に行うには、スクラム チームは 3 つのことを行う必要があります。
アジャイルなチームワーク – 書くのをやめて話し合おう
要件についてはこんな話があります。要件を書き留めておけば、ユーザーはまさに欲しいものを手に入れることができるというものです。それは真実ではない。せいぜい、ユーザーは書き留められたものを正確に取得することになりますが、本当に欲しいものと似ている場合もあれば、そうでない場合もあります。そのため、スクラム チームは、時間のかかる事前の要件フェーズや、その結果として得られる製品仕様を取りやめ、動的な製品バックログを優先します。
スクラムチームは要件について書くことから話すことに焦点を移すため、製品仕様ではなく、製品関係者との会話が、新機能がどのように動作するかを見つける主な方法になります。チームメンバーは、機能がどのように動作するか、どのくらいの速度で実行されるべきか、どのような承認基準を満たさなければならないかなどについて製品関係者と話し合います。スクラム チームのメンバーは、必要に応じてユーザー、顧客、その他の関係者とも話し合いますが、最も重要なことは、メンバー同士で話し合うことです。
従来のプロジェクトでは、アナリストが仲介役となり、顧客のニーズをプログラマーに伝えることがよくあります。ですが、スクラムチームでは、アナリストはファシリテーターとして、チームとプロダクトオーナーとの間で適切な議論が行われるようにします。たとえば、特定のユーザー ストーリーについて話すようにプロダクト オーナーとチームと話し合うなど。また、チームと製品関係者を集めて詳細について話し合う前に、アナリストが新機能に関する理解をチームに伝えることもあります。いずれの場合も、スクラム チームのアナリストは、文書を通じて情報を抽出するのではなく、コミュニケーションを通じて行います。
書面による要件文書がダメということではありません。むしろ、適切な場合には文書を使用する必要があります。経験豊富なスクラム チームは、きれいに書かれたコードと自動化されたテストケースに重点を置いています。次に、規制、契約、法的目的に役立つ、または必要な範囲でのみ、書面による要件文書を使用してこれらの形式の文書を補強します。
アジャイルチームワーク – 小さな仕事をこまめに転送する
スクラム チームでは、分野間の転送単位は、個々の製品バックログ項目よりも小さい必要があります。つまり、常にある程度の引き継ぎは発生しますが、次の人に引き継がれる仕事の量は、可能な限り少なくすべきなのは言うまでもありません。
例として、チームが新しい e コマース アプリケーションを開発しているとします。チームは、製品バックログからこのユーザー ストーリーに取り組むことを選択しました。「買い物客として、自分の住所への実際の配送コストに基づいて商品の配送方法を選択できるため、最善の決定を下すことができます。」スプリントの開始時に、この機能の開発に携わる予定の人達が話し合いをします。このグループに製品所有者、ビジネス アナリスト、テスター、プログラマーが含まれていると仮定します。機能に含まれる要件について話すことから始めます: どの配送会社をサポートしているか？夜間配達をサポートしているか？配達は二日以内に可能か？など
こうした議論が行われると当然、どのように始めるべきかを考え始めます。従来のプロジェクトでは、各人が（仕事が引き渡された後）好きなように始めることができました。ただし、スクラム チームではどのように開始するかについて、この機能に取り組むメンバー間で協力して議論する必要があります。この例では、プログラマが何らかの理由で ある会社を使った方がメリットがあると主張したと仮定します。テスターも同意します。アナリストは配送コストに影響を与えるパラメーターについて詳しく調査します。アナリストの目標は、プログラマーとテスターが この会社での作業を終了するまでに、その情報を入手できるようにすることです。
プログラマーは、ある程度十分な情報を得たら、コーディングを開始します。プロダクトオーナー、アナリスト、テスターは、高レベルのテストについて話し合います。その議論の後、テスターはテストリストを具体的なテスト（このサイズと重さの箱がこの目的地に届く）に変えます。テスターはテストデータを作成し、テストを自動化する。ある種の自動化はプログラマからの中間成果物がなくても可能かもしれませんが、完全な自動化はプログラマから初期バージョンを入手する必要があるかもしれません。テスターが具体的なテストを考えている間に、プログラマーがプログラミング中に考えていないようなテストケースをプログラマーに伝えることも必要です。
プログラマーとテスターが完了したら、配送料を計算するためのサポートをビルドに追加し、自動テストを完了します。
次に、プログラマーとテスターはビジネス アナリストに確認します。ビジネス アナリストは配送コストの計算についてさらに調査をします。このプロセスを繰り返し、プログラミングとテストが完了すると、配送計算のサポートがアプリケーションに追加されます。重要な要素は、チームが常にすべてのことを少しずつ行うことで作業方法を学習していることです。分析フェーズ (プログラマーやテスターなしで行われる) に続いてプログラミング フェーズ、その後にテスト フェーズが続くのではなく、これらのアクティビティのそれぞれが常に少しずつ行われています。
過度に大きな単位で作業を引き継ぎ続けると、スプリントの最後の数日まで製品バックログ項目が完了しない傾向があります。
スプリント内の毎日ある時点で完了した製品バックログ項目の数のグラフを作成することでチーム内に作業を明確に共有します。チーム メンバーは、グラフを確認して製品のバックログ項目をより早く完了する作業を行います。
アジャイルなチームワーク – 管理可能なバックログ項目を作成する
スプリントを計画するとき、チームはコミットしている製品バックログ項目のサイズに注意を払う必要があります。一部の製品バックログ項目は、上記の例よりも複雑です。最初はテスト可能なものでもプログラマーがテスターに提供できるようになるまでに、1 週間以上のプログラミングが必要になる可能性があります。すべてを思うように小さく分割できるわけではないので、その場合はそれで大丈夫です。重要なのは、このような多数のアイテムを同じスプリントに持ち込まないようにすることです。そうすると、多くのテスト作業がスプリントの最後に移行されてしまいます。
たとえば、部分的には実装できない 3 つの非常に大きな項目を含むスプリントを計画するのではなく、そのような項目を 1 つまたは 2 つ、さらに 2 つまたは 3 つの小さな項目をスプリントに組み込みます。プログラマーの中には、可能な限りテスターに引き渡しながら、大きな項目に取り組むことができる人もいます。残りのプログラマーはより小さな項目に取り組むことができ、スプリントの初期段階でテスターへの作業の流れがある程度スムーズになります。
適切なチームワークの感覚を作り出すのは難しい場合があります。スクラムマスターは、各スプリントの終了時に動作するソフトウェアを提供するというチーム全体の責任とチーム全体のコミットメントの概念をチームが確実に受け入れるようにすることで支援できます。チームは最初は専門化と引き継ぎという長年の習慣を打ち破るのに苦労するかもしれませんが、コミュニケーションを増やし、引き継ぎの量を減らし、スプリントに持ち込むバックログ項目の規模を大きくすることで、個人が順次開発からチームとして働くことにシフトすることができます。
PractiTest(プラクティテスト)に関する
お問い合わせ
PractiTest(プラクティテスト)のトライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
