BT

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

寄稿

Topics

地域を選ぶ

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

  • 氾濫するマニフェスト

    定義によると、マニフェストとは、グループの動機、理由、要求を記述した原則や意思の公的宣言のことだ。よく知られているマニフェストのひとつにアジャイルマニフェスト(Agile Manifesto)があるが、その登場以来、マニフェストはかなりまん延している。

  • 「技術的負債」は今でもメタファとして有効か

    LinkedIn Agile Alliance グループでは,今日のグローバルなソフトウェア開発の世界において "技術的負債" が現在もメタファとして有効なのかが議論されている。そしてこの議論が20年を経た今でも,このメタファの有効性に対しての強い支持が存在することを明らかにした。

  • プレゼンテーション: 最悪でないアプリケーションをつくる

    驚きと喜びをもたらすアプリケーションを開発することは、明確に話したり定量化するのが難しい靄の中のゴールのように思われる。しかし、InfoQに投稿された最新のプレゼンテーションの中で、DeliciousライブラリやTap Tap Revenge、Obama氏の2008年のiPhoneアプリケーションなどに取り組んだソフトウェア開発者であるMike Lee氏は、よりよいアプリケーションを構築するためのアルゴリズムを提案した。

  • アジャイルアーキテクチャとハリケーンに共通するもの

    先日 SATURN 2011 で行ったプレゼンテーションで Eric Richardson 氏は,アジャイル環境におけるアーキテクトとハリケーンを予報する気象学者との類似点をいくつか挙げてみせた。どちらもさまざまな予測をしてそれぞれ資料を作成する,多種多様なデータソースを入力として使用する,データ取得のために数々の手法を駆使する,といった具合だ。それならばアーキテクトが気象学者から学べるものは何だろうか?

  • コードは負債、少ない方がいい

    無駄のないリーン製造の過程では、在庫の定義は明確だ。余分な物品、製造中の物品、次の処理を待っている物品が在庫だ。リーンでは在庫を減らすことが重要だ。在庫にはコストがかかるからだ。ソフトウエア開発では要求は在庫と見なされるが、ではコードはどうか。

  • アジャイルテストの描写

    アジャイルコミュニティの何人かのメンバが、ユーザストーリーテストやテーマ全体に関するテストをどう表現するか、いくつかの方式を提案している。

  • Googleの品質保証

    以前はMicrosoftのアーキテクトを務め、現在はGoogleのテストエンジニアリングのディレクターであるJames Whittaker氏は“How to Break Software” シリーズで何冊かの著書がある。氏はGoogleがどのようにテストをしているかについて数回に渡って記事を書いた。Googleではテストは��発と共に行われ、テスターの数は比較的少ない。各製品は多くの人に触れられる前に一連のチャンネルで評価される。

  • 無欠陥システムという聖杯

    無欠陥システムとは言えば聞こえはいいが、本当に実現可能なのか。それとも無理なのか。多くの組織が'無欠陥手法'を取り入れているが、本当に成果があがっているのか。

  • 職人技か、職人技ではないか? Dan North氏がソフトウェア職人マニフェストを否定

    ソフトウェア工学の有名な専門家であるDRW TradingのDan North氏が、最近のブログの投稿において、ソフトウェア職人マニフェストを否定するコメントを述べている。この投稿よって、コミュニティやブログ読者の間からすぐに反応があった。Dan氏によると、2万人の人たちがブログを訪れ、150人がコメントを残している。

  • Facebookはどのようにコードを出荷しているか

    Facebookは今日おそらくもっともホットな企業であり、大きな興味を駆り立て、詮索の対象となっている。高度なセキュリティに守られている中、SkypeのプロダクトマネージャYee Lee氏はFacebookでどのようにコードが出荷されているかの詳細を書いたメモの膨大なコレクションをまとめた。

  • バグを残さずにストーリーを完成させるには

    受け入れられないほど多くのストーリーが"完了"になっているにも関わらず、品質に多くの問題がある場合、どうしたらいいだろうか。

  • いつもコードが悪いのか?

    ソフトウェアプロジェクトの失敗には、様々な理由が挙げられる。プロジェクトが失敗するのは間違った要求のためであったり、コストとスケジュールが超過したためであったりする。単にマネジメントが悪かったと言って失敗するプロジェクトはほんの少しだ。根本原因の分析をした場合に、すべての失敗したプロジェクトは、不完全なコードが主な元凶になるだろうか? いつもそうだろうか?

  • Sonar 2.4: アーキテクチャ制約ルールとMaven 3のサポート

    オープンソースのコード品質管理ツールである Sonar の最新バージョンは、アーキテクチャ制約ルールとカスタムなダッシュボードをサポートする。SonarSourceチームが最近、この製品のバージョン 2.4をリリースした。Maven 3のサポートとSonarプラグインをインストールし、アップグレードするアップデート センターも含まれている。

  • プロダクトオーナーにバックログを優先順位付けさせる方法

    スクラムは優先順位付けされたプロダクトバックログがあることで最も効果的に機能する。バックログを優先順位付けするのはプロダクトオーナーの役割なのだが、プロダクトオーナーが優先順位付けの価値を理解していないためにバックログを優先順位付けしないとき、あなたには何ができるのだろうか?

  • 技術的負債の支払い方

    技術的負債を顧客の価値と直接つなげるのは難しいことがあるが、顧客の価値を納品することは、そもそもアジャイルプロセスが何かということに関係している。では、アジャイル開発環境において、どうやって技術的負債を追跡して、減らすことができるだろうか?

BT