SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
それは説明責任の問題 - rabbit2goのブログ
ソフトウェア開発者の仕事は、もちろん納期通りに要求されたソフトウェアを開発することだけど、それだけではない。成果物に対する説明責任も伴うはずだ。 どのようなアーキテクチャ、デザインパターンを採用しているのか？ モジュール構成、クラス構成はどうなっているのか？ 何をどのようにテストすれば良いのか？ 性能面、機能面でのボトルネックはどこか？ どのような障害が発生したのか？ 次の派生開発時に改善すべき問題は何か？ 通常、これらの情報は仕様書などの資料として残したり、申し送り事項という形で整理されるはずだ。もちろん、ソースコードを読めば分かるようなことはどうでも良くて、そのコードの背景にある設計思想とか、大量のコードの中に埋もれがちな考え方、役立った開発資料などの情報の方がずっと重要な意味を持っていたりする。こんな情報こそ整理しておく価値があると思う。 しかしながら、開発が終わって一安心するのか、
仕様書は作成過程が大切 - rabbit2goのブログ
ソフトウェア開発の現場で良く聞く発言。 「仕様書をキッチリ書こう」 「きちんとした仕様書を書ける人が欲しい」 「仕様書に記載漏れが無いようにしてくれ」 仕様書とは、完成した文書が一つ有れば全てが片付くような性質のものではなく、何をどう作るかという検討内容を記録として明文化したものだ。だから、仕様書の作成行為そのものが設計行為であり、個々の対応項目を明確にして、設計上の漏れ・不備・矛盾を早期に見つけ出すための重要な作業だ。単に、これをやる、あれをやるという程度の文章の断片が並んでいるようでは、それは仕様書としての役割を果たしてない。 後のテスト工程で火を噴くような開発プロジェクトに共通しているのは、そのような明確な設計工程が欠如している点だ。仕様の検討を疎かにしたり、漏れや矛盾の確認を事前に行っていない以上、潜んでいた問題点が顕在化してくるのは当然のことだ。こんな時「仕様書が無いから」という
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
デスマになるのはPDCAを滝に対して垂直に回すから - 404 じゃばてないわー Not Found(一部X-RATED)
ちょっと書いてみる最近、PMBOKだかを読むような人も増えてると思うけど、いくら読んでもデスマは解決しないのは、PDCAを滝に対して垂直に回すから。PDCAと滝の関係はP設計D開発CテストA修正と水平に回るべきなのに、今はこうなってる。PDCA設計PDCA開発PDCAテストPDCA修正つまり、垂直に回っている。設計に対していくらPDCAをまわしてみても、せいぜい誤字脱字、書式が正しくない、更新日付が間違ってる、と言ったことしか見つからないし、こいつらは、プログラムに対してまったく関係がない。まったく関係がないミスをいっぱい見つけて、はい、これで完璧です。次のフェースに行きましょう。って言ってるのが現状。で、開発になってこの設計ではうまく行かない点が見つかって大騒ぎになっている。何でだ設計書は完璧なんだろう？はい完璧に誤字脱字はありません。ギャグですかと。テストになってバグがいっぱい見つかっ
「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：あらためて感じる、開発の進め方の難しさ
あらためて感じる、開発の進め方の難しさ 公開日時： 2006/04/16 14:43 著者： kenn 最近めっきり開発者モードへと還って失われた日々を取り戻しつつ目下急成長中（注：当人比）の江島でございます皆様いかがお過ごしでしょうか。 色々模索しながらやってきた新サービス開発プロジェクトですが、同僚のダニーがバックエンドのコードを書き、ぼくがUIの部分を担当するという大まかな分業に落ち着いてきています。 すでにpretrieve.comというパブリックレコード検索エンジンを開発してリリースした経験のあるダニーはともかく、ぼくは本格的なウェブのサービス開発というのは初めてなので、あちこちで頭をぶつけながら修行中です。 この手のウェブのプロジェクトは、一見簡単そうに見えて実際やってみるとスピーディにやるのは結構難しくて、とくに進め方についてはずっと暗中模索でちょっとずつ前進という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
