■1 2008年のkakutani.comのアサマシランキング 2008年のふりかえりっぽいネタも入れつつ、恒例行事を。 2007年のkakutani.comのアサマシランキングと見比べるとあまり代わり映えしないが、2007年には1冊もランキングに入ってなかった翔泳社の書籍が2冊ランクインしている。でもこれは「翔泳社の書籍」というよりは「青木靖さんによる訳書」だな。野口さん去りし後、kakutani.com的には今後はどうかな。 いっぽうオーム社の書籍は2007年の4冊から1冊減って、2008年は3冊になってしまった。がんばれ、日本オーム社の会。では1位から順番に: 1位 『実装パターン』 2008/12/08の紹介(しかも大したこと書いてない)にもかかわらず1位になった。お前らはKentBが好きすぐる。 実は私は翻訳はまだ読み終えてないのだけれど(いま8章)、これまでのところ翻訳はわりと

■ アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き(Esther Derby) 翻訳者の「角征典氏(a.k.a kdmsnr氏、児玉サヌール氏)」*1から献本いただいた。昨日のネタは別にしても、おれもこのタイトルはひどいと思っているわけだが、良い本はまず褒める主義なのでまずは褒める。 どんな本かと言うと、「アジャイルなソフトウェア開発チームに、効果的なふりかえりを導入するための手引き」になる。アジャイル開発にはさまざまなメソッドがあるけれど、短いイテレーションを上手に回していくためには、PDCAの輪を閉じる「ふりかえり」についても手法を整理しておいた方がいい。 これって別にソフトウェア開発に限った話じゃなくて、例えばおれは今、Webサイト運営チームをいくつか抱えているんだけど、週単位で更新するようなサイクルで動いているから、サイクルの切れ目にふりかえりを入れるのは

今仕事でRailsアプリケーションを組むときに、test/unitじゃなくてRSpecを使ってる。mock周りの使い勝手がいいとか、語彙が馴染みやすいとかいろいろ魅力があるんだけど、その「可読性」を保つにはなかなかコツがいると思う。言うまでもなくRSpecはRubyのコードを「英語の表現として自然に見える」ようにすることを意図して語彙や書き方を決めている。これは英語圏のエンジニアには非常に素敵なことではあるんだけど、英語が苦手で英作文なんて始めて数分で泣きたくなるようなへたれ外国語学部生にとっては正直やっかいだし、周りの人達の大半は英語に慣れていない人達*1だったりするので、せっかく可読性が高い綺麗な表記でさえむしろ意図を理解する妨げになったりする。いっそドイツ語で書いて「お勉強」に活用してやろうかという衝動に駆られたけども、誰一人として読めない上に一週間後の俺ですら理解に苦しみそうなので

スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

Artificial Bill Gates EUで顔面認証義務化 trac + スクラム開発2006年06月30日 20:50 ソフトウェア開発手法については様々な手法が提案されてますが、アイデアマンズではここ最近スクラム開発というのを試験採用しています。 スクラム開発では開発期間をスプリントと呼ばれる短い期間に分割し、期間内での目標消化タスクを設定します。タスクを消化するために必要な総作業時間を毎日プロットし、スプリントバックログなる図を作成します。 仕事の目標を残作業時間を減らすという単純なものに置き換えることで、ある種ゲームのような感覚が生まれて、モチベーションを上げるのに非常に効果的です。 で、この手法とtracとの相性が非常によい。tracでチケットを発行するときに１タスク１チケットとして予想工数を書いとくと後で簡単にバックログが作成できます。 今、アイデアマンズでは trac

This domain may be for sale!

スクラム(scrum)という言葉を聞き及んだのでメモ 2006-02-14-4 [仕事] はてなダイアリー - スクラムとは <http://d.hatena.ne.jp/keyword/%a5%b9%a5%af%a5%e9%a5%e0> アジャイル開発手法の一つ。[...] プロジェクト管理が弱いとされるeXtreme Programming (XP)を補完される 形で併用されることが多い。 主なプラクティスは - スプリント：30日間のイテレーション - 日次スクラム：毎朝行う15分程度のミーティング - プロダクトバックログ：優先順位付けされた製品の仕掛かりリスト - スプリントバックログ：スプリント中に行う仕掛かりリスト なるほど！ そもそもどういう位置づけのものなのか、が分かった！ Technologic Arts Incorporated--推進技術

アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで

ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は

by William Pietri XPをこれから始めてみようと思っている人達は、開発部屋がどんな状態か興味を持っているはずです。(XPを知らない人は、この資料の後ろの方の用語集にある簡単な説明を見てください。)　ここでは、５人で九ヶ月かけたプロジェクトで撮影した写真を説明していきます。　私達の顧客の機密に関わる部分は写真をぼかしてあります。　質問や、もっと良い方法などの情報は筆者まで。 概要 最初の写真では、開発部屋におけるおもな機材に番号をふってみました。自然光を取入れ、机は木製にし、高い天井の部屋を選んだことで快適な労働環境を実現しています。　写真からもわかるように、最も広い壁側にはプロジェクトに関する様々な情報が掲示されています。 顧客 写真には写っていませんが左側には顧客(Product Manager)が座ります 開発中のストーリ その週に開発するストーリが詳細記述と共に掲示さ

■1 Agile Web Development with Rails(AWDwR)読書会＠東京 第0回 (あとで書く)書いた 昼前に妻と息子と近所の公園に出かけて、ベンチで昼ごはん。その後、妻子を公園に置き去りにして、Ruby業務チームの集まりへ。業務チームの集まり、といっても高橋さん(日本Rubyの会会長)とogino.さん(Rubyヲチャー)は業務チームだろうが基盤チームだろうと参加しているわけだが。ちなみに、基盤チームとか業務チームとかいうのは私の勝手な便宜上の分類。 「今後の進め方を決めよう」の会なのに30人も来ちゃうのがすごい。ポジションペーパー発表はdanさんのが印象に残った。「最後は君の強さと俊敏さが勝る」というフレーズは私もXP祭りのトークスで使ったので勝手に親近感。ここで「俊敏」という語を選んだ林完治の字幕センスに感謝したい。transcriptでは「they will

連載 NAgileで始める実践アジャイル開発 第1回 .NET＋アジャイルなら本当に幸せになれるのか？ ――フリーのN*ツールによる楽しいアジャイル開発―― デジタルアドバンテージ　一色 政彦 ＆ 正木 理絵子 2005/10/19 なぜ現在のソフトウェア開発においてアジャイル開発が生まれたのだろうか？ それは、「新しい時代の流れ（例えば、オブジェクト指向設計／開発やプロジェクトの短期化など）」と「古い開発体制（例えば、ウォーターフォール型のきっちりした開発プロセスやドキュメント作成を重視する姿勢など）」という無理な組み合わせにすでに大きな矛盾が生じており、その矛盾の中で実際に働いている多くのデベロッパーがそれを何とかして改善しようと思うようになってきたからだと筆者は考えている。要するに、矛盾が生じている現在のソフトウェア開発に対するアンチテーゼとしてアジャイルが提唱されたのではないだろう

やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。