若い開発チームが混乱する場合があります。
これは、エッジが何であるかをまだ完全に理解していないときに起こります。 プロジェクトと製品は、どちらが誰であるかを主張し、それぞれが独自にタスクを実行します。 または、誰もがすべてをすでに知っていますが、スプリントを計画することはできません-タスクがうまくいかず、デモやレトロは定期的ではありません。
同様の話もありましたが、私たちは道を見つけました。
これは、Yandex.Kassa個人アカウントのチームからのストーリーであり、計画を改善したい人のための詳細な指示です。
どうでしたか
Yandex.Kassaの個人アカウントチームは、新しい商人をキャッシャーに接続する利便性を担当し、請求サービスを提供しています。 Yandexの標準では、チームは若く、6人の開発者のうち4人が6か月以内に働いており、プロジェクトマネージャーである私は3か月前にチームに加わりました。
新しいスプリントの初日に、チームは製品所有者（以下、PO）と一緒に集まり、約2時間スプリントを計画しました。 このアプローチには明らかな欠点があります。
- 要件の精緻化が低い。 POにはすべての質問に答える十分な時間がありませんでした。 そのようなタスクをスプリントで行うか、アナリストにタスクを評価してもらい、次のスプリントの開始までその実装を延期しました。
- スプリントが本格化したときに利害関係者が記憶されている状況があり、関連チームからのいくつかの改善または解決策が緊急に必要でした。
- リスク管理の欠如。
それらを考慮して、新しいプロセスの要件が現れました。
- タスクの要件は、製品の所有者とすべての関係者の両方が検討する必要があります。
- 各アクティビティに実装されたdod（doneの定義は、開発の目的が何であったかを理解できる一連の基準です）。 彼らは利害関係者を特定し始め、新しいスプリントの開始の1週間前に作業の進捗状況を通知し、フィードバックを収集しました。
- 現在のスプリントに集中するための最小限の会議。 それぞれ1時間、2週間で2回の会議に制限されます。
- 今日、主要なリスクの1つは製品に関する知識の欠如であるため、彼らはチームとして定期的に内部製品トレーニングを実施し始めました。
新しいコンセプト
コマンドの新しいコンテナ（リスト）を導入しました：
最初のリストを除くすべてのリストのタスクの優先順位は、POによって決定されます。
スプリントでタスクが完了すると、チームメンバーはEstimatedからタスクを引き受けることができ、仕事の準備が完全に整っていることを理解します。
最初の週
クリックで-フルバージョン。
月曜日
製品所有者は、アクティビティをタスクリストコンテナからグルーミングに移動し、優先順位を付けて、完了の定義をできるだけ明確に説明します。
PMは、グルーミングコンテナ内のアクティビティをチェックリストと照合します。
- 新しいアクティビティにはレイアウトが必要ですか？その場合、レイアウトは必要ですか？
- 最も重要なプロジェクトのすべてのアクティビティが含まれていますか？
- タスク間のリンクは示されていますか？
何か問題がある場合、PMはPOと通信して詳細を明確にし、グルーミングリストが最新であることをチームに通知します。
例：
- 「夜間に発行された請求書に関する手紙は遅れて送信されます。」というタスクを取ります。 テスターによってグルーミングリストの最後に追加されました。
- POはリストでこのタスクを提起しました。
- PMは、PO側のコンテナの操作に関するアクティビティが実行されていることを確認し、チームに通知しました。
火曜日
チームは新しい活動に精通し、コメント、質問を書き、提案をします。 POはすべての新しいコメントを自動的に受信し（Jiraを使用しているため、これは簡単です）、明日までに回答を準備する時間があります。
チームメンバーは、タスクが関連するかどうかを指定しました。 タスクが関連していることが判明し、テスターは問題の原因を見つけて報告しました。 ただし、ビジネスロジックの観点からは、疑問は未解決のままです。
水曜日
チームの質問に答えるPOとのミーティングがあります。 会議の目的：DoDを修正する。 ミーティングに続いて、アクティビティの一部は「定義済み」コンテナに移動し、一部-このアクティビティにかかる時間がすぐに明らかな場合はすぐに「推定」に移動します。 依存関係と利害関係者を定義します。
PMとPO間の対話。これにより、何をする必要があるかが明確になりました。 通常、この対話は修正されませんが、会議中にPOが利用できなかったのはこのアクティビティのためであったため、コミュニケーションは書面で記録されました。
木曜日
PMは、推定および定義されたリストから近くのアクティビティのリストを、表示およびコメントのリクエストとともに関係者に送信します。
金曜日
PMは、必要に応じてチームまたはPOを巻き込んで、利害関係者の質問に答えます。
例として示すタスクに関するコメントはありませんが、一般的には次のようになります。
メッセンジャーを通じてフィードバックを受け取ることができます。
最初の週の結果は活動であり、それに応じて、関係者の希望を考慮に入れて、何をする必要があるかが明確になります（dodが決定されます）。
二週目
月曜日
チームは、「定義済み」リストのアクティビティと「推定」リストのアクティビティの分解を独立して評価します。 POはここで関与しません。なぜなら、彼はビジネスの一部で目標を設定する責任があり、計画の実行方法を評価するのは彼の責任ではないからです。
火曜日
POとの2回目の会議があり、そこでチームは詳細を明確にし、評価を伝えることができます。 POは、過去1週間に発生した可能性のある新しい導入イベントを通知するだけでなく、アクティビティが正確にそのような推定値であり、それ以上ではない理由を明らかにすることができます。
水曜日
現在のスプリントにはデモがあります。 デモの結果として、通常、新しいアクティビティが形成され、その一部は週の終わりまでに完了し、残りは次のスプリントで完了する必要があります。 デモの目的は、フィードバックを収集することです。 チームは作業の結果を提示し、新しい機能の作業に関する早期のフィードバックを受け取ります。
デモは内部および外部です。
内部デモはPO向けで、チームが期待どおりの結果を達成したかどうか、または改善が必要かどうかを評価します。 テスト環境でテスターが実行します。
外部デモは、利害関係者を対象としています。 「戦闘への」新機能の計算後に発生し、POをリードします。
デモの後、新しいアクティビティがバックログに追加され、優先度と評価に応じて、現在のスプリントに追加できます。 スプリントの終わりまで改善のための時間を確保するため、2週目の半ばにデモを実施しています。
木曜日
POは定義済みリストに優先順位を付けます（スプリント中にアクティビティが予想される期限より早く完了する場合、このリストから新しいアクティビティを実行することが可能になります）および推定（このリストからのアクティビティは新しいスプリントに転送されます）
金曜日
PMおよびPO開発チームが参加するスプリントプランニングが行われます。
現在のスプリントでどのように働いたか、次のスプリントに向けて準備ができているかどうかを議論するレトロがあります：意見を交換し、今後のスプリントのためにすべてが明確であり、予期しないバグを修正するためのリソースにまだ十分なリソースがありますか？
リスク管理会議が開催されています。 現時点では、その優れた理解がリスクを大幅に削減するため、今回は製品の研究に専念しています。 PMは1週間にテスターと一緒に製品を研究する時間を割り当て、結果をチームと共有します。 ユニットの代表者が会議に招待され、写真を補完します。
毎週金曜日は、週の終わりだけでなく、スプリントも終わりです。 これは、コミュニケーションとフィードバックの日です。 したがって、新しい週の週の月曜日は明確で高く評価されたタスクで始まります。これは、チームにとっても論理的で快適です。
結論と次のステップ
このプロセスの助けを借りて、POとチームの間に高品質の相互作用を確立することができました。競合と誤解は過去にありました。 チームの気候は改善され、調和のとれたリズミカルな作業の感覚が現れました。 もちろん、まだ多くの問題がありますが、チームまたはPMがプロジェクトを保存しなければならない緊急事態や予想外の状況ははるかに少ないものでした。
すべての生物と同様に、私たちのプロセスは時々更新する必要があります。 次の分野で最終決定する価値があることがわかりました。
- バグ。 バグの処理も計画する必要があります。 スプリントプランニングプロセスで発生するバグを実行することはできませんが、ここではより多くの運用作業が必要です。 これを行う方法について考えています。
- 一般的なリスクの表を作成して、それらを考慮し、スプリントの実装におけるエラーの可能性を減らしたいと思います。
- スプリントを計画するときは、スプリントの目標に基づいて作業の焦点を維持したいと考えています。 チームは若いので、これには困難があります。
私たちの経験があなたのチームに役立つことを願っています。 コメントでアプローチを議論したり、質問に答えたり、アドバイスしたりする準備ができています。