新刊案内：スクラムの作者2人によるマネージャのためのスクラム入門 - capsctrldays(2013-03-08)
新刊案内：スクラムの作者2人によるマネージャのためのスクラム入門 Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド Ken Schwaber/Jeff Sutherland/角征典/吉羽龍太郎/原田騎郎/川口恭伸 アスキー・メディアワークス ￥ 1,680 私にとっては10冊目の翻訳書です。日本のスクラムで著名な3名の方と共訳しました。ソフトウェア開発手法であるスクラムを使って「組織を変革していく」という内容です。 私は知らなかったんですが、組織改革では著名なジョン・P・コッター教授の『 カモメになったペンギン(ジョン・P・コッター/ホルガー・ラスゲバー/野村 辰寿/藤原 和博)』などを引き合いにだしながら、スクラムを組織に広めることをスクラム的にやる、という論を展開しています。また、付録に「スクラムガイド」もついていますので、ミドルアップダ
Martin Fowler's Bliki in Japanese - 実例による仕様書
http://martinfowler.com/bliki/SpecificationByExample.html XP/Agile Universe 2002のワークショップで「Specification By Example（実例による仕様書、SbE）」という言葉に心を奪われた。これは、XPにおけるテストのあり方のひとつではないか。 （このところ、テスト駆動開発(TDD)のテスト部分を語るのは流行遅れなのだそうだ。ひどい話だ。Jonと同じく、私も、そんな副次的なものなんかよりも包括的な自動テストにこそTDDの真髄があると考えている。 例えば、誰かに「100万ドルあげるから山にハイキングしておいで」と言われたとしよう。私は胸を張ってこう言うね。「今回のハイキングの目的は、自然の美を堪能するためである」と。いや、まあ、もちろん、懐もあたたかくなるけど……ね。 ） 仕様書について議論する際、
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
テストダブル - Martin Fowler's Bliki in Japanese - TestDouble
http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double（テスト代役）」という言葉だ（スタントの代役(double)を想像してほしい）。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダブルコード − 忘れてもいいコードを書こう。 - capsctrldays(2012-07-06)
