先日、BPStudy#155〜要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法に行ってきました。オンライン開催。簡単に所感をまとめます。
所感
これまでに増田さんの DDD のセッションは何度か聴いたことがあり、CCSR もブログでは読んだことはありましたが、直接、話を聴くのは初めてでした。RDRA はあまり分かっていないので、そのあたりはちょっと理解が追い付かず...。とりあえず、RDRA ハンドブックを読んでみるか。あと、CCSR のパターンカタログとか参照実装を見ながら勉強するといいのかなぁ。
今回の CCSR の話はこのブログにまとまっています。
自然言語による要件や仕様の定義では抜け漏れが起きやすく、複雑なソフトウェア開発に対応できない。論理的に明確に要件や仕様を定義してシームレスに実装まで落とし込むというサイクルをいかに回すか、複雑なものはどうしたって単純にすることはできないので複雑なものをいかにコントロールするか、というのがこれらの手法を取り入れるポイントなのかなと思います。
「仕様が変わる」とは、これまで見えていなかった暫定仕様が正式仕様に変わっただけ、というのが目から鱗でした。あと、パネルディスカッションの最後に言っていた「要件定義と実装は近い」というのも印象的でした。なるほど。
以下、メモから抜粋。
要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法
ソフトウェア開発のやり方の改善 from 増田 亨
www.slideshare.net
- CCSR手法
- 継続的, 並行的, 段階的改善
- 複雑なソフトウェアは1歩ずつ改善するしかない
- コードを書く開発者が主体的に取り組む☆
- 全体像の認識を合わせる
- つながりを整理する
- 軸/中心を強化して周辺を広げる
- 要件定義の質を高くする
- RDRA 2.0
- つながりによる整合性
- 仕様を明確に記述する
- ビジネスロジックを軸にする
- 値の種類(型)でモジュール化する
- 手続きでモジュール化しない
- ビジネスルール > ファクト, ロジック, リザルト
- ファクト ⇒ フィールド/引数
- ロジック ⇒ メソッド
- リザルト ⇒ メソッドが返す型
- ハンドブック, パターンカタログ, 参照実装
- ビジネスルールの可視化
- 強い型付け言語がよい
- enum (バリエーションを表す)
- JIG
- 一覧にするとフラットに見てしまうので軸を持つ
CCSRを実現するRDRA活用法
www.slideshare.net
- 大きな手戻りを起こさないためにどの段階からくり返しを始めるか
- くり返しの単位は？
- BUCを管理単位にする (バックログなど)
- BUC単位で仕様化して実装
- BUCは価値や責務を表す
- 関係者間で認識を合わせやすい
- テストを考えやすい
- MVPは最小のビジネスパラメータの組み合わせ
- バリエーションはビジネスパラメータになる
- 個人顧客/法人顧客, ...など
- RDRAレイヤー
- システム価値
- 外部環境 (システムがどう使われるか)
- 境界 (システムの入出力)
- システム (システム化対象の情報と状態)
- 1つの業務フローがビジネスユースケースの単位になる
- ユースケースはシステムの境界
- ユースケースを階層化することでスコープが分かる
- くり返し開発では手戻りは起こるもの
- 情報, 状態, バリエーションの変更は手戻りが大きい☆
- ここを先に固く作る？
- 決められないところは暫定仕様で作る☆
- 暫定仕様を正式仕様にする
- 暫定仕様をマーキングする☆
- 暫定仕様の影響範囲を把握する
- 計画的な手戻り
- 要件-仕様-実装をシームレスに
- RDRAの図の関連はツールに頼る
- CCSRで無駄な作業が減る/気が付く
- 設計と実装はほぼ同じ
- 要件定義と実装は近いもの
