ニューヨークだより 2005 年 7 月.doc 「米国におけるアジャイル・ソフトウェア開発の動向」 渡辺弘美＠JETRO/IPA NY 新たなソフトウェア開発手法 ― アジャイル・ソフトウェア開発 1. ソフト�
ニューヨークだより 2005 年 7 月.doc 「米国におけるアジャイル・ソフトウェア開発の動向」 渡辺弘美＠JETRO/IPA NY 新たなソフトウェア開発手法 ― アジャイル・ソフトウェア開発 1. ソフトウェア開発の新たな手法として、アジャイル・プログラミングに注目が 集まっている。アジャイル開発を導入することによって、従来の開発よりも、早 く、安く、しかも品質の高いソフトウェアを開発することが狙いである。 『Agile and Iterative Development: A Manager’s Guide』の中で著者の Craig Larman はアジャイル開発を次のように定義している。 アジャイル開発 (agile development) 手法は、適応型の計画を行い、タイムボ ックスを適用しながら反復型・進化型の開発を行い、段階的に出荷するもの であり、そのほかにも
海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言
海外ではなぜアジャイル型開発が普及しているのか、IPA（独立行政法人情報処理推進機構）が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro
前回，タスクかんばんが，現在の状況を見える化するものであり，先を見通すような視点は持ち合せていないことを説明した。この「先を見通す視点」で「進ちょく状況の見える化」を実現するのがバーンダウン・チャートと呼ばれるチャートである。バーンダウン（burn down：燃え落ちる，全焼する）チャートは，一般的なチャートにありがちな右上がりではなく，右下りになっている。チャートを作成する際には，縦軸に残りの作業量を，横軸に時間を割り当てて日々の残り作業量をプロットしていく。右下，つまり残り作業量がゼロ(=全焼)になれば，すべての作業が完了するというわけだ。 バーンダウン・チャートは，元々リリースまでのバック・ログ（プロジェクトとして実施する必要があるすべての作業）の残量を視覚化するチャートだったが，現在はイテレーション単位でのタスクの残作業量（デイリー・バーンダウン・チャート）の見える化にも使われてい
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
アジャイル型開発を推進するための活動成果を公開 - 情報処理推進機構：ソフトウェアエンジニアリング
2012年3月26日 更新 2011年4月7日 公開 独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 概要 最近のソフトウェア開発では、ビジネス環境の変化への対応、これに伴う要求の変更、ソフトウェアの市場投入や投資効果の確認の迅速化が、以前にも増して厳しく求められています。このような状況において、要件を最初に決めずに開発に着手できるアジャイル型を中心とする非ウォーターフォール型の開発手法が注目されています。 IPA（独立行政法人情報処理推進機構）ソフトウェア・エンジニアリング・センター（SEC）では、ウォーターフォール型開発及び、アジャイル型開発の経験が豊富な実務者、契約に詳しい専門家など、産学官の有識者をメンバーとした「非ウォーターフォール型開発ワーキンググループ」を設置し、これらの課題について検討してきました。 この度、日本におけるアジャイル型開発に適したモデル
プレス発表 俊敏かつ柔軟なシステム開発を可能にするアジャイル型開発を推進するための活動成果を公開：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）ソフトウェア・エンジニアリング・センター（以下、SEC）は、アジャイル型開発の適用領域や適用方法を整理するための活動を行い、アジャイル型開発に適したモデル契約書案2種を含む「非ウォーターフォール型開発WG（*1）活動報告書」（以下、報告書）を公開しました。 URL： http://www.ipa.go.jp/sec/reports/20110407.html 現在、日本におけるソフトウェア開発の殆どは、ウォーターフォール型と呼ばれる手法です。この開発手法は、初期にシステムに対する要件を正確に決め、前工程を誤りなく完了させ次に進むことが求められます。しかし現実的には、要件の間違いが後で判明することや、開発着手までに要件を確定できない場合もあり、これらに起因するシステムトラブルや開発の遅れが生じています。 このように、初期段階で顧客ニー
ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版) - その2
テストコード書いてますか？ HIROKIです。 murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。 1．テストが重要だという共通認識を持つ。 前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。 その経験を元にテストが重要だという共通認識を持つことができました。 2．プロジェクト開始時からテストファーストに踏み切る気持ちが必要 テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。 3．でも、テストコード書いたことないよ？ テストコードを書いたことの
- データベースの進化的設計
データベースの進化的設計 Martin Fowler Pramod Sadalage 原文(Evolutionaly Database Design) ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。 変化に対応する 制限事項 プラクティス集 DBAは開発者と密接に協力し合う 全員が自分のデータベースインスタンスを保有する 開発者は共有マスターに頻繁に結合する スキーマとテストデータから成るデータベース すべての変更でデータベースのリファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
