パスワードを忘れた? アカウント作成
1405 story
プログラミング

みんなExtremeプログラミングしている? 60

ストーリー by wakatono
決してWindowsXP上のプログラミングではない 部門より

takusi 曰く,"最近、話題のExtremeプログラミング、導入してますか?かつてのソフトウェア開発というものは、codingに入る前にいかにバグのない設計をしているかがkeyになるといわれてきた。しかし、XPではその考えの大胆な変革を求める。XPでは、変化ヲ抱擁セヨという重要なキーワードがあり、これの意味するところは、きちんとした設計をするのではなく、あとからいかに柔軟に設計を変えるにはどうすれば良いのかという視点である。 [eXtreme programming FAQ]"

「変化ヲ抱擁セヨ」、この短い言葉に集約された意味は大きい。今更XPについてオレがどうこういうことはないが、XP(に限らないが)を誤解している人は多いだろう。OOPもそうだが、単に導入するだけでソフトウェア設計/製造シーンが変わるような銀の弾丸も魔法の杖もないのだ。さて、このあたりのことも含め、プロセス改善とかで周囲への説明に苦労している方々はどのくらいいらっしゃるのだろうか?そしてどのくらいXPをしたいのか?もしくはしているのか?その心の声を聞かせてくれ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2001年10月30日 5時08分 (#33873)
    XPでない、今までのプログラミングは、要するにソフトウエアを「工業製品」と考えるやりかただよね。製品として他人の手に渡ったその時点で、よほどのことがない限り、デバッグなんかできない環境になってしまう。たとえば、炊飯器の中のマイコン用のプログラムはXPでは行けないことは明らか。オンラインで手軽にバグフィックス/Updateできる、という環境になるまでは。

    対して、ネット上のWebなどで行われるサービスのプログラムの場合は、XPは有効だと思うし、大方のサービスは、実際に動かして多くのユーザに使ってもらわないと、どうしてもわからないところが出てくるから、仕方なくXPせざるを得ない、という側面もなきにしもあらず。ましてやネット上のサービスは、サービス提供に至るまでのスピードが勝負ですから、XPはとても有効と思います。

    要するに、ケースバイケースではないかと思います。

  • by perla (1645) on 2001年10月30日 7時11分 (#33889)
    だけは抵抗があります。あとのプラクティスは「なるほど納得」という感じで理にかなっていると思うけど。
    設計段階では2人いてもいいけど、プログラミング中に横に人がいて集中できそうにない。
    以前職場の上司に話したら、「この人手が足らないときにプログラム1本に何で2人も必要なんだ」だそうです。
    実際の現場で、特に大規模な開発になると、周り(特に上司)を納得させることが難しそうですね。
  • 部分導入してます。すぐに効果がでたのは単体テストです。 メインが Java なので JUnit を使いましたが、テストバカになりました。 冗談でなく、本当に、好き好んで、喜々として、 テストのコードばかり書くようになります。 更に症状が進むと、単体テストし易い設計をするようにまでなります。
    • by nitonito (2431) on 2001年10月30日 10時02分 (#33924)
      ほかの言語用の単体テストフレームワークは、こちらから。

      ところで、GNUにはXPが話題になるずっと前から、DejaGnuってのがあったと思うのだけど、使っている人っています?
      親コメント
    • 激しく同意。

      僕も、XPはUnitTestから導入してみました。
      効果は絶大です。自動テストなのでソースの改善が自由に出来ますからね。
      動いてるものは汚くてもいぢるな!」
      という近視眼的な考えにとらわれる必要がなくなります。

      でも、GUIやDB周りのテスト自動化は難しいッス。

      --

      --- (´-`)。oO(平和な日常は私を鈍くする) ---
      親コメント
  • by seldon (5637) on 2001年10月30日 16時43分 (#34075)
    私が大学生だった頃(10数年前)に、ラピッドプロトタイピングという手法が提唱されていた。
    これは、まず設計を行う代わりに早い時期からプロトタイプという形で目に見える(実際に動作する)ものを作って、要求仕様と設計、プロダクトの擦り合せを行うという方法論で、XPで言う所の
    • 計画ゲーム(The Planning Game)
    • 小規模リリース(Small Releases)
    • 比喩(Metaphor)
    • オンサイト顧客(On-Site Customer)
    に該当するようなものでしょう。
    比喩というのが、言葉上の比喩ではなく、実際に動くコードだという所が違いますが...

    また、

    • 小規模リリース(Small Releases)
    • ペアプログラミング(Pair Programming)
    • 共同所有権(Collective Ownership)
    • 継続的インテグレーション(Continuous Integration)
    • オンサイト顧客(On-Site Customer)
    というのは、Linuxなどのオープン開発で取られている手法ですね。 特にCVSでリポジトリを公開してるような場合が最も近いかな?
    オープンソースの開発ではペアプログラミングどころか、数十人、数百人という単位で一緒にプログラミングしてるようなもんだし。

    という事で、XPは「新しい手法/考え方」という程の事もないような...
    もちろん、これらを体系的にまとめたという意味では意義があると思うし、この方法論自体は良いと思う。

  • by keast (761) on 2001年10月30日 9時08分 (#33905)
    日経コンピューターで、XPの紹介があった際に、
     あぁこれはいい。「仕事が面白くなりそう」と思い上司に相談

    「人件費が二倍かかるじゃん。」 と一蹴されてしまった。
  • by Anonymous Coward on 2001年10月30日 10時38分 (#33942)
    ??不思議な気がします。 日本でペアプログラミング以外のことが出来るのですか? アメリカだと完全に個人毎にパーティションが分かれ、 他の人が何やってるのか判らない状況でコーディングしますよね。 だから、スペースをオープンにしてペアプログラミングと 声を大にして言わないと実行できない。 それに対し、日本では机並べて開発しますから、 判らない部分があったら直ぐ隣の人、 関連する部分を作ってる人のところへ行きますし、 おせっかいなオヤジ(オレのこと?)が 作ってるコードに茶々入れにくるし。 まぁ、時間中すべてペアでやってるわけでもないでしょうけど、 瞬間々々ではペアでやってるのでは?
    • by HashiZ (4465) on 2001年10月30日 14時22分 (#34020)
      デバッグの際に、何人か集まってデバッガでコードを追いかけてみるという光景はときどきみかけますね。そうゆう意味では確かに誰しも部分的には経験のあることなのかも。

      これをコーディングのすべてのフェイズで extreame に実行するのがペアプログラミングというだけで。
      親コメント
    • by G7 (3009) on 2001年10月30日 21時58分 (#34192)
      >日本でペアプログラミング以外のことが出来るのですか?

      日本であっても(というか、だからこそ?)、たとえば「私語厳禁」とか言われたらオシマイなわけです。

      以前居た職場が、ある意味でそれに近い面が有ったんで、泣きました(T_T)
      ええ。開発者間の"情報のやり取り"が少ないため、志気も品質も(以下略

      そういう閉塞状況に対して公然とNO!を言ってくれるという意味では、XPはナイスだと感じました。
      まだやったことは無いですけど、さぞHappyだろうな。
      親コメント
  • XPというかユニットテストを非常に重視してます。
    テストのおかげで自分で書いたコードを信用できるようになって楽になります。(特にデバッグ時の精神衛生上いいと思う)
    ただテストコードを書くことに熱中して本当の目的が果たせなかったりします。(本当のXPだったらペアプログラミングが解決してくれるのかな?)
    一番よく好きな言語はC++ですが、CppUnitを使ってると、JUnitが羨ましくなります。
  • by Anonymous Coward on 2001年10月30日 10時56分 (#33953)
    Web上のシステムは確かにXPと親和性高いと思います。
    特に、PerlでCGI作った日にゃ、
    ・毎日がリリース
    ・他人のソースも見れちゃうから気に入らなければ
     勝手に修正。
    ・ユーザにとにかく動くものを見てもらって、
     気に入らないところを少しずつ直す。追加する。
    ただ、、、、、WebUnitっちゅうのもあるけでど、
    現実的じゃない。単体テストだけができない。
  • 日本でも (スコア:2, 参考になる)

    by trueOne (134) on 2001年10月30日 11時30分 (#33966)
    どなたかの第132回ソフトウェア工学研究会レポートによると、
    日本でも古くからSmalltalkコミュニティでは似たようなことが行われてたようですな。

    あと、文末の「やっと日本のやり方にアメリカが追い付いてきた」というのはスバラシイ洞察(^^;
    --
    trueOne
  • by G7 (3009) on 2001年10月30日 22時09分 (#34196)
    >設計段階では2人いてもいいけど、プログラミング中に横に人がいて集中できそうにない。

    集中といっても、単に静かで他人が居なければ対象物に集中できる、とは
    限らないぞ、ということなんじゃないかと憶測してます。

    人それぞれかもしれませんが、「考えを、誰かに喋ってしまうと、不思議と欠点に気付いたり
    改良案が浮かんだりする」って経験、ありませんか?少なくとも俺は一杯あります。

    対象物のことを考えるという意味では集中を保ったまま、かつ隣人と議論(?)したとき、
    不思議と思考が前進するっていう。

    あ。ここでいう隣人は、"同志"であるほうが望ましいとは思います。
    人形でもイイという噂も聞きます(^^;が、やっぱり志を同じくしてる人が最高でしょうね。

    で、それを形にしたのが、ペアプロなんじゃないかと思います。

    音楽(?)とかで最近流行の言い回しでいえば「コラボレーション」って奴かな?(^^;
    コラボレーションそのものは必ずしも同志とべったりしてることを要請しはしないでしょうけど
    (OpenSourceの開発なんかも分散してますね)、仕事なりなんなりで何人かが集まって集中して一本のソフトを書く
    という状況ならば、せっかくだから赤^H互いに密着してたほうが効率が良いぞ、ということなんじゃないかと。

    あと。
    漫画「Natural」(LaLa、成田美奈子)によると、集中が研ぎ澄まされると、
    対象をがっちり把握してて、かつ同時に周囲の雑事まで判る、
    ということが人間にはあるとか。あれも関係あるかな?

    ま、コーディングも、隣人との掛け合い漫才(笑)も、「思考の外在化」という意味では
    似たようなものだという面もあるんで、いいんじゃないでしょうか。
    コミュニケーション苦手な人でも、超うまい流暢なコミュニケーションがペアプロに必須とまでは
    言わないんじゃないか?と邪推してるんですが、経験者諸兄、どんなもんですか?
    • ペアプロってXPによると、ドライバーとコーダーは交互に(2日おき?)に変わる必要があるとされています。
      だから皆さんが考えているペアプロのようにコーダー固定じゃないです。
      --
      -----------------
      #そんなワタシはOS/2ユーザー:-)
      親コメント
      • by Average (3404) on 2001年10月31日 10時01分 (#34370) 日記
        訂正、大体5~10分で交代、だそうです。
        だから人から見られてイヤーンってのはすぐ消えそうですね。
        --
        -----------------
        #そんなワタシはOS/2ユーザー:-)
        親コメント
        • by G7 (3009) on 2001年10月31日 15時44分 (#34513)
          うーん。そうだ。それ聞いて思い出したのが、
          バレーボールのローテーションってルール。
          ポジションを次々入れ替えることを義務付けるって奴。
          #最近はまたルールかわったんでしたっけ?

          ん?1つの奴に拘ることが出来にくいという意味では、スラドの構成にも似ている、のか?(笑)
          親コメント
  • 私の勤務先には技術者は私しかいないので、ペアプログラミングができませーん。
    XPは全部を実践しないとXPとは言えないので...

    それはそうと、「徹底したテスト」の具体的な内容がちょっとまだ謎なのが...テストの自動化...う~む。
  • by nitonito (2431) on 2001年10月30日 9時20分 (#33909)
    < 設計段階では2人いてもいいけど、プログラミング中に横に人がいて集中できそうにない。

    そもそも、ウォーターフォール型のように設計とプログラミングが段階的になっていると、ペアプログラミングってのは無理だと思う。イテレーション単位が小さく、細かな機能アップを頻繁に行うような開発体制なら、お互いにコメンテータやアドバイザとなり、アイデアが触発されるといった良い面が出てくるはず。オブジェクト指向技術は、比較的XPを適用しやすいはずだけど、現場が段階的にドキュメントなどの成果物を要求するので、それを許さないってのはあると思う。変化は悪というのが、多くの開発現場の共通認識ではないかと思う。

    # 変えるなら金をくれ。変えないなら、それは仕様通り。
  • 単純に、「現在のやり方」を変えずに導入すると泥沼でしょう
    多分、頭の切換が必要だね。

    しかし、ちゃんと設計できていなくて穴だらけの仕様書をプログラマが泣く泣く補完しながらコーディングしているような現場も沢山あるから、実は救いになるのかも。
    • そうですねえ。穴だらけの要求仕様書を無責任に渡すだけ渡して
      (しかも分量が無闇に多いし。さほど巨大なプログラムじゃないはずなのに
      ダンボール箱一杯だったりとか!)、こっちの質問に真っ当な答えを
      (時間内に)返せもせず、それで成果物が変(彼らの思惑と比べて。勿論それが
      きっちり仕様書に反映されていたわけではない)だったらこっちにペナルティ罰金を科す、
      などという駄目すぎなお客には、是非XPの爪の垢を煎じて飲ませたいんですが、
      あっちは大企業(ついでにこっちは零細)なんで、こっちが言っても無理だろうな…(T_T)
      親コメント
      • 私はXP一本槍なヒトではないので、そのような方には

        「CMM認定されれば、最近話題のインドなソフト関係者の
         方々と同じく、世界レベルで通用し、運が良ければ
         米軍の調達時に企業連合等々の一員として参加可能な
         段階までレベルアップ可能なので、御社のように主と
         して上流工程をご担当される場合、是非とも取得すべき
         認定資格であり、営業的な意味合いからも非常に有利
         なのでご検討ください~~」

        な、どっかのコンサルタントさんの口調を借りて、影響力
        があって、キーマンな方を徐々に洗脳される事をお奨め
        します。

        要は、CMM的な取組みに参加してさえ頂ければOK。

        後はCMM的なトレーナーと、CMM的な認定チェッカーな方が
        厳しくトレーニング&レベル判定して頂けるので、自ずと
        要求仕様書の精度が向上していくハズです。
        #米国認定を取得するように、勧めるのがキモです。

        ...う~む、これは謀略か?、それとも世の為か?
        親コメント
  • よく車の運転に例えて説明してますが、実際XPはそんなイメージなので、目的地に向かって車を運転する運転手なのがXP的なイメージと思って良いかも。

    別の方も仰っている通り、WEB(EC)系開発ではリリースしてからが勝負、と言うより目の前で動かないとユーザもイメージが湧かないような点もあって、先ず動かしてみよう的な取組みに向いている事に同意します。

    私には根性が無いけど、誰かに実装する根性があれば、セキュリティ・プロセスの運用等にも向いている、スパイラルな手法を使用して、目的へ収束させる為の哲学的な考え方が基礎になってたります。
    関西地区で興味がある方がいらっしゃれば、入門セミナの受付を下記で行っているようです。
    (http://members6.tsukaeru.net/xpjug-kansai/index.html)
  • 私もペアプログラミングは実行したことがないので
    すが、実際にやってみた人、効果のほどはいかがですか?

    技術のある人が、勉強中の人に、手とり足とり指導しながら
    プログラミングするというのならば、ペアでやる効果が
    ありそうですが、実際の開発でどの程度効果があるのか
    興味があります。

    # 近くに相手が見つからないし...。
    # うーむ。やっぱりちょっと他人から見られながら
    # コード書くのって、なんとなく抵抗があるなぁ。

    • by HashiZ (4465) on 2001年10月30日 10時36分 (#33937)
      >技術のある人が、勉強中の人に、手とり足とり指導しながら
      >プログラミングするというのならば、ペアでやる効果が
      >ありそうですが、実際の開発でどの程度効果があるのか
      興味があります。

      私も本格的な経験はないのですが、実験的に3日ぐらいやってみたところ、

          * スペルミス/リソースの解放し忘れなどの単純ミスが劇的に減少する。
          * 説明するのが面倒なので、意図がわかりにくいコードを避けるようになる
          * 一人で作業しているよりも袋小路に迷い込む場面が減る

      などの効果がありました。

      ただし、作業効率的には、1人でやるときの2倍にはならないと思います。たぶん 1.5 倍程度。ただし、副作用として、デバッグやテストなど、コーディング以降の作業の工数が減っていると思うので、トータルで考えるととんとん以上の成果が得られると思います。

      まぁ、多少慣れは必要だと思いますが。
      親コメント
      • Re:ペアプログラミング (スコア:2, すばらしい洞察)

        by white (2295) <whiteNO@SPAMniu.ne.jp> on 2001年10月30日 11時33分 (#33967) ホームページ
        コーディングとコードレビューを同時にやってしまうようなものなのでしょう。思い込みのミスも減るし、常に他人の目が入ることでコーディングスタイルも良くなる。

        効率を上げるというよりは、後の非効率の要因を取り除くという感じ。どこかで限界が来て(余計な)整理をするのではなく、最初から整理された状態にしてしまう、と。他にも、ペアの流動によるノウハウの流動・教育効果もあるだろうし、存外効率的なのではないかと思います。
        親コメント
      • 実体験を伺いしたいのですが,

        “ペアプログラミングはどのようにやるのですか?”

        XPをちらりと知った時にも疑問に思ったのですが,ペアでプログラムをするとなるとキーボードの前にスペースが無いと思うのですが……
        二人体をくっつけあっても液晶だと見えづらいし,キーボードは打ちにくいし.(勤め先だとそもそも二人並んで座るスペースが無いですし )

        もしかして,学校教育用なんかに作られている,別のPCでターゲットのPCを操作するシステム等を使うのでしょうか?

        勤め先ではCVS等でソースツリーを管理してるから,マルチユーザーでプログラムしてるといえばしてますけど,ペアプログラミングってそういうことじゃないですよね?
        親コメント
        • by HashiZ (4465) on 2001年10月31日 11時55分 (#34427)
          基本的にはごく普通の1台のモニタとごく普通の1台のキーボードを二人で共有するわけですが、確かに狭い環境だとつらいでしょうね。

          ただ、マシンの前に椅子を二つならべるだけのスペースすらないのであればペアプログラミングに関係なく、プログラマの作業環境としては狭すぎる気がします。1日の大半をそこで作業するわけですから、なるべく快適な環境を整えることが重要かと。

          XP の場合、部屋の中央に大きな机を置いて、そこにマシンを何台か置き、プログラミングするときはそこに行って作業するというスタイルが提案されているようです。
          親コメント
          • いや,中途半端なパーティションの中で過ごしているので,二人並べないだけなんです.

            でも,結局大きなスペースが必要なんですね……狭い日本ぢゃ1つのプログラムに二人かかるというコストよりも,場所的な問題のほうが厳しいでしょうね.

            XPやるからスペースくれなんて,上司は納得しても総務が納得しないでしょうし.
            親コメント
        • by G7 (3009) on 2001年10月31日 16時24分 (#34526)
          実体験じゃなく伝聞(電文?)オンリーですが。

          なんかどこかでその話題をしたら、キーボードも画面も「同一物を共有しろ」と言われた記憶が。

          それが本当だとすると不思議なんですが、キーボードやキーバインドの各自の好みの問題は
          一体どうするのやら?
          viな人とEmacsな人とNotepad.exe(笑)な人と…
          HHKでないと駄目な人とHHKじゃ駄目な人と…

          誰か、真相(?)をフォローお願いします。
          親コメント
    • Re:ペアプログラミング (スコア:4, おもしろおかしい)

      by Nautilus (2554) on 2001年10月30日 10時50分 (#33950) ホームページ 日記
      実質的な話ではないんですが・・・
      部署内で実験的にやった結果、二人でやってるとなぜかお菓子をかってきてだべりながらやってしまうので太ったという意見がありました(^_^;)
      親コメント
      • by yasiyasi (5450) on 2001年10月30日 14時45分 (#34028)
        部署内で実験的にやった結果、二人でやってるとなぜかお菓子をかってきてだべりながらやってしまうので太ったという意見がありました(^_^;)
        「飲み物とお茶菓子を、開発室内に常に用意しておくこと」
        というのも、XPのルールではなかったでしょうか。

         ダイエットに命がけの人には、酷な環境なのかも(^^;

        親コメント
  • これが分かれていないのがXPでは無いのでしょうか。
    設計(テスト作成)→製造(プログラミング)
    のループが肝かと。

    実際、独りよがりなコードと設計を防止できるので
    良いかと思っています。
    5年目と2,3年目の人でチームにしたりすると
    全体的なコードの質が向上しそうに思います。
    (全くの新人では先輩の負担が重すぎます)
    テクニカルでも後輩が理解できないようなコードは
    ダメだって事である程度目安になりそうです。
    組み込み・制御系の様にハードが絡む系列には
    XPは向いていないとは思いますが。
    --
    ------------------------ written by BlueJocker ------------------------
  • 徐々に出来そうなものから取り入れていってます。 現在実践出来ているかな?と思っているのは ・UnitTest ・リファクタリング ・イテレーション計画 あたりでしょうか。 UnitTestとリファクタリングは導入しやすく効果も大きいですね^^。
    --
    -- niwaken
  • 上司にXPを試行させるための、説得材料の方が
    決定的に不足しています。

    もちろん、その提案能力も、こちら側の責任であることは
    承知しておりますが。

    --本題からそれます--

    逆療法として、耳栓(スポンジみたいな)をして、
    質問されにくい(?ペア・プログラミング拒否)のような
    動きをしつつ、「質問はどんどんしなさい」状態にして、
    回りの動きがどうかわるかを試してみました。
    (質問が減ったら、それは・・・質問する側の問題でしょう。)

    実際、電話の鳴る音や、話し声は消えませんし、
    耳障りな空調の音のようなものは消えてくれて
    逆に快適に感じられます。

    質問の増減はどうだったか・・・
    --
    Copyright (c) 2001-2014 Parsley, All rights reserved.
  • 私の場合、「ペアプログラム」ならぬ「ペアデバッギング」なら
    10年位前(って言うかこの業界に就職してから)から良くしますけどね。
    二人以上で一緒にデバッガーでソースコードを追いながらデバッグするという。

    結構思い込みによるバグに見逃しに効果があります。
    --
    masamic
  • by Anonymous Coward on 2001年10月30日 17時16分 (#34093)
    onoyan のコメント: Monday October 29, @10:30PM
    > でも、GUIやDB周りのテスト自動化は難しいッス。

    画面出し前なら UnitTest の導入は積極的にやってます。

    でも 60 fps で動かすフレームワークの方では、
    オートデモ用のキー入力テーブルを受けての
    出力確認ぐらいしか自動化できていないです。

    ゲーム開発で使える XP 面白ネタありませんかねぇ。
  • XP については人によって賛否両論があると思いますが、私はある程度有用性を感じています。

    XP を読んで感じたことは、方法論ではあるもののどちらかというと「変化ヲ抱擁セヨ(Embrace Change)」を中心としたデザインパターン的なカタログという感じがしました。

    何が言いたいのかというと、あくまでもカタログなので、それが参考になるとはいうものの、この方法ですべてがうまくいくとは思っていません。

    やっぱり「変化ヲ抱擁セヨ(Embrace Change)」といっても実際のプロジェクトでは限界があるし、リファクタリング(一応私の認識では外部的な仕様を変えずに内部を改良すること)もどこまでリファクタリングというのかという難しい問題があります。最終的には、納期とコストのバランス問題になってくるんでしょうけど。

    いままで、こういう方法論で成功したものはないですし、どうしても経験的に否定的になってしまっています。

    ただ、今まで方法論が成功したことが無いから方法論を作るのは意味が無いとは思っていなくて、(普及を含めて)十分使えるものになっていくことを祈っています。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...