タグ

developmentに関するGooddayのブックマーク (3)

  • ウォーターフォールのほうが楽だという話 - 勘と経験と読経

    わたしはまだ格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い(プロジェクトマネージャーの立場で、スクラムマスター的に推進)。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった? 「第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile

    ウォーターフォールのほうが楽だという話 - 勘と経験と読経
    Goodday
    Goodday 2012/04/20
    アジャイル開発は、ユーザーが主体で開発する手法なのでは?丸投げされた開発会社のプロジェクトマネージャがマネジメントするとなると「短期間Waterfallリピート」になってる感じ。
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • はじめてのiGoogleガジェット開発#1

    どうも、「公開APIを利用したサンプルサイトを作っていくよ」管理人のZAPAです。 今日は、マッシュアップツールを作るための第一歩として、「iGoogleガジェット」の開発方法を解説します。 「Googleからのプレゼントが届いたよー!!!」に登場した、iGoogleガジェット。 「ガジェット大好き!」って人も、「これからの時代はガジェットだ!」って人も、「ガジェットって何だろう?」って人も、これからの時代は自分でガジェットを作れるとカッコイイと思うよ!!iGoogleガジェットに興味を持っても、開発情報を調べるのはなかなか大変です。 公式サイトに重要な情報はたくさん載っていますが、コンパクトにiGoogleガジェット開発方法を理解できるページがありませんでした。 公式ドキュメントをマジメに読むと30分以上かかり、やる気がそがれてしまいますので、ここに「iGoogleガジェット開発方法」を

    はじめてのiGoogleガジェット開発#1
  • 1