BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Software_Craftsmanship に関するすべてのコンテンツ

  • アジャイルテストで挑戦

    Gerald Ford 国際空港に、駐車料金計算機があり、 Matt Heusser氏は、それにひどいバグがあるのに気がついた。そこで彼は、世界中のテスターに、挑戦状を送った:ParcCalcに存在するバグを見つけて欲しい。それに答えたのは、James Bach氏、Selena Delesie氏など多数いた。

  • SEMAT - ソフトウェア工学の方法論と理論

    SEMATは2009年11月に設立されたもので、ソフトウェア業界があまりに多くの一時的流行と未熟なプラクティスにあふれていると主張している。ここに名を連ねる人々は、ソフトウェア工学を建て直し、今の時代に合ったものにすると約束している。

  • 技術的負債を貨幣化する

    ほとんどのアジャイルチームが,技術的負債(Techninal Dept) は悪いものである,という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子はソフトウェアを維持・拡張するために要する余分な労力,という形で支払われる。アジャイル実践者たちの多くが技術的負債を可能な限り早く返済するよう勧めているが,それを定量的に把握するための貨幣化(monetize)を実現できているアジャイルチームは稀である。

  • 完了に関するマニフェスト

    Alixx Skevington氏は、ディスカッション・スレッドの発端となる完了に関するマニフェスト(Manifesto of Done)という記事を投稿した。氏は記事の中で、チームメンバ間での作業のクオリティに関する取り決めついて語っており、コードを通じてビジネス価値を提供するための取り決めを明確に示している。また、コーディング、規約、有用なコード、ユニット・テスト、テスト・カバレッジなどの分野を取り上げ、クオリティへの取り組みの重要性を強調している。

  • 一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード

    よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。

  • アジャイルと"ユーザ中心設計"の調和

    UX のスペシャリストである Anthony Colfelt 氏がアジャイルについて,それが単独では不完全なものであることを論証するとともに,ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して,詳細かつ興味深い検証を行う。

  • 業界の新しいSOAベストプラクティス

    MITREの新しいホワイトペーパーはSOAの実装に成功するためのさまざまなベストプラクティスと主要な特性について論じている。

  • コメントを書くべきか書かざるべきか

    開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。

  • 継続的デプロイのプラクティス

    継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。

  • 技術的負債は技術的な問題か?

    技術的負債は,リファクタリングやテストで直接アプローチできるような純粋に技術的な問題なのか,あるいはさらに大きな問題の兆候だろうか。TDD の適用はこの問題を解決できるのか,それともより大きな何かを覆い隠してしまうだけなのだろうか。

  • ビジネス価値を見積もる

    従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装する。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。Pascal Van Cauwenberghe 氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。

  • 安定化スプリント - 必要悪か、それとも純粋な無駄か?

    安定化スプリント("Stabilization Sprint")とは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。これはアジャイルに属するものなのか?それとも「完了」すれば充分なのか?

  • ソフトウェアの型 - 公の場で練習することで完璧になる

    アジャイルコミュニティの思慮深きリーダーたちが、ソフトウェアの型 - 体にしみこむまで特定の練習を行う方法 - について語りはじめている。Robert Martin氏はそれを"パフォーマンスアート"と呼んでいる。最近型に関するブログ投稿やサイトが増えている。最新の追加:katas.softwarecraftsmanship.orgでの毎週スクリーンキャストについて追加している。

  • Scrumチームの個々のメンバに対する報償

    最近、LinkedInで、"Scrumチームの個々のメンバに報償や表彰をするべきか"という議論が持ち上がり、賛成と反対の意見が提出され議論は盛り上がった。

  • リファクタリングかリライトか?

    リファクタリングやリライトの目的は、コードの可読性、構造、明確さを改善することでシステムの健全さを改善する点にある。クリーンなコードはメンテナンスもエンハンスも楽だろう。しかし、多くの状況下にて、アジャイルチームはリファクタリングとリライトのどちらを行うかで厳しい選択を迫られる。

BT