CMMIに関するamnmaのブックマーク (12)
-
amnma 2014/03/12
-
CMMとAgileについて、Capers Jones の記事：An Agile Way：オルタナティブ・ブログ
アジャイルとCMMの比較記事です。 ■ Development Practices for Small Software Application http://www.stsc.hill.af.mil/crosstalk/2008/02/0802Jones.html Agile と CMM(or CMMI) の考え方の共通点として、 ソフトウェア要求は、常に変化する。 欠陥を修正するのは最もコストが高い。 高品質であることが、生産性と納期短縮につながる。 としていて、逆に異なる点として、 ドキュメントを書くことは二番目にコストが高い(Agile) 測定しなければ、継続的な改善は起こらない(CMM) を上げている。そして、1,000 FP の小さめのプロジェクトで、アジャイルチームとCMM 3 チームを統計して、 Agileの方が生産性(短時間あたりのFP）が高い。 Agileは欠陥潜在を下
-
InfoQ: SEIがCMMIとアジャイルの統合に関するレポートを発表
SEIがCMMIとアジャイルの統合に関するレポートを発表 いいね | 作者： Manoel Pimentel Manoel Pimentel フォローする 0 人のフォロワー , 翻訳者 沼田 暁子 沼田 暁子 フォローする 0 人のフォロワー 投稿日 2008年11月23日. 推定読書時間： 2 分 | 共有 | 後で読む マイリーディングリスト 先日はソフトウェア開発の国際的なシナリオが熱かった。ソフトウェア工学研究所(リンク)（Software Engineering Institute：SEI）は最近、「CMMIかアジャイルか：両者を採用してみては！」と題されたレポート(リンク) を発表した。その中では、CMMIのアイデアやプラクティスとアジャイルのアイデアやプラクティスとの一体化を、ソフトウェア開発プロジェクトで可能な何かとして扱っている。 このドキュメントはDavid Ande
-
-
-
CMMIなら、どんなチームも開発効率を改善できる
CMMIなら、どんなチームも開発効率を改善できる：今日からできる“CMMI流”開発効率改善術（1）（1/2 ページ） ソフトウェア開発のスピードと品質は、プロジェクトチームの開発能力に大きく依存している。しかし、ただでさえ日々の業務に忙殺されている中、チームの開発能力と作業効率を着実に改善していくためにはどうすれば良いのだろう？ V1.3がリリースされ、さらに使いやすくなったCMMIにヒントを探る。 開発組織が着実に成熟するための道標、CMMI 市場競争が激化している近年、企業にはビジネス展開のスピードと品質が求められています。そうした中、業務を支えるソフトウェア開発の品質・生産性向上のために、あらゆる標準モデル・技法が編み出されてきました。例えば、PMBOK、SLCP-JCF、アジャイルのスクラム開発などは多くの方がご存じかと思います。 本連載でご紹介するCMMI（capability
-
徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント
スクラムとCMMIの基礎知識 では、スクラムとCMMIの対比に入る前に、まずはそれぞれの基礎を簡単に振り返っておきましょう。以下の図1をご覧ください。これはスクラム開発の流れを簡単にまとめたものです。 スクラムでは、まず「プロダクトバックログ」を管理します。システムが備えるべき機能をエンドユーザー視点でまとめたものを「ユーザーストーリー」と言いますが、プロダクトバックログとは、それを機能単位に分割し、一覧にしたものです。例えば、オンラインショップのシステムなら「新規ユーザーを登録する」 「商品を検索する」などです。プロダクトバックログは、真ん中の大きな輪で示した「スプリント」に回され、開発作業に入ります。 「スプリント」とは、2～4週間のサイクルで繰り返し行う「作業時間の単位」です。ここでは、開発するプロダクトバックログを管理可能な単位に分割した「スプリントバックログ」という概念が存在しま
-
アジャイルの概念を取り入れたCMMI - プログラマの思索
岡本 隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。 ラフなメモ書き。 【元ネタ】 徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント CMMI | CMMI Solutions | Translations | CMMI 日本語翻訳版 上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。 ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。 「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。
-
なぜかうまくいかない「標準化」、その失敗パターンとは？ - 週末スペシャル：ITpro
CMMI、ITIL、PMBOK、COBIT、ISO27001――。システム開発/運用や業務プロセスの「標準化」に役立つ“お手本”は、いろいろある。だが、標準化に取り組んだ結果、現場から聞こえてくるのは「窮屈だ」「かえって生産性が落ちた」「品質がちっとも上がらない」といった不満の声ばかり、というケースが多い。苦労して取り組んだにもかかわらず、「標準」がいつの間にか形骸化してしまう。 よい“お手本”があるのに、なぜ標準化はうまくいかないのだろうか。そこには6つの典型的な失敗パターンが存在する。好評連載「失敗する標準化」では、筆者らが見てきた失敗事例をもとに失敗パターンをあぶり出し、その解決策を提示する。標準化の策定や定着化に悩む現場のリーダーやマネジャには、ぜひ参考にしていただきたい。 連載目次 第1回 窮屈で効果薄の標準化はもういらない 第2回 業務を把握できていない組織が陥る罠 第3回 「
-
窮屈で効果薄の標準化はもういらない
業務プロセスの「標準化」は、プロセスの品質を高め、より良い成果を安定して生み出すために必要とされている。だが、標準化に取り組んだ多くの事例が失敗に終わっている。かえってプロセスが非効率になってしまう例さえある。窮屈なばかりで効果が薄い標準化はもういらない。「失敗する標準化」の原因を明らかにするとともに、成功への道筋を提言したい。 標準化は、なぜ失敗してしまうのだろうか――。昔から標準化の取り組みは盛んだが、どういうわけか同じような失敗を繰り返している。 最近のIT業界には標準化への取り組みに効果を発揮する様々な方法論が存在している（図1）。変化に強いITのあり方を定義する「EA」、ITガバナンスの確立や内部統制の整備を支援する「COBIT」、開発組織に継続的な改善を促す「CMMI」、そしてIT運用におけるノウハウを集約した「ITIL」など、上流から下流まで標準化の推進に役立つ方法論は一通り
-
CMMI V1.2 モデル 公式日本語翻訳版
CMMI for Development V1.3 is now available in a Japanese language translation. The translation was sponsored by JASPIC (Japan SPI Consortium). The translation was performed and verified by JASPIC CMMI V1.3 translation project. 『開発のためのCMMI 1.3版』の日本語翻訳版は、ここから入手することができます。 この日本語訳は、日本SPIコンソーシアム（JASPIC）の援助を受けて、「日本SPIコンソーシアム（JASPIC）CMMI V1.3翻訳研究会」により翻訳および検証が行われました。
-
CMM/CMMI導入・成功と失敗の分かれ目（1/3） ― ＠IT
組み込みソフトウェア／ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
