パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

eXtreme Programingはお金がかかる?」記事へのコメント

  • なんかXPに対して否定的な意見が全部スコア0ってのはいかがなもんかなーとか思いつつ。
    結局問題なのは費用対効果の問題なので、そこの部分の検証を誰か事例紹介かなんかでやってくれないもんかなーとか思う今日この頃。
    XPについて解説し
    • おやつ代・・・ てのは,冗談として。
      コストはさほど,問題にならないと思う。

      管理者視点で見た場合。
      XPのマネージメント上の最大のメリットは,プロジェクトへの投入人数をかなり柔軟に変えられるようになるところ。でもって,仮に開発フェーズ全体で開発担当者の人数を最適化できたとすれば,10%程度の効率アップが望めるのではないかと。(誰がマネージメントするのか,は棚上げしとくとして)それと長期的には「離職率の低下」も期待できるでしょう。
      たぶん,XPにかかるコストより,サービス残業(タダ働き)が常態化している部門との軋轢がボトルネックになると思う。XPで効率が上がったとしても,1円入札とタダ働きにはかなわないからね。

      いいかえれば,体育会系のとこは難しいつうところか。たとえて言えば,OOPなんかさくさく出来るような知的レベルが要求されそうってところが,心理的に導入しづらいですね。
      --
      斜点是不是先進的先端的鉄道部長的…有信心
      親コメント
      • 人を雇う費用っていうのは、明確に見えない部分がありつつかなり巨大なものになりますから、
        離職率の低下は非常に大きなコストダウンに繋がると思います。

        あとは、判りやすい数字で実例が出てくれれば…
        親コメント
      • 管理職として見た場合、「それぞれが置き換え可能な部品」
        になることが一番のメリットかも。
        #いつでも首をすげかえられるということではないですよ。
        スーパーマンが個人的な理由で離職するようなことが起こっても、
        XPの体制ができていればなんとか対応できますからね。

        親コメント
        • >>プロジェクトへの投入人数をかなり柔軟に変えられるようになるところ。
          >「それぞれが置き換え可能な部品」
          >になることが一番のメリットかも。

          それについては微妙な疑問を感じます。

          そのプロジェクトに人を新たに「追加」する場合って、たとえXPでも
          言うほどスムーズに行くものなんでしょうか?

          受け入れるプロジェクトの側はまぁいいんですが、問題は受け入れられるスタッフのほう。
          いかにペアプロだ共同所有だといったところで、彼(女)にとってはそのプロジェクトのメンバーとソースは
          今日はじめて触る者/物ばかりなのですから、一般に人がプロジェクトに追加されるときに
          生じるとされる(実際生じるよね)参入コストそのものは、 XPでもあんまり減らないのではないでしょうか?

          特にソースの週熟度。XPは「その」プロジェクトのソース(それも一部じゃなく全部)に
          関わってる度合いの多さを、作業効率というメリットに転換するのを狙った形態に
          なってると思うんですが、「その」プロジェクトにとっての新人さんについては、
          それはそもそも無いわけで。プロジェクト内部の人の間では高速な接続(笑)が既に構築
          されているでしょうが、新人さんには全てがこれから。

          以前から言われているように、プロジェクトから人間を削るのは簡単だが追加するのは困難だ、
          という法則(?)は、XPでも同じようなものではないかと。

          まあ、XP未満なやり方よりは多少は全体的なコストは下がるかも知れませんけど。

          余談:
          複数のXPプロジェクトが社内で進行しているとき、
          複数のプロジェクトは「同じ」部屋で作業/打ち合せ/御菓子食い(笑)を
          していいんでしょうか?別部屋にしたほうが良いんでしょうか?
          親コメント
          •  ポイントが,いくつかあって。

            1.イテレーションの切れ目で新しいストーリの開発から参加する。
            2.バギーなコードを引き継ぐことがない。
            3.で,XPの原則から見れば,全員,そこから新しいストーリーを開発することになる。条件の違いは,問題領域に対する知識のみ。

             個人的な意見ですが,一つのプロジェクトに同じメンバーを半年以上塩漬けにすると,生産性が落ちてくると思います。それと,うまく相殺できれば,よいのではないかと。

             ちなみに,抜けたメンバーは隣の机で,別件をしていたりする。
             だから,質問はいつでもオッケーだし,変な改造をしてれば,つっこみをいれたりもします。ソースの差分に目を通すだけなら,そんなにコストかかんないし。

             それにしても,みんなフルボリュームでXPしてるのかな?
            --
            斜点是不是先進的先端的鉄道部長的…有信心
            親コメント
          • XP だと、前の人が抜けてもユニットテストが残っているので、新しい人が改造してもユニットテストが通る限り大丈夫という保険があります。不用意に手をつけられないということはないわけで、早めにコードに
            • >ファクタリングかけて担当分のすべのコードを自分好みに書き換えても、XP的には、ユニットテストさえ通れば OK です。

              ところでリファクタリングって、「人それぞれの好みによって」、
              修正の方向性が色々ちがってても、よいものなんでしょうか?

              それって首をかしげます。
              だって、(チームメイトの)別々の2人がソースを編集するたびに
              コードがアッチ指向になったりコッチ指向になったりを「くりかえす」可能性を
              否定できなくなっちゃうわけですよね? 一種の千日手に陥っちゃう。

              そういうのって、(コーディング規約か何かを使って)方向性を揃えないんですか?
              親コメント
              • そういうのって、(コーディング規約か何かを使って)方向性を揃えないんですか?
                ですね。シンプルな設計/コーディング規約/共同所有
                /メタファがリファクタリングの欠点をサポートするような
                感じですかね?

                それぞれのプラクティスには欠点があるので、他のプラクティスで
                補完するのがXPの特徴なんでしょうね。
                そういう意味では全部のプラクティスを一気に導入するのが
                一番安全なXP導入方法かも。
                #趣味でプログラミングしている自分には出来ないけど……
                親コメント
              • だって、(チームメイトの)別々の2人がソースを編集するたびに コードがアッチ指向になったりコッチ指向になったりを「くりかえす」可能性を 否定できなくなっちゃうわけですよね?

                ペアプロでは、XP がうまく行っているときには、アッチ指向のいいところとこっち指向のいいところがうまく混ざります。

              • >時々一人で仕事させるときもあります。その場、その場の判断でいいんじゃないでしょうか。別に XP でやることが目的じゃないので

                うーん。そりゃそうですが、XPは逆にいえば、部品が欠けると脆くも崩れさる組み木細工みたいなところがありますよね。
                自分たちの都合(^^;で、そうそううまく部品を着脱できるか?というと
                必ずしもそれは保証されないわけで。

                ペアプロを止めたところで、共同所有をを止めなければ
                (そして共同所有を止めるのはXPにはかなり無理ですよね?)、
                リアルタイムの千日手が時間差攻撃の千日手に変わるだけ、じゃないでしょうか?
                今日A君がA指向に書きなおし、明日B君がB指向に書きなおし、明後日A君がA指向に戻し…

                余談ですが、共同所有うらやましか。
                隣人が書いたソースを見ながら、彼の顔色を伺いつつ、
                「ここ困るんだけどなあ、直させてくれないかなあ」
                なんて言いだせず(笑)に悶々(?)とする羽目におちいるのって、不毛だ…

                つまり、リアルタイム(=ペアプロ)だろうがそうでなかろうが、チームは協力してないとイケナイのでは?
                #というかこれはXPに限った話ではないですよね

                >端末は2人に一つ

                ところでコレはどうにも信じ難い。
                思考の衝突と統一については判る。コーディング規約などの下世話(笑)な部分の統一も判る。
                が、こんな、人間様の「インターフェース」の部分を
                統一することを要求されるってのは、なんか変。
                Emacs vs vi、とか、耳きこえない人 vs 目見えない人、とか、どうなのよ?と。

                やっぱり、同一(同値じゃないぞ)のソースを、ふたりが「同時に複数のエディタで」
                編集できるようにならんと、だめだな。
                つまり、1つのEditBufferを複数の人のEmacsとviとが(!)共有できるようにならんと、ね。
                エディタのインスタンスという概念が、処理方式と処理対象の二つの部分に分割されてるのね。
                カーソルはどっちのエディタ(処理方式)から操作しても同一のカーソルが動くようにする。

                まあ、「現状では」そんな道具は無いのだから、今ある道具でのベスト解は
                今ある形のペアプロである、ということなのだろうけど。
                親コメント
              • 「今日A君がA指向に書きなおし、明日B君がB指向に書きなおし、明後日A君がA指向に戻し… 」

                これが上司かコーチ担当に見つかると,
                「そのリファクタリング作業に対応するストーリーは,いかなるものか?」
                と,小1時間ほど問い詰められることになるでしょうね。まあ,バレないようにやっていただければいいのですが。

                共同所有に不安を感じるのは,自分の作ったコードがどのように修正されるかわからないからだと思います。これはバージョン管理ツールで,自分で差分を確認すればいいし,わからないことがあれば,修正担当者に確認すればよろしい。と私なんかだと思うのですが,慣れるまでは,結構むずかしいのかもしれない。

                中堅プログラマでチームを組むと,どちらも譲らなくて口論になることがあります。傍で聞いていると,声が甲高くなってるのですぐわかります。この場合,会話が通じていないことが多くて,その時点で介入して,あらためて第3者に対して説明してもらうと解決する問題がほとんどです。

                「XPは逆にいえば、部品が欠けると脆くも崩れさる組み木細工みたいなところがありますよね。」
                そんなこと無いと思うよ。
                XPは必要なプラクティスを,開発チームの成熟度にあわせて無理の無い程度でやれば良いんで,必ずレベル10にする必要は無い。もちろん,フルにやったほうが効果的かもしれませんが,それがプログラマの負担になってしまうようでは本末転倒になる。そこまでは,わかってるんだけど,なかなかうまく行かないものです。ペアプログラミングするのが負担なら,全モジュールをのうち一部だけに適用するとか,作業時間を減らすなどして,調整してみる。
                この「ドライビング」と彼らが呼んぶ,実践とフィードバックが,XPのキモなんでは?
                --
                斜点是不是先進的先端的鉄道部長的…有信心
                親コメント
              • >端末は2人に一つ
                ところでコレはどうにも信じ難い。
                思考の衝突と統一については判る。コーディング規約などの下世話(笑)な部分の統一も判る。
                が、こんな、人間様の「インターフェース」の部分を 統一することを要求されるってのは、なんか変。
                Emacs vs vi、とか、耳きこえない人 vs 目見えない人、とか、どうなのよ?と。

                現実には、30分とか1時間とか単位でコードを書く人、となりでレビューしたりアイディアを出す人の役割分担が自然にできますね。コードを書いているときにも常にしゃべっているので疲れます。キーボードを

              • by G7 (3009) on 2002年02月01日 2時01分 (#59184)
                >共同所有に不安を感じるのは,自分の作ったコードがどのように修正されるかわからないからだと思います。

                いえ、(とりあえず俺は)共同所有に不安は感じていません。
                俺が書いたものは勝手になおして欲しいし、他人が書いたものを勝手になおさせて欲しい。

                #え?そりゃもう、www掲示板やスラドと似たようなものですから(爆笑

                問題と思ったのはそこではなく、つまりどのように修正されるかではなく、
                どのように修正「すべき」かをどう制御するのか?を、です。
                千日手が駄目ってのは当然の事でしょうが、ならば明日からAとBは
                どんなコードを書けば良いのか?ということです。

                A(またはBまたは別のC)の流儀に合わせる、とかでしょうか?
                でも、それもなんか変な気がするし。

                それとも、そういう問題は発生しないんでしょうか?
                でも、シンプルデザインとコーディング規約くらいでは、
                各自が「いかように」プログラムを書くか?という自由度を
                制約したことにはならないはずです。

                #それとも、デザインパターンがそうであるように(^^;、
                #「言語ごとに」落しどころが大体きまってしまうものなんでしょうか?
                #つまり、言語(が持つ機能や特性)ごとに方向性が違ってくると…

                >傍で聞いていると,声が甲高くなってるのですぐわかります。

                いいなあ(^^;
                喧嘩にすら成らないっていう状態くらい、疲れるものは無いです。
                なにも進展しませんから…。
                親コメント
              • XPでの設計に与える制約は,オブジェクト指向設計されていることだけ要求されることになると思います。あとは自由です。

                テストファーストの実装は,インターフェースを定義することを要求しますし,その中身をあとで改修したければ,カプセル化することになります。また,自動化されたテストを実現するために,外部変数を多用するプログラムでは,すぐに壁にぶちあたります。また,実装単位を一日以下に抑えることを要求されるので,クラスは,多くても数個のテストケースで振る舞いを定義される,シンプルなものであることが要求されます。

                XPのいかがわしさ,というのは,このようなクラス設計が,テストファーストでサクサクできるかのように説明するところですが,そんなはずは無くて,やはりクラス分析からテストケースを導くまでが,もっとも苦労する作業になるはずです。
                だから,コーディングの段階に入ると,もう,あまりこだわらないんだよね。流儀とか実装方法とか,そういうのは。好きにやればよい。

                ただ,オブジェクト設計ができない,または無視した場合は,テストのコストばかり増加して,品質や生産性の向上は望めなくなります。わかりやすくいうと,死ぬほどハマります。

                よって,オブジェクト指向設計できるときには自由を,出来ないときには不自由と苦労が与えられます。こら,みんな反対するわね。
                --
                斜点是不是先進的先端的鉄道部長的…有信心
                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...