Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発プロセスのつくり方 / How to create development process
Search
Dai Fujihara
February 03, 2021
Technology
0
190
開発プロセスのつくり方 / How to create development process
開発プロセスのインプットからアウトプットまでの流れを整理する資料です。
Dai Fujihara
February 03, 2021
Tweet
Share
More Decks by Dai Fujihara
See All by Dai Fujihara
なぜ自社ではスクラムがうまくいかないのか アジャイルコーチと考える、スクラムのアンチパターン / Why Scrum doesn't work in my company?
daipresents
1
690
CI/CDパイプラインにE2Eテストを統合する / Integrate E2E testing into the CI/CD pipeline
daipresents
0
1.3k
アジャイル・DevOps時代のタスク管理ツール / Task Management Tools for the Agile and DevOps Era
daipresents
0
320
品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World
daipresents
0
1k
アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり / Agile Development and Quality Engineering
daipresents
1
7.9k
QA組織パターン - 構造ごとのメリットデメリットまとめ / QA organizational structure
daipresents
2
1.2k
人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / Automated Code Review
daipresents
0
2.4k
アジャイルテスティングが倒せない / I can't beat agile testing
daipresents
5
2.1k
E2Eテスト自動化の本質 - 品質と開発スピードを支えるテスト自動化時代へ / The Essence of E2E Test Automation
daipresents
0
710
Other Decks in Technology
See All in Technology
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.4k
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
290
OS 標準のデザインシステムを超えて - より柔軟な Flutter テーマ管理 | FlutterKaigi 2024
ronnnnn
0
170
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
330
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
The Rise of LLMOps
asei
7
1.6k
ドメインの本質を掴む / Get the essence of the domain
sinsoku
2
160
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.9k
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Six Lessons from altMBA
skipperchong
27
3.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Adaptive Systems
keathley
38
2.3k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Optimizing for Happiness
mojombo
376
70k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
Transcript
開発プロセス のつくり方 Copyright © 2019- Sekai Co., Ltd. All Rights
Reserved. https://daipresents.com/service/ Dai FUJIHARA @daipresents
はじめに 2 ◦ プロセスは現場ごとに異なるため、カスタマイズは現場に ゆだねられますが、そのベースとなるプロセスの整理・まと めにご利用ください ◦ 特定のプロセスには意思決定が必要になります。その意 思決定については考えられる選択肢を並べてみました。 必要に応じて追加したり削除してください
自分の背丈の確認 3 ◦ Q. 今の開発チームはどういう位置にいますか? • プロダクト価値を高めていくチーム体制やプロセスが 整っています(すごくいいね) • 開発スピードを高めていく段階になっています(いい
ね) • 開発プロセスを安定して回していく必要があります(よ しよし) • 開発プロセスを考える時期がやっときた(がんばろ)
ゴール設定 4 ◦ Q. ゴールをどう設定しますか? • ユーザやPO、開発者の意見をどんどんとりこめるプロ セスを作りたい • POの要求に答えられるプロセスにしたい
• 開発スピードを上げたい • 非効率な手戻りをなくして生産性を高めたい • 安全に確実にプロダクトをリリースしたい
今とゴールのギャップ はなんでしょう? プロセスを考えるときの材料になるはずなので洗い出してみましょう。 5
ステップ 1. インプットを整理する 6 要件、お問い合わせ、ユーザーレビュー、開発フィードバック・・・。 どこからなにがきて、どれはどういった意味があるものなのか? 要件となりうる入力のすべてを整理する。
インプットをさばく 7 なに? どこから? どんな? ビジネス要望 ビジネス、POなど ビジネスのために必要となるもの。 お問い合わせ ユーザーからCS経由な
ど ユーザーの不便や不満や疑問。ユーザーニーズとな りえるもの レビュー アップストアなど アプリレビュー、ご意見など、ユーザーフィードバック となりえるもの バグ ユーザー、自社メンバー など 致命的なものは修正が必須。無視する判断も必要。 お問い合わせやレビューに混ざる可能性がある。 その他要望 自社メンバー 作っていて気がついたことなど。もっとこうしたらよくな るとか。
ステップ 2. インプットから要件 8 たくさんの入力をどうバックログに仕上げていくのか?
インプットから要件で決めるべきこと 9 ◦ 優先度を誰がつけるのか? • どれを誰が? • 優先度をつけたものをどこにどう並べるのか? ◦ 変更をどこまで許容するか?
• 常に変更を受け入れるのか? • スプリント終了や開始のタイミングだけにするか? ◦ やったほうがいいけど後回しになりがちなものをどうさばくのか? • ちょっとずつやるのか? • まとめてやるのか? • 通常作業と同じレベルで扱うのか? 別で管理していくのか?
バックログ完成 要件のバックログなので粒度はまだ荒いです。 10
ステップ 3. 要件から仕様 11 大多数の問題はこの場所におこりがち。なぜ歴史は繰り返してしまうのか? 原因を考え、直視しながら対策を考えるべきです。
要件と仕様のはざま 12 このギャップによる手戻りが一番のムダ。 一番防ぎたいところ。 ギャップ ほしいもの (要件) 作るための ルール (仕様)
要件と仕様で決めるべきこと 13 ◦ 要件を仕様にするために何を決めるか? • デザイン • 状態や画面の遷移 • 技術的実現性
• アーキテクチャレベルの決定 ◦ 仕様をどこまで表現するか? • 仕様のフォーマットをどうするか? • どこまで記述すべきか?必要なのか? ◦ 仕様策定に誰が参加すべきか? • 次ページへ
14 • BizやPOが仕様を決めるなら ◦ 開発は作ることに集中できる ◦ 開発は作るだけに集中してしまう 要件と仕様で決めるべきこと
ステップ 4. 仕様からタスク 15 作るためのルールが決まったので、タスクに分割可能になります。 タスクに分割できると見積もれます。 見積もれるものはテストも可能になります。
16 仕様からタスクで決めるべきこと ◦ 作業レベルのタスク分割 • これが全部終われば次に進める • タスクは個人レベルで管理されればよい ▪ POはユーザーストーリーなどもう少し大きいレベ
ルで確認 ◦ 見積もられ優先順位が明確なタスク • スケジュールができる ◦ タスク分割に誰が参加すべきか? • 作業する人 • 作業する人からの質問に答えられるBizやPO
ステップ 5. タスクからデモ、リリース 17 完成したもののレビューとリリース判断。
ステップ 6. リリース後の フィードバックサイクル 18 ABテスト、問い合わせやレビューといったフィードバックのインプットへのつなぎ込み。
CREDITS - Special Thank! ◦ Presentation template by SlidesCarnival and
Photographs by Unsplash • Photo by Randy Fath on Unsplash 19 お問い合わせは https://daipresents.com/service/ からお気軽にどうぞ。