ピープルウェアを読んだ - はこべにっき ♨
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2013/12/18メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。 実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。 いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコ
ユースケース駆動開発実践ガイド - プログラマの思索
「ユースケース駆動開発実践ガイド」を読んで、この手法がまさにRUPなんだな、とようやく気づいた。 理解した内容をまとめてみる。 ＃一部はメモなので論理的整合性は無視。 【1】ドメインモデルはプロジェクトの用語集 「ユースケース駆動開発実践ガイド」では、プロジェクトで実際に使われている単語を全て収録した「生きている」辞書だ。 単なるプロジェクトの用語集よりもはるかに優れている。 それぞれの単語間の関係がグラフィカルに表現されているから。 【2】ユースケースは叙述的に書く 「ユースケース駆動開発実践ガイド」では、ユースケースに「～しなければならない」という命令形が混じる時がある。 機能要求は「～しなければならない」のように指示的に書かれた要求。 機能要求を分離してユースケースに割り当てなければならない。 ユースケースに機能要求が混在している時は、ユースケースが良くない兆候。 ユースケースは要求
ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。 シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい 最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。 書籍を読み直してみたところ、次のように書いてありました。 コントローラと操作の間に1対1の対応を取る必要はありません シーケンス図上にフローチャートを描こうとしてはいけません そこで、シーケンス図か
オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ！」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって？
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今泉みね『名ごりの夢』 - かわうそ亭
