締切（納期）のある仕事をする時には、できるだけ早く着手するべきか、あるいはぎりぎり間に合うタイミング（ジャスト・イン・タイム）に着手するのが正しいのか。その答えは、スケジューリングが何を主目標とするかによって違う、と前回書いた。もし顧客が納期遅れを嫌うのみならず、予定より早く納品されることも好まないような場合、あるいは、自社内の仕掛在庫や作りすぎのムダを極小化したい場合は、ギリギリのタイミングで作るのが正しい。しかし、早く出荷すればするほど競争に有利な場合や、成果物が情報のように保管場所をとらず材料の仕入れも無い場合などは、最早着手が望ましい、ということになる。つまり、ケース・バイ・ケースなのである。 「正しい答えはどれか？」という問いをビジネスで出された場合、あわてて答えを出さずに、まず、“正しいとは、誰にとって（あるいは、どのモノサシにとって）の話だろうか？”と逆に自問すべきである。私

TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 ＃下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過

Redmineでチケット駆動開発を実践して改めて、アジャイル開発は繰り返し開発であると認識した。 Redmine、Trac、Mantisでチケット駆動開発を経験してみて、繰り返し開発の戦略やコツがあるのがぼんやりと分かってきた。 ロジカルに言い尽くせないけれど、以下メモ書き。 【元ネタ】 変更要求に対する選択肢: プログラマの思索 Subversionコードラインのライフサイクル: プログラマの思索 チケット単位に並行開発する事例: プログラマの思索 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間: プログラマの思索

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

チケット駆動開発にTestLinkを導入してテスト管理してみて、テスト戦略みたいなものをぼんやりと感じた。 以下メモ書き。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkを運用して気付いたことpart4～TestLinkの概念を再考: プログラマの思索 TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索 TestLink・BTS・SVN・Hudsonの関連構造: プログラマの思索

チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは

ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係についてメモ。 【1】「システム要求、システム要件をどのように書くか？」はどのSW開発手法でもバラバラ。 オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。 ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。 ユースケースの書き方、観点のノウハウが詰まっている。 特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。 ユースケース記述書のサンプルは下記を参考。 ユースケースについて システムユースケース記述 [C02あんしん電話（高齢者] ユースケース

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

以前のhokorobiさんの記事にあったTestLinkの使い方の意味がようやく分かったのでメモ。 僕が勘違いしていた部分もあったので、再考してみる。 【元ネタ】 TestLink を使ってみた - hokorobiの日記 テスト手法の概念をTestLinkで説明する: プログラマの思索 第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記 TestLinkの運用方法は、開発チームがシステムテストで使う場合と発注者が納品モジュールを受入テストで使う場合で、観点が異なるようだ。 【1】開発チームがシステムテストで使う状況では、テスト計画をイテレーションと同一視して、Agileに開発するのがいいと思う。 理由は、スコープを狭めて徹底的にテストでバグを潰し、リリースできる範囲を少しずつ広げる手法の方が、システムの品質を確保しやすいからだ。 バグが残ってい

「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。 【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。 内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。 【本書で解説するEclipseプラグイン】 ・Checkstyle → コーディング規約チェック ・FindBugs → バグパターン検出 ・JUnit → 単体テストの作成/実行 ・TPTP → プロファイリング(非機能テスト) ・djUnit → カバレッジ計測 ・StepCounter → ソースコード行数測定 上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか？ 僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは

Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。 【元ネタ】 Re:Re:mercurialでチケット駆動開発 - ろじぼ Mercurialによるチケット駆動開発は強力だ！: プログラマの思索 ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索 【Mercruial以前のTiDD】 「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。 基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。 理由は、コードラインの品質を維持したいからだ。 リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。 そし

プライベートではMacがメインPCなのでSubversionはコマンドで操作していましたが、会社のWindowsマシンでは定番のSVNクライアントであるTortoiseSVNを使用していました。 ・TortoiseSVN | The coolest Interface to (Sub)Version Control TortoiseSVN は GUI なので、DiffをとってMergeしたりするとき何かは特に威力を発揮します。 ・・・なんですが、ここしばらくExplororが固まって再起動するはめになったりが何度もあり、OSが不安定な状態になってしまったのでアンインストールしました。 そもそも、WindowsマシンでもVMware上で動かしているLinux上で開発環境を構築しているので、普段のSVN操作はCUIです。 なので、TortoiseSVNを使わなくてもOKな状態にはなっていたんで

