タグ

bookとdevelopmentに関するsomatのブックマーク (5)

  • 「ほんとうのプロダクトアウト開発」 ― マツダはなぜ、よみがえったのか? - naoyaのはてなダイアリー

    "プロダクトアウト"。技術や思い入れなどを優先して製品を作るやり方です。 技術から発想しなければなし得ない製品というのは当然ありますし、そういうものこそ革新的であるとずっと思っていました。ですが、僕はこの「プロダクトアウト開発」というのを、いつからか都合の良いように解釈していた。自分達がやりたいことを優先するための正当化、技術的に困難な課題を解くことからはじめるのではなく、そこに扱いやすい技術があるからそれで作るという、リスクを取らない開発のための言い訳。 「プロダクトアウトじゃないと、真に新しいものは作れないんです。」 先日、『マツダはなぜ、よみがえったのか?』というを読みました。不振に陥った自動車メーカーのマツダが、苦境の中から RX-8 を開発し、その状況から脱出するまでをつづったノンフィクションです。このには「ほんとうのプロダクトアウトとはなにか」ということが記されていました。

    「ほんとうのプロダクトアウト開発」 ― マツダはなぜ、よみがえったのか? - naoyaのはてなダイアリー
    somat
    somat 2010/03/13
    プロダクトアウトを言い訳にしない/具体的ビジョンを伴なう困難な目標を技術的に解決する
  • 2009-08-09

    "Continuous Integration: Improving Software Quality And Reducing Risk(asin:0321336380)"の翻訳のようですね。去年の10月に辛抱たまらず原書買って読んでないオレの立場は...。:-) 今やCIサーバと言えばHudsonというくらいにHudsonが有名だけど,原書ではあまりHudsonのこと取り上げてなかったような記憶があるな(今,手元に原書無いんで未確認)。翻訳には追補とかあるのかな?ちょっと屋で探してみよう。 そうそう,久しぶりに原著者のサイト見に行ったらURL変わってた。 http://integratebutton.typepad.com/integrate-button/ そんなワケで以前紹介したHudsonのデモムービーは,こちら。 → http://integratebutton.type

    2009-08-09
  • デッドライン ソフト開発を成功に導く101の法則

    正しい管理の四つの質・適切な人材を雇用する。 ・その人材を適所にあてはめる。 ・人々の士気を保つ。 ・チームの結束を強め、維持する。 (それ以外のことは全部管理ごっこ) 安全と変更・変更は、あらゆるプロジェクトの成功のために(ほかの大抵の物事についても)必要不可欠である。 ・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。 ・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。 ・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。 負の強化・脅迫は、結果を上げさせる手段としては不完全である。 ・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。 ・さらに悪いことに、目標を達成できなければ、脅迫の内

    デッドライン ソフト開発を成功に導く101の法則
  • ThoughtWorksアンソロジー

    マーティン・ファウラーが所属することでも知られるThoughtWorks社は、アジャイルコミュニティへの貢献で世界に知られています。書は14人のThoughtWorkerが綴ったエッセイ集です。DSL、プログラミング言語、多言語プログラミング、オブジェクト指向設計、マネージメント、メトリクス、SOA、ドメインアノテーション、ビルド、デプロイ、テストといった、ソフトウェアのライフサイクル全般にわたる広範囲かつ興味深いテーマが目白押しです。ThoughtWorkerの知見に触れることができる一冊です。 翻訳者によるサポートページ オージス総研の 和書(日語翻訳版)のサンプル ● 「推薦の言葉」「賞賛の声」「まえがき」のPDF(500KB) 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷

    ThoughtWorksアンソロジー
  • 「アジャイルプラクティス」はスゴ本

    marsさんが、「システム開発に関わる人はみんな読めー」と強力にオススメするにつられて読む。これはスゴ。marsさん、良いを教えていただき、ありがとうございます。 ■ どんな? 書は、開発現場で培われた「成果を出す習慣」を、45のプラクティスとして紹介している。開発速度を大幅に上げたり、高速納期を目指すような、「アジャイル開発プロセス」という決まったやり方は、存在しない。アジャイルな開発とは、現場でのさまざまな活動をアジャイルにしていく――つまり、変化に適応することを継続させていく―― 「習慣」だということに気づく。協調性+フィードバックによるプラクティスは、あまりにもあたりまえすぎて見過ごされがちかと。その反面、意識して実践するならばこれほど心強い金棒はないだろう。 ■ 忘れがちな基中の基「成果をあげるのが仕事」 面白いのは、「悪魔の囁き」と「天使の導き」との間で揺れ動く「感

    「アジャイルプラクティス」はスゴ本
  • 1