見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
ソニックガーデン11期〜経営方針
プロダクトの価値を最大化する「言語化筋トレ」のすすめ / "Verbalizing muscle training” to maximize the value of products
アジャイル開発者からみた「納品のない受託開発」の疑問を解消！？〜アジャイルラジオで倉貫が語った本音【前編】
ウェブとポッドキャストで配信中の、 IT系エンジニア応援番組！「アジャイルラジオ」 の記念すべき 第１００回目（2014年の10月15日に配信） のゲストとして、弊社代表の倉貫を呼んで頂き、ラジオらしくざっくばらんにお話させて頂きました。そこで今回は、アジャイルラジオさんから特別に許可を得て、記事として書き起こしました。 パーソナリティーの山根さん、西さんは関西系のベテランのアジャイル開発者です。そんなお二人からの鋭い質問とツッコミに、どう倉貫が答えていくのか、ぜひ楽しんでご覧ください。記事の前編では「納品のない受託開発」とギルドの仕組みについて、後編では経営の視点からビジョンやお客様との関係について、語っています。
受託開発にアジャイルは適用できるか？
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
一括の受託開発でアジャイル - Be Happyman!!
スクラムのコーチとしてトレーニングに参加したりすると、必ず契約の話題になります。（質疑応答で100％でてきます） 「うちは一括でしか契約できないのですが、スクラムではどうしますか？」 「リリース日を約束しないとなると、契約上の納期に遅れそうな場合どうしますか？」 見積もりした結果に利益加算して契約するかと思うのですがスクラムでの契約はどうするんですか？」 などなど。よく言われているように日本のエンジニアは受託開発に従事されている方が多いので、そりゃ質問したくもなるだろうなぁ、とは思います。ただ、身もふたもない言い方をしてしまえば、今のところ答えは「準委任契約ですね」となってしまいます。 もちろん、契約モデルについては様々な試行錯誤がされています。価値創造契約も一つの形ですね。ものすごく細かく（それこそスプリント単位で）請負契約を分割するやり方も実践されています。 ただ、従来のウォーターフォ
ゼロから始めるスクラムによる受託開発 | Fintan
はじめに このドキュメントは、受託開発をスクラムで実践した事例をまとめたものである。 自社サービス開発でのスクラム事例は数多く存在する一方で、受託開発をスクラムで実践した事例は少ないのが現状である。 そんな中、私たちはアジャイル型開発の初心者であったが、スクラムによる受託開発に挑戦する機会を得た。 実際に挑戦すると、想定していた以上に難易度が高く、プロジェクト運営が困難な状況も多くあった。しかし、さまざまな問題に直面し改善していく中で、受託開発にスクラムを取り入れるメリットや注意点など多くのノウハウを獲得できた。 私たちの獲得したノウハウが、これから受託開発をスクラムで挑戦しようとしている人、すでに挑戦はしているが進め方に悩んでいる人の参考になることを目的として、本事例を公開する。 なお、本ドキュメントでは基本的なスクラムの概要については説明しない。 スクラムの概要については以下のサイトを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
進化する「納品のない受託開発」
