クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～2012年8月26日に行われた、CSS Nite in SAPPORO, Vol.5 での発表資料です。
ワンクリックデプロイ101 #ocdeploy
2011年12月20日に実施したワンクリックデプロイ勉強会の資料です。 http://www.ryuzee.com/Read less
プレス発表 俊敏かつ柔軟なシステム開発を可能にするアジャイル型開発を推進するための活動成果を公開：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）ソフトウェア・エンジニアリング・センター（以下、SEC）は、アジャイル型開発の適用領域や適用方法を整理するための活動を行い、アジャイル型開発に適したモデル契約書案2種を含む「非ウォーターフォール型開発WG（*1）活動報告書」（以下、報告書）を公開しました。 URL： http://www.ipa.go.jp/sec/reports/20110407.html 現在、日本におけるソフトウェア開発の殆どは、ウォーターフォール型と呼ばれる手法です。この開発手法は、初期にシステムに対する要件を正確に決め、前工程を誤りなく完了させ次に進むことが求められます。しかし現実的には、要件の間違いが後で判明することや、開発着手までに要件を確定できない場合もあり、これらに起因するシステムトラブルや開発の遅れが生じています。 このように、初期段階で顧客ニー
大規模アジャイル開発の実態～ セールスフォース・ドットコムの作り方（前編）
クラウド上に構築したアプリケーションをサービスとして提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、開発を行っています。 アプリケーションのメジャーアップデートは年3回。クラウドで提供しているサービスという性格上、もしもアップデートにバグがあればそれは全ユーザーに対して大きな影響を与える可能性があります。バグがないこと、性能低下を起こさないこと、品質管理はパッケージソフトウェア以上に重要です。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」で詳しく紹介されていました。 同社の開発手
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） アジャイルなソフトウェア開発手法としてもっとも広く使われているのが「スクラム」です。このスクラムは、1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによって提唱されたものですが、その考え方の基盤となったのが1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。 1月14日にコミュニティが主催し都内で行われたイベント「Innovation Sprint 2011」は、このスクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏がそれぞれ
「10分でスクラム」、アジャイル開発の「スクラム」に興味がわいた方へ
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために（かどうかは分かりませんが：-）、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
Agile in 30mins - 30分でだいたいわかるアジャイル開発
Are you ready? ～これからアジャイル開発をスタートアップするために プラクティスの実践と実感～
RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
第3回 成長できるチームの作り方
講師にはスクラムの開発経験が長いエマーソン・ミルズOdd-e Japan代表を招き、初対面の5人がチームを組んで三つのロールプレイ形式のワークショップ（参加型講習会）を実施した 2009年11月25日夜7時、金融情報サービス会社QUICKの会議室で、「チームとは何だ」と題してすくすくスクラムの第7回勉強会が始まった（写真1）。約40人の参加者はほとんどが技術者で、システムの受注者側と発注者側が半々程度だという。また毎回約半数が初参加である。 スクラムとはアジャイル開発手法の一つで、プロジェクトでの採用が増えている。理由はシンプルであること。「30日ごとの繰り返し開発」「毎朝15分のミーティング」「繰り返し開発が終わったら必ず3時間の振り返りを実施する」といった、繰り返し開発と振り返りの二つの枠組みのみを決める。技術的な技法にまでは踏み込まない。 今回、勉強会はなぜチームをテーマにしたのか。
アジャイル開発はツールに依存している～SW構成管理を再考しよう - プログラマの思索
アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。 【元ネタ1】 Kent Beck VSTSのホワイトペーパーの日本語訳 (前略) アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。 (中略) アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。 (中略) アジャイル開発は既に開発ツールに影響を与えています。 (中略) 今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。 以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用
アジャイル開発の見積もりとリスク
ここ３年ぐらい同一案件のアジャイル的な開発をやっているのですが、 見積もりについて経験則がまとまってきたので整理してみたいと思います。 まず、前提として以下のような作業を請け負っています。 顧客の要望を聞いて要件開発を行う 要件を元にシステムの設計を行う 設計を元にプログラムの製造を行う テストを行う 運用時に発生した障害の調査 開発は１期のスパンが２か月～３か月程度で、 開発した機能のリリースを行いながら順次機能拡張していくといった感じになります。 作業の見積もりはその作業の種別により分類されます。 建築での比喩で表現すれば、大きく分けると設計図面を引く前と引いた後です。 これに加え、突発的な飛び込み作業があるので、以下の３つに分類しています。 設計図面を引くまでの作業 引いた図面をもとに開発する作業 突発的に発生する作業 そして、それぞれの作業ごとに不確定要素（リスク）が存在します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】テストについて考える