ところでコレはどうにも信じ難い。
思考の衝突と統一については判る。コーディング規約などの下世話(笑)な部分の統一も判る。
が、こんな、人間様の「インターフェース」の部分を
統一することを要求されるってのは、なんか変。
Emacs vs vi、とか、耳きこえない人 vs 目見えない人、とか、どうなのよ?と。
>端末は2人に一つ
ところでコレはどうにも信じ難い。
思考の衝突と統一については判る。コーディング規約などの下世話(笑)な部分の統一も判る。
が、こんな、人間様の「インターフェース」の部分を
統一することを要求されるってのは、なんか変。
Emacs vs vi、とか、耳きこえない人 vs 目見えない人、とか、どうなのよ?と。
費用対効果 (スコア:1)
結局問題なのは費用対効果の問題なので、そこの部分の検証を誰か事例紹介かなんかでやってくれないもんかなーとか思う今日この頃。
XPについて解説し
お金かかるところってあるかな?(Re:費用対効果) (スコア:3, 興味深い)
コストはさほど,問題にならないと思う。
管理者視点で見た場合。
XPのマネージメント上の最大のメリットは,プロジェクトへの投入人数をかなり柔軟に変えられるようになるところ。でもって,仮に開発フェーズ全体で開発担当者の人数を最適化できたとすれば,10%程度の効率アップが望めるのではないかと。(誰がマネージメントするのか,は棚上げしとくとして)それと長期的には「離職率の低
斜点是不是先進的先端的鉄道部長的…有信心
離職率の低下も重要だけど、 (スコア: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のいかがわしさ,というのは,このようなクラス設計が,テストファーストでサクサクできるかのように説明するところですが,そんなはずは無くて,やはりクラス分析からテストケースを導くまでが,もっとも苦労する作業になるはずです。
だから,コーディングの段階に入ると,もう,あまりこだわらないんだよね。流儀とか実装方法とか,そういうのは。好きにやればよい。
ただ,オブジェクト設計ができない,または無視した場合は,テストのコストばかり増加して,品質や生産性の向上は望めなくなります。わかりやすくいうと,死ぬほどハマります。
よって,オブジェクト指向設計できるときには自由を,出来ないときには不自由と苦労が与えられます。こら,みんな反対するわね。
斜点是不是先進的先端的鉄道部長的…有信心