アジャイルソフトウェア開発宣言
アジャイル アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発の価値 プロセスやツールより人と人同士の相互作用を重視する。 包括的なドキュメントより動作するソフトウェアを重視する。 契約上の交渉よりも顧客との協調を重視する。 計画に従うことよりも変化に対応することを重視する。 原文 アジャイルソフトウェア開発の原則 最も重要なことは顧客を満足させること。早く、そして継続的に、価値のあるソフトウェアをリリースする。 開発の終盤においても要求の変更を受け入れる。アジャイルプロセスは顧客の競争力を優位にするための道具である。 数週間、数ヶ月の単位で頻繁に実用的なソフトウェアをリリースする。タイムスケールは短い方がよい。 プロジェクトの間中、毎日、顧客と開発者は一緒に働くべきである。 やる気のある人を中心にプロジェクトを構築する。環境と必要なサポートを与え、彼らが仕事を成し遂げると信じるこ
ソフトウェアさかば
液晶パネルが精細になったLUMIX DC-TX2D全機種の発売を記念して、カメラ選択のポイントと全機種のLUMIX DC-TX2をどう考えたかをまとめました（その１購入経緯はこちら）。 センサーのサイズ 大きいサイズのセンサーの方がたくさんの光を受けられますので、無理に感度を上げなくて良いのできれいな写真をとることができます。一般向けでは35ミリフィルムと同じフルサイズが大きくてきれいな写真えお撮ることができます。 逆にサイズが大きいとレンズのひずみが出やすくなるので、レンズが複雑になって高価に、重く、大きくなります（ひずみが大きいと写真の端の方で柱を撮ると曲がって映るなど見てわかるひずみが出たりします）。価格や携帯性を考えるとセンサーが小さい方が有利になります。 そこでカメラを選ぶ際は価格と携帯性のバランスを考えることになります。 私の場合、下の項目も考慮して1インチで良いと思いました。
eXtreme Programming
eXtreme Programming 4つの価値 コミュニケーション シンプル フィードバック 勇気 ルールとプラクティス 計画 ユーザストーリを書く リリース計画の作成 常に小さくリリース プロジェクト速度を測る イテレーション開始にあたってのイテレーション計画 あちこち歩く スタンドアップミーティング XPを自分のプロジェクトに合わせる 設計 単純に システムメタファー（比喩）を選ぶ CRC(Class Responsibility Collaboration)カードを使う リスクを小さくするためのスパイク 早い段階での非機能的要求の追加 いつでもできるだけリファクタリング コーディング いつでも顧客と コーディング標準に従う ユニットテストからはじめる すべてはペア・プログラミングで コードの統合は一つのペアで いつでも統合 コードはみんなのもの 最適化は最後 残業はしない テスト
開発現場で学べること（1）
エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■プロジェクトスクーリング 「あなたの開発現場は順調ですか？」という質問に「はい」と答えられる人は、案外少ないかもしれない。過去に多くの開発に携わり、経験も豊富なシニアエンジニアは、その過去の経験を生かしていまの開発を順調に進めることができているのだろうか。私の知っているエンジニアは、最近よくこんなことをいう。 「なぜか毎回同じような失敗を繰り返してしまう。毎回反省はしているのだけど……」 かくいう私も、毎回現場で同じような失敗を繰り返し、そのたびに反省していることは多い（もちろん、開発現場にきて数年で、経験不足という面もあるだろうが）。では、どうすればうまく開発を進めていけるのだろうか。 私はいま
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
NET開発者のための開発プロセス入門（前編） アジャイル開発を導入できていない.NET開発者たちへ
「あなたのプロジェクトでは、どのような開発プロセスを採用しているだろうか？」 ご存じのとおり、「開発プロセス」とは、ソフトウェア開発の進め方を定めたものである。一般に開発プロセスでは、開発作業の手順と内容、それを実行すべき担当者の役割、各作業の成果物であるドキュメントやプログラム、さらにそれらの指針となるガイドラインなどが定義されている。 今日まで、そのような開発プロセスがソフトウェア開発を成功させるために数多く出現してきた。これらは、単に開発プロジェクトの規模や開発言語だけを背景に考え出されたわけではない。当然、当時のソフトウェア開発が置かれていた状況や要求が大きく影響している。 そこで本稿前半では、開発プロセスの成り立ちから、現在の最新開発プロセスが誕生するまでの経緯を、その時代背景を含めて説明する。このような開発プロセスの歴史を知っておくことは、開発プロセスの本質を理解するうえで役立
Principles: The Agile Alliance
アジャイル･アライアンスの原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル･プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
yagihiro light output: 開発モデルについて云々
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。