なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
Manifesto for Software Craftmanship（ソフトウェア職人マニフェスト）にサインしよう：An Agile Way：オルタナティブ・ブログ
最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
