arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 2007年6月19日に実施されたJavaWorldDAY2007にて、JavaとLLで実現する「アジャイル・アーキテクチャ」という講演をさせてもらいました(使用したパワーポイントのPDFファイル)。 もともとがITアーキテクト次号の特集用に書いたものなのでコードよりも概論が多くなっています。しかも、マシンがうまくディスプレイを認識してくれなくてもデモもできずにすみませんでした。以下、概要です。 アジェイル・アーキテクチャとは何か どんなことにでも対応できる万能アーキテクチャは存在しません。僕なりには「ビジネス環境で起こりうる変化に迅速に対応できるように適切に選択されたアーキテクチャ」ととらえています。ポイントは以下の2つになります。 - 起こりうる変化を管理する
米IBM Practice Leader Agile DevelopmentのScott W.Ambler氏 19日、東京都千代田区において、IDGジャパン主催の技術カンファレンス「JavaWorld Day 2007」が開催された。JavaWorld Dayは、昨年末まで定期刊行されていたJavaWorld誌の内容をライブで技術者へ伝えることを目的として始まった技術カンファレンス。同誌が休刊になった現在も、継続して開催されている。 7回目を迎えた今年のJavaWorld Dayでは、「The Agile Modeling(邦訳:アジャイルモデリング)」などの著書で知られるScott W.Ambler氏をはじめ、国内外の著名なエンジニアによる10のセッションが設けられた。ここでは、同カンファレンスの中からScott W.Ambler氏の基調講演を取り上げ、その模様をお伝えしよう。 アジャ
最懂你的优质手机视频网站,禁止未满18岁人员进入,本站视频永久免费、免下载、最佳看片体验。亚洲伊人色欲综合网,三级国产三级在线,亚洲婷婷五月激情综合查询,久久国产欧美日韩精品,夜夜添夜夜添夜夜摸夜夜摸,国产精品乱码高清在线观看,欧美成人精品视频在线不卡,免费提供最火爆最优质的好电影,性感的美女波霸、迷人的午夜诱惑是您寂寞消遣的网站!
ソフトウエア開発の世界でアジャイル手法が注目されている。「アジャイル」というのは「俊敏な、素早い」という意味の英単語(agile)で、「アジャイル開発」とは、 ユーザーからの要望にもとづいて素早く『動くソフトウエア』を組み立て、それを用いて要望をより具体化しつつソフトウエアに反映させる といった開発スタイルを意味する。 筆者自身もアジャイル開発には共感を覚える。ユーザーが事前に表明できるシステム要件は非常に限られたもので、それに頼って仕様を固めることには無理がある。どうしても、ユーザー要件を漸進的に具体化するための「動くソフトウエア」のような仕掛けが要る。 とはいうものの、その適用に関しては疑問もある。アジャイル開発では、小さなモジュール毎の「設計・構築・テスト・評価」の繰り返し(イテレーション)で作業が進むが、そもそもその「小さなモジュール」を切り出す根拠がよくわからない。この問題はシス
コーチングやファシリテーションは、IT業界でも積極的に取り上げられ、活用している企業や個人も多い。そこで本連載では、コーチングやファシリテーションなどのヒューマンスキルを活用している人と、その事例を紹介していく。 今回はWebシステムの構築プロジェクトで、アジャイルプロセス(コミュニケーションを重視する開発プロセス)、コーチングなどを盛り込んだプロジェクトファシリテーション(参加者の協業の場作りに重点を置いた、プロジェクトの中でのファシリテーション)を実践した松本潤二氏の事例を紹介します。 本事例は、アッズーリが受託した案件で、Javaによる企業間取引のWebシステムです。要件定義からリリースまでの新規開発案件で、2005年4月から7月末までの4カ月間で行いました(その後も契約は継続中)。 納品までの1回のサイクル(以下、イテレーション)は2週間で、計画・開発・リリースを8回ほど繰り返しま
ソフトウェア開発ではこれまで、設計の重要性が繰り返し提言されてきた。良い設計ができれば、仕様を満たして正しく動作するだけでなく、理解や変更がしやすく、さらに再利用しやすいシステムとなる。逆に、そのようなシステムが実現できているのなら、それは良い設計であったといえるだろう。 では、良い設計が実践できているかというと、できていないことの方が多いのではないだろうか。例えば以下のような状況を聞くことは決して少なくない。 良い設計が実践できていない例: 不具合を修正してリリースしたら、その影響によりほかの個所で不具合が発生し収束に時間がかかった ほぼ同じコードが複数個所に大量に存在するため、1つの目的の修正でも数多くの同じ修正が必要となった 修正した場所と本来関係ない個所で問題が発生してしまった 機能アップする場合、修正するより作り直す方が早かった それでは良い設計を実践し、このような状況に陥らない
連載 開発をもっと楽にするNAgileの基本思想 第1回 アジャイル開発ではドキュメントを書かないって本当? ――より良いコミュニケーションを実践するコツ―― 福井コンピュータ株式会社 小島 富治雄(Microsoft MVP 2006 - Visual C#) 2006/02/22 はじめに 本連載は、人気連載「NAgileで始める実践アジャイル開発」の姉妹版となる別枠の新しい連載である。「NAgileで始める実践アジャイル開発」の連載が基本的にプラクティスを実行する方法やツールにフォーカスしているのに対し、本連載ではアジャイル開発の基本思想を身に付けるためのコツを中心に書いていこうと思う。 どちらの連載もNAgile開発を実践するうえで欠かせない知識となるので、基本版「NAgileで始める実践アジャイル開発」と姉妹版「開発をもっと楽にするNAgileの基本思想」の両連載(NAgileシ
PF(プロジェクトファシリテーション)の1つのプラクティスである、「かんばん」。最近よく講演をするのですが、よく聞く悩みが、「うちのチームには壁がありません…」 そこで、紹介したいのが、これ。 Kanban-nano ... (モバイルかんばん!) 普通は壁に貼るのだが、これをポータブルにする。めちゃめちゃおもしろいです。昨年末のオブジェクト倶楽部クリスマスイベントのライトニングトークスで、CCSの佐藤竜一さんが発表した、「形から入る『見栄っぱり』アジャイル開発講座」に出てくる、アイテムです。 かんばんを安定させるための、「まな板立て」の利用法に注目。こういうちょとしたディテールへの実用的な工夫が泣かせます。(※協力 CCS佐藤竜一) どこにでもかんばんを持ち出そう スーツにも、ベストマッチ。オフィスを颯爽と駆けろ
スクラムという開発スタイルがあるらしい。 スクラムとは、チームとそのサイクルを意味するもので、次の5つのプラクティスからなるスタイルだそうだ。 http://www.tech-arts.co.jp/agile/agile8.html 【スプリント】 30日ごとに課題を決める 【スプリント・レビュー】 30日終了後に、関係者全員でレビュー&次を決める。 【バックログ】 残り課題リスト。 【スクラム・ミーティング】 毎日ミーティング。 【スクラム・マスタ】 チームを前進させ、守り、責任を持つ。 なるほど。 おれの勤務先での開発スタイルは 基本的には週単位でリリース 週に1時間、社内全関係者で次の週の課題(機能、バグ)を決める 開発タスク(や要望、不具合)は全部BTS(影舞)管理 週の課題として決まったら「受付」ステータス 毎朝、技術スタッフは、下記についてスタンドアップミーティング 昨日やった
に行ってきました。 いろいろ決めてきたのですが、内容についてはあとで書くか、Rubyの会MLの方で。 英語ではすでに速報が。 http://redhanded.hobix.com/cult/rubyspameeting2006.html がまだできてません……。どうしよう。盛り込みすぎか? メモ。 XP2.0 chap.23のアレグザンダーの話は、Kent Beck自身の話でもあると思います。 彼もまた、いったんデザインパターンで失敗したのでした。顧客と開発者の間で使える言語を夢見たパターン言語は、しかし開発者が独占することになってしまいました。顧客がデザパタを使えるようになることはありえないでしょう。そしてそれを間違ったことだと、失敗だったと思っている開発者はほとんど皆無でしょう。だって、ふつうそんなこと思わないですよね? ……その、「ふつうそんなこと思わない」という状態になってしまった
坂田さんやヤマモトさんがやっている「ニコニコカレンダー」という今日の自分のムードの見える化手法がある。 http://www.geocities.jp/nikonikocalendar/index_ja.html チームの壁にこれを貼って、今のチームムードを全員でフィードバックする。ちょっとうまくリーダーに報告できないような「こころもち」も、これなら気軽に伝えられる気がする。略して「ニコカレ」。命名者は、 “つらい気持ちの人も、体調の悪い人も、変化のない毎日の人も、シールを貼っていくうちにこのカレンダーがニコニコマークでいっぱいになればいいなぁ、という気持ちでニコニコカレンダーとつけました。” という。mixi にも、「ニコニコカレンダー愛好会」というコミュニティがある。 ところで、「ブログ」というメディアを使って、「世界ニコカレ」の実験をしてみたい。ブログエントリの「題名」の最後に、自分
The AgileTrack Projectは16日(米国時間)、AgileTrackの最新版となるAgileTrack 0.5bを公開した。AgileTrackはJavaで開発されたソフトウェア開発トラッキングアプリケーション。特にアジャイル手法やXP(Extreme Programming)手法を使った開発をトラッキングする。 AgileTrackは開発のトラッキング以外にも、バグ管理、ISSUE管理、サブタスクの管理、時間トラッキング、複数プロジェクトの管理、イテレーションプラニング、イテレーションレポートなどの機能を提供している。また、管理のためのユニークなインターフェースを提供しているという特徴もある。 AgileTrack 0.5bは主に付属ツールのLinux配布物における改善に注力したもの。新しいインストールスクリプトは、Javaのインストールパスを適切に処理するようになって
■1 PofEAA読書会:第9回 『エクストリーム・プログラミング 説明編:変化ヲ抱擁セヨ 第2版』:Distilled 「日本にまだ輸入されていない」XPの第2版のなかでも高橋さんが読めと言っていたという第23章を簡単に(というか乱暴に)要約してみた。アーキテクチャとかに興味があるような人たちに伝えてみたかったので。期待してくれていた方もいらっしゃったようなのだけれど、期待に応えられたかどうかはあまり自信なし。当日のRabbitの資料を置いときます: 『時を超えたプログラミングの道』(HTML + PNG via Rabbit) 資料に書いてなくて当日言ったこととしては、第2版の邦副題(変化を受け入れる)は、事の半分しか語ってない、ということ。 原副題(Embrace Change)は語っているのに邦副題が語っていないもう半分とは、本文の1行目、すなわち「XP is about soci
http://d.hatena.ne.jp/takahashim/20060103#c1136479145でkakutaniさんの言う通り、アジャイルは日本でも少しずつ広がりつつはありそうですが、実際のところはまだまだ普及には至っていないでしょう。XPに至っては、すべてのプラクティスを実行できている、という例はほとんどなさそうです。私自身はアジャイルに近い立場にいるので、ちょっと偏っているのですが、それでも現場まで浸透しているとはとても思えない状況です。 元々日本は、ソフトウェア開発ではアジャイル的な手法が使われていなかったようで(といっても、昔のことはよく知らないのですが……)、特に「使えなくなった」とか「海外に盗まれた」ということはないようです。ただ、様々な場面でのコミュニケーションの問題が大きくなり、アジャイル的な手法を求める声が出てきているのだと思います。そういう意味では、「水平的
http://d.hatena.ne.jp/takahashim/20051230#c1136188711 コメントどうもありがとうございます。長くなったので本文に書きます。 アジャイル開発は「アジル生産システム」とは関係なさそうです。アジャイル開発(またはアジャイルソフトウェア開発)は、2001年2月にアメリカで生まれた言葉で、ソフトウェアを重厚長大な計画のもと開発するのではなく、もっとシンプルかつ顧客や開発者間など、人間のコミュニケーション重視で開発する手法です。 アジャイル開発と目されている開発手法は複数あるのですが、その中でもXP(エクストリーム・プログラミング)がアジャイルの最右翼と言われています。XPは二人一組になって同じディスプレイ・同じキーボードを共有し、互いに相談しながら相互監視状態の下でプログラミングをする「ペア・プログラミング」や、顧客といつでも相談できるように、ずっ
個人的にすごく考えさせられる本に出会えました。 大野正和『まなざしに管理される職場』(ISBN:4787232495) たとえば、ドイツに関する報告では、1980年代後半からの「ジャスト・イン・タイム」や「リーン生産方式」といった日本的経営の手法の導入が、ストレスにつながっているといわれる。(15ページ) だが、驚くべきことにジャスト・イン・タイムといった日本的経営・生産システムの組織デザインでは、このスラック資源を取り除いて構成員同士の強い相互依存関係をつくりだしたのだった。これに顧客第一主義が結びつくと、職場から市場まで一貫した強い人間関係の連鎖が生まれるのである。ひたすら顧客(市場)を志向した生産への努力は、納期の厳守や製造のムダとりなどあらゆる局面にわたって人々を駆り立てる。(38ページ) ピア・プレッシャーには、「他人に負担(迷惑)をかけた者に制裁を加える」という傾向だけではなく
* コミュニケーションと品質保証 ウォーターフォールという昔ながらのソフト開発手法も、アジャイルという最新のそれも、コミュニケーションと品質保証の為の決めごとであることは共通している。 品質保証とは「このプログラムにはバグがありません」という嘘をなぜつき通せるかという理由であり、コミュニケーションとは開発者の頭の中で何が一致しているべきかという指標である。 両者の相違点は、この二つを瞬間的に濃密にやるか継続的にやるかだ。ウォーターフォールは、設計の区切りとテストの時、瞬間的に濃密な最高レベルのコミュニケーションと品質保証をしようとする。アジャイルは、コミュニケーションと品質保証を継続的にやろうとする。 もうひとつの違いは、ウォーターフォールがコミュニケーションと品質保証を主としてドキュメントでやろうとするのに対し、アジャイルはプログラムのコード自体でやろうとすることだ。 コミュニケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く