InfoQ ホームページ Software_Craftsmanship に関するすべてのコンテンツ
-
Naresh Jain氏、"Simple Design & Testing"とそれに関するカンファレンスについて語る
「シンプルさ」はアジャイル開発の中心的教義のひとつだ。ソフトウェア設計やテストのやり方に関しては特にそうだ。Naresh Jain氏は2006年以来、世界規模の「オープンスペース」型カンファレンス Simple Design & Testing Conference を開催してきた。このカンファレンスは実践者たちが一同に介して、このトピックについてその限界を押し上げるものだ。InfoQはNaresh氏から、この小規模ながらよく知られたカンファレンスの背景に何があるのか、なぜこれほどまでに彼がこのトピックに情熱を注ぐのか、話を聞いた。
-
アジャイルアーキテクチャ - 矛盾? それとも賢明なパートナーシップ?
アジャイル技術とアーキテクチャに関する考え方の間にある意見の相違について、数多くの解説者たちが話題にしている。 この投稿は、Big Up Front Design (BDUF) と You Aint Gonna Need It (YAGNI)の考え方の間にある緊張状態を調べ、2つのアプローチが好意的なやり方で実際に協力できる方法を探る。
-
アジャイルテストで挑戦
Gerald Ford 国際空港に、駐車料金計算機があり、 Matt Heusser氏は、それにひどいバグがあるのに気がついた。そこで彼は、世界中のテスターに、挑戦状を送った：ParcCalcに存在するバグを見つけて欲しい。それに答えたのは、James Bach氏、Selena Delesie氏など多数いた。
-
SEMAT - ソフトウェア工学の方法論と理論
SEMATは2009年11月に設立されたもので、ソフトウェア業界があまりに多くの一時的流行と未熟なプラクティスにあふれていると主張している。ここに名を連ねる人々は、ソフトウェア工学を建て直し、今の時代に合ったものにすると約束している。
-
技術的負債を貨幣化する
ほとんどのアジャイルチームが，技術的負債(Techninal Dept) は悪いものである，という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子はソフトウェアを維持・拡張するために要する余分な労力，という形で支払われる。アジャイル実践者たちの多くが技術的負債を可能な限り早く返済するよう勧めているが，それを定量的に把握するための貨幣化(monetize)を実現できているアジャイルチームは稀である。
-
完了に関するマニフェスト
Alixx Skevington氏は、ディスカッション・スレッドの発端となる完了に関するマニフェスト(Manifesto of Done)という記事を投稿した。氏は記事の中で、チームメンバ間での作業のクオリティに関する取り決めついて語っており、コードを通じてビジネス価値を提供するための取り決めを明確に示している。また、コーディング、規約、有用なコード、ユニット・テスト、テスト・カバレッジなどの分野を取り上げ、クオリティへの取り組みの重要性を強調している。
-
一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード
よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。
-
アジャイルと"ユーザ中心設計"の調和
UX のスペシャリストである Anthony Colfelt 氏がアジャイルについて，それが単独では不完全なものであることを論証するとともに，ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して，詳細かつ興味深い検証を行う。
-
-
コメントを書くべきか書かざるべきか
開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。
-
継続的デプロイのプラクティス
継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。
-
技術的負債は技術的な問題か？
技術的負債は，リファクタリングやテストで直接アプローチできるような純粋に技術的な問題なのか，あるいはさらに大きな問題の兆候だろうか。TDD の適用はこの問題を解決できるのか，それともより大きな何かを覆い隠してしまうだけなのだろうか。
-
ビジネス価値を見積もる
従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装する。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。Pascal Van Cauwenberghe 氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。
-
安定化スプリント - 必要悪か、それとも純粋な無駄か？
安定化スプリント（"Stabilization Sprint"）とは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。これはアジャイルに属するものなのか？それとも「完了」すれば充分なのか？
-
ソフトウェアの型 - 公の場で練習することで完璧になる
アジャイルコミュニティの思慮深きリーダーたちが、ソフトウェアの型 - 体にしみこむまで特定の練習を行う方法 - について語りはじめている。Robert Martin氏はそれを"パフォーマンスアート"と呼んでいる。最近型に関するブログ投稿やサイトが増えている。最新の追加：katas.softwarecraftsmanship.orgでの毎週スクリーンキャストについて追加している。