二つ訳したが、どっちも訳が微妙になった。っていうか原文がなんか変なところあるので、問い合わせ中です。
その上、両方ともあまり面白くないという。ちょっと失敗。
MongoDBの翻訳全般については、 こちら参照。
アクセス記録から振り返ってみる。
Google Analytics調べて、一日200ページビューの60-80ユニークユーザくらいらしい。やっとキーワードが増えてきたことからか、ここ1週間で、検索エンジンからのアクセスが増えた。EvernoteとMongoDB、Nginxでの検索が目立つ。ページランクは0。ひどい。
RSSリーダー的なsubscriberが、Google Readerが27、Livedoor Reader系が19。Bloglinesが1。まだBloglinesってあったんだね(ユーザの人ごめんなさい)。
ブラウザの統計的には、Firefoxが43%、Chromeが25%、Safariが14%、IEが7%。なんか分かりやすい。Chromeが多いのは最近自分がChromeってのはあるような気もするが、それでも想像よりは多い。
Google AdSenseが1.13ポンド(150円くらいか)。憧れの「たいしたことないよ、鯖代が払えるくらい」まで遠い。ダメだこりゃ。
このブログが載っているVPSの月間のネットワークの制限が50GBなんだけど、今のところ2.2GBくらい。2.2GBのうちのほとんどがパッケージのインストール関係だと思う。ブログへのアクセスは微々たるもの。しばらくいけそう。もちろんhtmlやxmlなどをgzipしたり、画像はキャッシュさせたりと基本的な工夫はしている。机上の計算だと一日平均10000人とかでも余裕。同時アクセスによってはメモリとかの方が先に死ぬだろうけども。よっぽど釣り的なこと書かなければそういうことはないでしょう。Nginxのアクセスログは数日で消してしまっているんだけど、1ヶ月くらいは残して流量計算に使おうかな。
というわけで、今年は薄っぺらいことでも頭の中を地道に出していこうと思ってるので引き続きよろしくお願いします。
プロファイラの方を読んでみて思ったが、その辺はいい意味でも悪い意味でもRDBMSを踏襲してる。
注：まだよくわかってない。
(前職含め)普通のウォーターフォールな開発の経験はそれなりにあり、その大変さは知ってるつもり。もちろん！、デスマーチの経験もあり。ただアジャイルの経験はほとんどなし。こんな自分が今さらながらアジャイル開発を初めてやってみた感想をメモ。
やってみることになった経緯。現在の会社では、小さい会社ということもあり、今まで部分的にウォーターフォールな感じで、残りは力技で開発してきた。今まではそれでなんとかなっていたんだけど、そろそろそれもまずいよね、という感じになってきたので、小さめのプロジェクトでアジャイルっぽい開発をやってみた。Webのアプリケーションで画面数的には(結果的に)大小含め11ぐらいの規模のプロジェクト。
プロジェクトメンバーは、開発側はプロジェクトマネージャを入れて４人。プロジェクトマネージャ（兼コンテンツ担当）とデザイナー、フロントエンドエンジニア的な人と、バックエンドやその他サーバ関連とか雑務な人（私）。デザイナーの人が入ったのは最初だけだったので実質3人でアジャイルをしたという感じ。
その開発メンバーに加え、社内の営業をお客さんとして入れ、イテレーションを進めていった。2週間ずつのイテレーション、全部で8イテレーションで合計3ヶ月くらい。プロジェクトメンバ全員ともにフルタイムでこのプロジェクトというわけではなくて、人によって割合は違うが業務時間の半分くらいをこのプロジェクトに使った感じ。
結果から言うと、なかなか気持ちよく開発ができたなと思ってる。
さて、アジャイルにも色々あるが今回試してみたのは、以下のプラクティス。
- 要求仕様をストーリーに落とし込む。 ストーリーは、 As X i want to do Y (so that Z) 形式で作る。
- ストーリー毎にだいたいの難易度(かかる時間ベースで)をポイントとして付ける
- イテレーション毎に、そのポイントの合計が均一になるようにストーリーを割り振る
- このとき、メインとなる機能のストーリーを前の方のイテレーションへ
- 関わらる担当者が多いストーリーほど前の方のイテレーションへ (担当者が多いところ == オーバヘッドが大きかったり、計画時に見えないところが多いので)
- 各イテレーションを実行し、進捗や結果を見て、その後のイテレーションでやることを動的に変えて行く。
こんな感じで進めてみて、アジャイルいいかもと思ったのは、
- 精神的に楽。各メンバーが、１イテレーション内に、このプロジェクトに対して何をcommitすればいいことが明確になるので、精神的に楽。全体のスケジュールがあって、それを順番にこなしていく、という従来の方法だと、スケジュール通りに進んでいても、後ろに山のようなタスクが見えてしまってどうも焦る。
- クオリティが上がる。自分のイテレーション内のタスクに集中できるので、60-70%ぐらいの完成度で、次のタスクを前倒ししておこう、という欲が出なくて済み、今のイテレーションの作業を完成させようという気持ちになる。結果的に全体のクオリティが上がる。山のような後ろのタスクが見えてしまうと、めんどくさいところや細かいところはつい後回しにしてしまうが、そういうのがないのできっちり今のイテレーションに集中できる
- さぼれない。逆に１イテレーション内にやるべきことが明確になっているので「それは後でやる」的な開発者のわがままがされにくい。
- (各イテレーションで)できなかったことがチーム内で明確になる。イテレーション内でイテレーション毎の目標を達成するのは基本だが、できなかった場合、後のイテレーションに回したり、機能の削減を考えることを含めじっくりと検討することにある。このときに何をしたかというのがチーム内で明確になる。ウォーターフォール的な開発だと、すべてがちょっとずつ遅れ、結果的に全部がひどいことになりがちだが、アジャイルではそれが防げるような気がしている。
- 各メンバーが、フルタイムでないケースだと、どうしても時間の配分が難しくなってくるが、週単位でのゴールが明確な分、時間配分もわかりやすくなる。
でも、今回はうまくいったが、アジャイルに持っている不安、
- 最終的にユーザが納得するようにまとまるか (ユーザが参加しているとは言え、最終的にユーザが幸せな物を作れるのか)
- 予想外、予定外の大きな仕様変更が発生した場合どうなるのか
- スケジュールは守れるか
は、まだ残っている。特に、微調整はしながら大きい問題を起こさない、というのがアジャイルの肝だとは思っているのだけど、それが本当に色々な場面で通用するのか、と言ったところを中心にまざまざ色々不安はある。
ただ、なんとなく感じているのは、アジャイルというのは開発側が開発の主導権を取り戻すための方法なのかな、ということ。開発側が主導権やオーナーシップがないプロジェクトはうまくいかないしね。
とりあえず一回ぐらいではどうにもわからないので、もうしばらく続けてみるつもり。
RSSリーダで読む