アジャイルソフトウェア開発
カテゴリー：インターネット・IT | 関連グッズ一覧
ブログからのネタの種
- アートオブアジャイルデベロップメント第4章その3
- 第4.3章アジャイル度を評価しよう **要約** アジャイル度の評価ができる ・考えること ・協力すること ・リリースすること ・計画すること ・開発すること の5つについて診断をする **感想** 一番低かったのは開発することでした。とくにバグに関しての診断が
2010/03/11 12:49:06 [プログラミングお勉強きろく] - Developers Summit 2010 に行ってきた
- テストを書く unitTestではない 不安をテストする WEB+DBのvol.35 ペアプロでコードの共有 コードの批判は人格批判ではない hudson ci slowtest問題 アジャイルな見積もりと計画づくり planning poker 誰が何をやってるかいつでも誰でも見えるように 付箋いいよ don't repeat yourself 大きなものは把握できるよう
2010/03/11 00:11:10 [ダメ人間オンライン] - [アジャイル][読書]アート・オブ・アジャイル デベロップメント
- 「4章 XPを導入する」の続き エクストリームショッピング 仕事場の必需品がずらっと書いてあります。以下は、普段のアジャイル開発でヘヴィに使っている、個人的に特に重要と思うものです。・ビルド専用マシン ・ホワイトボード ・インデックスカード(付箋 ・マグネット ・xUnit ホワイトボードに関しては id
2010/03/10 19:10:47 [noire722の日記] - [アジャイル][読書]アート・オブ・アジャイル デベロップメント
2010/03/10 12:09:06 [noire722の日記]- 変わり種、「裏技」
- おつき合いありがとうございました メイクアップで 惑わしOpenPNE その01 by Happy Engineer Life (PukiWiki/TrackBack 0.3) (01/09) さくらインターネットでOpenPNE その04 by アジャイルな社長が教える!自分をもっとレベルアップさせる裏技 (11/15) ロボゴング by 頑屈王国ネオ (08/07) RDF Site Summaryアンプラグド
2010/03/10 11:45:30 [国際 裏技 時事] - 4/13(火)「Visual Studio 2010 Ready Day
- プロジェクトマネジメント」を考え、アジャイルは「開発実務マネジメント」を考えているんだろうな。だから、両者は組み合わせられる。日本のSIerでは、こういう入り方が現実的で効果もあるんじゃないかな。id: 10203996696 screen_name: yusuke_arclamp 多くの人はアジャイルって言葉に何を
2010/03/10 06:43:59 [ウィリアムのいたずらの開発日記] - [駄文] 自分なりの表現のカタチを探
- などの趣味であったり、もちろんプログラムも列挙されていた。余談ですが、アジャイル・ソフトウェア開発もプログラムという実物を披露して皆に理解させるというポイントを含んでいる事を思い出した。アジャイル・ソフトウェア開発とは総合的な開発手法の一つで、長期開発期間を細かく分け
2010/03/09 21:34:53 [stv_tributeの日記] - 「AgileとScrumの重大な欠陥を明らかに」
- 待ちしております!#suc3rum id: 10154452868 screen_name: kanu_ "[B!] 「アジャイル宣言の背後にある原則」が2ページ目にあるのが気に入らないという話。アジャイルを語るときには必ず語るべきだと私は思う。んで他の重大な欠陥
2010/03/09 07:42:25 [ウィリアムのいたずらの開発日記] - 「Androidデベロッパ向けにPhotoshop.com Mobileエディタを公開
- でも大丈夫だわな。検索さえどうにかなれば id: 10153934435 screen_name: terurou 短い文章に、クラウド、SaaS、グリーンIT、XML、モジュール構造、アジャイル開発手法、業界共通って単語が並ぶとスーツ臭がすごいな… id: 10121052966 screen_name: terurou TokyoCabinetでMVCC的な事を簡易実装できない
2010/03/09 02:23:33 [ウィリアムのいたずらの開発日記] - ゲーム会社「DS2はこれまで使った中
- かなと思ったりしましたが。OpenPNE その01 by Happy Engineer Life (PukiWiki/TrackBack 0.3) (01/09) さくらインターネットでOpenPNE その04 by アジャイルな社長が教える!自分をもっとレベルアップさせる裏技 (11/15) ロボゴング by 頑屈王国ネオ (08/07) RDF Site Summary● ゲーム会社
2010/03/09 01:24:05 [裏技日記で毎日笑わせるのを目標に]
はてブ注目エントリーからのネタの種
- カプコンに学ぶデスマーチにならない仕事術 - teruyastarはかく語りき
- ほんとにヤバくなってギリギリになるまで相談しない人々: 切込隊長BLOG（ブログ） Lead‐off man's Bloghttp://kirik.tea-nifty.com/diary/2010/03/post-1da9.html いつも予防線が突破されるので、いずれにせよ年がら年中修羅場になってるわけだが、修羅場をこなしているうちに、常在戦場みたいな組織が出来上がって、毎日ラットレースをしてい...
1970/01/01 00:00:00 [] - 【Game Developers Conference（GDC） 2010現地レポート】 Game Developers Conference 2010が開幕 今年のキーワードは「ソーシャル＆モバイル」。来場者の関心は“マネタイズ”か - GAME Watch
- Game Developers Conference（GDC） 2010現地レポートGame Developers Conference 2010が開幕今年のキーワードは「ソーシャル＆モバイル」。来場者の関心は“マネタイズ”か3月9〜13日開催(現地時間) 会場：サンフランシスコMoscone Center世界最大規模のゲーム開発者向けカンファレンスGame Developers Conferen...
1970/01/01 00:00:00 [] - （番外）『カネを産むシステム』への羨望：『社内SE』の視点から - CNET Japan
- 最近、『モバゲータウン』にハマっている。TVCMでよくやってる怪盗ゲームでお馴染みの携帯コンテンツ。ちょっとした暇つぶしのつもりで興味本位だったが、思いの外サービスレベルの点でもビジネスモデルの点でも非常によく出来ていることに気づき、システムを生業とする人間としていろいろ思うところがあった。ちなみに今週の週間ダイアモンドの特集「FREEの正体」でもモバゲーに関する記事があり、FREEの成功モデルと...
1970/01/01 00:00:00 [] - InfoQ: アジャイルにおけるプロジェクトマネジャーの役割
- どの本もアジャイルのコーチやファシリィテーターの役割は語っているが、マネージャーの役割について語っていません。この記事では最初に一般的に産業界でのプロジェクトマネージャーの役割について説明し、それからアジャイルにおけるコーチ/ファシリィテーターの役割について述べていこうと思います。この議論の中でコーチ/ファシリィテーターの意味の範囲を広げていくつもりです。アジャイルにおけるプロジェクトマネージャー...
1970/01/01 00:00:00 [] - 第5回 アジャイルな要求定義に求められるもの：ITpro
- 本研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていきます。開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられるからです。今回は、アジャイルと要件定義の関係について考えてみます。みなさんはもう十分に実感されているかもしれませんが、ここ最近の私は、アジャイル開発における要件定義の重要性を改めて認識す...
1970/01/01 00:00:00 [] - InfoQ: アレグザンダー祭りにて、James.O.Coplienが語るアジャイルとスクラムの源流とは
- 作者平鍋 健児投稿日2010年3月1日 午前4時27分コミュニティArchitectureトピック設計「パターン」と呼ばれる設計手法をご存知ですか？この建築の分野ではじまった設計の形式知化手法、および、使う人と作る人の対話のプロセスは、私たちソフトウェアの世界に援用されて1995年に「デザインパターン」という書籍で注目を浴びました。さらに、アジャイルと呼ばれる開発手法には、ユーザーといっしょに対話...
1970/01/01 00:00:00 [] - InfoQ: Agile と Scrumの重大な欠陥を明らかにする
- 作者Vikas Hazrati, 翻訳者編集部Ｎ投稿日2010年3月7日 午後3時6分コミュニティAgileトピックアジャイル技術タグプロセス採用,Agile Manifesto,Scrum原文(投稿日：2010/03/02)へのリンクソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人...
1970/01/01 00:00:00 [] - InfoQ: 実験駆動開発 - ポストアジャイルの手法
- 作者Sebastien Auvray, 翻訳者徳武 聡投稿日2010年3月7日 午後3時4分コミュニティRuby,Agileトピックアジャイル技術,顧客要求,Agile in the Enterprise,方法論タグRubyConf原文(投稿日：2010/02/25)へのリンクTDDとBDDは今や、広く使われているソフトウエア開発技術だ。しかし、単にBDDやTDDに従っているだけではビジネス機会を...
1970/01/01 00:00:00 [] - InfoQ: ふりかえりを改善するためのルール
- 作者Chris Sims, 翻訳者笹井 崇司投稿日2010年3月4日 午後3時4分コミュニティAgileトピックアジャイル技術タグBest Practices,継続的な改善,Retrospectives原文(投稿日：2010/03/01)へのリンクJames Carr氏は最近、ふりかえりを改善するための5つのルールを公開した。これらのルールは、成功したものも失敗したものも含む、何百回にも及ぶふりか...
1970/01/01 00:00:00 [] - [Agile][翻訳]アジャイルコーチングで学んだ78のこと | Ryuzee.com
- Categories Agile・生産性向上 (65)Ajax/Web2.0 (7)apache (14)CMS (3)Delphi (11)Linux (45)Perl (29)PHP (106)Ruby (4)Trac (76)Zope (11)オープンソース (99)Firefox (9)OpenVZ (3)phpBB (3)phpMyFaq (12)scuttle (3)taskfreak...
1970/01/01 00:00:00 [] - InfoQ: 仮想パネル：ソフトウェアアーキテクチャの文書化について
- ソフトウェアアーキテクチャの文書化というのは、企業のアプリケーション開発プロセスにおいて重要である。プロジェクトにおけるアーキテクチャの文書化のニーズを理解する上で重要なことは、アーキテクチャの文書化がプロジェクトのライフサイクルにおいてどんな役割を果たすのか理解することだ。プロジェクトにおいて、アーキテクチャドキュメントを作成する根本的な理由は、コミュニケーションと分析と記録のためである（例えば...
1970/01/01 00:00:00 [] - InfoQ: スクラム認定制度はまた作り替えられるのか？
- 作者Vikas Hazrati, 翻訳者和智 右桂投稿日2010年2月28日 午後3時2分コミュニティAgileトピックトレーニング/認証タグ認証,Scrum原文(投稿日：2010/02/09)へのリンクスクラム認定制度は、おさまることのない議論の１つである。当初は、 認定制度というものが持つ空虚な性質 に向けられたもので、「授業料を払い、２日間にわたる授業の間椅子に座っていればなれる」というコメ...
1970/01/01 00:00:00 [] - OSC2010 Tokyo/Springに行ってきました - murapongの日記
- イベント, OSS | 21:242/26(金)にオープンソースカンファレンス2010 Tokyo/Springに行ってきたので、参加したセミナーおよび気になった展示についてまとめておきます。一番の収穫は、Trac（というよりもアジャイル）のセミナーで、今まで何となく理解したつもりになっていたアジャイルについて真面目に勉強してみようかなと思うきっかけになりました。 プロジェクト管理Webアプリ「T...
1970/01/01 00:00:00 [] - ディー・エヌ・エー（DeNA） 【ソフトウェアエンジニア】Web・モバイルシステムの自社内開発 の採用 求人情報 | 転職は【green】
- 【仕事内容】 1日14.5億PVを超える『モバゲータウン』や『モバオク』等の国内最大級のモバイルサイトや、国内有数のECサービス『ビッダーズ』『ポケットビッターズ』『モバデパ』等のECサイトの企画開発から運用までを広くお任せ致します。全て自社内開発となります。 【仕事のやりがい】 業界最大のユーザー数を誇る「モバゲー」「モバオク」など、自身が創り上げたものを世に発信することができます。又、ユーザー...
1970/01/01 00:00:00 [] - テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索
- テスト消化とバグ発生曲線(バグ収束曲線)をパターン分けした素晴らしい記事があったのでメモ。【元ネタ】 テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOistテスト消化曲線は、未実施テストケース数を時系列に表示したグラフで、普通は右肩下がりになる。 バグ発生曲線(バグ収束曲線)、累積バグ数を時系列に表示したグラフで、普通は右肩上がりになる。テスト消化とバグ発生曲線は密接に関係してい...
1970/01/01 00:00:00 [] - SEMAT.org の Signatories：An Agile Way：ITmedia オルタナティブ・ブログ
- 先の記事で、semat の共同署名者のリストを載せました。Pekka Abrahamsson Scott Ambler Victor Basili Jean Bézivin Dines Bjorner Barry Boehm Alan W. Brown Alistair Cockburn Larry Constantine Bill Curtis Donald Firesmit...
1970/01/01 00:00:00 [] - SEMAT.org にて「ソフトウェア工学再建」運動が開始：An Agile Way：ITmedia オルタナティブ・ブログ
- semat.org というサイトで始まっている、「ソフトウェア工学の再建」とも言うべき復興運動をご存知ですか。現在のソフトウェア工学が、あまりにもおそまつであることを省みて、再度、基礎からソフトウェア工学を積み上げようではないか、という動きです。そこに署名している人たち(signatories)の顔ぶれがすごい。Pekka Abrahamsson Scott Ambler Victor Bas...
1970/01/01 00:00:00 [] - TestLinkのベストプラクティス集: プログラマの思索
- 【1】ブロックテストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッキングバグが原因でテスト不能になった状態でもある。例えば、Webのカート画面でカート投入のテストが失敗した場合、注文フローのテストケースは全てブロックになる。カート投入機能にバグがあるのだから、その状態で注文のテストを続けても無意味だからだ。実際のテスト工程では、テストに失敗した場...
1970/01/01 00:00:00 [] - Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」（3月18日、学術総合センター）
- Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」（3月18日、学術総合センター）情報処理学会ソフトウェア工学研究会パターンワーキンググループは、Jolt Award を受賞した書籍『パターン指向リファクタリング入門 -ソフトウエア設計を改善する27の作法』（原題: "Refactoring to Patterns"）の著者、ならびに、エクストリームプログラミングやアジャイ...
1970/01/01 00:00:00 [] - FP法で業務モデルを計測する: プログラマの思索
- 児玉公信さんの本「システム開発の見積りのための実践ファンクションポイント法」を読んで、ファンクションポイント法を業務モデルの計測に使えないか、考えてことをメモ。 ＃まとまっていないので、あくまでもメモ書き。ファンクションポイント法(FP法)は、機能の規模の見積もりとして古くから知られている。 しかし、計算が複雑で、見積もりの根拠となるモデルが曖昧なため、普及しているとはいえない。 「システム開発の...
1970/01/01 00:00:00 []
Wikipediaサマリーなネタの種
アジャイルソフトウェア開発（-かいはつ、agile software development）は、ソフトウェア工学において迅速かつ適応的にソフトウェアを開発する軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。
アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。
アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する（⇒反復型開発）。 この反復のサイクルを継続して行い、1つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に1つの小さな機能を追加する。 計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。場合によっては、1つの反復内で開発すると計画していたソフトウェア機能を、必ずしも期間内で充分に実現できるとは限らない。このように時にはうまくゆかない反復もあるが、アジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェア (ビルド) をリリースすることを目指す。 各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。 ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる (ここでの顧客とは開発対象のソフトウェアが何であるかを定義する人々である。「顧客」は、時にはプロジェクト管理者であったり、ビジネスアナリストや本物の顧客である場合もある) 。 この作業場所では、テスト担当者、ユーザインタフェース設計者、テクニカルライタ、管理職も一緒に作業する場合がある。
またアジャイル開発手法では、実際に動くソフトウェアこそが最重要なプロジェクト進行尺度であることを、強調する。この実際に動くソフトウェアという進行尺度の採用と、直接顔を合わせた意思疎通の重視とがあいまって、アジャイル開発手法で作成する文書の量は、他の開発手法と比較すると、非常に少ない。 この少ない文書化については、無統制で雑な作業 (ハッキング、カウボーイコーディング) であるとして、アジャイル開発に対する批判材料の一つとなっている (後述する) 。