BT

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

寄稿

Topics

地域を選ぶ

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

  • 氾濫するマニフェスト

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

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

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

  • スクラムアライアンスがCSP認定を強化、ベータプログラムを発表

    スクラムアライアンスは6月のニュースレターで認定スクラムプロフェッショナル(CSP)の指定を強化して"認証評価に必要な仕組みとテストを世界的な標準に合わせた認証プログラム"にする計画を発表した。CSPの認定は実際の仕事でアジャイルを実践した経験が必要なので、スクラムアライアンスの認定スクラムマスタ(CSM)よりも上位の認定として位置づけられている。ベータプログラムの詳細は次のスクラムアライアンスニュースレターで確認できる。

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

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

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

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

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

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

  • JanovaとEdgeCaseが7ヶ月間でテストツールを作成

    ソフトウエアの専門会社であるEdgeCaseはエンタープライズアーキテクチャの専門とする会社であるJanovaを支援し、ウェブベースの自動テストツールを開発した。このツールはクラウドベースのアプリケーションで、自然な英語でテスト用のバッチ処理を記述できる。実装にはRubyを利用する。

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

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

  • 商業的関心が失敗を隠す

    Philippe Kruchten氏がアジャイルについて次ように述べている。"アジャイルの運動はティーンエイジャーに似ています。自己中心的で、鏡ばかり見ていつも外見を気にしていて、批判は受け付ず..."。氏は12の口に出しにくいことを列挙する。意図的に避けられている言いにくい問題だ。第一に挙げられているのは、商業的関心が失敗を隠してしまうことだ。

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

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

  • ソフトウェアアーキテクチャに関する新刊

    ソフトウェアアーキテクチャはソフトウェア技術者にとって重要なトピックのひとつである。ソフトウェア開発プロジェクトの失敗の大部分が不適切な設計を原因とするものだからだ。だからアーキテクチャ上の問題の理論と実際について学ぶのは重要なことだ。最近出版された,あるいは近々出版予定の興味深い新書が大いに役立つだろう。

  • チームアカウンタビリティを問う

    Glen Alleman 氏が自分たちの用いているビジネス管理プロセスについて説明し,個人が責任を負わない,チームアカウンタビリティという考え方に異議を唱える。氏はチームが責任を負うことの効果性に疑問を呈し,単に成功ないし失敗の責任を負う個人が存在しないだけなのではないか,と問いかけている。

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

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

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

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

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

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

BT