2019/11/09 Agile Tour Osaka 2019 x miniPLoP
2019.11.09 Agile Tour Osaka 2019 × miniPLoP
https://www.kokuchpro.com/event/2588deb7811111547e835490dc66b1fd/
もう少しまとまった記事はこちらに書きました。ここは私のメモなのでメモを
オープニング
- 遅刻
- 道に迷った
ソフトウェアシステム設計におけるアレグザンダー理論の活用。数理的システム設計手法の提案。 -15の幾何学的特性とパタンランゲージ-
（ネイチャーオブオーダー） kyon-mmさん
○ 本を読んで使ってみようと思ったことを話す/ 経験を話す × パタンランゲージ論をくわしく網羅的に解説する アジャイルとクラウドの普及 → 分散システムの採用がふえる よくみる負債 ( やりたいことの可能性との乖離、プランBの不足、技術の変化に追従できない） よくきく解決方法（リファクタリング？MVP ? DDD? クラウドアーキテクチャ？） リファクタリング→大きな変更に耐えられない、システムレベルの変更をカバーしない、リストラクチャのナレッジがない MVP → 全体像からの予測によって得られる、精神的な準備・技術的な準備ができなくなる DDD → システム全体への提供手法がない、 クラウドアーキテクチャ → 現状の技術に依存・技術変化への追従を想定していない プロセス 1. 仮説 <- DDD 2. (クラウド）アーキテクチャ <- クラウドアーキテクチャ 3. アプリケーションアーキテクチャ 4. 実装 <- リファクタリング 5. 運用 1 - 5 をうすくMVPがやる 1と2を繋ぐ重要性が増しているが、既存手法ではカバーしていない システムアーキテクチャに寄り添う設計行為、設計図が解決するかも ＝ 1と2の間に「数理的システムアーキテクチャ」をしよう メリット 1. 理想と現状のGAP がわかる 2. 数理的なアーキテクチャのため機能を配置する場所が限定されない 3. 技術に依存しない、追従しやすい関係性を 数理的システムアーキテクチャ設計の方法 step 1 : 定量化できる普遍的ななにかを軸にして、要件やシステムを表現し、 step 2: それらの特性や関係性を15の幾何学的特性によって表現する 軸は？ ... 気合いで！ 例：IoT システムなら、横 : 情報の合成度 / 縦: 情報間の地理的距離→ セミラティス構造をつくっていく 軸をどうやっておもいつく？ ビジネスの間に絶対に変化しない & 重要かつ定量化できそうな軸をみいだす アイディアの源泉はシステム開発をとおした全ての活動 でも最初は仮説からなる だめな軸 技術進歩で変化するものはだめ（例：DB爆速になったらだめ、とか） いわゆる「主観的」なもの ( 親密度、仲良しみたいな多様なのでなにを置くか定まりにくい） 15の幾何学的特性 * センター : 生き生きとしている部分 軸は「10.段階的変容」によってシステムの全体の形をつくる 縦と横に「段階的変容」があるはずだ！ どこが「力強いセンター？」 境界は？ 粗っぽさ シンメトリー これを繰り返して、部分や全体をみつけていく 機能ではなく、幾何学的特性として必要な全体と部分をみつけていく → 機能は変わる！機能をデザインするのではなく、普遍的なものをデザインすることによりrobust で柔軟なシステムになるはず ある程度形がきまったら、ユースケースを利用して情報やアクションの流れをウォークスルー ウォークスルーで、部分や特性の過不足を修正する 井庭せんせの「全体性のたまご」 全体 - 部分をいったりきたり 課題：事例が少ない、他手法との比較、システム開発のどのフェーズで有効な手法？
要件 とシステムアーキテクチャの間に抽象的・普遍な構造を設計するステップを1個いれる、という話。 ただし、この汎化・言語化の能力って相当難しいよね。という話が質疑応答にもでてきていた 既存システムがある派生開発の場合、あらためて全体のTo Be な数理的システムアーキテクチャを設計できれば、、現在とのGAP をみつつどこをせめていくか（あるいは変更しないのか）議論ができるのではないか
余談で、軸は3か4軸になることが多いそうで、kyon-mm さんはCAD で設計図つくってぐるぐる回しながら特性やセンターを発見していくそうです。 全体観をみたいときにポンチ絵を描くのは岡崎先生の教えですが、3次元でぐるぐるまわしながら考えるのはその先をいってて変態的でいいですね。４軸はみれないけど。
The Power of Patterns and Pattern Languages
Joseph Yoder
Patterns The Origins of Patterns, 1977 - ボトムアップ パターン 課題 / core solution / 何万回もつかわれているけど同じものはひとつもない事例 Software Patterns → 今はいっぱいある パターンの実践、repeatable / useful / adds QOL / 結果 "名前のない品質" パターン proven solutions to repeating problems / proven practices to repeating situation ... context / problem /solution solution は path も示さないとだめ -> pos/neg 両方はなす 例：microservices.io マイクロサービスにはコストがかかるそれもきちんと喋る パターンを絵に描く、名前をつける FORCES ： 足をひっぱり合う、別の方向に Known uses : 事例、3つはないと パターンを書いてみよう！ 名前 / コンテキスト / （フォース） / 問題 / 解決 → このフォーマットでpractices をまとめることによりつっこみをいれやすい/名前をつけるとそれがつらなって「language」になる パターンは自分がいなくてもうまくいくもの 人にみせることで発展する このスプリントでうまくいったことをパターンで書いてみよう Pattern Languages Collections vs Languages Language ( Intent / Maps / Context / patterns / Sequences ) リストとネットワーク Teams That Finish Early Accelerate Faster https://hillside.net/
成功したことにラベルをつけて、コンテキスト/(フォース) / 問題/解決 を記録する のはやってみる Kent Beck が普通にでてきてえらいひとなんだなーと思った 「エキスパートがパターンプラクティスの記述に長けているとは限らない。むしろ当たり前に実行しすぎてエキスパート自体は記述できないことはよくある。なので分析して書き下す人は別にいてもいい」
アジャイル品質パターンのワークショップ
なぜパターンなのか？
"Quality is not an act, it is a habit." -- Aristotle
アジャイルの源流 パタン + 品質
QA と AQ( Agile Quality)
24+のパターン （中核 / 品質上アジャイルのやり方 / 特定 /可視化）
https://qiita.com/kenjihiranabe/items/a0795dbdab4c58e746a1
戦略 ーリリース ーイテレーション ー日々 ー 継続的
中核パターン
障壁の解体（物理的な障壁、文化的相違...)
品質上アジャイルなあり方
"チーム全体"で / 外からみるのではなく、中から見る → 品質保証プロダクトチャンピオン/アジャイル品質の専門家/Agile QA Tester
品質上アジャイルな展開
品質に関する作業負荷の展開 / Shadow The Quality Expert / 品質主導者とのペア
これをプロセスへの品質の組み入れ例
ロードマップ - 本質的品質発見 / アジャイル品質シナリオ
↓
PBL - 品質ストーリー / 折り込み品質 - 基準がある
↓
スプリント - 品質に焦点をあてたスプリント/ 品質のモニタリング
↓
品質テスト
品質の特定 : 品質シナリオ
やわらかく、読める、わかるように品質をかく
刺激、環境、測定可能な応答が明白なこと
measurable , アジャイルな着地点 ,着地点の再調整、品質目標の合意
着地点の再調整の例
進むにつれ（必要に応じ）自動化 : Automate As You Go
品質ダッシュボードと品質ラジエーター
（ヤフーと一緒につくって、マネージャーさんにみてもらった
可視化：バックログ上の品質検討
可視化：ロードマップ
機能 / プラットフォーム に「品質」をつんでおく
アーキテクチャ ロードマップ
シェアする
definition of done
(ポシャる基準さっさと決めようぜ。日本の企業、苦手）
昨日アメリカから帰ってきて、今日大阪について、明日アムステルダムに行くという早稲田の先生。 品質を言語化する/測定可能な基準を設定すること → それではじめてダッシュボードやラジエーターで監視可能に コードの品質のうちの拡張性・変更容易性を測るために、「用もないのに変更してみる」プラクティスをkyon-mm さんが紹介していた。「いろいろなプラクティスがあるけど、実際はやってみないと設計がいいかわからないことも多い。でもやんなきゃいけないときにやってすっごい変更できない設計だったーじゃ遅いので、やってみる」と。
