実験駆動開発 - ポストアジャイルの手法
原文(投稿日：2010/02/25)へのリンク TDDとBDDは今や、広く使われているソフトウエア開発技術だ。しかし、単にBDDやTDDに従っているだけではビジネス機会を逸したり、もっと悪いときにはビジネスに悪影響を及ぼしてしまう。TDDとBDDには解決できないふたつの問題がある。すなわち、どのようにして開発したアプリケーションの使用を評価するのか。そして、どうやって顧客からフィードバックを得るか。 ユーザを調査する従来の方法は決して正確な結果にはならない。アプリケーションの提供者も顧客も多大な時間を必要とし、先入観にとらわれてしまう。Nathaniel Talbott氏はRubyConf 2009でのプレゼンテーションで次のような考えを発表した。すなわち、開発時におけるTDDと同じような方法でビジネスもフィードバックを得るべきだ、という考えだ。 (画像はLabnotesから) ソフトウエ
継続インテグレーションとデータベースのバージョン管理
原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの（ビューやストアドプロシージャ、ファンクション、トリガ等の）プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。 Allen氏は自身の経験から学んだことを、関係データベースを使用した開発のための３つのルール(source)として記載した記事を投稿した後で、一連の投稿を始めた。そのルールとは、: 1. 開発作業には、共有データベース・サーバは決して使用してはいけない。 ソフトウェア開発におけるたくさんの便利なもののように、共有データベー
- 継続的インテグレーション
継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。本論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵
発注者はアジャイル開発をこうみている ― ＠IT
メンバーの特徴はアジャイル開発に積極的な人物が多いということ、プロジェクトへの途中加入が多いということ、開発者だけではなく、発注者の猪狩氏が含まれていることである。アジャイル開発は開発者側から語られることが多いが、発注者からはどのように見えるのだろうか。今回はその辺りに注目してインタビューを読み進めてもらいたい。 プロジェクト対象 ワークフローを管理する製品の開発がプロジェクト全体の目的である。このチームは製品の基盤となるエンジン部分をJ2EEで開発している。開発チームは4人体制である。 利用ツール ―― 「開発にはどのようなツールを利用しましたか？」 角谷 「統合開発環境（IDE）はEclipseですね。それとORマッパーの機能もあるので、Jude（永和システムマネジメントが開発したモデリング支援ツール）を拡張して使っていました。ほかに使ったといえばホワイトボードと、後はXPカードですね
危険を測る、可能性を測る:近藤淳也の新ネットコミュニティ論 - CNET Japan
前回、完成度が50%の状態でサービスを公開するという話を書きましたが、「半分の完成度でサービスを出すなんて無茶苦茶だ」といった感想をもたれる方もいるのではないかと思います。 そうした意見の大半は、不具合などによる被害を想定してのことだと思います。確かに「ログインパスワードを誰でも盗めるような仕組みになっていたけれどろくに検証もせずに公開してしまった」みたいな事は許されない事です。 しかし、「パスワードを盗まれて他人が自分に成りすましポイントを換金されてしまう」といった被害と、例えば「一部のブラウザで表示が崩れて見えてしまう」被害とを比べたときに被害の規模が違うことも確かです。 ウェブページの表示が崩れて見えてしまうことを防がなくてはいけないのは確かなのですが、様々な被害を客観的に評価し、例えば表示が崩れるといった被害に対しては「これまでに表示を確認したブラウザは○○と△△ですが、もし他のブ
ユーザーセンタードデザイン(UCD)をエクストリームプログラミング(XP)の中で実現するには
こんにちは、ディレクターの安藤です。 37signalsに、「Extreme Programming vs. Interaction Design (エクストリームプログラミング(XP)とユーザーセンタードデザインの融合手法)」という興味深い記事が出ていました。 「XP」は、ケント・ベックなどが考案したよりよいソフトウェアを作り出すための開発手法であり、一方「ユーザーセンタードデザイン(UCD)」は、人間(正しくはターゲットユーザー)にそのものの持っている機能をわかりやすく伝えるというコンセプトのデザインのことですね。 ユーザーセンタードデザインの普及に努力している人の1人としてはアラン・クーパー(Alan Cooper)が挙げられます。アラン・クーパーはVisualBasicを開発したカリスマエンジニアです。プログラマー出身ながらユーザーのことを考えたインターフェースの創造に精通しており
CNET Japan Blog - 近藤淳也の新ネットコミュニティ論：連続的な開発と非連続的な開発
ペアプログラミングや偉くない管理職、といった方法のほかに、はてなでは様々な開発業務を「連続的」「非連続的」といった概念で分類して考えています。 例えば、携帯電話から見ると、はてなダイアリー向け以外のリンクが張られない。はてなアンテナと同様に、コンテンツ変換を通して携帯から読める形のリンクを張ってほしいといった問題に対してシステムの変更を行う作業は「連続的」な問題です。 既に動いているコードがあり、そのコードに対して変更を行うような作業は、それなりに時間がかかる場合もありますが既存のシステムから予測可能な変更作業です。こうした作業は、継続的に行うことでサービスの品質を上げたり、ユーザーの満足度向上に貢献します。 これに対して、「新しいユニークなブログの仕組みを思いついたので作ってみよう」といったアイデアは「非連続的」あるいは「破壊的」な問題です。こういうアイデアは、待っていてもなかなか生まれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー