筆者はデータ分析の会社に勤めている。自チームでスクラムを適用・運用しているが自分自身の理解が浅く、うまく扱えている気がしていない。日本語記事もあまりヒットしなかったので色々調べてアウトプットすることにした。データサイエンスプロジェクトで選択するプロセスこの記事によると、CRISP-DMの次に選ばれた手法となっている。スクラムを「使用する」ほとんどのデータサイエンスチームは、このフレームワークから逸脱することがよくある。省略している、といったこともある模様。適用のメリットスクラム適用によって7つのメリットを受けることができる。それぞれについて述べる。実証的証拠データサイエンスと同様に、スクラムは既知の事実に基づく実行の原則に基づいています。(簡単に言えば、何かを提供する。何が機能するかを確認する。何が機能しないかを確認する。)それに応じて計画を調整する。顧客重視スクラムは顧客価値の提供に重点を置いている。スクラムは開発作業を顧客の視点から組み立て、スプリントレビューなどのプラクティスを通じて関係者が継続的にフィードバックを提供するように促します。厳格な時間制限によりチームは定期的な作業リズムに慣れることができる。自律性チームに自己管理の幅広い自律性を与えることで、チームはより生産的で、より積極的になれる。検査による改善チームは、特に各スプリントの終わりのレトロスペクティブにて常に自分自身を内政する。これまでのサイクルから学び、適応することで、各開発サイクルを通じてパフォーマンスを向上させます。個人はチームメンバーに対して説明責任をもつ。レビューなどの実践によって強化されます。期限が常に迫っているため、成果を出す意欲が高まる。適用するときの課題この記事に下記以外の課題も含まれていたが、データサイエンスに限らないスクラムの課題のように感じたため除外した。タイムボックスの課題:ほとんどのデータサイエンスの問題に対するソリューションを実装するために必要な時間は曖昧で、データ取得、データ品質の疑わしい点、信号とノイズを区別する未テストの能力など、未知の要素に依存する。この状況下で期限に間に合わせるよう迫られた結果、テストが不完全になったり、分析が急がれたり、不要な技術的負債が生じたりする可能性がある。会議の時間の課題:スクラムにはデイリーやプランニングなど様々な会議があり、通常週に約4時間か必要とする。ストーリーの洗練とバックログ管理のための時間も必要となる。これらの会議は避けるべきオーバーヘッドと見なされる可能性があると考えている。Sutherlandは、「私が調査したシリコンバレーの何百ものチームのうち80%はこれを実行できませんでした」と報告している。(Sutherland、2015)。この課題は、データサイエンスにとって特に困難であり、必要でない可能性もある。実際、特に初期の探索フェーズにおけるチームの作業の多くはデータサイエンスチーム外へのリリースを考慮していない可能性がある。上記の課題を認識し、チームのニーズに合わせてスクラムを調整する計画を考案する必要がある。考えられる解決策は次のとおり。「スパイク」を優先するスパイクとは開発に潜む「未知」を「既知」に変えるためのひとつの手法のこと。調査と発見を可能にするために、チームはバックログ内の項目であるスパイクを作成し、特定のトピックについて集中的に調査するための調査時間を確保できる。これらのスパイクは、バックログ内の製品増分アイデアと並んで配置されます。指定された調査目標が達成されるか、期限が切れると、「完了」と見なされます。分割して征服するタスクにどれだけの労力が必要かを把握していないことがよくあるため、作業増分を”定義可能で見積もることができる小さな部分”に分割することです。Mezick曰く「何かが混乱に近づけば近づくほど、何をすべきかを把握する方法は、頻繁な検査です」と述べている。彼は、より頻繁な検査を強制するために、より短いスプリントサイクルを使用することを推奨しています。時々「完了の定義」を緩める探索的な作業や概念実証は、完全に「完了」する必要がないことがよくある。そのため、チームは特定のストーリーの完了の定義を緩めることに同意できます。チームは、「コア成果物の品質の低い出力を受け入れる」という危険な道に陥らないようにする必要があります。スプリント中に作業を再交渉するスプリント計画はスプリント計画時に固定されるわけではない。バックログの範囲を交渉」する必要がある。(Akred、2015)。チームが妥当なサイクル数内で実現可能性を証明できない場合は、他の作業に再び焦点を当てることができます。ランウェイ」を構築する新しい大規模なアーキテクチャを必要とするチームは、慎重な事前計画の方が効果的であると感じる場合があります。概念を取り入れ、最初のスプリントのいくつかをアーキテクチャの開発に充てることで上手くいく可能性がある。別のデータサイエンスライフサイクルをスクラムと統合して、プロジェクトを管理する。所感まとめて感じたことを雑に書きます。曖昧な要件に対して「何をもって終了とするか」の具体化が重要にように感じる。自分たちのチームの特性・状況に応じて柔軟な動きを取り入れる。時には大原則を無視するなど柔軟な動きを行って課題解決を行う勇気が必要。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。