受託開発の「作りすぎの無駄」を防ぐ［受託開発の極意 ―― 変化はあなたから始まる。現場から学ぶ実践手法（WEB+DB PRESS plusシリーズ）］｜gihyo.jp … 技術評論社
岡島幸男 なぜ作りすぎてしまうのか？ 『リーン開発の本質』を読んで改めて考えました。なぜ，受託開発でも作りすぎてしまうのか？ 製品（パッケージ）開発とは違い，受託開発では，お客さまから要望のあった機能のみ作られるはずです。 もちろん問題はそう単純ではありません。イテレーション開発やアジャイル開発が生まれた背景には，「そもそも要件が最初に完全に決まることはありえない」というソフトウェア開発50年の歴史から学んだ経験則があります。 私が言うまでもなく，要件は揺れ動きます。お客さまのニーズはシステムの開発期間を通じて少しずつ固まります。その影響で，要件や仕様が増えたり減ったり変わったりするのです。 「28分の10」。これは私が担当したあるシステムの設定項目（プロパティ）のうち，「利用されていない項目の数」です。28の設定項目のうち，10個は実際には利用されていません。約35％です。これら10個は
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
