エンピリカルとは：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
エンピリカル（empirical）って何ですか？という質問をいただくことが増えてきた。エンピリカルソフトウェア工学に関する質問に対しては「技術や手法を開発するだけでなく、実際の開発にあてはめ、技術や手法の適用効果や限界を検証すること」と回答している。 ソフトウェア工学に関わらず、エンピリカルな検証が必要なものはたくさんある。システム開発をされている方ならば一度は経験があると思うがパフォーマンスチューニングやフィールドテストはそのうちの1つだ。利用状況を想定して、システムやソフトウェアを設計するところが上述の「技術や手法の開発」にあたり、実際の環境におき、実データにあてはめてパラメータチューニングしたり模擬データで検証したりして、設計を変更するのが「実際の開発にあてはめ・・適用効果や限界を検証すること」に対応する。 身近に感じていただけたのではないだろうか。 書籍「ソフトウェア開発におけるエ
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
SVNリポジトリの管理方法 - プログラマの思索
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の
チケット駆動開発を日本発のアジャイル開発へ発展させるには？ - プログラマの思索
さかばさんの記事を読んで考えたことをメモ。 【元ネタ】 [TiDD] 小規模開発の難しさを考える: ソフトウェアさかば チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。 しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。 ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。 情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。 その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。 テスト駆動開発を実践するには、JUnitを使いこなさねばならない。 常時統合
チケット駆動開発が進むべき道 - プログラマの思索
さかばさんのBlogにTiDD(チケット駆動開発)の分析が書かれているのでメモ。 【元ネタ】 必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかば TiDD：チケット駆動開発: ソフトウェアさかば [TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば [TiDD]チケット駆動開発と見える化: ソフトウェアさかば [TiDD] チケット駆動開発によるフロントローディング: ソフトウェアさかば [TiDD] プラクティスから方法論へ: ソフトウェアさかば TiDDとアジャイル開発に強い関連性があると色んな観点から分析されている。 TiDDはまだ定義すらない曖昧な概念であり、プロセスですらない。 今後進むべき方向は、方法論やベストプラクティス集を定義することだろう。 僕はTiD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
