BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アジャイル技術 に関するすべてのコンテンツ

  • Eli Goldratt 博士の遺したもの

    2011 年 6 月 11 日,TOC (Theory of Constraints,制約理論) の提唱者である Eli Goldratt 博士が亡くなった。博士の最初の,そして最も有名な著書が,TOC を定義した "ザ・ゴール (The Goal)" だ。博士の遺したものは,我々が日々実践する技術に具体化されたそのアイデアを通じて,間接的な影響をアジャイルに与え続けるだろう。

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

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

  • アジャイル開発での価値に基づいたアーキテクチャの決定

    eBayのチーフアーキテクトであるJeromy Carriere氏がSATURN 2011カンファレンスでアーキテクチャインプラクティス賞を受賞した。氏は、アジャイルチームによる設計上の一貫した意思決定を維持しつつ、アーキテクチャの変化の経済的な責任とオーナシップによって自主性を基礎付ける方法について話した。

  • 満足感と自己組織化したチーム

    自己組織化したチームで、満足感はポジティブにもネガティブにも、成果に影響を与えるのだろうか? Mark Levison氏は心理学における研究成果について紹介した。これによると、選択とコントロールは交換可能だという。「もし権限がなければ、選択する権利があることを強く要求しますが、もし選択する権利があれば、同等の権限を求めないのです」これは自己組織化の成功と痛みを説明するものだろうか?

  • 確かに失敗した。で、次は?

    失敗は怒りと失望、批判合戦を生み出すものだ。しかし、失敗から何も学ばなかったらその失敗は完全に無駄になる。アジャイルチームはどうやって失敗を価値あるものにしているのか。

  • PowerMockup、簡易モックアップのための新しいツール

    高品質なユーザ体験を実現するために、アジャイルチームはコーディング前に(例えばスプリント/イテレーション計画前に)、さまざまな粒度でモックアップを作って、適切なデザインを絞り込むということをよくやる。PowerMockupは簡易モックアップを作りたい人向けの新製品で、なじみのあるPowerPointを利用したものだ。

  • アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるか

    アーンドバリュー・マネージメント(EVM) の価値と,それをアジャイルに統合することに関して,激しい議論が巻き起こっている。アジャイルが EVM を必要とするほど大規模な IT プロジェクトに進出し始めたことがその原因だ。意見はさまざまだが,単にアジャイルが EVM に適用可能であるというだけではなく,アジャイルを適用した EVM がそうでないものより優れている,という考えもある。

  • 過去から学ぶことは必要か

    著述家でコンサルタントでもある Gerald M. Weinberg 氏は,コンピューティングビジネスに半世紀以上も積極的に関わり続けている人物だ。氏は,新しいテクノロジに係わるハイプサイクルが不可避と思えること,情報産業が過去のハイブサイクルからほとんど何も学んでいないこと,についての懸念を表した。同じように Elisabeth Hendrickson 氏も先日,"偽アジャイル (fake agile)" の影響についてブログした。両氏とも,改善のためのアドバイスも合わせて提供している。

  • チームから信頼を得るには

    Wanjun Zhuang氏がLinkedInのアジャイルコーチンググループのメンバに新しいアジャイルチームから信頼を得ることについて質問している。氏はメンバからマネージャだと思われていて気持ちを開いてくれない。評価者だと思っているのだ。この質問にはたくさんの助言が寄せられた。どれもそソフトウエア開発チームに役に立ちそうだ。

  • JenkinsはHudsonとの和解に興味なし

    最近のJenkins会議で、Hudsonプロジェクトとの和解が可能かどうか(HudsonのEclipse.orgに移る提案が出された後に)、そのためには何が必要か、という議論がなされた。話された要求は、EclipseあるいはApacheファンデーションのいずれに移るにも障害であり、よってHudsonとの和解も難しい。

  • TeamCity 6.5: Git および Mercurial との統合を拡張し,.NET 対応を改良

    JetBrains は先日 TeamCity 6.5 のリリースを発表した。外観の改められた今回のリリースには Git および Mercurial との統合の改良に加えて,特に .NET 開発者向けにいくつかの改良点が盛り込まれている。さらに無償版の Professional Edition のユーザ数が無制限となった。

  • クラウドにおけるテスト

    クラウドテスティング(Cloud testing)はクラウドの力を利用するテストの手法である。これは多くの場合、テストにかかる時間を削減するか、アプリケーションの現実世界でのトラフィックをシミュレートする目的で行われる。加えて、高いトラフィックを持つウェブアプリケーションのスケーラビリティ要求を満たすためにテストも同様にスケールする必要がある。

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

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

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

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

  • 継続的開発:言うが易し行うは難し

    継続的開発は書いたコードはすぐにリリースするという考えとしてアジャイルやリーンの技術として語られることが多い。この方法には明確な利点がたくさんある。例えば、開発サイクルを短くすることで素早くバグ修正や新機能の市場投入ができる点だ。しかし、これは言うほど簡単だろうか。

BT