「ウチの事業部の商品をWebサイト・アプリで目立たせて！」私だけじゃなかった！ 社内政治と落としどころの見つけ方
XP lives, XP dies, XP lives again !!
「ウチの事業部の商品をWebサイト・アプリで目立たせて！」私だけじゃなかった！ 社内政治と落としどころの見つけ方
野中郁次郎先生の講演資料の解説記事 - プログラマの思索
Scrum Alliance Regional Gathering Tokyo 2013で野中郁次郎先生の講演資料の解説記事が公開されていたのでメモ。 SlideShareの資料だけでは読み取りにくい内容がうまく説明されていて理解しやすくなっている。 【元ネタ】 プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（前編） － Publickey プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編） － Publickey アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ 野中先生の資料を読むと、古き良き時代の日本企業の経営手法からエッセンスを取り出して、知識をベースとした組織のあるべき構造を説明されようとしているように思える。 で
スクラムで陥りがちな罠24個
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下に
ユーザ機能駆動開発FDDを再考 - プログラマの思索
「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」を読んで、Agile開発のスケールアップに必要な概念が揃っている感覚に陥って驚いた。 考えたことをメモ。 間違っていたら後で直す。 【元ネタ】 ユーザー機能駆動開発 - Wikipedia トカゲの独り言: 『アジャイル開発手法FDD』読了 銀行システムの失敗から生まれた開発方法論 - 日経コンピュータ・コラム：ITpro Twitter / @akipii: FDD(Feature Driven Development)本を読んだら、まるでデジャブみたいだった。概念モデル設計＝ドメイン駆動設計(DDD)。フィーチャ＝ユーザ機能リストorバックログ。フィーチャの進捗＝パーキングロットチャート。 Twitter / @akipii: FDDのクラスオーナーはConwayの法則の観点からも正しい。SW組織はテクノロジラインではなく
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
ウォーターフォールはアジャイルよりも難しい - イトウ アスカ blog
きっと同じような記事を書く人がたくさんいるんだろうなぁと思いつつ。 アジャイルはウォーターフォールよりも難しい | 日経 xTECH（クロステック） ↑こちらの記事に触発されて、私がウォーターフォールやりながらアジャイルでやりてぇと思ったときの経験を書いてみる。 難しさ（1）落ちない水。隠れた溯上用水路 ウォーターフォールとは、滝のことです。各プロセスが手戻りすることなく、次々にこなされている様が、また、ガントチャートなどで書き表わした場合の様がその滝のように見えますね。 さて、このプロセスって、ちゃんと予定通りこなすことってできるんでしょうか？ まず無理でしょう。なぜなら、見積り工期の根拠が乏しいからです。ふたを開けてみたら「思ったより時間がかかった」という経験を持っている方は少なくないでしょう。 また、やってみたら「この仕様じゃダメじゃね？」となったこともあるか思います。と言いますか、
それでもアジャイルに未来があるとすれば - GoTheDistance
前回のこのエントリの続き。 アジャイルって受託開発との相性が最悪な気がする - GoTheDistance 受託開発との相性の悪さについて問題提起をしてみたのですが、アジャイル開発って内製向きだよね以上のことが言えなかったので、もうちょい掘り下げてみます。 アジャイルや受託という切り口で書いてみたんですが、僕も頂いた様々なフィードバックを鑑みて考えたところ、受託も内製も滝も俊敏も関係なくて、要は｢前工程の成果物を後工程で活用できず断絶されている｣ということが全ての根幹にあるように感じた。 ソフトウェア開発は｢設計→実装→テスト→改善｣のサイクルを回して初めてPDCAが回るのに、我が国では何故か｢設計でPDCA｣→｢実装でPDCA｣→｢テストでPDCA｣という感じになっていて、前工程の成果物が後工程でフィードバックができず、やる必然性の無いことを違うレイヤーで繰り返しているんですね。で、当然
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
制度会計とAgile開発・"Stupid Finance team!" - masayang's diary
Scrumのメーリングリストで興味深いネタがあがっていた。 まず質問した人 our Finance team has instructed us to code all of our hours to one of the following categories: Analysis, Design, Build, Test, Post Launch Support. 弊社の経理チームが、私たち開発チームの勤務時間を「分析」「設計」「開発」「テスト」「サポート保守」に区分して報告するように要求してきました。 Obviously, this feels pretty non-agile. The response to questions on this has been that this coding follows Generally Acceptable Accounting Pri
Agileでやってるけどデスマったｗ
Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
フィーチャで考えると見えてなかったものが見えてくる - masayang's diary
その１ 最近Agileに切り替えたとあるプロジェクトのリーダーは、こんな事を語ってくれた。 以前は進捗会議の話題が「納期」や「予算」に話が偏る傾向があった。 切替後は、開発されたフィーチャやこれから着手するフィーチャについて議論されるようになった。 →いかに中身を見ないでお金や納期の話をしていたか、ということが浮き彫りになった。 その２ Agile採用を検討しているプロジェクトのリーダー曰く： フィーチャで考えるのは難しい。 ユーザがどんなフィーチャを欲しがっているのか、意外にわかってない。 →フィーチャで考えるという事は、受入れテストの必要条件を考えているのに等しい。そこを曖昧にしたまま包括的に記述してしまう従来型の要求定義だと、受入れテスト〜納品の段階で非常にややこしいことになる。フィーチャで考えるのは大変だが、プロジェクト最終段階でのゴタゴタを前取りしていると思った方が良い。
要件定義とか設計とか真面目に考えてみよう - masayang's diary
画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。 要点繰り返し 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。 ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ？ なのでそんなのはやめちゃえ、ということ。 以下、頂いた意見に対しての感想などを。 家やマンションに例えない 「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。 むしろ、操作することで「紙芝居」ではわからなかった要
Rinse, wash, and repeat! - masayang's diary
今回もAgile導入のお手伝いやらAgile開発のススメやらで来日。 ゆっくりだけど確実にAgile開発は普及しつつある。 だけど...組織の体質を変えるのはそんなに簡単ではない。 それを実感した出来事。 なぜ文書整備から入るのか？ 今回お話を聞いたプロジェクトのうち二つで、こんな悩みを相談された。 「Agileでは不要な分書類を作ってしまう。画面設計書、画面遷移図、テスト計画書など」 よくよく理由を聞くとおもしろいことがわかった。 それらの文書類を作る人達は、「なぜ、その文書を作るのか」という理由をわかってない可能性があるのだ。 もっと具体的に言うと、「これまでの開発手順では、そういう文書を作ることになっていたから」となる。 つまり、開発手順のマニュアル化による副作用だ。 対策 マニュアル化＝考えないことの推奨 つまり、その弊害を取り除くには「考える」ようにするしかない。 実践（プラクテ
和風Agile? Part-2 - masayang's diary
和風Agile?の続き ウォーターフォール開発に慣れ親しんだマネージャ達にAgileを売り込むときによく指摘されるのが「最初に要件も予算も確定させないAgileのやり方はおかしい」ということ。 で、「じゃぁ、ウォーターフォールで最初に『確定』させた要件や予算が正しかった事がどれくらいありましたか？」と聞いてみると、「実はそれほど正確ではない。」という答が多いのも事実。 しかも要件抜けが発覚するのがUAT段階なら良い方で、本番稼働後に発覚する事例も珍しくない。そして不思議な事に、こういう「抜け」は要件定義段階の度重なるレビューでは発覚しない。ものすごく丁寧な業務フロー図やらなんやらを描いているのに、だ。 「だからこそ、要件抜けなどに対処しやすいAgileがいいのでは？」と売り込むと、「いや、それは困る」という答。どうやらこういうことらしい。 発注元の立場では、まず最初に予算総額を確定させる必
レトロスペクティブ（ふりかえり）の失敗とその回避方法
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルUX物語