人月の神話、ウォーターフォールとアジャイル開発とエンジニア
人月の神話 は、旧版で読んでいて気づきのあった書籍である。ある意味、エンジニアなら誰でも通る道の類の本であるから、書かれているブログエントリも多いのだろう。
サムネイルが印象的なエントリがあり、ざっと読んでみると、本を読み、記録を残しておくことはやはり良いことなのだろうと思う。
書かれている記事の中で『そうだよな』と思うところと、『そうでもないよ』と思うところがある。『そうだよな』よりは『そうでもない』方がやはり気になる。
例えば、下表をまとめられている。
世界観 ウォーターフォール アジャイル 科学アプローチ いわゆる古典的科学 いわゆるシステム科学・生物学的アプローチ 全体と部分 全体は部分の集合によって説明可能 全体と部分は異なる性質を持つ 認識 変化しない 変化する 分離・分類可能性 分離可能 分離不可能・分類困難 事実・真理 事実・真理が自分たちの外にある 事実・真理は関係の中での解釈にすぎない デザイン 機能 意味 コミュニケーション形態 一方向 双方向
引用 銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world
1つは『全体と部分』の所の『全体と部分は異なる性質を持つ』はそうなのだろうか。POが要件を持っていて、スクラムマスタとチームでバックログの中から価値のある機能を届けるなら、性質としては同じなのではないだろうか。
『認識』についてはどうだろうか。『認識』は何に対する認識なのだろう。スコープに対する、であればそれは間違いである。『NAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Dr. Winston W. Rovce 』のP330では大規模開発のプロジェクトマネジメントにおいて反復について述べられている。
これは『認識』について変わることを言っているのではないかと思う。その変わる理由は、仕様どおりでないとか、要件を満たしていないとか、欲しいものとは違ったなど、様々な理由は想定される。
以降の項目についても項目としての言葉を選んだ意図や項目に書かれている意味合いを教えていただくとこちらが気づいていないことを学べそうだと感じている。
最後の『コミュニケーション』でウォーターフォールのコミュニケーションは『一方向』とするのはウォーターフォールでのシステム開発においてどのようなプロジェクトマネジメント のスタイルかと、エンジニアとして担うロールに依存するだろう。
それこそ統制型の、トップダウンのプロジェクトマネジメントにおいて、チームの一エンジニアで経験が少なければそうかもしれない。それでもチームの中でのコミュニケーションは双方向である。これがエンドユーザであればどうか。
UIがある機能を分担すれば、双方向であるし、バックエンドの処理であっても前工程や後工程のエンジニアとはコミュニケーションは存在する。
それより、人が一人でなければ成し遂げられない作業以外、つまり、チームで活動するのであれば必ずコミュニケーションは存在するのである。だから、アジャイル開発であっても、ユーザが実現したいことを知ろうとするし、チームビルディングをフォーカスしたくなるほどチームメンバを知りたくてコミュニケーションを取ろうとするのではないだろうか。
アジャイル開発もウォーターフォール開発も本質は同じであり、特性が違うだけなのである。それはプロジェクトが持っているもので、エンジニアはどちらが適切か見極められるかどうか、問われているのである。
エンジニアの好き嫌いで選んではいけないし、ましてや思い込みで選んでもいけない。
