また例のごとく、自身の解釈がもりもりです。
登壇者
岡 大勝さん
開発プロセスを現場へ落としこんでいきたいと考えている。
一貫してエンタープライズに関わっている。
全体の流れはスライドに任せるとして。
"DAD本"の歩き方 - DevLOVE #134
- 参加するにあたって考えていたこと
- DAD
- 参加し終えて考えたこと
- 疑問
- キーワード
エンタープライズの今回の定義。
既存システムとの依存関係を避けられないモノ。と捉える。
DAD
ウォーターフォールでは今の開発は満たせない。
重さ、変化、速度、複雑さなどギャップがある。
しかし、エンタープライズ=ウォーターフォールという訳ではない。(前述)
だから、アジャイルの手法を採る。
アジャイルを内包する形でのエンタープライズ = DAD
DADは、アジャイルの開発プロセス。
しかし、agileは速さではなく
JIT(Just in time = 適切なタイミングで適切な量の作業をすること)と捉えている。
本は、必要なところを自由に読んでくれればいい。
量が多い全部読むのは大変。
プラクティスや戦術がそれぞれ列記されている。
価値が無いなら捨てよう。(価値があるなら続けよう。)
BxUF = Big XXX Up - Front
は窓から投げ捨てろ。
要件定義、設計書作成、モデリング、見積もり。
こいつらは、その時点での推測。
あとでいくらでも変わる。
BxUFに惑わされるな、こいつは悪だ!!
｢知の道具箱｣
DADは、いろいろなプラクティスや戦略をまとめている。
それぞれの利点と欠点を把握して利用して欲しい。
参加し終えて考えたこと
現場での経験と体系的な知識をもって事にあたる。
価値のデリバリをしていく。
DADは、今までの様々な開発プロセスを包含しようとしているのかな。
ただ、『ぼくのかんがえたさいきょうの開発プロセス』という新しいプロセスというわけではなく、
DADという、開発プロセスの知識体系、辞書という形での包含なのかなと。
疑問
JITは、ともすれば場当たり的ともいいかねないのでは。何を拠り所にして進めばいいのだろうか。
全体観を出す?それはコミットとして捉えられては変化に対して許容できない。
では、全体観を内部的に出せばいいのか?
予算でも計画でも、初期でも中間でも、顧客から納得感を引き出すにはどうしたらよいのだろうか。
例、｢見積もりを正確に出してほしい。｣とどうしてもなった場合。
互いに納得する形でそれを受け入れその見積もりをコミットしなければいけないのか。
はたまた、別の形での納得を引き出せるように啓蒙活動していかなければいけないのだろうか。
