E-Agility Conference
アジャイル開発が広がりを見せ、E-Agility Conferenceのテーマである企業システムの俊敏で軽快なシステム開発が、次第に現実のものとなりつつあります。 しかしながら、ユーザー企業の現場には、アジャイル開発が役に立つのか、どうすれば成功するのかを考えて、一歩が踏み出せない人たちがたくさんいるのも現実です。 そこで、今回のメイン講演では、これまで日本のアジャイル開発のリーダー的役割を果たされ、 現在は楽天株式会社でご活躍中の川口恭伸氏をお招きし、ユーザー企業でのアジャイル 開発の事例と成功の勘所をじっくりとお話ししていただきます。 事前登録性となりますので、ご登録はお早めに。 皆様のご来場を心からお待ちしております。 13:20 受付開始 13:40-14:00 開演/協議会からのご挨拶（20分） 講演者： 依田 智夫（株式会社シナジー研究所 代表取締役社長・プリンシパルコンサルタ
マイルドなアジャイル開発手法 AMOP | オブジェクトの広場
今回は, アジャイルモデリングを実践するためのベースとなるアジャイル開発手法として筆者らが考案したAMOP (Agile Method for Ordinary Projects) [1] という開発手法を紹介します. AMOP は, 既存の開発のやり方に慣れた開発者や管理者に受け入れられやすいものであることを目指したアジャイル開発手法です. 今回の記事では, まずスクラム [2] の短所や難しい点を説明し, 次いでそれらを XP (eXtreme Programming) [3] のプラクティスでどのように補おうとしたかについて説明します. さらに, AMOP を２つのプロジェクトに適用した結果を紹介します. 1. スクラムの短所や難しさ 前回の記事では, もっともシンプルで取り入れやすいと筆者が考えるアジャイル開発手法スクラムを紹介しました. その記事では, スクラムの長所を中心に説明
アジャイルプロジェクトの契約に関する私見
みなさんこんにちは。@ryuzeeです。 ソフトウェアを構築するときに締結する契約は、大別すると請負契約と準委任契約、そして派遣契約（今回は割愛します）があります。 請負契約は、完成させるべきものを事前に規定し、それを満たすものを納品することで代金が支払われます。 一方で準委任契約は、発注者の代わりに自身の裁量で業務を遂行する契約であり、働いた時間に応じた代金が支払われるのが一般的です。 アジャイル開発では、顧客やユーザーのフィードバックを得て作るものを変えていきます。 つまり事前に詳細なスコープは確定しません。 それにも関わらず請負型の契約を行った場合、事前に決められた「完成させるべきもの」に加えて、フィードバックへの対応が必要になってしまいます。 事前に決められた内容によって期間と費用が固定されるため、このような変化は開発側としては避けなければいけないものになります。 その理由は、単純
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
Agileでやってるけどデスマったｗ
Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが
ウォーターフォールとスクラムとリーンの違い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Agile101より引用の図が分かりやすいので引用・意訳にてご紹介します。 ウォーターフォールプロジェクトの終了直前のデプロイまで、何の価値も実現できないテストを最後に残しているため、最後の最後まで問題の発見が遅れる要求事項が変化しているかもしれないのに、ステークホルダーへの提案をしない計画に大きく依存しているため、(計画に失敗していると)プロジェクトの失敗に結び付きやすいプロジェクトマネージャの力量に依存しているフェーズ分割型ウォーターフォール従来型ウォーターフォールに比べればリスクは少ないよくある問題はボトルネックの発生若干の工程の遅れをテスト工程まで引きづり、結果として最後に想像以上に解決の時間を要することになり、結果プロジェクトの終了時期を守れない見積りは難しいのでオーバーコミットメント(過剰な約束)する可能性があるフェーズでの見積りは他の
Webサイト構築手法、累進的拡張を知る | エンタープライズ | マイコミジャーナル
A List Apart - for people who make websites A List ApartにおいてAaron Gustafson氏がUnderstanding Progressive Enhancementのタイトルのもと累進的拡張によるWebサイトの構築を紹介している。累進的拡張(Progressive Enhancement)はもともと2003年にSXSW AustinでInclusive Web Design For the Future with Progressive EnhancementとしてSteven Champeon氏およびNick Finck氏によって紹介された考え方。Inclusive Web Design For the Future with Progressive Enhancementで紹介されている累進的拡張戦略を簡単にまとめると次の
株式会社フォービス｜やわらかいシステムが事業成長を実現します
たとえば、髪を切るとき。フルオーダーで家を建てるとき。 すべてを言葉にするのは、とてもむずかしい。 言葉にできない部分を丁寧にくみとって、隠れたニーズまで形にしてくれる。 そんな相手に任せたいと思いませんか？ システム開発も同じこと。 わたしたちフォービスは、お客様に寄り添い、とことん対話することで、お客様自身も気づいていないこと、一歩先のことを形にしてみせます。
株式会社フォービス｜やわらかいシステムが事業成長を実現します
たとえば、髪を切るとき。フルオーダーで家を建てるとき。 すべてを言葉にするのは、とてもむずかしい。 言葉にできない部分を丁寧にくみとって、隠れたニーズまで形にしてくれる。 そんな相手に任せたいと思いませんか？ システム開発も同じこと。 わたしたちフォービスは、お客様に寄り添い、とことん対話することで、お客様自身も気づいていないこと、一歩先のことを形にしてみせます。
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
