CMMIにAgileの思想とプラクティスを取り込む動きは2006年あたりから始まっていたが、今回開催されたSEPG Conferenceにおいて以下のような議論が進行した。 従来のウォーターフォール思想を基盤としたCMMIは今後メンテされない。つまり進化しない。(お猿さん向けに残るには残る。) AgileはCMMIに正式に取り込まれる。 ただし、CMMIが重視する「成熟度」「再現性」などはAgileであっても尊重されなければならない。 成熟度や再現性が問われる以上、プロジェクトは一定以上の「見通し」が確保されるべきである。 すなわち、イタレーションやスプリントという言葉に代表される「やってみて、できるところまで作業する」という姿勢は正されるべきである。 このような考えのもと、Agile+CMMIはRUP(Rational Unified Process)を踏襲した工程名を採用することになっ
原文(投稿日：2010/03/02)へのリンク ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか？ Kai Gilb 氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。 氏は、Agile の栄光にもかかわらず、 ある重大な欠陥があるという、 Agile に関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます：欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。 氏は、 AgileやScrumの焦点は、間違っている、と言う。これらは、ステーク
標準化は業務活動に必要不可欠なものだが、それが企業や組織の「強み」を破壊してしまうとしたら、そんな標準化を実施してはいけない。業務には、標準化すべきものと、そうすべきでないものがある。ある点に注目すれば、「標準化すべきか否か」が自ずと明らかになる。 標準化の効果としてよく期待されるのは「属人化の排除」だ。ご存じの通り、属人化とは特定の業務プロセスが特定の担当者に強く依存して行われている状態を指す。特定の担当者に業務が集中しがちになり、「会計システムは、あの人が対応しないと仕事が回らない」とか、「この帳票システムの設計書のレビューには、あの人がいないと不安だ」といった事態に陥ってしまう。 属人化は、IT部門ではよく起こる問題である。IT部門の業務は、専門的なITの知識が問われつつ、さらに業務の知識も問われる。2つの異なる知識と幅広い経験が求められることから、どうしても担当できる人が絞られてく
不況の折は、特にリスクマネジメントが問われる。 そういう意味においては、フリービット社の石田氏のこの行動指針は、リスクヘッジのための黄金の法則だと思っている。*1 早く動いて、早く失敗して、早く修正する。 以前のエントリを書かせてもらったが、「ベスト」ではなく「ベター」な戦略で未来に起きるリスクを早期に回避することが仮説思考だ。まさにその仮説思考に通じる行動指針といえる。 つまるところ、最後のゴールにリスクを持っていかないことだ。ゴールの到達までに、早期に実践し、失敗し、修正することを繰り返すことだ。最後に実践し、失敗することは避けなければならないのだ。 ビジネスの分野ではもちろん有益な行動指針であるが、開発プロセス論に適用すれば、「アジャイル」のような開発プロセスになる。XP本に書いてあるハンドルを小刻みに動かして車の行方を常に軌道修正するあれだ。また、設計と実装の実践論においては「テス
情報家電にオープンモデルが採用されることでセキュリティ上のリスクが高まりつつある。今回は家電製品のライフサイクルに照らして、セキュリティ対策をいかに講じるべきについて掘り下げていこう。 前回は情報家電におけるセキュリティ脅威として、不正プログラムによる攻撃、製品自体への不正プログラムの混入、フルブラウザを通じたWebからの脅威に関する事例を挙げ、セキュリティ対策の必要性を検証した。今回はこれらの脅威に対してどのような対策を打つべきなのか、そのフレームワークと対策の詳細を提示し、特に情報家電の企画や設計、開発段階におけるポイントを紹介したい。 セキュリティ・ライフサイクル・マネジメントを考える テレビなどの家電は、数年から場合によっては10年を超える長期間に渡って使用される非常に寿命の長い製品である。情報家電はメーカーで企画、開発、製造され、小売業者などを通じて流通してユーザーが購入、使用す
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ソフトウェアインスペクション・ワークショップ 2009に行ってきました。 定員は60名だったと思うのですが、100名ぐらいが結局参加している様子で、席もいっぱいいっぱいだった事を考えると欠席者も少なかったんじゃないかと思います。 それだけ興味/注目をもって来た方が多かったって事でしょうか。 このワークショップですが、メインはハンズオンとして、実際に個々人でコードレビューを行いその結果を研究材料にするという感じ。 ソフトウェアインスペクションとは？ どうやったら効率いいのか？ というのを聞きに行くようなものじゃありませんでした。 「コレがベスト。一番効率いいっす！」なんてものはまぁないですしね。 ハンズオンの内容ですが、「仕様書」 と 「コード」 を対象に、或る人は Adhoc, 或る人は SGIT, 或る人は Guided Checklists が手渡され、その観点を元に一定時間内に欠陥を
“ベンダーがいないと何もできない”現状 一般にシステム開発は「V字型のプロセス」によって実施されることが多い。このプロセスには「ユーザー主体の作業」と「開発ベンダー主体の作業」が存在する。上流工程では、ユーザーが主体となりシステム化構想が行われ、ユーザーがベンダーの支援を受けてシステム要件を定義する。その後、ベンダーがシステムを実装し、その成果物をユーザーが受け入れテストとして検証するという流れである。 V字型のシステム開発プロセス しかし、多くの企業では「ユーザー側が主体となるべき工程までベンダーに依存している」のが現状ではないだろうか。 本稿で紹介するH社は、システム開発のほとんどを特定のベンダーに委託しており、システム開発の主導権をベンダーが完全に握っていた。このため、以下に挙げるようなさまざまな課題があった。 開発コストがベンダーによってコントロールされてしまう 長い付き合いによる
要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム
今日の不景気の中で、ITマネジャーは自分がIT部門で“最後に残された人”のように感じているようだ――実際、そういったケースもないわけではない。もしあなたもそのようなITマネジャーの1人だとしたら、責任の重圧で押しつぶされそうになり、孤立無援の状態に置かれたあなたの現在の任務は、IT部門の業務効率を維持することである。IT部門に最後に残された1人（あるいは最後のスタッフ）として何をなすべきかという判断を迫られている人に対して、わたしは通常、長期的なソリューションに目を向けるようアドバイスするが、今日の状況では短期的なソリューションも必要だ。 ITプロフェッショナルが今日の職場で生き残るためのキャリア管理テクニックを幾つか紹介しよう。 時間を浪費しない わたしがセキュリティ評価を実施して分かったのは、ビジネスリスクを生み出すのは、技術面での脆弱性や運用上の不注意などではなく、勤務中に時間を浪費
なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。 例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか？なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。 いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。 この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
