BT

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

寄稿

Topics

地域を選ぶ

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

  • FIT/FitnesseのためのFixture Gallery 2.0リリース

    Fixture Galleryは、FIT/Fitnesseのフィクスチャの公開された手引書であり、Gojko Adzic氏によってバージョン2.0が最近リリースされている。ギャラリーのこのバージョンで追加されたのは、Pythonでウェブのプログラムを作成する人たちのためのPythonのコードサンプルである。

  • ROIの最も高いアジャイルプラクティス

    投資利益率は、投資額に対して、その投資で得られた(あるいは失った)金額として定義される。予想されるROIは、ソフトウェア開発の特定の技術を採用する上で、非常に重要な決定的要因である。IBM developerWorksの記事で、Roger N.Dunn氏はアジャイルの採用を決める上で助けとなる手段の点から、アジリティを調べている。

  • 議論: リーン開発ツールで大学生の技術力は向上するだろうか?

    Greg Wilson氏が、最近「アジャイル自動機能テストツール」コミュニティに挑戦した。それは、大学新卒者の「製品品質コード」を納品する能力を改善しようとする彼の努力を支援するようにというものであった。Wilson氏が提案した方法では、プロフェッショナルが使うツールの簡易バージョンを最初に提供する必要がある。それらのツールは、コンピュータサイエンスを専攻する平均的な大学生でも使いこなすことができるものだ。

  • あなたのアーキテクチャはSOAやBPMにフォーカスすべきか?

    SOA は、バズワード(もったいぶっていて、意味があまりない単語)のタグクラウドにおける大物だった。しかし、BPMはどんどんその存在感を増してきている。「IT投資から利益を得るためには、プロセスを飼いならす必要がある」と組織が気づくにつれ、BPMの重要性は高まり、IT内外での意識共有が広まっている。

  • バリューストリームの妨げとなるもの

    スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープについて、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。

  • Interview: Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。

    JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。

  • Article: 高い生産性を生み出すソフトウェア開発の秘伝

    何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。

  • Article: コーディング標準のためのガバナンスの自動化を実現する

    Mark Figley氏がコーディング標準とベストプラクティスの実施をビルドプロセスの一部として自動化する方法について説明しています。

  • FitNesseを利用するための新たなクイックリファレンス「Fixture Gallery」

    Gojko Adzicは先ごろ、新たに開発者コミュニティにとって役に立つFitNesseリソースの、最初のバージョンをリリースした。Fixture GalleryはGojkoによるオープンなドキュメントで、FIT/FitNesseテストのための新たなクックブックだ。それによって開発者は、FITフレームワークを利用するアジャイルな受け入れテストのために、最も重要なフィクスチャのタイプやコンセプトを素早く概観することができる。

  • Article: AgileEVM: 製品ライフサイクル全体で費用対効果を計測する

    AgileEVMは、出来高管理の指標を使用した基準計画と比較し、コスト、スケジュール及びスコープの実際の値を計測する伝統的なプロジェクト管理手法を適応したプロジェクト管理手法です。

  • 循環的複雑度に関する再確認

    Enerjyは数万にもおよぶソースファイルを研究し、最適な循環的複雑度は11で、その場合のエラーの潜在率は28%であると発表した。実際、それ以下の複雑度であった場合、エラーの可能性が高まる。メソッドの複雑化を検討するときなのであろうか?

  • ビジネスバリューを理解する

    最近、Joe Little氏は、もっともよく利用されるが同時に広く誤解されてもいる、アジャイルのコアとなる概念「ビジネスバリュー」に関する自分の考えを投稿した。

  • LINQ Framework Designのガイドライン

    LINQが完成版となってリリースされたので、次はその使用方法について考える番である。Keith Farmer氏はLINQを使用することでサブクラスが削除できるとまで言及している。しかしそちらに進む前に、Microsoftからの公式ガイドを見てみよう。

  • デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー

    デザインとコードレビューに関する興味深い記事でKirk Knoernschild氏は、レビューを行うということは��ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。

  • Article: 3つのM - リーンの3要素

    リーン主義をソフトウェア開発に適用することについての議論では、主にムダ(無駄:Muda)なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ(無理:Muri)とムラ(ばらつき:Mura)を削除することも目指しています。

BT