アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Agileでいこうよ... (スコア:3, 興味深い)
最近のシステムは昔より複雑化しているので、お客さん自身もどんなシステムが欲しいのか、要件定義段階では頭の中に描けなくなってきているし、開発する側も見積が困難になりつつあるわけです。
そういう状況で納期と予算を定めて開発をするというのはお客さん側も開発側も相当なリスクを背負う必要があります。
ならば優先度の高い要件から順次開発していくAgile型手法のほうがお客さんも開発側もハッピーになれるのではないかと。
ちなみに件の「納期が決まっている場合」の対処は、Agile的には「機能を絞る」です。
---- 末は社長か懲戒免職 なかむらまさよし
Re:Agileでいこうよ... (スコア:3, 興味深い)
まあ、私自身、アジャイルというのはあまりよく分かっていない部分もあるのですが。
でも、斜め読みした書籍やサイトから、まず最初に感じたのは、
なんか、アジャイルの話って、お客さんがあまりにも優秀で、物分りがいいという前提に立ちすぎており、
結果、開発する方の、費用・納期・資源という部分の戦略に欠けていると感じていました。
それでも、この前、顧客の要件が大まかな枠組みのみ決まっている案件に対して、実験的に顧客の担当者を
スケジューリングや開発の現場にコミッ
Re:Agileでいこうよ... (スコア:3, 興味深い)
>顧客の要件が大まかな枠組みのみ決まっている案件に対して
どれくらいの枠組みなのかはこれだけではわかりませんが、顧客にとってのゴール(これができるようになる、何が改善される)が明確でなければ、Agileもへったくれもないですよね。
>以下のような問題で大混乱となりました。
大混乱に陥いるということは、イタレーション単位がでかすぎたとか、イタレーションを見直す頻度が低すぎたとか、高すぎたとか、そういう問題があったのではないでしょうか?
>1. 顧客の中で全ての要件の優先順位づけが上手く行くことがない
これは顧客が神様でない限り不可能では? 事前に要件を全て洗い出せないのと同様、優先順位も常に確定できるとは限りません。 となると見直しが発生するのは必須ですが、見直し頻度が多すぎれば完成できない機能が山積みになりますし、少なすぎれば「え、この機能ないの?」と後から騒ぐ羽目になります。
イタレーション周期が一週間なら、優先度見直しは一ヶ月、イタレーション周期が半月なら、優先度見直しは二ヶ月くらいが良いようです。それ以外は、ストーリの順序は固定させるべきでしょう。
>2. 顧客と開発者が直にやり取りすることにより、
これ、XP本などでは良く書かれている話ですけど、そんなにうまくはいかないでしょうね。顧客側の責任者(Product Owner)と、開発側の責任者(Scrum Master)が定期的に状況確認をするのが現実的ではないでしょうか。
>3. ドキュメントが防波堤にならない為、
なのでドキュメントを残せばよいわけですよ。うまくいってる事例では、ホワイトボードに書いた内容をデジカメで撮影して保存している、というのがありました。議事録の代わりです。ここから起こしたストーリは、紙媒体ならデジカメ、XPlannerなどのシステムだったら顧客が直接見るとか、他形式に変換して渡すとか、共有手段はあります。変更履歴(とその理由)が残るシステムならさらに良いわけですが、いまのところオープンソースでこういうのは見たことないです...
あと、ストーリの入れ替えはそれなりの課金をする、という契約方法もあります。コロコロ言うことが変われば、それなりに開発価格も高くなる、ということで一定の縛りをかけるわけです。
>4. 2に関連して、顧客が雑談などで話したことが、なぜか仕様の一部になり、
開発ストーリを決める場とそうではない場を明確にし、そこで話しあわれた内容を文書化することで解決するべきでしたね。方法は、デジカメでホワイトボードを撮影すれば充分でしょう。
>5. 2に伴い、開発スコープが勝手に肥大化することにより、営業的に大失敗となる。
米国では、請負開発価格をスライド式にして解決するのが最近の主流みたいです。もちろん、のんべんだらりと開発されたら顧客側が損するので、そのあたりはいろいろ工夫があります。必要なら別コメントで説明します。
ちなみに、ウォーターフォール開発での初期見積りがダメダメで営業的に大失敗する事例が多いので、Agileが台頭してきた、ってのが北米(なぜかカナダにAgile企業が多い)での背景です。
>6. 顧客が開発者のスケジュールなどを把握できる為、
これも顧客との関係がよくないからでしょうね。仕事を随時ネジこむのがAgileではありません。
>7. 顧客の営業的な理由で、段階的な成果物のアウトプット自体が不可能。
段階リリース=段階本番リリースではありませんよ。段階的なアウトプットは内部リリースで評価してもらい、それが本番リリースに耐えうる内容・品質かどうかを顧客に確認してもらうのがAgileの本質ではないでしょうか。
>8. 1-7の結果、モノが納期までに出来なかったとしても、結局のところ、顧客に責任はない。
そもそもどんなモノを作るかが明確になってなければ、顧客に責任を問うことは不可能でしょう。
イメージを固めながら開発を進め、リリース時期をずらせるのならずらし、無理なら機能制限でリリースする。
これがAgileの良いところではないでしょうか。
自分の少い経験からも同意できるのは
>通常の会社の稟議システムの面倒さ
これですね。
課長とか部長とか執行役員とかいうのは、自分に課せられた責任を許される予算の範囲で、自分の判断で解決していく、というのが本来の姿なわけです。
でもそれだと失敗したときに責任問われちゃうので、稟議という形式にしちゃう。みんなが同意したんだから、自分一人に責任はないよね、というわけです。
当然、意思決定の速度はどんどん落ちてしまう...
まあ、銀行護送船団方式だった時代の日本ならいざ知らず、今後はこのあたりも変化してくるのではないでしょうか。
>自社内案件以外、2度とアジャイルっぽいものには近づかない方向で。
まあ、ここまで原因が追求できているのなら、次はいろいろ打つ手もあるのでは? たしかに自社内案件で実証、というのが正解でしょうね。
Agile管理手法の一つ、SCRUMは日本の製造業が手本になっているわけです。そして日本のソフトウェア産業はなぜか建設業界を手本にしています。
手本を間違えているから、いろいろ悲劇が起きているのではないかなぁ...
長文、失礼しました。
---- 末は社長か懲戒免職 なかむらまさよし