タグ

アジャイルとシステムに関するshozzyのブックマーク (5)

  • アジャイル開発とクラウド(SaaS)利用の位置づけ、SIerの生きる道

    早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー

    アジャイル開発とクラウド(SaaS)利用の位置づけ、SIerの生きる道
  • Agileの現状に対する漠然とした不安 - masayang's diary

    去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー?」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投

    Agileの現状に対する漠然とした不安 - masayang's diary
    shozzy
    shozzy 2010/09/21
    ふむ。発注側としては、契約内容と開発方法は不可分に見えるのだけど。Agileな発注ってどんなんだろう…。最終的にいくらになるのかわからないと契約できない。/職人思想だから、カネのことなんか気にしてないのか。
  • じゃあ見積りもアジャイルでやりましょう!:グロースハッカー研究所

    はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。 お客様はアジャイルがお好き 私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。 顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリッ

    じゃあ見積りもアジャイルでやりましょう!:グロースハッカー研究所
    shozzy
    shozzy 2009/11/12
    結局そこなのよ。契約まわりがネックになる。
  • agile+オフショアは非常に困難。 - プログラマーm-matsuokaの生存記録

    http://d.hatena.ne.jp/nanoha3/20090305/1236232630 →今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile+オフショアは無理な組み合わせ? 非常に困難。 なぜなら、オフショア側からのフィードバックを受け取るのが難しいから。 オフショア側のコーディングミスや仕様理解の誤りなどのフィードバックを受け取ることが難しいため、そのフィードバックをもとにした改良も困難になる。 こちらの仕様や要求の変更をオフショア側に伝えるのも難しい。 (厳密な仕様を作って伝えるくらいなら、こちらでコードを書いた方が早いと思う) コーディングスキルが無ければ、オフショア側が作ったコードの品質もチェックできないだろうし。 ビデオ会議やメールで、相手の理解度のチェックや、こちらの仕様を理解させるのは非道く疲れることですし(

    shozzy
    shozzy 2009/03/06
    やっぱりねぇ。個人的にはオフショアにいい思い出は全く無い。
  • 大規模プロジェクトでagileやった結果がこのざまだよ - World Digger

    知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 【状況】 ・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。 ・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。 →クリティカルなシステム(例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム)をagileでやるのは、先が読めないからいかんとのこと。 【問題発生】 /結局SI側もクライアント側もあまりagileを理解してなかった系 ・今までウォーターフォール開発の進捗管理になれていた役員(意志決定者)が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ;゚Д゚))))ガクガクブルブル!→怖いからやめた。 ・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。 →今

    大規模プロジェクトでagileやった結果がこのざまだよ - World Digger
    shozzy
    shozzy 2009/03/06
    これは参考にしたい/規模とか、どれだけ意識改革をできるかとか、そういうファクターも絡んでそう/結局ウォーターフォールって、なんというあるあるw
  • 1