eXtreme Programingはお金がかかる? 35
ストーリー by wakatono
まずは部分的な試行から? 部門より
まずは部分的な試行から? 部門より
bravo 曰く、 "XP未経験(知識は書籍のみ)なのですが、ソレを話にもちこんだら、「それは理想だけど、お金がかかる」と言われてしまいました。(答えた方もXP未経験) これは、多数の会社に業務を委託しているため、受け入れテストの予算を確保することが難しいからであるそうです。 こういうときはXPは使うべきでは無いのでしょうか。 また、XPは日本でどう使われているのか参考になる記事とかがあるでしょうか。"
いきなり全体に、というのはムリがあるのだろうけど、試行導入というのは抵抗ないんでは?とか個人的には思う。試行/本格試行までこぎつけた参加者もいるとは思う。もちろん潰えた参加者も。どんな経験をみんなは持っているかな?
XPは私達に何をもたらすのか (スコア:2, 参考になる)
Re:XPは私達に何をもたらすのか (スコア:1)
http://www.mamezou.com/tec/Tips/xpExperienceOnSqueak/index.html
Re:XPは私達に何をもたらすのか (スコア:0)
でも、テストファーストは実施して欲しかったような気が。
実装を何も書かずにテストユニットだけ書いて、コンパイルしてみて
「やっぱり、コンパイル通りませんでしたね。」と始めるところが、
一つの面白さなので、次にはやって欲しいですね。
ここから始めると、既にデバッグ状態なのではじめか
Re:XPは私達に何をもたらすのか (スコア:1)
実体験としてはないのですが・・・。:-D
実践するしないに関わらず、XPの内容は、参考になることが多く、
個人的には、とても興味があります。
XPのテストに関して、これはもうご存知かもしれませんが、
書籍がありますので、紹介しておきます。
http://www.amazon.co.jp/exec/obidos/ASIN/4798101281/249-9477983-0683517
全部のプラクティスを導入する気なのかな? (スコア:2, 参考になる)
2)今また、新規案件でXPでやってくれ、といわれてるんですが。
1)仲の良いチームだったためか、実に高品質のコードができていました。先行開発チームはペアプログラミングまで実践していたようです。
2)うちの上司は「能力ないやつと組みたくねぇ」って渋ってます。こういう意見が出る時点でペアプログラミングは不可能だと思います。
どういうときはXPは使用すべきではない、ってのはあると思いますが、
プラクティスの組み合わせによって解決できるところもあるのでは。
特にペアプログラミングは難しいと思います。
XPのおかげか先行開発者の力量か知りませんが、高品質なコードがいったんできると、途中から他社が参加するときの負荷はかなり減ると思います。
Re:全部のプラクティスを導入する気なのかな? (スコア:1, 参考になる)
1)能力が拮抗していて仲良し。
2)片方がベテラン、片方があまり経験のない新人で、新人のほうに主にプログラム書かせる。
だと、実際に効果が上がるように思います。能力のないやつと組みたくない上司さんは、能力のない新人と組ませましょう。
1年差の中堅を組ませたときには、中途半端な知識でどちら教えるともなくなので、あまりうまく行きませんでした。
お金がかかります (スコア:1)
研究機関とかだったら可能だろうけど、
企業としては、よほど金に糸目をつけないクライアントじゃない限り
XPで開発することは不可能です。
そりゃ、XPで開発できるなら是非やりたいですが。
というか、ソフトウェアに限らず、他の分野でも同じだよね。
産学共同みたいな。
費用対効果 (スコア:1)
結局問題なのは費用対効果の問題なので、そこの部分の検証を誰か事例紹介かなんかでやってくれないもんかなーとか思う今日この頃。
XPについて解説しているところってたいがいプログラマー視点で書かれていて、管理者視点で書かれたものがまったくないような気がする。
そこがイマイチ自己満足的な印象を与えてしまってるんじゃないかなあ?とか思うのだがどーっすか?
お金かかるところってあるかな?(Re:費用対効果) (スコア:3, 興味深い)
コストはさほど,問題にならないと思う。
管理者視点で見た場合。
XPのマネージメント上の最大のメリットは,プロジェクトへの投入人数をかなり柔軟に変えられるようになるところ。でもって,仮に開発フェーズ全体で開発担当者の人数を最適化できたとすれば,10%程度の効率アップが望めるのではないかと。(誰がマネージメントするのか,は棚上げしとくとして)それと長期的には「離職率の低下」も期待できるでしょう。
たぶん,XPにかかるコストより,サービス残業(タダ働き)が常態化している部門との軋轢がボトルネックになると思う。XPで効率が上がったとしても,1円入札とタダ働きにはかなわないからね。
いいかえれば,体育会系のとこは難しいつうところか。たとえて言えば,OOPなんかさくさく出来るような知的レベルが要求されそうってところが,心理的に導入しづらいですね。
斜点是不是先進的先端的鉄道部長的…有信心
Re:お金かかるところってあるかな?(Re:費用対効果) (スコア:1)
離職率の低下は非常に大きなコストダウンに繋がると思います。
あとは、判りやすい数字で実例が出てくれれば…
離職率の低下も重要だけど、 (スコア:1)
になることが一番のメリットかも。
#いつでも首をすげかえられるということではないですよ。
スーパーマンが個人的な理由で離職するようなことが起こっても、
XPの体制ができていればなんとか対応できますからね。
Re:離職率の低下も重要だけど、 (スコア:1)
>「それぞれが置き換え可能な部品」
>になることが一番のメリットかも。
それについては微妙な疑問を感じます。
そのプロジェクトに人を新たに「追加」する場合って、たとえXPでも
言うほどスムーズに行くものなんでしょうか?
受け入れるプロジェクトの側はまぁいいんですが、問題は受け入れられるスタッフのほう。
いかにペアプロだ共同所有だといったところで、彼(女)にとってはそのプロジェクトのメンバーとソースは
今日はじめて触る者/物ばかりなのですから、一般に人がプロジェクトに追加されるときに
生じるとされる(実際生じるよね)参入コストそのものは、 XPでもあんまり減らないのではないでしょうか?
特にソースの週熟度。XPは「その」プロジェクトのソース(それも一部じゃなく全部)に
関わってる度合いの多さを、作業効率というメリットに転換するのを狙った形態に
なってると思うんですが、「その」プロジェクトにとっての新人さんについては、
それはそもそも無いわけで。プロジェクト内部の人の間では高速な接続(笑)が既に構築
されているでしょうが、新人さんには全てがこれから。
以前から言われているように、プロジェクトから人間を削るのは簡単だが追加するのは困難だ、
という法則(?)は、XPでも同じようなものではないかと。
まあ、XP未満なやり方よりは多少は全体的なコストは下がるかも知れませんけど。
余談:
複数のXPプロジェクトが社内で進行しているとき、
複数のプロジェクトは「同じ」部屋で作業/打ち合せ/御菓子食い(笑)を
していいんでしょうか?別部屋にしたほうが良いんでしょうか?
新人は,新しいストーリーから参加します。 (スコア:1)
1.イテレーションの切れ目で新しいストーリの開発から参加する。
2.バギーなコードを引き継ぐことがない。
3.で,XPの原則から見れば,全員,そこから新しいストーリーを開発することになる。条件の違いは,問題領域に対する知識のみ。
個人的な意見ですが,一つのプロジェクトに同じメンバーを半年以上塩漬けにすると,生産性が落ちてくると思います。それと,うまく相殺できれば,よいのではないかと。
ちなみに,抜けたメンバーは隣の机で,別件をしていたりする。
だから,質問はいつでもオッケーだし,変な改造をしてれば,つっこみをいれたりもします。ソースの差分に目を通すだけなら,そんなにコストかかんないし。
それにしても,みんなフルボリュームでXPしてるのかな?
斜点是不是先進的先端的鉄道部長的…有信心
Re:新人は,新しいストーリーから参加します。 (スコア:1)
ちょっと知恵絞って工夫する、ってのが大事ですね。
Re:離職率の低下も重要だけど、 (スコア:0)
Re:離職率の低下も重要だけど、 (スコア:1)
ところでリファクタリングって、「人それぞれの好みによって」、
修正の方向性が色々ちがってても、よいものなんでしょうか?
それって首をかしげます。
だって、(チームメイトの)別々の2人がソースを編集するたびに
コードがアッチ指向になったりコッチ指向になったりを「くりかえす」可能性を
否定できなくなっちゃうわけですよね? 一種の千日手に陥っちゃう。
そういうのって、(コーディング規約か何かを使って)方向性を揃えないんですか?
Re:離職率の低下も重要だけど、 (スコア:1)
/メタファがリファクタリングの欠点をサポートするような
感じですかね?
それぞれのプラクティスには欠点があるので、他のプラクティスで
補完するのがXPの特徴なんでしょうね。
そういう意味では全部のプラクティスを一気に導入するのが
一番安全なXP導入方法かも。
#趣味でプログラミングしている自分には出来ないけど……
Re:離職率の低下も重要だけど、 (スコア:0)
ペアプロでは、XP がうまく行っているときには、アッチ指向のいいところとこっち指向のいいところがうまく混ざります。
Re:離職率の低下も重要だけど、 (スコア:1)
うーん。そりゃそうですが、XPは逆にいえば、部品が欠けると脆くも崩れさる組み木細工みたいなところがありますよね。
自分たちの都合(^^;で、そうそううまく部品を着脱できるか?というと
必ずしもそれは保証されないわけで。
ペアプロを止めたところで、共同所有をを止めなければ
(そして共同所有を止めるのはXPにはかなり無理ですよね?)、
リアルタイムの千日手が時間差攻撃の千日手に変わるだけ、じゃないでしょうか?
今日A君がA指向に書きなおし、明日B君がB指向に書きなおし、明後日A君がA指向に戻し…
余談ですが、共同所有うらやましか。
隣人が書いたソースを見ながら、彼の顔色を伺いつつ、
「ここ困るんだけどなあ、直させてくれないかなあ」
なんて言いだせず(笑)に悶々(?)とする羽目におちいるのって、不毛だ…
つまり、リアルタイム(=ペアプロ)だろうがそうでなかろうが、チームは協力してないとイケナイのでは?
#というかこれはXPに限った話ではないですよね
>端末は2人に一つ
ところでコレはどうにも信じ難い。
思考の衝突と統一については判る。コーディング規約などの下世話(笑)な部分の統一も判る。
が、こんな、人間様の「インターフェース」の部分を
統一することを要求されるってのは、なんか変。
Emacs vs vi、とか、耳きこえない人 vs 目見えない人、とか、どうなのよ?と。
やっぱり、同一(同値じゃないぞ)のソースを、ふたりが「同時に複数のエディタで」
編集できるようにならんと、だめだな。
つまり、1つのEditBufferを複数の人のEmacsとviとが(!)共有できるようにならんと、ね。
エディタのインスタンスという概念が、処理方式と処理対象の二つの部分に分割されてるのね。
カーソルはどっちのエディタ(処理方式)から操作しても同一のカーソルが動くようにする。
まあ、「現状では」そんな道具は無いのだから、今ある道具でのベスト解は
今ある形のペアプロである、ということなのだろうけど。
千日手は,ルール違反。 (スコア:1)
これが上司かコーチ担当に見つかると,
「そのリファクタリング作業に対応するストーリーは,いかなるものか?」
と,小1時間ほど問い詰められることになるでしょうね。まあ,バレないようにやっていただければいいのですが。
共同所有に不安を感じるのは,自分の作ったコードがどのように修正されるかわからないからだと思います。これはバージョン管理ツールで,自分で差分を確認すればいいし,わからないことがあれば,修正担当者に確認すればよろしい。と私なんかだと思うのですが,慣れるまでは,結構むずかしいのかもしれない。
中堅プログラマでチームを組むと,どちらも譲らなくて口論になることがあります。傍で聞いていると,声が甲高くなってるのですぐわかります。この場合,会話が通じていないことが多くて,その時点で介入して,あらためて第3者に対して説明してもらうと解決する問題がほとんどです。
「XPは逆にいえば、部品が欠けると脆くも崩れさる組み木細工みたいなところがありますよね。」
そんなこと無いと思うよ。
XPは必要なプラクティスを,開発チームの成熟度にあわせて無理の無い程度でやれば良いんで,必ずレベル10にする必要は無い。もちろん,フルにやったほうが効果的かもしれませんが,それがプログラマの負担になってしまうようでは本末転倒になる。そこまでは,わかってるんだけど,なかなかうまく行かないものです。ペアプログラミングするのが負担なら,全モジュールをのうち一部だけに適用するとか,作業時間を減らすなどして,調整してみる。
この「ドライビング」と彼らが呼んぶ,実践とフィードバックが,XPのキモなんでは?
斜点是不是先進的先端的鉄道部長的…有信心
Re:離職率の低下も重要だけど、 (スコア:0)
現実には、30分とか1時間とか単位でコードを書く人、となりでレビューしたりアイディアを出す人の役割分担が自然にできますね。コードを書いているときにも常にしゃべっているので疲れます。キーボードを
Re:千日手は,ルール違反。 (スコア:1)
いえ、(とりあえず俺は)共同所有に不安は感じていません。
俺が書いたものは勝手になおして欲しいし、他人が書いたものを勝手になおさせて欲しい。
#え?そりゃもう、www掲示板やスラドと似たようなものですから(爆笑
問題と思ったのはそこではなく、つまりどのように修正されるかではなく、
どのように修正「すべき」かをどう制御するのか?を、です。
千日手が駄目ってのは当然の事でしょうが、ならば明日からAとBは
どんなコードを書けば良いのか?ということです。
A(またはBまたは別のC)の流儀に合わせる、とかでしょうか?
でも、それもなんか変な気がするし。
それとも、そういう問題は発生しないんでしょうか?
でも、シンプルデザインとコーディング規約くらいでは、
各自が「いかように」プログラムを書くか?という自由度を
制約したことにはならないはずです。
#それとも、デザインパターンがそうであるように(^^;、
#「言語ごとに」落しどころが大体きまってしまうものなんでしょうか?
#つまり、言語(が持つ機能や特性)ごとに方向性が違ってくると…
>傍で聞いていると,声が甲高くなってるのですぐわかります。
いいなあ(^^;
喧嘩にすら成らないっていう状態くらい、疲れるものは無いです。
なにも進展しませんから…。
XPの設計に与える制約 (スコア:1)
テストファーストの実装は,インターフェースを定義することを要求しますし,その中身をあとで改修したければ,カプセル化することになります。また,自動化されたテストを実現するために,外部変数を多用するプログラムでは,すぐに壁にぶちあたります。また,実装単位を一日以下に抑えることを要求されるので,クラスは,多くても数個のテストケースで振る舞いを定義される,シンプルなものであることが要求されます。
XPのいかがわしさ,というのは,このようなクラス設計が,テストファーストでサクサクできるかのように説明するところですが,そんなはずは無くて,やはりクラス分析からテストケースを導くまでが,もっとも苦労する作業になるはずです。
だから,コーディングの段階に入ると,もう,あまりこだわらないんだよね。流儀とか実装方法とか,そういうのは。好きにやればよい。
ただ,オブジェクト設計ができない,または無視した場合は,テストのコストばかり増加して,品質や生産性の向上は望めなくなります。わかりやすくいうと,死ぬほどハマります。
よって,オブジェクト指向設計できるときには自由を,出来ないときには不自由と苦労が与えられます。こら,みんな反対するわね。
斜点是不是先進的先端的鉄道部長的…有信心
XPの本質は? (スコア:1)
というのがXPの本質かなぁと思います.
そういう観点だと, ゆとりの法則 [nikkeibp.co.jp]なんかは参考になるかと.
[OT] (スコア:0)
単に AC なだけでそ。
Re:[OT] (スコア:1)
本来まじめにやるとコストがかかる。 (スコア:1)
機能と期間のバランスって、客が発注した段階で合ってるわけは無くて(超人的なSEがいない限り)、でも受注した以上仕上げなきゃなんないから、てきとーなコーディングやテストでお茶を濁して納品することはよくあるはず。コードの保守性とか拡張性とか機能の完全性とか考えずに。
でも XP はコードや成果物の品質を上げることが目的なので、てきとーにごまかすことによって隠れてたコストが表面化する。
ってなとこじゃないかなあ。
逆にコードの保守性や拡張性を犠牲にして開発期間を稼ぐパターンがあって、それを XP プラクティス内に取り込めれば、より XP を導入しやすくなるかも。
プラクティス (スコア:1)
そもそも (スコア:1)
「未経験のPracticeを体験してみよう」
ということなので、最初は全てのPracticeを実践(=体験)すべきでしょう。
世のプロジェクト形態全てに適用可能な方法論なぞ存在しない訳ですから、
ソフトウェア開発の開発者にとってのBestPractice(だと思われる)XPを一度体験してから、
実際の現場の環境に合わせてPracticeの取捨選択を行なうべきです。
体験してもいないものを「必要だ、不要だ」と議論しても始まりません。
#どこで体験するのかは、また別の問題ですが
結局は自分たちの置かれている環境や、存在しうるリスクに応じて
良いと思った手法を組み合わせてみるしかないでしょう。
費用の制約なんて、完全に「環境から派生した政治的リスク」ですから、
部外者がどうこう言っても何の参考にもなりませんよね。
委託って発注だとすると (スコア:0)
この時点でXPで無いような
委託先で XP すべし ! (スコア:0)
XP 一番の難所 (スコア:0)
まあなんというか、無理して XP 使わんでもええやん、という気はするんだが、
なんでここにタレ込む人ってこうも XP 使いたがるの?
もし本当に明確に better な方法なら、それを示せば済むだけなんだし、
計画段階でそれが示せないうちは結局は仕事には使えない、
ってことなんじゃないかな。
Re:XP 一番の難所 (スコア:0)
Re:XP 一番の難所 (スコア:1)
そういう予感がかなりしますね。
上司は現状を当然の有りようだと思い、XPなどという未知のものに
踏み込むのは無理があるし、そもそも理由も無い、と思っているんでしょうけど、
一方のプログラマとかは全然逆で、今我々が置かれている現状こそ無理があると思い、
XPなるものを導入したらこの無理が少しは改善するかも知れない!と、思っているんではないかと。
つまり、「現状から抜け出したい」とどれだけ思っているか?の温度差かも、と思います。
XPって… (スコア:0, 興味深い)