データサイエンスチームにどのようなフレームワークまたは方法論をお勧めしますか？
私は主にデータサイエンティストと一部のソフトウェアエンジニアのチームのスクラムマスターであり、プロダクトオーナーです。
私たちの組織は、すべてのチームがスクラムを使用して2週間のスプリントで作業することを決定しました。私は個人的にそれが機能しているとは思わない。スクラムフレームワークは、次の理由で実際には機能していません。
- 未知数のレベルが非常に大きいため、推定するのは非常に困難です。たとえば、実験を実行するためのバックログアイテムがある場合、出力は非常に変化する可能性があり、通常は変化します。実験の成果は、文字通り、今後数日間の作業を促進します。
- チームをストーリーに分解させることができたとしても、ストーリー間には膨大な数の依存関係があります。フローチャートやデシジョンツリー、そしてストーリーマップのようなものです。
- POとSMはデータサイエンティストではないため、ストーリーの内容を実際に支援することは不可能です。
- 上記の理由により、スプリントのコミットメントが完了することはほとんどありません。
- チームはエンジニアと同じようにコミュニケーションをとっていません。彼らは議論し、仮説を立てるのに多くの時間を必要とします（つまり、スクラムが意図したものではありません）、少なくともこれは私の経験です。
- 作業の性質が不明なため、計画会議は扱いにくくなります。
データサイエンスチームにどのようなフレームワークまたは方法論をお勧めしますか？
回答
スクラムとは何か（スクラムガイドで定義されている）と、スクラムに一般的に関連付けられているものを区別する価値があります。
たとえば、ストーリーポイント、ストーリー、見積もり、速度などはスクラムガイドの一部ではありません。
チームはエンジニアと同じようにコミュニケーションをとっていません。彼らは議論し、仮説を立てるのに多くの時間を必要とします（つまり、スクラムが意図したものではありません）、少なくともこれは私の経験です。
繰り返しになりますが、スクラムガイドには、議論や仮説を立てるのに多くの時間を費やさないと言っているものは何もありません。フレームワークが実際に言っていることではなく、スクラムの慣習について話しているのです。
私はスクラムフレームワークを使用するデータサイエンスチームと協力してきましたが、彼らは自分たちの仕事について議論するのに膨大な時間を費やしました。
作業の性質が不明なため、計画会議は扱いにくくなります。
次に、同期に多くの時間を費やし、計画に費やす時間を減らすことをお勧めします。スクラムのようなフレームワークの価値は、チームがより協調的な方法で協力し、必要に応じて互いにサポートするのを支援することです。
あなたの質問に答えるために、スクラムとかんばんの両方をデータサイエンスチームと連携させることができます。フレームワークの選択は通常、チームメンバーの性格タイプ、組織の性質、および作業しているドメインのタイプに依存します。
私は推測していますが、ここでの問題は、チームが彼らの働き方を制御するのではなく、彼らに課せられたアプローチを持っていることだと思います。スクラムの回顧と検査と適応のサイクルは、チームが適切なアプローチを見つけるまで、作業方法を調整できるようにすることを目的としています。
かんばん、つまりタイムボックス化されたスプリントではなくマネージドフローは、まさにあなたが言及した理由から、調査と発見の作業に非常に意味があります。おそらく、チームが経営陣に説明責任を負わせるためにメトリックとステータスレポートを作成することもできますが、そのアイデアは、見積もりと反復ではなく、優先順位付けと持続可能な配信に焦点を当てることです。あなたが言及した種類の問題を証明することができれば、これについて良い主張をすることが可能であるはずです。
また、効率的な継続的インテグレーションパイプラインが整っていることを確認するように努めます。必要なだけリリースできる場合は、1週間または2週間の増分ですべての期待を設定する必要がなければ、全員が勝ちます。
「仮説」や決まった時間枠のない会議がたくさんある場合、それは作業の範囲がまだ明確にされていないということです。スコープが固定され、タイムラインが準備されているが、新しい要件が近づいているか、変更されているか、会議が遅れている場合-優先順位を下げたい場合は、トレードオフのオプションを使用して、お客様の遅延を強調し、すでに合意されたスコープでのみ作業を進めますある機能が別の機能に有利に働きます。
SAFeフレームワークを試すことができます（https://www.scaledagileframework.com/# そして https://www.guru99.com/scaled-agile-framework.html）-他のレスポンダーが以前に言及したものの上にそれを強調することができます。ロシアで開催された専門家会議の多くの講演者から、このフレームワークは「実験室」で使用されているように何度も強調されました（この用語は、まだ知られていない分野での製品開発に焦点を当てた中規模または大規模のチームの名前に使用されます私たちのように）。エピック->機能->ユーザーストーリーフロー。あなたが言ったように、「あなたのPOは主題分野の専門家ではありません」そして「ストーリー間には膨大な数の依存関係があります。それはフローチャートや決定木、そしてストーリーマップのようなものです」と私はSAFeがE2E値に個人的に責任を持つようになる機能と機能所有者を持っているので使用に潜在的に適していることを発見しました。エリアとビジネス価値+コードを提供することができます。
The decomposition in SAFe is: Epic -> Architectural sub-epic (then breakdown to a Feature(s), which are split to Stories, which are split to Tasks in their turn) plus Business sub-epic (then breakdown to a Feature(s), which are split to Stories, which are split to Tasks in their turn).
私の個人的な経験（大企業プロジェクトのビジネスアナリスト。そのフェーズの1つでは、いくつかのシナリオがロードされたトピックのビジネス価値の提供に焦点を当てるために、SAFeのような機能ベースのアプローチを使用しました）。機能は、製品のコンポーネントが最も影響を受けるビジネスアナリスト（別名「ビジネスオーナー」-E2Eおよび特にビジネス価値に責任がある）と開発リーダー（別名「テクニカルオーナー」-はすべてのストーリーの開発を調整します。つまり、E2E）が所有します。機能内）。一方、「事業主」は「技術所有者」が所有する実施結果に依存し、「事業」はとにかく主要なものであり、彼が最終的にそれを顧客（外部または内部の全体的な製品所有者-あなたの場合のように）に示し、フィードバックを収集するとき。機能の下のビジネスストーリーは、それぞれがビジネスアナリストによって所有されます（特定のシナリオ、つまり機能分解に従った機能を担当します）。ビジネスストーリーが説明され、目に見えるE2Eまたはその堅実な部分があると、テクニカルストーリーの所有者/チームのキックオフが手配されます。機能の下のテクニカルストーリー、それぞれが開発リーダーによって所有されています（特定のシナリオ、つまり機能分解に応じた機能を担当します）-レポートを簡素化するために、DEVチームは技術機能->技術ストーリーをミラーリングし、ビジネスストーリーのIDへのリンクを維持します（ JIRA）。テクニカルストーリーが実装され、目に見えるE2Eまたはその一部が存在するようになると、ビジネスストーリーの所有者/チームのデモが手配されます。このアプローチでは「機能」がより関連性の高い用語であったため、エピックは強調しませんでした。要するに：長所：個人的な関与と個人的な責任。短所：技術的でない「事業主」の技術的タスクを監視するためのオーバーヘッド。