アジャイルと創造性
私の職業は、IT技術者。ということで、自分の仕事を忘れないために、たまにはIT技術関係の話題を取り上げてみようと思う。 この数年、アジャイル開発手法が日本でも広まりつつある。私がアジャイル開発手法に出会ったのは、Kent BeckがeXtreme Programmingを広め始め、日本でようやく書籍が出始めたころだった。その頃、アジャイルの面白さを説明をしたところ、鼻で笑われ悲しい思いをした記憶がある。 アジャイル開発手法とは、「設計」「実装」「テスト」「リリース」を短いスパンで繰り返し実施する特徴がある(テストと実装が逆になることもある)。リリース後、お客様のレビューを受け、意見を聞き、さらに機能を追加して行く。 つまり、アジャイル開発手法は、お客様の要望を、次々に叶えて行く開発手法と言える。 そこで私は、ひとつひっかかった。「お客様の要望を、次々と叶えて行く」ということは、開発者の創造
Martin Fowler's Bliki in Japanese - 対話的ストーリー
http://martinfowler.com/bliki/ConversationalStories.html 2010/2/4 アジャイル方法論に対するよくある誤解の話をしよう。 アジャイル方法論は、開発のなかでユーザーストーリーを作り、変化させていくことに重点を置いている。 よくある誤解とは、プロダクトオーナー（あるいはビジネスアナリスト）がユーザーストーリーを作り、それを開発者に差し出して実装してもらうというものだ。 この考えでは、流れはプロダクトオーナーから開発者に向かっている。 プロダクトオーナーの責任は何が必要かを決めることであり、開発者の責任はどうやって実現するかを決めることだというのだ。 この考えは、能力に沿った責任の分割をその理由としてる。 プロダクトオーナーはソフトウェアの目的であるビジネスを知っており、何を行うべきかを知っている。 一方、開発者は技術とその方法を知っ
ソフトウェア開発の革命
前回（第4回 アジャイル開発と反復開発の落とし穴）は、ウォーターフォール開発に代わるべく登場した、反復開発（*1）やアジャイル開発の問題点、課題、そして落とし穴についてお話しした。最終回は、ここまで説明してきた問題について、IT企業やITエンジニアたちがどう立ち向かうべきなのか、自分なりの考えを述べることとする。 ユーザー企業とIT企業の不幸な関係 ユーザー企業の求める真の要求は、業務要求がその根拠となる。業務をどのようにデザインするかでシステム要求が決まり、また、システムをどのように活用するかによって、業務に新しいイノベーションを起こせる。業務とシステムの有機的な結びつきが企業の業績に大きな影響を及ぼすのである。しかし、現状は、業務とシステムが分断されたままである。 ユーザー企業とIT企業の契約の仕方を観察すれば、業務とシステムの不幸な分断状況を俯瞰できる。 通常、ユーザー企業はIT企業
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
アジャイルだウォーターフォールだいう前にさぁ - Identity Not Found
もうさあ。 アジャイルだかウォーターフォールだかどうでもいいよ。 どっちでもいいから、ともかくまずは顧客の要望をきちんとほじくりだして並べてみせてくれよ。 通り一遍のヒアリングでいきなり開発し始めておいて、そうじゃなくてこんなのがいいって指摘したら、仕様変更です直せるけど納期に影響が出ますって。それがアジャイルとかいう手法なのかい? 顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。 この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初から満足な量の要望なんて出し切れないんだよ? 要望を仕様書としてまとめる代わりに、いわゆる「最低限を満たして動くもの」をもってきたとしよう。それに誘引されて顧客側の頭のなかに「どんなものを作るべきなの
第35回：アジャイル開発の要求工学(要求工学：Requirements Engineering)
最近、製造業で発達したリーン生産方式に基づくアジャイル開発手法（Agile Methods）がソフトウェア開発でも注目されている。 今回は、アジャイル開発における要求工学がどういうものなのかについて紹介しよう。 アジャイル開発とは アジャイル開発では、顧客が開発者との協働プロジェクトを通じて開発者から提供される価値を理解し、満足することに注力することでソフトウェア開発のさまざまな無駄を省くことを目的としている[1]。たとえば無駄なドキュメントやコードを作らないことや、逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がある。 幾つかのアジャイル手法が提案されているが、アジャイル手法に共通する特徴がアジャイル宣言としてまとめられている。代表的なアジャイル宣言の例を表１に示す。
2007-12-23_22-28 - 生きてま2 改 - オブラブクリコン2007資料UP
オブLOVEクリコン2007 LT資料UP まず感想より、自分の資料のUPを先にする。 オブラブクリコン2007のLT資料をSlideshareに公開した。 今回のLTの目的はTRICHORDの宣伝と、狩野モデルの紹介、そして実際に来場者を交えて試してみることだった。ネタはちょっと前にネットでも流れてた狩野モデル(狩野分析法)について。こちらの方は、ScrumのCertified Product Owner(CPO)経由で知ったそうですが、私はMike Cohnの執筆したAgile Estimating And Planning(AEP)で知った。Mike Cohnは1990年後半からScrumを実践しており、バリバリのCertified Scrum TrainerでCertified Scrum Masterトレーニングの講師も勤めているし、AEPはScrum Masterの参考書籍にも
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storymapping presentation
プロダクトオーナーパターン