「BDUF」を含む日記 RSS

はてなキーワード: BDUFとは

2014-02-12

何でソフトウェア開発の手法って上手くいかないの?

私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールシリコンバレー会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。

( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法プログラミング工学風のプロセス提供してくれる。しかし、上記の理由でそれだけでは不十分だ )

ソフトウェア開発手法が上手くいってる」っていつ言うことが出来るの?

チーム生産性幸福度メンバーのつながり・1日あたりのコード量・人月コード品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか?

もちろんどんな手法だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題  ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。

上記は私の経験則だけど、僕の知ってる殆どプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」

こんな思考実験をしてみよう、

つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。

この思考実験にはもちろん意味がない。メンバー一人ひとりのスキル性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。

アリスター・コッバーンが2003年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。

" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "

私達の最大の敵

私がプログラミングを始めた1970年当時、開発体制プロジェクトマネージャービジネスアナリストシニアプログラマと言った階層構造ガッチリ管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。

今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマ監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。

ガントチャートスケジュールドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルコーディングを放っておいてるのに、彼らは自分好きな手法適用するか作るかさせて、1980年代以上に決め事・儀式だらけだ。 

実際、今のプログラマは1970年代COBOL現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。

プログラミングチームが手法論を採用する(多くの場合チームの数名か、一人のいじめっ子が決めるのだが)と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジー生産性を高めるより早く、チームの生産性を下げてしまう。

で、何がうまくいくの?

私の経験から言わせると、アリスター・コッバーン論文やフレデリックブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクト成功させるにはチームメンバーが共通のビジョンを共有する事(その本では「コンセプトの統合」と呼ばれている)が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了ボタンクリックするだけのチームで働いことがあるが、何故か分からないがBDUFアナリスト監査の元で働いていた昔よりも気分が悪いものだった。

私はプログラマ様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマ手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。(私は必ずしもそうだと思っていないが。)でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。

これの翻訳です。

http://typicalprogrammer.com/why-dont-software-development-methodologies-work/

注1 '14/02/11 まだ半分しか翻訳してません。(明日完成予定)

注2 '14/02/12 翻訳完了しました。コメントの指摘に対応して文章を一部直しました。ありがとうございます

 
ログイン ユーザー登録
ようこそ ゲスト さん