ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（後編）。Agile Conference tokyo 2011
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 前編に続いて、ファウラー氏の基調講演の様子を紹介しましょう。 （本記事は「マーチン・ファウラー氏が語る、、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011」の続きです） 継続的インテグレーション アジャイル開発の中で重要な「継続的インテグレーション」と「継続的デリバリ」について話そう。まずは継続的インテグレーション。 複数のプログラマが集まって開発しているソフトウェアでは、それぞれのプログラマのコードをマージする作業に苦労する現場を多く見てきた。 あるソフトウェアプロダクトに二人のプログラマ
アジャイルはウォーターフォールよりも難しい
ここにきて、アジャイル開発手法を業務システム（アプリケーション）の開発に適用しようとする動きが本格化している。これまで小規模、Webシステムへの適用が目立ったが、最近は業務システムや大規模プロジェクトへの適用事例も出てきた。アジャイルはもはや“ブーム”ではなく、本格的な普及が始まったと見てよさそうだ。 ところが、実際にアジャイルを採用した現場に話を聞くと、何とことごとく失敗している。そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。 それでも開発現場はアジャイルに望みをかけている。刻々と変わる要求やリスクに迅速に対応する必要があるからだ。最
AgileJapan2018
Timetable | タイムテーブル 資料公開しております。 Timetable | タイムテーブル Satellite | サテライト サテライトオーナー募集しています。 Satellite | サテライト Theme ｜ テーマ Rebuild our Agile! 「再会、再構築、再開発・・・究極のAgile体験へ」 今年のテーマは、「Rebuild our Agile!」とし、私たちのアジャイルマインドやカルチャーを新たな高みへ導き、いにしえの輝きを取り戻し、新たな未来へ向けて進化することを目指したいと思います。「Rebuild our Agile!」には「再会」「再構築」「再開発」という3つの要素を含んでいます。 カンファレンスでは、アジャイルの考え方や組織への適用方法を一新し、より強力で効果的なものに再構築する意欲を持ち、アジャイルのあり方を見直し、進化させ、新たな世界を創り
スクラムとかんばんの議論、対立か両立か？
ソフトウェア開発において、スクラムとかんばんとは、対立するものなのか、それとも両立するものなのか。同じ日に異なる意見がブログで表明されていると、平鍋健児氏のブログ「An Agile Way」のエントリ「かんばん、と、スクラム。現時点での最新議論。」で紹介されています。 かんばんで削ぎ落とすムダとは創造性だ Waterfall, Lean/Kanban, and Scrum « Ken Schwaber's Blog: Telling It Like It Is 平鍋氏は、スクラムの創始者であるKen Schwaberが6月10日にポストしたエントリ「Waterfall, Lean/Kanban, and Scrum」について、自身のブログで次のように紹介しています。 Kenは、「スクラムは難しい問題を人間の創造性を使って解くためのもの。かんばんを使っても、ウォーターフォールに隠れていた無駄
ソフトウェア開発をシンプルにする考え方のコツ ― ＠IT
ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費 やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約