アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
アジャイル契約
この資料では，サプライヤと顧客がアジャイル開発契約を成立させる方法として，４つのモデルを検討します。やがて新しいモデルが登場すると思われますが，現時点で選択肢として存在するのは，概ねこの４つのオプションです。 固定的な契約を覆す 固定された金額，固定された期間，固定されたスコープを持った契約は，依然として IT 業界における契約の標準的ベンチマークであり続けています。この種の契約は，プロジェクトの初期段階で作業のスコープを定義可能である，という考えに基づきます。サプライヤ側はこれを基準として，何が必要か – というより，何人がどれだけの期間必要か – を決定し，金額を算出します。それが完了すれば契約書が正式に署名され，実施に移されます。 このようなモデルは，提供される対象が "もの" ，すなわち一定量の専門的ソフトウェアである，という解釈を基準としています。しかしカスタムソフトウェアを購入
アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた
「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか？ 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け
InfoQ: ビジネス価値を見積もる
原文(投稿日：2010/01/04)へのリンク 従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装するようにする。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。 Pascal Van Cauwenberghe氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。 ユーザストーリーのビジネス価値はどうやって見積もる? いや見積もれない。と題した記事で氏が警告しているのは、ユーザストーリーが前提にあり、そのユーザストーリーのビジネス価値を評価する、という想定には根本的な欠陥がある、ということだ。そして、より優れた出発点として次の質問を考えることからはじめることを提案している。す
アジャイル開発手法ではオフショア開発でも有効ではないか、という調査結果
アジャイル開発手法はオフショアを用いた開発でも使えるのか？ この問いはアジャイル開発手法を議論する場で何度となく発せられている質問です。小規模なチームが発注者を巻き込んでコミュニケーションを密にとり、短期間の開発を反復して行うアジャイル開発手法は、地理的に離れた場所にあったり、文化的に異なるバックグラウンドを持つ人たちで構成されたチームでも有効なのでしょうか？ アジャイル開発手法のコンサルティング業務などで知られるテクノロジックアートと、アジャイル開発手法の論客マーチン・ファウラー氏が所属するThoughtWorksが主催して12月8日に都内で行われた「Agile Conference tokyo 2009」では、日立製作所の山中敦氏が、オフショアと協力して行ったアジャイル開発の例を紹介しました。 果たしてアジャイル開発はオフショア開発の現場でも機能したのか。この記事では山中氏が行ったプレ
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟
アジャイルアーキテクチャ - 矛盾? それとも賢明なパートナーシップ?
オピニオン:アジャイルとはなにか？役立たずな説か欠くことのできない質問か？
繰り返しタスクはアジャイルの臭い？
機能チームの五つの利点