不確実性に向き合うためにチームの アジリティを高める開発タスクの切り方

XP祭り2022の発表資料です

Transcript

1. 2022/10/01 XP祭り 2022 炭田高輝（@tac_tanden） 不確実性に向き合うためにチームの アジリティを高める開発タスクの切り方
2. 自己紹介① BASE株式会社 ネットショップ作成サービス「BASE」の エンジニアリングマネージャー Scrum Master (LSM) 北海道旭川市出身 2016.09 - 新卒でWebゲーム開発 2020.01 - BASE株式会社で「BASE」の開発 本日はよろしくお願いします！ 　　　 炭田高輝（tanden） Back-End Web Developer 2
3. 自己紹介② • 新卒1年目に「アジャイルサムライ」に出会う • 「おお、これだ！」と思い、本を読み漁ったりスクラムマスターの 研修に行ってみる • スクラムをチームに提案して実際にトライしてみるも、なんとなく 良くなったがうまく定着させることができなかった • 途中1社を経て、BASE株式会社で「よりよい開発チーム」「品質の 高いものをより早くユーザーに届ける」にはどうすればよいか、模 索中です 　　　 炭田高輝（tanden） Back-End Web Developer 3
4. 本日のアジェンダ １ ２ ３ 不確実性とは何か 受け渡し型開発の構造的な課題 ユーザーストーリーで 開発タスクを分割する 4
5. 不確実性とは何か
6. 不確実性とは何か 不確実性の定義 • 白黒はっきりつけられない曖昧さ（確率）が 残っている状態や状況のこと • 不確実性を減らすとは、確率をどちらかに 寄せる作業（白黒つける） Q. この設計で負荷の問題は起きるのか、起きな いのか？ A. 調査の結果、起きるとわかる 結論を出すことで、曖昧さがなくなり、不確実性 が減ったとみなせる 6 エンジニアリング組織論への招待 ~不確実性に向き 合う思考と組織のリファクタリング 広木大地　著
7. サービス開発における不確実性 目的不確実性（Whatに関する不確実性） 作ってみるまでは、何がユーザーに受け入れられるのか分からない 方法不確実性（Howに関する不確実性） やってみるまでは、どう作ればいいのかわからない 通信不確実性（意思疎通に関する不確実性） 正しく伝わるか分からない、正しく伝わったとしても他者はその 通りに行動するとは限らない
8. 不確実性はチャンスでもある 不確実性を効率よく減らすことができる良い問いを立て その問いを解き、明らかにできれば組織や個人に利益をもたらす • サービスが売れるのか売れないのか（目的不確実性） 白黒つけることができれば大きなビジネスチャンス • アーキテクチャをAにするのか、Bにするのか（方法不確実性） アーキテクチャを決定できれば、プロダクトにとって大きな前進 8
9. 不確実性に振り回されないことが大事 不確実性の全てが悪いわけではない 不確実性はむしろチャンスになり得る 不確実性があることを前提に 不確実性をコントロールしながら白黒つけていく ことができればチャンスを活かせる可能性が高まる 9
10. 不確実性に振り回される5つのパターン 不確実性に振り回される5つのパターンを見ていきます • 突発パターン • 手戻りパターン • 大群パターン • 氷山の一角パターン • 忘却パターン 10
11. ①突発パターン 急遽対応したい開発タスクや不具合が入ってくるケース • 「緊急の開発タスクがあるんだけど、差込でできないかな？」 • 「調査してみないと原因がわからない不具合が見つかり、対応する のに時間がかかりそうです」 突然、新しい不確実性が吹き出してくるパターン。 新たに発生したタスクによって、開発計画に大きな影響が出たり、 チームの過負荷つながる場合もある。 11
12. ②手戻りパターン 開発したものが、必要なものと異なっていたケース • 「あれ、これはお願いしていたものと違いますね」 • 「すみません、これは〇〇はできないんですか？」 成果物がずれていて、不確実性が高い状態に逆戻りするパターン。 せっかく開発した機能が使われず、修正作業が必要になる。 また、最悪の場合、いちから作り直しになってしまう。 12
13. ③大群パターン 大量のやることが目の前に広がっているケース • 「やることが多すぎて、どこから手を付けていいかわかりません」 • 「修正が必要な箇所が多すぎませんか？」 不確実性がある事象の多さに圧倒されるパターン。 大量のやることリストがプレッシャーとなり、チームの混乱やモチベー ションの低下につながってしまう。 13
14. ④氷山の一角パターン 予想していたよりもやることが多かったケース • 「思っていたより全然やること多いじゃん」 • 「想定していた工数の2倍になりそうです」 不確実性の大きさを正しく観測できないパターン。 着手してみないとわからないことも多く、開発計画が大きく狂う原因に なりやすい。 14
15. ⑤忘却パターン 出した結論がチームの知識から失われてしまうケース • 「前に話した気がするんですけど、結論なんでしたっけ？」 • 「あ、仕様書を更新するの忘れていました」 すでに不確実性を減らしたのに、その知識が失われてしまうパターン。 せっかく出した結論が忘れられてしまい、探して思い出す作業が発生す る。最悪の場合、同じ検討作業が必要になることもある。 15
16. 不確実性に振り回される5つのパターン 不確実性に振り回されれる5つのパターン • 突発パターン • 手戻りパターン • 大群パターン • 氷山の一角パターン • 忘却パターン 5つのパターンが起きることを前提として うまくコントロールできるようにすれば、開発がぐんと前に進むはず 16
17. 不確実性に振り回されないために この発表では 不確実性をコントロールするための 開発タスクの切り方を紹介します 17
18. 受け渡し型開発の構造的な課題
19. 受け渡し型の開発とは 成果物を受け渡していく開発のこと • 要件定義 • 仕様作成 • デザイン • 設計 • スケジュール見積もり • バックエンド実装 • フロントエンド実装 • 結合テスト（QA） • 受け入れテスト（QA） • リリース 19 ウォーターフォールやリレー形式の開発と呼ぶこともあります
20. 受け渡し型開発の構造的な課題 受け渡し型の開発で、構造上どうしても避けられない課題があります 着手からリリースに至るまでの作業量が多い＝バッチサイズが大きい 20 要件定義からリリースまでの中で多くの作業を一度に行う 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計
21. バッチサイズとは何か ”batch”とは束、1回分、ひとまとまりの数量を意味します。 システム開発界隈では、同じような種類のデータに対してまとめて処理 することを「バッチ処理」と呼ぶことが多いです。 この発表では着手からリリースに至るまでの一連の作業を一つのバッチ として考え、その作業量のことをバッチサイズと呼びます。 21 要件定義からリリースまでの一連の作業＝バッチ
22. バッチサイズが大きいことの問題点 受け渡し型開発は構造上バッチサイズが大きくなってしまう • 突発パターン • 手戻りパターン • 大群パターン • 氷山の一角パターン • 忘却パターン バッチサイズが大きいと上の5つのパターンが起こりやすく、また対応も しにくいことを見ていきます 22
23. ①突発パターン 突然新たな不確実性が噴き出してくるパターン • バッチサイズが大きいと、きりの良いタイミングが少ない • 無理に入れると、更にバッチサイズが大きくなる 23 極論、リリースタイミングしか きりの良いタイミングがない 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計
24. ②手戻りパターン 出した結論が間違っていて、不確実性が高い状態に逆戻りする • 判明した時点から前の工程の作業が無駄になってしまう • バッチサイズが大きい分、無駄になる作業も多くなる 24 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 テストで気付くことが多い
25. ③大群パターン 不確実性がある事象の多さに圧倒されるパターン • バッチサイズが大きい分、一度に多くの不確実性が見つかる • 多くの不確実性に一気に襲われてしまう場合が出てきてしまう 25 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 多くの不具合と仕様変更 が見つかる場合がある
26. ④氷山の一角パターン 不確実性の大きさを正しく観測できないパターン • バッチサイズが大きい分、含まれる不確実性の大きさを見極めるこ とが難しい • その結果、実体より小さく見積もってしまう 26 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 見積もる作業範囲が広くなってしまう
27. ⑤忘却パターン 前に不確実性を減らしたのにその知識が失われたパターン • バッチサイズが大きいと、出した結論を使うまでの期間が長くなる • その結果、過去の決定を忘れてしまい、最悪の場合再び決定作業が 必要になる 27 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 仕様作成を行ったのは3ヶ月前 昔のことは忘れてしまう ?
28. 各パターンの合わせ技で不確実性が襲ってくる① • 受け入れテストで突然（突発） • 「この機能ではなく、別の機能が必要です」と言われ（手戻り） • 実はそれが仕様書の更新漏れが原因（忘却）ということが判明する 28 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 受け入れテストで突発的に 手戻りが発生する ?
29. 各パターンの合わせ技で不確実性が襲ってくる② • 受け入れテストで突然（突発） • やっぱりこの機能も必要です（手戻り） • 全部作り直しですが、どこから手をつけましょう（大群） 29 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 受け入れテストで突発的に 手戻りが発生して、一気にやることが増える
30. 受け渡し型の開発は不確実性に振り回されやすい 受け渡し型の開発では、どうしてもバッチサイズが大きくなってしまう その結果、不確実性に振り回されてしまう場面が多くなる 30 要件定義からリリースまでの中で多くの作業を一度に行う 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計
31. 受け渡し型の開発は不確実性に振り回されやすい 受け渡し型の開発だと 不確実性に振り回されやすい ではどうすればよいか 31
32. ユーザーストーリーで 開発タスクを分割する
33. 受け渡し型開発の構造的な課題 受け渡し型開発の構造上の課題＝バッチサイズの大きさ 開発タスクをユーザーストーリーで切ることで バッチサイズを小さくすることにトライします 33 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計
34. 開発タスクを工程に分けない 工程に分けるするのではなく 全ての工程を含むように開発タスクを小さくしていきます 34 APIのインターフェースの設計 APIの実装 … バッチサイズが大きくなる ので避ける 仕様作成 デザイン 設計 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 要件定義
35. ユーザーストーリーで分割する ユーザーストーリーを使って、最低でも受け入れテストを必ず含むよう に小さく分割していくのがオススメです この発表における「受け入れテスト」は、開発した機能が実際にビジネ スメリットをもたらすかをユーザー視点でテストすることを指します。 仕様通りに動作することはもちろんですが、ユーザーが機能を使った結 果として望む通りの行動や成果がもたらされるかを主眼に検証を行うこ とを「受け入れテスト」と表現しています。 35
36. 受け入れテストであれば頻度を上げられる 理想は細かく分割した開発タスクを都度リリースすることですが 以下の理由から難しい場合も多いと思います • リリース作業のコストが高い • そもそもユーザーにリリースするまでの十分な機能が足りていない しかし、受け入れテストまでであれば頻繁に行うことを許容できるチー ムも多いのではないでしょうか 36
37. ユーザーストーリーとは何か ユーザーストーリーを以下のようなフォーマットで表すことが多いです • ユーザーとして • 「アクション」をしたい • それは「ビジネスメリット」のためだ ユーザーの部分をより詳細に「ペルソナ」とすることもあります 37
38. ユーザーストーリーに全工程を含めることができる 受け入れテストでユーザーストーリーのビジネスメリットが達成できる かを確認することが、開発タスクの完了条件として自然になります 例 • ユーザーとして • 自分の登録しているクレジットカードの有効期限を確認したい • 今も利用できるクレジットカードか確かめたいからだ ユーザーストーリーに分割することで、受け入れテストまでの全工程を 含む形に開発タスクを分割できるようになります 38
39. 実際にユーザーストーリーで小さく分けてみる 開発タスクを細かくユーザーストーリーに分ける例を見ていきます ここでは例として、ToDo管理アプリケーションを開発するケースを考え てみます 39
40. 比較：受け渡し型開発の場合 例えばバックエンドの開発工程の中で、以下のように分けることが一般 的だと思います • ToDoタスク登録用APIの開発 • ToDoタスクのステータス更新用APIの開発 • ToDoタスクの削除用APIの開発 40 要件定義 仕様作成 バックエンド 受け入れテスト リリース …. …..
41. 比較：受け渡し型開発の場合 工程に分けてしまう場合、ユーザー相当の検査（＝受け入れテスト）が 行われるまでのバッチサイズを小さくすることはできません 41 要件定義 仕様作成 バックエンド 受け入れテスト リリース …. ….. • 登録用APIの開発 • ステータス更新用APIの開発 • 削除用APIの開発
42. ユーザーストーリーによる分割① まず、ToDo管理アプリケーションを大きなユーザーストーリーに 仕立ててみます • ユーザーとして • ToDo管理をしたい • やる必要があるタスクを忘れずに実行し、完了させたいからだ 最初のユーザーストーリーができました 42
43. ユーザーストーリーによる分割② • ユーザーとして • タスクを登録したい • タスクを忘れたくないからだ • ユーザーとして • タスクを完了状態にしたい • 終わっていないタスクを判別したいからだ • ユーザーとして • タスクを削除したい • する必要がないタスクを実行してしまう無駄をなくしたいからだ 43
44. ユーザーストーリーによる分割② 44 • ユーザーとして • タスクを登録したい • タスクを忘れたくないからだ • ユーザーとして • タスクを完了状態にしたい • 終わっていないタスクを判別したいからだ • ユーザーとして • タスクを削除したい • する必要がないタスクを実行してしまう無駄をなくしたいからだ
45. ユーザーストーリーによる分割③ • ユーザーとして • タスクのタイトルを設定したい • タスクを見つけやすくして、実施漏れを防ぐためだ • ユーザーとして • タスクの詳細を記入したい • タスクの背景や実施する理由を忘れないようにするためだ • ユーザーとして • タスクの優先度を設定したい • 重要度によってタスクを分類したいからだ 45
46. ユーザーストーリーによる分割③ • ユーザーとして • タスクのタイトルを設定したい • タスクを見つけやすくして、実施漏れを防ぐためだ • ユーザーとして • タスクの詳細を記入したい • タスクの背景や実施する理由を忘れないようにするためだ • ユーザーとして • タスクの優先度を設定したい • 重要度によってタスクを分類したいからだ 46
47. ユーザーストーリーによる分割④ • ユーザーとして • タスクのタイトルを保存したい • タスクを見つけやすくして、実施漏れを防ぐためだ • ユーザーとして • タスクのタイトルを更新したい • タスクの内容が変わったことを反映するためだ • ユーザーとして • タスクのタイトルの設定に失敗したことを知りたい • タイトルの保存をやり直す必要があるかどうかを知れるからだ 47
48. ユーザーストーリーで小さく分割する 48 ToDo管理をしたい 登録をしたい 完了にしたい 削除したい タイトルを設定をしたい 詳細を記入したい 優先度を設定したい タイトルを保存をしたい タイトルを更新をしたい 設定に失敗したこと を知りたい ユーザーストーリーを使って開発タスクを小さくしていくことで ユーザー相当の検査が行われるまでのバッチサイズを小さくできます
49. バッチサイズを小さくするメリット① きりの良いタイミングを多く作れるので、突発パターンに対応しやすい • 「ストーリー2が今日中に完了するので、明日から着手します」 • 「ストーリー5までをまずは優先したいので、それが完了してから着 手するでもよいでしょうか？」 49 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 ストーリー4と5の間で着手する
50. バッチサイズを小さくするメリット② 手戻りが起きた場合でも捨てられる作業量は少しで済む • 「期待とずれていることが早めにわかってよかった」 • 「その範囲ならコストも少ないですし、試しに作って検証してみま しょう」 50 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7
51. バッチサイズを小さくするメリット③ 少しずつ処理するので、不確実性の大群に一度に襲われない • 「やるべき範囲が明確で、進めやすいです」 • 「一度に出てくる不具合のチケットが少ないですね」 51 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7
52. バッチサイズを小さくするメリット④ 作業単位が小さいことで、不確実性の大きさを捉えやすい • 「範囲が狭いと、見積もりがしやすいですね」 • 「見積もりのぶれが少なくなった気がします」 52 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7
53. バッチサイズを小さくするメリット⑤ 期間が短いことで忘却の発生を抑えることができる • 「昨日決まったところの実装が終わりました」 • 「今話して決まったところは、今から実装してしまいますね」 53 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 検討から実行までの時間が短い
54. バッチサイズ小さいと5つのパターンに対応しやすい バッチサイズを小さくすることで • 切れ目が沢山でき、方向転換が簡単になる（突発パターン） • 無駄が少なくなる（手戻りパターン） • やることの多さに圧倒されない（大群パターン） • 不確実性を捉えやすい（氷山の一角パターン） • 忘れないうちにやりきれる（忘却パターン） バッチサイズを小さくするためには • 着手ギリギリまで工程に分けない • 受け入れテストを含むように開発タスクを分割する • ユーザストーリーでの分割が便利 54
55. ユーザーストーリーで 開発タスクを分割する さらなるメリット
56. ユーザーストーリーで全員が協力できる① 最初から技術レイヤー（例：APIの実装）でタスクを切り出してしまう と、例えばAPIの実装工程の話の場合、バックエンドエンジニア以外は 一歩引いてしまう場合も多いと思います。 • 「 APIの実装はお任せするので、自分はフロントエンドの作業進め ますね」 • 「要件と仕様は伝えたので、APIの実装をよろしくお願いします」 早い段階で工程に分けすぎるとサイロ化してしまう。 56
57. ユーザーストーリーで全員が協力できる② ユーザーストーリーのよいところは、ユーザー視点という共通認識を通 して対話できるところです。 ユーザーストーリーの場合、開発チームだけでなく、ステークホルダー を含めた全員が議論に参加しやすく、色々な人の知識や経験を動員する ことができます。 共通認識を獲得でき、抜け漏れや求めていることが違ったといった、氷 山の一角パターンや手戻りパターンを回避することにも繋がります。 57
58. スコープを柔軟に変えられる① • 細かくユーザストーリーに分けて開発していくことで、 開発を進めながら「どの機能まで作るのか」のスコープを柔軟に 変更できます 58 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 最初はストーリー7まで作る予定 →途中でストーリー4までで十分だと分かった
59. スコープを柔軟に変えられる② 59 ToDo管理をしたい 登録をしたい 完了にしたい 削除したい タイトルを設定をしたい 詳細を記入したい 優先度を設定したい タイトルを保存をしたい タイトルを更新をしたい 設定に失敗したこと を知りたい 「タイトルの設定」と「詳細の記入」を作って使ってみて「優先度を 設定できる機能は後回しにしても十分機能として使える」のような判 断がしやすくなる。
60. 開発チームのモチベーションを保ちやすい① 受け渡し型開発の場合、実際に画面上で触れるようになるまでが長く 「今何を作っているのだろう」という感覚に襲われることがある。 60 画面上で操作できるようになるのは、結合テストの工程 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 「実際に使えるようになるまであと3ヶ月くらいか、長いな...」
61. 開発チームのモチベーションを保ちやすい② ユーザーストーリー毎に動くものができるので、その都度実際に触るこ とができ、進捗を実感しやすい。 「おおー、ToDoタスクのタイトル設定できる！」 「ToDoタスクの詳細まで保存できるようになりましたね」 61 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7
62. 「現在地」がわかりやすい① 受け渡し型開発の場合、目標に対しての「現在地」がわかりにくい。 「バックエンド工程のフェーズとしては今どのへんですか？」 62 画面上で操作できるようになるのは、結合テストの工程 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 設計 「ToDoタスクを保存するAPIの実装」は 全体からみてどの段階に位置する？
63. 「現在地」がわかりやすい② ユーザーストーリーの場合、目標に対する「現在地」がわかりやすい。 「今の所、残り3つのユーザーストーリーを作りきれば、リリースできる 機能が揃いますね」 63 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7
64. 分割にも慣れが必要 困った場合はお近くのスクラムマスターにぜひご相談を！ もしくは、以下の書籍やブログが参考になります • ryuzeeさんのブログ「プロダクトバックログアイテムの分割方法」 • 『アジャイルな見積りと計画づくり』 12章「ユーザーストーリーの分割」 • 『アジャイルエンタープライズ』 　　18章「ユーザーストーリーで協力する」 • 『エッセンシャルスクラム』 　　　　5章「要件とユーザーストーリー」 　 6章「プロダクトバックログ」 • 『More Effective Agile』　　　　　9.4「基本原則：バーティカルスライスでのデリバリー」 • 『スクラム実践入門』　　　　　　　 3.3「スプリントプランニング」 5.4「ユーザーストーリー」 • 『スクラム現場ガイド』　　　　　　 12章「ストーリーやタスクを分割する」 • 『大規模スクラム（LeSS）』　　　　11章「プロダクトバックログリファインメント」 64
65. ユーザーストーリーでの 分割に関するFAQ
66. FAQ① バッチサイズの目安 バッチサイズが大きいから小さくしないといけないと判断する基準はあ りますか？ • 基本的には1スプリントの中に収まるかどうかを基準に判断するのが よいと考えていますが、チームや開発内容によっても変わってくる と思います。 • 例えば、自分のチームに関しては2-3日で終わるかどうかを目安に分 解していくのがちょうどよいという感覚を振り返りを重ねる中で得 られたので、今はそれを基準に分解していくことが多いです。 66
67. FAQ② 技術的な改善タスクとユーザーストーリー ユーザーが直接使うような機能の開発ではない、技術的な改善のプロ ジェクトでもユーザーストーリーは使えますか？ • ユーザーストーリーの目的は「誰が」「何をすることで」「どんな 得があるのか」を明らかにすることだと考えています。 • 例：エンジニアが、アプリケーションのPHPのバージョンを8.0に上 げたい、8.0にすると使いたいライブラリが使えるようになるからだ • 技術的な改善をすることで、誰が、どんな得をするのかを加えると 「PHPのバージョンを8.0に上げる」とだけ書かれた開発タスクより も意図や目的がわかりやすくなるのでおすすめです。 67
68. FAQ③ 細かく分解しすぎると全体が見えない ユーザーストーリーに細かく分解しすぎると、機能全体を俯瞰しにくい のですがどうすればよいですか？ • 機能全体を俯瞰するために、ユーザーストーリーマッピングをする のがおすすめです • 分解したユーザーストーリーをユーザーがとる体験の時系列に沿っ てマッピングしていく手法です • 細かくしていくと全体を俯瞰しにくくなりますが、ユーザーストー リーマップが全体の視点を提供してくれるよき相棒になってくれる と思います 68
69. FAQ④ ユーザーストーリーを開発するときの疑問 1つのユーザーストーリーを複数人で実装すると、コードのコンフリクト やコミュニケーションが増加して非効率になる場合もあると思います が、なにか対策はありますか？ • XPのプラクティスを参考にしてやってみることが多いです。 • ペアプロ・モブプロやCI、自動テストなど。 • XPのプラクティス以外にも、同期レビュー、トランクベース開発の 考え方などが参考になると思います。 69
70. FAQ⑤ 分解するときにツールは何を使っているのか 最近はリモートで仕事をする場合も多いと思いますが、ユーザーストー リーに分解するのに、何かツールを使っていますか？ • ツールはなんでもよいと思います • BASEの社内では、スプレッドシートやToDo管理ツールを使ってい るチームもいます • 自分がスクラムマスターとして関わっているチームはFigjamを使っ ています 70
71. まとめ
72. まとめ 工程に分けて成果物を受け渡していく開発は、バッチサイズが大きくな り、不確実性をコントロールするのが構造的に得意ではありません 開発タスクをユーザーストーリーで小さく分割することで無駄が減り、 荒ぶる不確実性をコントロールしやすくなるのでオススメです 72
73. https://herp.careers/v1/base We are hiring! ご清聴ありがとうございました！