皿に盛ったご飯に卵割って混ぜて豚肉乗せてキャベツ盛ってドーン : まめ速
1：以下、名無しにかわりましてVIPがお送りします：2011/11/21(月) 22:41:10.16ID:fnuZut0t0 うまい 3：以下、名無しにかわりましてVIPがお送りします：2011/11/21(月) 22:42:28.25ID:fjtEqtMj0 調味料が要る 4：以下、名無しにかわりましてVIPがお送りします：2011/11/21(月) 22:42:47.69ID:aMK5gK4ZO 生キャベツはまだいいが、生肉はやめとけ 6：以下、名無しにかわりましてVIPがお送りします：2011/11/21(月) 22:44:10.54ID:fnuZut0t0 おまいら融通きかねぇなあ。スレタイ入らないから割愛したんだよ。 各自でなんとかしろ。仕方ないから詳しく書いてやるよ 皿に盛ったご飯に卵割って白ダシかけて混ぜて豚肉乗せてキャベツ盛ってマヨネーズかけてドーン 7：以下、名無しにか
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
要求の品質
BABOKの最重要ポイントは、要求の品質にある。 そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償（ただ）で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと]（とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける）。 しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。
新ビジネスモデル研究会（第27回）2010/3/30 ビジネスプロセス革新協議会（BPIA）
杉浦 和史 氏 はじめに－現場主導の仕様作成 本日は、システム開発の進め方についてお話いたします。 現場主導の仕様作成について、宮田眼科病院院内総合電子化プロジェクトの実例を示しながらご説明いたします。私は、2000年から宮田眼科病院の業務改革とそれを踏まえてのシステム整備を指導しています。この病院は宮崎県都城市に本院あり、分院が鹿児島市にあります。地方にありますが、開業から50周年を迎える病院です。来院患者数が年間約15万人、手術件数は約8000件の病院です。規模的には眼科で全国２位くらいだと思います、眼科というのは検査項目が95種類あり、一つの診療科の検査としては最も数が多く、また、時間辺りに診る患者の数が多いのも眼科の特徴です。宮田眼科病院では、現場の人達が仕様を作成しています。しかも、基幹業務の仕様作りですから、本当に作れるのかと思うかもしれません。ところが当院では、ベンダのＳＥ
Software Development Practices in Practice
A deep dive into TDD, BDD, DDD, design patterns and design principles.Read less
PragPub October 2010 | Way of the Agile Warrior | The Pragmatic Bookshelf
Ten Questions You’d Be Crazy not to Ask at the Start of Your Project by Jonathan Rasmusson It starts out so hopefully. As you begin the project, you and your team are all on the same page. Or so it seems. Then you start actually building, and you realize that you all had something different in mind. Has it happened to you? How many of your projects start off like this: You and your team get togeth
Agile Storycarding
An awesome process flow for storycarding. Much thanks @desi and @hashrocketRead less
User Stories for your Product Backlog
This is a general introduction into user stories, their advantages and a suggestion how to use them in scrum projects.Read less
Agile Requirements Writing
The document provides guidance on writing requirements to define a software project from concept to coding. It discusses establishing the client's needs through defining the territory, context and direction. It also covers identifying users and writing personas, user stories and acceptance tests to define features and their scope. The goal is to fully specify requirements before development throug
ユーザーの要望を聞きすぎてはいけない | JBpress (ジェイビープレス)
前回、社内における「IT標準化」について話をした。筆者が考えるIT標準化とは、業務の進め方やルールを社内で統一し、システムに求める必要最小限の機能を洗い出すことだと述べた。 経営者にとって、IT標準化は「自分とは関係ない」と思いがちな部分である。だが、この「IT標準化」の意味が理解できていないばかりにどれだけ無駄なコストが発生しているのかを理解していただければと思う。 「標準化されたシステムであれば」という条件 まず、IT標準化の難しさを示す事例を挙げよう。 社内のシステム案件というのは、必ずどこかでデータの扱い方について検討しなければならない。データが散在したものだとシステム化する意味がないので、データを公約数にしたり、公倍数にしたりしながら「共有データベース（DB）」に格納する。 筆者がいろいろな会社を見てきた中で、この「共有DB」の考え方が最も進んでおり、試行錯誤を重ねてきたのが、N
"本当の顧客要求"のつかみ方 | コラム | 経営 | マイコミジャーナル
新着記事一覧 67WS、Flashのモーションプログラミングにまつわるセミナーを開催 [22:55 3/1] AP通信、iPadアプリ提供で有料課金開始か - 各メディアの有料化進む [22:53 3/1] ソフトバンクBB、iPhoneのデータを遠隔操作で消去できる法人向けサービス [22:52 3/1] Webを経由した「文庫本」発売開始 - 100人の著名著者による「天然文庫」 [22:28 3/1] 米Adobe、iPhoneアプリ「Adobe Acrobat Connect Pro Mobile」公開 [22:24 3/1] MSI、「USB 3.0拡張カードプレゼントキャンペーン」開始 [22:12 3/1] 富士通とJAEAがスパコンシステムを構築 - LINPACK実行性能日本1位を達成 [21:46 3/1] 招待なしでも入会OK、「mixi」で登録制スター
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Success with Requirements: Agile Requirements Work!