Agileで失敗する時 - masayang's diary
ちょっと古いけど、こんな記事があったので訳してみた。 Allan's Blog: Failures in Agile process?(Agileでの失敗?) ACCU*1の会議でよく受ける質問に「Agile開発の欠点は？」「Agileでの失敗はどんな感じなの？」というのがある。 一つ目の質問には答える事ができなかった。ただ、プロダクトオーナーに負担がかかりやすい、という問題点はあるかもしれない。通常はビジネスアナリスト、製品マネージャ、顧客、あるいは顧客窓口の人がプロダクトオーナーになるのだけど、とても負荷のかかる仕事だ。このあたりはJames Nobleが研究しているね。 プロダクトオーナーは本来の仕事をこなしつつ、Agileチームの相手をすることになる。Agile開発チームの生産性があがってくれば、チームはプロダクトオーナーに「あれはどうするの？」「これはどうするの？」と色々と質問す
Agileによる再構築 - masayang's diary
「レガシーシステムとは？」と訊かれたら、自分は迷わず「Agileで作られてないシステム」と答える。 Java(servlet直呼び出し)で書かれた古いシステムをRailsで書き直したことがあるけど、非常にコンパクトなコードになってしまった。むしろ周囲が「これで旧システムと互換性あるの？」と心配したくらいである。 で、同じような案件がないか調べていたら次の短論文を発見。 An Agile Approach to a Legacy System(PDF、英語) 例によって無断適当に邦訳。長文注意。 An Agile Approach to a Legacy System Chris Stevenson and Andy Pols 概要: 本稿では小規模かつ自発的に形成されたXPチームがいかにしてぐちゃぐちゃな問題を抱えたシステムをきれいにしていったかを解説する。我々はレガシーアプリケーションを
＠IT：The Rational Edge （28）大規模プロジェクトにアジャイルを適用する方法
筆者は、「大規模」プロジェクトに取り組む際、「アジャイルプロセスのスケールアップ」という言い回しをよく耳にし、それが可能か不可能かをめぐるさまざまな意見も耳にする。以下の解説では、この問題を逆の方向から見てみたい。つまり、もしアジャイルプロセスがある程度明確な状況で機能するならば、大半の作業が最適なアジャイルの条件下で進み、このような条件下で優れた手法をすべて使えるよう大規模プロジェクトを変えることは可能だろうか？ と。その場合、結果はどうなるのだろう。コストは？ 組織や個人への制約はどうだろうか。 アジャイル開発プロジェクトの「スイートスポット」 アジャイル開発プロジェクトにとって理想的な条件とは何か？ アジャイル手法が成功する可能性はどのような条件で最も高いか？ 小グループ。プロジェクトチームの人数が10～15人以下の場合は、1対1で内容の充実したコミュニケーションを維持することが可能
アプリケーション開発3つのアプローチ
3.アジャイル 短期間で構築できるのでリスクが少ない アジャイルは、プロジェクトのライフサイクル全般を通して、革新的な変化を促進するソフトウェアエンジニアリングプロジェクトの概念的フレームワークだ。熟達した開発者やビジネスに精通したCIOたちにとって、この戦略はきわめて常識と思われるが、伝統的な手法と比べて十分に構造化されていないため、議論の多いフレームワークでもある。 ほとんどのアジャイル開発手法は、一般に「イテレーション」と呼ばれる1～4週間の短期フレームでソフトウェアを開発することにより、リスクの最小化を図る。それぞれのイテレーションはミニ開発プロジェクトのようなもので、プランニング、要求分析、設計、コーディング、テスト、ドキュメンテーションなど、追加的な新機能をリリースするまでに必要なすべてのタスクが含まれる。特定のイテレーションで製品のリリースに至る機能が追加されるとは限らないが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リファクタリングは設計の代わりではない
