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
AgileTourOsaka2011 「関係者に理解してもらえるアジャイル開発にむけて」
Search
Shuji Morisaki
April 13, 2024
0
15
AgileTourOsaka2011 「関係者に理解してもらえるアジャイル開発にむけて」
Shuji Morisaki
April 13, 2024
Tweet
Share
More Decks by Shuji Morisaki
See All by Shuji Morisaki
ソフトウェアテストシンポジウム北海道2013基調講演「コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて ー」
smorisaki
0
14
XP祭り関西2011 「プラクティスが有効にはたらく前提は明らかになっていますか?」
smorisaki
0
7
Rakuten Tech Meetup #2 基調講演「ソフトウェア開発活動のデータとアナリティクスの3原則」
smorisaki
0
39
Findy「バグ分類に合わせた品質評価 - エビデンスにもとづくシフトレフトとシフトライトテスティング」 #品質評価_findy
smorisaki
1
180
開発知見共有のためのEnablersの会 キックオフ資料
smorisaki
0
350
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
The Language of Interfaces
destraynor
154
24k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Agile that works and the tools we love
rasmusluckow
328
21k
We Have a Design System, Now What?
morganepeng
51
7.3k
Mobile First: as difficult as doing things right
swwweet
222
9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Become a Pro
speakerdeck
PRO
26
5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
Code Reviewing Like a Champion
maltzj
520
39k
Side Projects
sachag
452
42k
Transcript
森崎 修司 tweets: @smorisaki 関係者に理解してもらえるアジャイル開発にむけて ー採択されたアジャイル開発の学術論文から 説明のパターンをさぐるー
2 はじめに 姿勢・考え方がアジャイル プロセス・プラクティスがアジャイル
3 • 姿勢は必ずしもプラクティス・プロセスに縛られるもので はない。 金払うんだか ら後はよろしく。 アジャイル的姿勢がないとき(開発序盤) もちろんです。 委託側 受託側
契約、 コミュニケション ルール、 規約、 正論、・・・
4 • 姿勢は必ずしもプラクティス・プロセスに縛られるもので はない。 一緒に価値あるソフトウェ アを作りましょう。 アジャイル的姿勢があるとき(開発序盤) はい。限られた時間とリ ソースで価値を最大化し ましょう。
委託側 受託側
5 • お互いに開発するソフトウェア・システムのことを真剣に 考えていない。 状況がかわってき ました。仕様変更 させてほしいんで すが アジャイル的姿勢がないとき(開発中盤) 調整はしますが契
約上、仕様凍結後 なので・・ 委託側 受託側
6 • 変更があっても、もっともムダが少なく変更インパクトが 少ない方法を双方が検討する。 状況がかわって きました。仕様変 更させてほしいん ですが アジャイル的姿勢があるとき(中盤) どこを変えるのがもっ
とも効率的ですか? 変更によるインパクト を列挙してみます。 委託側 受託側
7 • お互いに歩み寄ることによって問題を解決しようとしな い。 こんな不具合が 発見できないもん なんですねぇ。 プロとしてどうする つもりですか? アジャイル的姿勢がないとき(不具合発見時)
も、申し訳ありませ ん。有識者をまじえ、 レビューを強化しま す! 委託側 受託側
8 • お互いに歩み寄ることによって問題を解決する。 この不具合は運用である 程度回避できますので、 我々のお客様には影響は 出さないようにできます。 今後はしっかりしてください。 アジャイル的姿勢があるとき(不具合発見時) 早急に不具合を修正しま
す。Aと Bの複合による問 題なのでAを先に解決し て復旧作業を済ませてか らBを修正します。 委託側 受託側
9 • 東京証券取引所Arrowheadの開発 • フィードバック型V字モデル – あるフェーズの成果物のレビューにおいて前工程の漏れ が発見できなければ、そのレビューや工程に問題がある。 事例 アジャイル的姿勢があるウォータフォール
詳細な情報: ソフトウェア品質シンポジウム2011 企画セッション http://www.atmarkit.co.jp/im/carc/serial/userprincipal/02/01.html 基本設計 詳細設計 (健全な例) 検出欠陥の混入工程の内訳 ・詳細設計: 120件 ・基本設計: 3件 レビュー レビュー (健全でない例) 検出欠陥の混入工程の内訳 ・詳細設計: 120件 ・基本設計: 0件
10 このあたり試行錯 誤してみたい。 アジャイル的プロセス・プラクティスがないとき うーん。次のバージョ ンですかねぇ。 委託側 受託側
11 このあたり試行錯 誤してみたい。 アジャイル的プロセス・プラクティスがあるとき パラメータをいくつか 変化させてみましょう。 この件はこのイテレー ションで決着を付け るつもりで 委託側
受託側
12 他サービスとの連 携のほうが優先 順位が高くなった。 アジャイル的プロセス・プラクティスがないとき その部分は未実装で す。優先順位が高い とされていた部分の 実装中なのでお待ち ください。
委託側 受託側
13 他サービスとの連 携のほうが優先 順位が高くなった。 アジャイル的プロセス・プラクティスがあるとき わかりました。そちら を先に作りましょう。 何を後回しにします か? 委託側
受託側
本セッションのあらましと今後の流れ • 前提 – アジャイル的プロセス・プラクティスには関係者の理解( アジャイル的姿勢)が必要である。 – 理解を得るための説明、説得方法にもコツがあるはず • 紹介の意図
– 学術論文の査読も同様に説明、説得の側面がある。 – 採録になっている論文をみればスマートな説明、説得に 役立つかもしれない。 • 以降では・・・ – 国際会議の査読の流れ – 採録・不採録になったアジャイル論文の紹介 14
論文査読の流れ 15 著者 査読者1 査読者2 査読者3 会議・シンポジウム 投稿 査読 採録
掲載 不採録 別の会議に 投稿等
アジャイル開発論文での採録の分かれ目 前提の明確化 • 説明の相手がプラクティスを熟知している場合でも、両 者のイメージが一致しているとは限らない。 • × – 読者がプラクティスの定義を知っていることを前提にし ており、特に説明がなく、具体的なイメージを持ちにくい
。 • ◦ – プラクティスの定義や観察・試行との関連性が示してあ り、アジャイルを知らない読者でも理解できるよう配慮が ある。 16
アジャイル開発論文での採録の分かれ目 前提の明確化例 • × – 構成管理ツールの履歴を調査し、100回以上のリファク タリングが実施されていることがわかり、テスト自動化の 効果が極めて高いことを確認した。 • ◦
– お考えください。 17
アジャイル開発論文での採録の分かれ目 前提の明確化例 • × – 構成管理ツールの履歴を調査し、100回以上のリファク タリングが実施されていることがわかり、テスト自動化の 効果が極めて高いことを確認した。 • ◦
– デグレードのおそれから保守性を犠牲にする場合があり 、テスト自動化によってその状況を防げるか調査した。 – 構成管理ツールの履歴を調査し、100回以上のリファク タリングが実施されていることがわかり、テスト自動化の 効果が極めて高いことを確認した。 18
アジャイル開発論文での採録の分かれ目 他との関連 • 他の開発プロセスや既存の慣習との関連が書かれて いる。 • × – 実施したプロジェクトだけに閉じている。 •
◦ – 既存の(アジャイルでない)体制やプロセスとの関連が明 示されている。 19
アジャイル開発論文での採録の分かれ目 他との関連の例 • ×(実施したプロジェクトだけに閉じている) – TDDにおいてテストコードの実行コード(テスト対象)のカ バレッジを計測したところ96%であることがわかった。この 結果はTDDの有効性を示している。 • ◦(既存との関連が明示されている)
– 手動テストでのソースコードのカバレッジを計測したところ 90%であった。TDDにおいてソースコードのカバレッジを 計測したところ96%であった。この結果はTDDがカバレッ ジの側面で妥当であることを示している。 20
アジャイル開発論文での採録の分かれ目 比較対象・評価基準 • 「ないとき」を比較対象にする。 • 評価基準は異なるプラクティスやプロセスでも使えるも のとする。(できれば説得相手も知っているものとする) • × –
プラクティスへの準拠度合い等、アジャイル開発に特化 した評価基準 • ◦ – 不具合密度、不具合修正時間や工数あたりの成果物 サイズ等、アジャイル開発以外でも適用できる評価基準 21
アジャイル開発論文での採録の分かれ目 試行・事例・観察プロジェクト • 事例は数多く、かつ、長期間のものがよい。 • × – 少数・短期間 • ◦
– 多数・長期間 • 数を揃えたり、長期間の試行は簡単ではない。 → 試行・事例 + シミュレーションの合わせ技 – 実際には試行していないが「こうなるだろう」という Example scenarioをつけているものもある。 22
例題1 • 前提 – 目的: ユーザにオンサイトでいてもらうこと – 対象: ユーザ –
タイミング: プロジェクト計画中(契約前) – ソフトウェア: 委託開発の業務システム • 何を課題と設定しますか? • どのような事実をもって理解してもらおうとしますか? • オンサイトでないときとのメリットとデメリットは何ですか? • 起こりうる課題が何であると説明しますか? 23
例題2 • 前提 – 目的: 透明性を確保すること – 対象: プロジェクトメンバと管理職 –
タイミング: プロジェクト計画の途中 – ソフトウェア: 内製の製品 • 何を課題と設定しますか? • どのような事実をもって理解してもらおうとしますか? • 透明性によるメリットとデメリットの比較はどうしますか? 24
まとめと参考文献 • まとめ – アジャイル的な姿勢とアジャイル的なプラクティスのどち らが必要? – アジャイル開発に関する学術論文から説明、合意のパ ターンを議論した。 •
参考文献 – Ultimate Agile Stories Iteration1「学術研究論文に学ぶ アジャイル開発の有効性の示し方」 (収益は東日本大震災義援金になります) 25
お知らせ 1. 論文、記事等の公開情報をお知らせするメールニュースご希 望の方はメールアドレスをお知らせください。 – From: 情報をお送りするメールアドレス – To:
[email protected]
– Subject: 論文、記事等の公開情報のお知らせ希望 – 本文 ご氏名: ご所属: – いただいた情報を本来の目的以外で使用することはありません。 2. 当研究グループとの具体的な連携(有償の受託・共同研究) を募集しています。 – 詳細な統計データや海外動向との比較ができます。 – 関西圏・首都圏の拠点の企業とも多く連携しています。 26