Share
Embed
AgileTourOsaka2011 「関係者に理解してもらえるアジャイル開発にむけて」
Shuji Morisaki
April 13, 2024
Transcript
26 slides
-
3 • 姿勢は必ずしもプラクティス・プロセスに縛られるもので はない。 金払うんだか ら後はよろしく。 アジャイル的姿勢がないとき(開発序盤) もちろんです。 委託側 受託側
契約、 コミュニケション ルール、 規約、 正論、・・・ -
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件 -
本セッションのあらましと今後の流れ • 前提 – アジャイル的プロセス・プラクティスには関係者の理解( アジャイル的姿勢)が必要である。 – 理解を得るための説明、説得方法にもコツがあるはず • 紹介の意図
– 学術論文の査読も同様に説明、説得の側面がある。 – 採録になっている論文をみればスマートな説明、説得に 役立つかもしれない。 • 以降では・・・ – 国際会議の査読の流れ – 採録・不採録になったアジャイル論文の紹介 14 -
論文査読の流れ 15 著者 査読者1 査読者2 査読者3 会議・シンポジウム 投稿 査読 採録
掲載 不採録 別の会議に 投稿等 -
アジャイル開発論文での採録の分かれ目 前提の明確化 • 説明の相手がプラクティスを熟知している場合でも、両 者のイメージが一致しているとは限らない。 • × – 読者がプラクティスの定義を知っていることを前提にし ており、特に説明がなく、具体的なイメージを持ちにくい
。 • ◦ – プラクティスの定義や観察・試行との関連性が示してあ り、アジャイルを知らない読者でも理解できるよう配慮が ある。 16 -
アジャイル開発論文での採録の分かれ目 前提の明確化例 • × – 構成管理ツールの履歴を調査し、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