お客様の開発パートナーを開発プロセスに参加させる必要があります。私たちは多かれ少なかれアジャイル方法論に従っています。一部のカスタマー パートナーは遠く離れており、他のパートナーは近くにあります。旅費を最小限に抑える必要があります。
当社の顧客は医療に従事しており、多忙で費用がかかり、スケジュールを立てるのが難しい傾向があります。
顧客の関与をサポートするためにどのようなプラクティスとテクノロジが機能していますか? 電話、電話会議、電子メールを使用しています。私たちはウィキのテクニックを活用することに興味があり、他の人にとって何がうまくいったかを聞きたいと思っています.
顧客が同じキュービクルにいるか地球の反対側にいるかは問題ではありませんが、通信の遅延は例外です。重要な要素は可用性です。
忙しすぎて数日間メールに返信できない顧客は、イテレーションが遅れるか、失敗する原因となります
お客様には、アジャイルに関する 2 つの重要なコミットメントがあります。
顧客は、1 時間以内の応答時間や 24 時間以内の応答時間など、可用性に関する合理的なサービス レベル アグリーメント (SLA) を約束する必要があり、ラグ ファクターによってすべての見積もりとスケジュールを調整する必要があります。顧客がコミットしない、または従わない場合は、反復をキャンセルして再計画し、顧客のコミットメントを再び前面に押し出します。顧客が望んでいると思われるものを単に「推測」しないでください。
結論: 顧客のコミットメントがなければ、アジャイルは機能しません。
アジャイル手法に関する私の経験は、主にデスクトップ アプリケーション向けです。お客様が遠隔地にいる場合、エンジニアをお客様のサイトに派遣して、デモ リグを構成/インストールするために時間を費やしてきました。エンジニアは、お客様と協力してテストおよびデモのセットアップ/計画を作成します。これにより、お客様は、展開環境の重要な側面を複製する一方で、デモ システムを既存のインフラストラクチャから分離すると信じている環境を提供します (必要なときにいつでも更新をプッシュできるようにするため)。 ）。また、エンジニアは、アプリケーションを本番環境に移行するための展開システムをセットアップして、現場にいなくても「展開」できるようにします。私たちのアプリケーションは (リリースごとまたはビルドごとに) 自己更新でき、リリースを慎重に計測してすべてをログに記録します。すべてのクラッシュをバグとしてバグ トラッカーに送信してください。このようにして、何がうまくいっているのかわからなくても、少なくとも何がうまくいかなかったのかがわかります。
お客様のテスト装置に表示されるリリース/ビルドごとに、プロジェクト リーダーまたは主要な開発者がナレーションを付けた (短い) スクリーンキャストを提供し、新機能のデモを行います。リリース ノートには、お客様に検討してもらいたい長期的な問題や質問 (つまり、電話や電子メールではすぐに解決できない問題) が含まれており、アプリケーションはこれらのメモをユーザーに表示します。
最後に、おそらく最も重要なこととして、顧客および/または顧客の担当者にカレンダー サーバーのアカウントを取得し、そのアカウントを使用するようにカレンダー アプリを構成します。これは双方向で行われます。お客様との時間 (オンサイト、電話、電子メールなど) のスケジュールを立てることができ、お客様は開発者と同じことを行うことができます。
1 つのオプション: 顧客が利用可能になったときに必要な情報を抽出できる「顧客パートナー」サイトに顧客プロキシをインストールします。これらの代理人に、顧客の見解を表すことを可能にする強固な関係を構築してもらいます。彼らの時間はすべてあなたのものです。そして、彼らが答えられない質問が生じた場合、彼らはあなたの顧客パートナーにいつでもアクセスできます。
アジャイルにおける顧客の全体的なポイントは、開発者とオープンで自由な会話をすることです (IE 即時フィードバック)。実際の顧客がこれを提供できない場合は、この役割を果たすことができる仲介者/プロキシが必要です. 実際の顧客は必要あり ません。顧客のニーズを満たすのに十分なほど顧客の関心を代弁できる人物が必要なだけです。
いくつかのアイデア:
Wiki を使用することを選択した場合は、Wiki 全体の「最近の変更」リスト、できればユーザー固有のリストをサポートしていることを確認してください。開発者との距離が縮まるほど、コンピューターを使用するメタファーとして電子メールを使用する可能性が高くなります。何か新しいものがあるとすぐに判断できなければ、それを探索することはありません。また、問題に注意を払う必要があること、または変更を CC のように扱うことを知らせる方法も必要です。
私は、インタラクションのビデオ スクリーン キャプチャ (ナレーション付き) を作成し、ユーザーに配布することを強く信じています。実際のデモとは異なり、顧客は中断する必要があるとは感じず、細部に注意を払いながら、同じやり取りを巻き戻して何度も見直すことができます。
最後に、プロトタイプを配布する場合は、誰か (または少なくとも画面共有セッション) を送信して、プロトタイプがどのように使用されているかを確認してください。コンテクスト デザインは効果的です。予想とは異なる方法でプロトタイプを使用している人々を当てにすることができます。問題がどこにあるかを本当に理解するには、たとえ彼らが報告していなくても、彼らがどのようにそれを使用しているかを理解する必要があります。
LogMeInのようなものを考えましたか。
これにより、顧客は、アプリケーションを既に実行しているネットワーク上の PC にログインできるようになります。または、顧客のコンピュータの 1 つでアプリケーションをインストール/更新できるようになります。
これにより、リモートの顧客の問題が解決され、アジャイル プロセスにおける継続的な継続的な顧客フィードバック要件もサポートされます。
以前の会社で技術サポートに使用していましたが、あなたの状況でうまくいかない理由はありません (おそらくコストを除いて)。
また、ユーザーがアプリケーションをどのように使用しているかを実際に確認して、何が機能し、何が機能していないかを確認することもできます。
まず第一に、製品マネージャーまたは製品所有者が開発者を閉じていることを確認してください. この担当者は、顧客との関係を管理します。
次に、プロダクト マネージャーは、各イテレーションの最後に顧客に製品をデモンストレーションし、ユーザー ストーリーを実装するために開発者がフィードバックを必要とする場合に顧客に質問することもできます。
顧客を巻き込むと、顧客から得られる肯定的なフィードバックは驚くべきものです。
私たちは wiki を使用せず、ほとんどのコミュニケーションは電子メール、電話、および画面共有アプリケーションを介して行われます (私たちは GoToMeeting を使用していますが、他にもたくさんの代替手段があります)。
顧客の関与に大きく依存するアジャイル プロセスのほとんどの定義では、「ベスト プラクティス」をすでに見逃していると思います。これは、オンサイト、できれば「チーム内」の顧客が常に存在するためのものです。ですから、「次善の策」を探していると思います。:)
現場での「代理顧客」紹介の可能性あり。私は代理顧客の価値について非常に懐疑的であることを認めなければなりません. 信号対雑音比が高くなり、メッセージが文字化けする可能性があるため、ある種の二流の、さもなければ不必要なビジネス アナリスト機能がミックスに導入されるリスクが懸念されます。また、忙しい実際の顧客がプロセスへの関与を減らすことを可能にするリスクも伴い、不満につながる可能性があります. 最近退職した専門分野の知識が豊富で、コンサルタントとしてこの資格で行動できる人がいるのだろうか?
遠隔地の顧客との通信帯域幅は、対面よりも驚くほど低く、これは私が別の国のユーザーと取引を始めるまで十分に認識していませんでした. ビデオであっても、損失は重大です。
あなたの反復はどのくらいですか？イテレーションを計画するのはどれくらい難しいですか? より長いイテレーションに移行して、より多くの計画をより少ない頻度で実行するか、イテレーションの長さを短縮してより小規模ではあるがより頻繁な計画セッションに進む方が簡単でしょうか? 複数の顧客が関与している
各反復の終わりに、使用可能で利用可能なビルドがありますか? 次の計画セッションの前に、関係するユーザーが実践的な時間を取る時間はありますか? 頻繁に出荷することでユーザーの関心を維持することは、表面的には良いアイデアのように思えます。
ウィキのアイデアはうまくいくかもしれません: FIT フレームワークを見たことがありますか? これは一種の統合された受け入れテスト/wiki であり、リモートの顧客から受け入れテストを取得するのに役立つ可能性があります。また、何らかの (個別または統合された) 「プロジェクト ダッシュボード」を提供したいと考えています。これは、主要な顧客に定期的にプッシュされるだけでなく、オンデマンドで利用できる可能性もあります。ホワイトボードのポストイットや大きな可視チャートなどの代わりとして使用できます。役立つ可能性のあるオープンソースまたは低コストのオプションがいくつかあります。独自の単純な代替案を作成するのに、時間やコストがかかりすぎる必要はありません。
とりわけ、「アジャイル」は、アジャイル マニフェストで支持されている価値と原則に重点を置いて実行される開発の一種の包括的なラベルであることを忘れないでください。ある状況では「最善」と見なされていることは、別の状況ではそうではない場合があります。原則を理解し、批判的な目でメソッドを定期的に確認すれば、状況に適用するベスト プラクティスに十分近づくことができるでしょう。
私はしばらくそれを見ていませんでしたが、Beck と Fowler が著者リストに載っているので、 Planning Extreme Programmingに役立つものがあるはずです。
おそらく、1 か所で全員でキックオフを 1 回行う必要があります。対面の時間はかけがえのないものです。これには、すべての開発者が含まれます。いくつかのメタプランの質問を準備しますが、交流するだけの時間も十分に確保してください。
私の以前の役職 @drchrono.com では、全国の 20,000 人の臨床医からのデータ/フィードバック/反復要求を集約しました。これを行う最善の方法は、uservoice.com のようなサイトを宣伝することです。私は、時には 50 人から 100 人の医師 (医師は私たちのウェブサイトから直接サインアップしました) と一緒に「毎日のライブ Web デモンストレーション」を開催しました。これらのデモでは、現在の製品をデモンストレーションし、ユーザーの声を伝道して、フィードバックを開発チームの便利なツールに反映させます。これらはすべてリモートで行われ、経常収益の全体的な成長率が 1,400% 増加しました。