InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ
-
あなたがやっているのはテスティングかチェッキングか？
ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。
-
メンテナンス可能な自動受け入れテスト
自動テストはすぐに辻褄が合わなくなってしまい、メンテナンスするのが大変だ。従って企業もテストを自動化したがらない、とDale Emery氏は言う。氏は、最近公開したペーパーにテスト自動化に関わる共通の問題を回避するための実践的な方法を記している。これは、典型的な自動化コードから始めて、より強力でメンテナンスしやすいコードに育てていく方法だ。
-
ソフトウェアの型 - 公の場で練習することで完璧になる
アジャイルコミュニティの思慮深きリーダーたちが、ソフトウェアの型 - 体にしみこむまで特定の練習を行う方法 - について語りはじめている。Robert Martin氏はそれを"パフォーマンスアート"と呼んでいる。最近型に関するブログ投稿やサイトが増えている。最新の追加：katas.softwarecraftsmanship.orgでの毎週スクリーンキャストについて追加している。
-
システム/受け入れテストで日付型と時間型をテストする
単体テストで日付と時間をでテストする方法はよく話題にあがるが、比較的簡単な解決策がある。もっと難しいのは、時間を受け入れ/システムテストでテストすることだ。どんな方法があるだろうか。
-
ClojarsとLeiningenを使ったClojure向け自動ライブラリ依存関係管理
ライブラリと依存関係を管理するのはうんざりする作業だ。Clojarsは Clojureライブラリのための新しいリポジトリで、Ruby GemsとGemcutterに発想を得ている。新しいビルドツールであるLeiningenと一緒にClojarsを使えば、ライブラリ管理の苦痛から解放されるだろう。InfoQはこのClojarsについてAlex Osborne氏に話を聞いた。
-
テスト駆動開発とレガシーコードのトラブル
Alan Baljeu 氏は大規模なレガシー(古い) C++ コードベースへの TDD 利用を試みていた。そこで「可能な限り簡単に (simplest thing that could possibly work)」という原則が原因になって，大きな手戻り作業の発生するトラブルを経験したのだ。
-
ScrumBanは進化か、それとも矛盾か?
カンバンのワークショップやコース、カンファレンスが現れ、アジャイル実践者たちは、リーンから適用されたこの手法がチームに提供するものを調査している。ボトルネックを明らかにすることから、より多くの"動き"を経験し満足するチームまで、魅力的な利点が挙げられている。しかし、指導者たちは、カンバンののんびりしたアプローチが直ちに障害を取り除くというスクラムの呼び掛けに対する「ク���プトナイト」であることを警告する。
-
分散型のふりかえりを改善する
多くの人がふりかえりをアジャイルチームが継続的に改善をする際の最も強力なツールと考える。ふりかえりにより経験が新しいうちに学習や見識を捕らえられ、教訓はチームの作業にリアルタイムに適用される。 Retrospectives Yahoo Group において、各地に散らばったチームがどのようにふりかえりを取り入れられるかが議論された。
-
RubyMine 2.0 - 動的開発へと続く道
第１級の Ruby IDE のひとつが JetBrains 社の決断によって商品化された。バージョン 1.0 のリリースから６ヶ月を過ぎた今日，リリースされる RubyMine 2.0 がそれだ。
-
Bobおじさんが述べるTDDの適用可能性
"TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。
-
アジャイルの本質的な要素
アジャイルを成功させるためには、どのスキルが開発者に必要か、またどのプラクティスが組織に適用できるか、多くの議論が行われてきた。しかし、アジャイルを成功させるために本当に欠かすことのできない重要な心はなんだろうか。Mark Schumann氏はアジャイルの"本質的な要素"としてアジャイルの基底的なテクニックではなく、正確にいえば<em>アジャイルの考え方と管理を共に位置づける事を提唱する。
-
-
革新はどこへ行ったのか?
アジャイルの世界で起きている革新のあり方に疑問を投げかける人たちがいる。繰り返し機能を追加していく開発によって、私たちは革新ではなく古い解決策を使う方向に向かう。そのため、本当に「独創的な」解決策を見つけ出すよりも、すでに知っていることに基づいて開発するのだ。アジャイルプロジェクトに革新をもたらす方法として、研究開発の流れを取り込むことを提案する。
-
アジャイル開発を成功に導く26のヒント
Keith Swenson氏は最近、アジャイル開発のための26のヒントを一覧にまとめた。氏は様々なトピックに関する知見を定期的に収集しているようで、この一覧はアジャイル開発について本当に考慮すべき点を抽出したものになっている。
-
技術的負債を解剖する
"技術的負債"という言葉はWard Cunningham氏によって作られた。この言葉が表すのは、短期的には簡単に実装できるが長期的には大きな悪影響を生み出すような設計上の方法を採用してしまったがために、開発チームが引き受けざるを得ない義務のことだ。技術的負債をどう考えるべきか、どのように分類できるか、についてアジャイルを実践する人々がそれぞれの見解を表明している。