タグ

siとagileに関するyohjizzz-backupのブックマーク (6)

  • これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)

    Austin 7 friction damper New discs 16.4 plus 1 turn to 5 turns preloadAdrian Ward

    これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)
  • アジャイル開発を前提とした受託開発 - プログラマの思索

    永和システムマネジメントさんがアジャイル開発を前提とした新しい契約形態での受託開発サービスを発表していた記事があったのでメモ。 【元ネタ】 新しい契約形態での受託開発サービス | 永和システムマネジメント プライベートセミナー『アジャイルに適したまったく新しい契約形態での受託開発サービス トライアルのご紹介』(2010/11/24) ? 株式会社永和システムマネジメント コンサルティングセンター 永和システムマネジメントの新しい受託契約がすごく面白い - ただのにっき(2010-11-11) WEB技術者の事業貢献度をもっと高めたい - GoTheDistance 受託開発の契約をアジャイル開発を前提とした形態にしてSIビジネスする発想はとても興味深い。 責任者は木下史彦さんと公開されていて、XP祭り関西などで何度もお話を聞いていたから、なるほどと思った。 SW開発が製造業と異なる収益構造

    アジャイル開発を前提とした受託開発 - プログラマの思索
  • アジャイルソフトウェア開発宣言

    私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

  • アジャイル開発と要件管理 - プログラマの思索

    要求や要件管理に関する「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、

    アジャイル開発と要件管理 - プログラマの思索
    yohjizzz-backup
    yohjizzz-backup 2010/02/28
    これも後で読む!!
  • Agileなプロセスと受託開発は本当に相性が悪いのか?

    アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。 SIerから見たアジャイル 工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。 要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。 今の日SIerのモデルは“まだ"建設業みたいな多重階層の構造であることは間違いない。 収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って

    Agileなプロセスと受託開発は本当に相性が悪いのか?
    yohjizzz-backup
    yohjizzz-backup 2010/02/13
    「自分達で投資対効果を検討できたり、リリース時期によるビジネス機会の拡大/損失が理解できる顧客の場合は、アジャイルは向いている…」
  • アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

    全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey 「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。 滝 「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

    アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
  • 1