Amazon で購入した本と本屋に行って買った本がダブって涙目、ktanaka です。 今日は、Subversion(TortoiseSVN) でコミットしたくないけど必要なファイルのうまい扱い方について考えます。 Subversion はチームが安心してプロジェクトを進めるためにつかうものですが、Subversionを使うことを決めたために起こる悩みというのもあります。そのなかに一つが、コミットしたくないものを間違ってコミットしてしまうことではないでしょうか。そういった状況でいくつかの手段のなかから適切な方法を選ぶことができれば、無駄な時間が減らせるでしょう。 目次 常に不要だけど生成されちゃうファイル Thumbs.db 特定のディレクトリでコミットする必要のないもの (ログ、キャッシュファイル)など すでに Subversionで管理していてコミットしたくないローカルな変更 (デバッ

最近、携帯電話を換えました。こんにちは、 nakamura です。トイレに水没しても死ななかったタフガイにもついに寿命が訪れたようです。なぜか普通に閉じようとしただけでボキっと逝ってしまいました、、、かなすぃ、、、 さてさて、Windows のエクスプローラ上で手軽に使える Subversion クライアントとして人気な TortoiseSVN ですが、デフォルトの設定のままだと PC 全体を重たくしてしまう曲者です。スペックがそんなに悪いわけではないのにどうにも全体的に重たいなぁ、とかれこれ半年ほど悩んでいたのですが（半年は大袈裟か）ようやく原因が分かったので、その辺りの設定をご紹介しようと思います。 なんで重たくなるの？ そもそも TortoiseSVN をインストールするとなぜ PC 全体が重たくなるのでしょう。原因は TortoiseSVN 自身ではなく一緒にくっついてくる TSV

2009年12月12日23:14 by 山崎泰宏 管理機能とかもう作りたくない時はGoogle Spreadsheetsに逃げる カテゴリデザインネタ Tweet sparklegate Comment(1)Trackback(0) 応募フォームを作ったりアンケートを取ったり、その度にアプリケーションを開発するのは面倒なので、Google Spreadsheetsを使うことにした。 しかしどうもGoogle Formとか言うのは使いづらいし、もうちょっと何とかならんかなーと思ったので試作してみた。 こんな感じ ↑管理者は空っぽのSheetを開いてじっと見ています。 ↑利用者は管理者が設置したサイト上にあるこんなhtmlに適当な値を入れてSubmitします。Submit後、利用者は「ありがとうございました」ページを見て立ち去ることでしょう。 ↑管理者は、その値がシートにスポンと入るのを目撃し

Google AppEngineではBigtableの上にDatastore Serviceが構築されていて、開発者は、このDatastore Serviceを利用してBigtableにアクセスすることになります。このDatastore ServiceはPython版もJava版も機能はほとんど同じです。もしかすると、全く同じものかもしれません。 GAE/Jの場合、JDOを通じて、Datastore Serviceを利用するのが推奨されていますが、実はこれが嵌りポイント。 JDOは汎用的なインターフェースなので、Datastore Serviceを理解するのには向いていません。Datastore ServiceがRDBMSのような高機能なら、JDOを通じて抽象化し、Datastore Serviceのことは知らなくても済すのもぜんぜんありなのですが、残念ながら、そうなってはいません。 Da

「Gitを使いたいが、中央リポジトリにはSubversionを使わざるを得ない」という場合も多いだろう。そのような状況で便利なのが、SubversionリポジトリとGitリポジトリの橋渡しをする「git-svn」である。git-svnを利用することで、SubversionリポジトリとGitのローカルリポジトリを同期させることが可能だ。本記事では、このgit-svnの活用方法を紹介する。 git-svnのアーキテクチャ Gitの大きな特徴として、分散型アーキテクチャがある。分散型アーキテクチャでは、コミットはローカルのリポジトリに対して行い、ソースコードの同期はそれぞれの開発者間が持つローカルリポジトリ同士で変更点をやりとりすることで行う。もちろん公開リポジトリを利用したソースコードの同期も可能であり、柔軟な開発体制を取れるのが長所である。 しかし、一方でGitは非常に多数のコマンドがあり、

Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurbKoichiro Sumi

Say your Rails application is running in production and it’s getting good traffic. Performance isn’t as good you would like. You’ve already determined that your database is not the bottleneck. What’s your next move? There is a good chance that PassengerMaxPoolSize to be adjusted. PassengerMaxPoolSize specifies how many instances of your application Passenger will spin up to service incoming reques

株式会社クリアコード > ククログ > Ruby on Rails Technical Night: Railsで作るActive Directoryと連携した社内システム 先日開催された〜Ruby on Rails Technical Night〜 Ruby on RailsセミナーでActive Directoryと連携したRailsアプリケーションの作り方について話しました。 概要 ActiveLdapという社内システムをRailsを使って実現するときに便利なライブラリをデモを交えながら紹介しました。 社内向けのシステムをWebアプリケーションとして実現することは驚くことではなくなりました。Webアプリケーションなので、もちろんRailsを使っても実現することができます。 そのときに避けて通れないのが既存の社内情報との連携です。社内向けのシステムなので、社内情報と密接に連携し、より便

行ってきました、ただのメモです 聞き違え等間違っているところは多々あると思います クックパッドインフラ キャパシティプランニング ユーザが快適に使えるために 分析 キャパシティを知る ユーザが快適に使えなくなる限界値を知る 限界値を知る 予測 ユーザが快適に使えなくなる限界値を知る 予測日を知る サーバ増設のスピードアップ OSインストールスピードアップ PXE Bootでネットブート boot用サーバにDHCP/tftp/Apacheが立っている kickstart.cfgをじ自動生成 http://bootsearver/deplyment/kickstart 動的生成されたkickstart.cfgを使ってKickstart ミドルウェアインストールのスピードアップ database.yml,my.cnf 以前はcapistranoで puppetを導入 サーバの状態管理ツール Ma

Rails2.3.5がリリースされたようです。 Riding Rails: Ruby on Rails 2.3.5 Released 上記エントリの内容をざっくり意訳します。基本的にはバグ修正しただけみたいですね。 strip_tagsのXSS脆弱性を直した strip_tagsメソッドにバグがあり、IE利用時にXSSできてしまう脆弱性があったのを直した。(該当バージョンは2.2.xから2.3.4まで) XSS Weakness in strip_tags - Ruby on Rails: Security | Google グループ Ruby1.9の互換性を高めた 1.9との互換性に関するバグがちょっぴり残ってたので直した。 RailsXssプラグインが使えるようになった Rails3から、erbファイルで自動的に文字列がエスケープされるようになるけど、RailsXssプラグインを使うと

(※12月の1日から25日まで、日替わりで Ruby の Tips を紹介するイベント、 Ruby Advent Calendar jp: 2009 の 12 日目です。昨日は id:ohac さんでした。明日はうづら(udzura) さんの予定です。) Railsネタをひとつ書きたいと思います。 titleをviewで設定したい ほとんどのRails使いの皆さんは、おそらく下記のようなlayoutを使うことでviewをDRYにしているのではと思います。 app/views/layouts/application.html.erb <html> <head> <title>タイトル</title> </head> <body> <%= yield %><!-- ここを各viewファイルで定義する --> </body> </html> ですがこれだとタイトルが固定になってしまいますね。アク

「最近お仕事はどうですか？」 T氏「それがさっぱりなんですよねえ」 「え、さっぱり？」 T氏「もうここ数年、ずっとそうなんですけど、キャリアが主導でビジネスをやる時代じゃなくなってきたんですよね」 「その傾向は強まっているように感じますね。実際。いまはどうやって公式メニューに乗るかということよりも、どうやってモバゲータウンにアフィリエイトしてもらうかということが大事になってきてるね」 T氏「そうなんですよ。それに端末に新機能を載せても、肝心の端末が売れてないですから」 「昔は新端末が出ると、それにワッと飛びつく人が一定数いて、そこにくっついた新機能を試してみたくてコンテンツに入会する、という好循環があったからねえ」 T氏「そう。今は端末の価格が上がってしまったので、そういう消費行動がなくなってきたんですよ」 「それで各キャリアが開発工数のかからないAndroidへの移行を表明してるわけか」