あなたのいうウォーターフォールとアジャイルはそんなに違うものじゃないよという話 - kawaguti’s diary
日経SYSTEMSの安藤さんの記事が、それなりに盛り上がりまして。 3分でわかる アジャイル開発 | 日経 xTECH（クロステック） 以下の記述が、企業さんなんかを訪問させていただいて意見交換していると出てくる「私たちウォーターフォールでー」というご発言の部分をうまく写し取っているのではないかと思いました。膝ポンです。 現在多くの開発現場で利用されているウォーターフォール型の開発では、要件定義工程で要件を確定させてから、設計工程や開発（製造）工程に移る。後工程になって要件定義の漏れや変更などが発覚すると、要件定義の工程まで戻って作業をやり直さなければならない。 要件定義の漏れや変更が発生した際、アジャイル開発では次のイテレーションの始めに要件の優先度を再検討する。これにより変更リスクに備えつつ、より価値の高いソフトを提供できるようになると言われている。 この２つは実はほとんど同じことにす
Fearless Change のタイトルに「アジャイルに効く」を入れた理由 - kawaguti’s diary
原題の Fearless Change にはアジャイルという表現はございませんで、リンダ・ライジングがアジャイル(とパターンのコミュニティ)で活躍している人だというニュアンスで、アジャイルについて気になっている人に届けたいという思いがありまして、タイトルに入れることになりました。 内容については、もちろんアジャイル開発に限定せず、新しいアイデアや技術、文化などを組織に導入する際に参考になるものになっています。 この「アジャイルに効く」というタイトルを決めるまでにはかなり議論があったのですが、アジャイル開発の導入に効く、と、使い方もアジャイルに柔軟に、というような意味合いでダブルミーニングを志向してみました。 出版後、「アジャイルアレルギーの人はこれで読まなくなるので、ないほうがよかった」というフィードバックもいただきまして、なかなかむつかしいなぁ、と思っております。 Fearless Ch
コードレビューのアンチパターン(とパターン) - kawaguti’s diary
@nihonbuson さんから、アジャイルでのレビューについて話してほしいというご相談をいただいた。そういえばレビューについてあまり調べたことがないし、カンファレンスでもテーマとしてそれほど聞いた感じがしない。 森崎先生が書かれた連載が本になっていて大変勉強になったのだけど、ご本人曰くこれは設計レビューであってコードレビューではないとのこと。スプリントレビューもまた違う観点もあるかなと思いつつ、指摘のダメパターンはだいたい共通している気がしている。 なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書） 作者: 森崎修司 出版社/メーカー: 日経BP社 発売日: 2015/10/06 メディア: Kindle版 この商品を含むブログを見る Erik Dietrich さんの Manual Code Review Anti-Patterns という記
Fearless Changeの48のパターンのチートシートを作りました。 - kawaguti’s diary
Fearless Change のパターンリストを A4 x 2枚 のシートにしました！ PDFファイルはこちらです。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者:Mary Lynn Manns,Linda Rising出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本（ソフトカバー）Fearless Change: Patterns for Introducing New Ideas (English Edition) 作者:Linda, Ph.D. Rising,Mary Lynn, Ph.D. Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: Kindle版
社内で新しいことを始めるには - Kanazawa.rb でLTしてきました - kawaguti’s diary
Kanazawa.rbという北陸、石川県金沢市のコミュニティでLTをしてきました。平鍋健児さんを招いてアジャイルに関するセッションということで、偶然近くまでくる予定があったのでふらりと...。金沢は学生時代を過ごした第２の故郷なので、コミュニティが盛り上がっていることがうれしかったです。皆様ありがとうございました。 新しいことを始めたとき、どう周りを巻き込んでいくか アジャイルに限らず、仕事上でなにか新しい技術や試みを始めるとき、一人で勝手にやれる部分はいいのですが、その成果物に継続的なサポートが必要なことは多く、やはりある程度周りを巻き込む必要はでてきます。たとえば、WikiやチケットシステムやCIサーバなどは、サーバをたてるまではなんとか一人でやることが多いでしょうが、たててしまったサーバのお守りや、使い方のサポート、バージョンアップへの対応など、一人でやっていると限界が早めにくるので
デブサミ2016 で発表しました : 実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう - kawaguti’s diary
デブサミ2016でお話しました。 【18-D-1】実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう http://event.shoeisha.jp/devsumi/20160218/session/1004/ 前年の話を下敷きにしつつユーザーストーリーマッピングと、カイゼンの先に新規ビジネス開発をしてこそ....というお話をしました。 Day1の朝イチにもかかわらず、おかげさまで満席のお客様に入っていただきまして、ありがたい限りです。壇上に上がってから、2008年のデブサミに初めて参加して、奇しくも同じくDay1の最初のセッションで関さんの「8年目のアジャイル」のセッションに参加して、アジャイルのはじめかたとして「信頼貯金」のアイデアとか、テストの話を聞きまして、ああ、できないと思っていたけど、とっくに始めている人はいて、自分の環境でも始めようと思えば始められるの
ゼネコンとITゼネコンとデスマーチと工程修正 - kawaguti’s diary
よしおかさんがざっくりいいきるときは、だいたい適当なので、突っ込んだ方が損した気になったりするものなので、適当には適当で返しておこうと思います。なのでこちらの話はとても適当ですので、突っ込まれると知識不足が露呈しますが、予めご容赦ください。 システム管理者、感謝の日イベントに参加した。 - 未来のいつか/hyoshiokの日記 どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。 建築プロジェクトではデスマーチの代わりに工期遅延が起こる ワールドカップやオリンピックごとに、建築間に合うのか問題が起きているのは、日
自分より長生きするソフトウェアより、自分より長生きするチーム - kawaguti’s diary
同僚が、 「自分より長生きするモノが作れたら、開発者としては幸せだろうね。」 と書いていた。 私も以前はそう思っていたんだけど、いつ頃からかそう思わなくなった。その「想い」によって、よいソフトウェアも、ダメなソフトウェアも生み出されるんじゃなかろうか...と考えるようになったからだろう。 ダメなソフトウェアというのは、いろいろあるが、開発者が去った後にメンテできなくなってしまったソフトウェアも、やはりダメなものだと思う。ソースコードがいかに優れていても、メンテナンス体制が組まれなくなってしまえば、徐々に利用価値を蝕んでいくようになる。実装がまともでないものは論外だが(リリース時点でだめとか、リリース前に負けてるとか)、設計も実装も当初の運用もすべてまともであっても、時が過ぎるとダメになってしまうものは、よくあるのだ。 自動車のエンジンが危険なく動き続けるためにはメンテナンスが必要で、それは
デブサミ2014 で 「ピンポンゲーム (Ball Point Game)」 - kawaguti’s diary
デブサミ2014 に参加して、セッションを一つ提供させていただいた。 【14-B-5】 ピンポンゲームでスクラム体験ワークショップ Ball Point Gameはスクラムの体験ワークショップとしてとても有名なもので、ピンポンゲームと勝手に名付けて社内の新人研修や、東工大での出張講義などで提供してきた。私がこのゲームを知ったのは、ヘンリック・クニベルグさんと、ジェフ・パットンさんの研修をサポートした時に、彼らがやっていたものだ。ヘンリックさんのやつは、カール・スコットランドさんのFlow Gameにもちょっと似ていた気がする。 今回は45分と時間が短かったので、少し調整をしてイテレーションを減らした。クロージングでの解説が足りなかったり、配布するつもりだったスクラムのプロセス部分の簡単ガイドを配り忘れたり、あらら、というのはあったが、全体としては上手くいったのではないかと思う。もちろんスク
「Fearless Change」日本語版パターン名リスト - kawaguti’s diary
「Fearless Change」日本語版を1月30日に出版いたしました。ありがとうございます。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本（ソフトカバー）この商品を含むブログ (16件) を見るFEARLESS CHANGE [ マリリン・マンズ ] ジャンル: 本・雑誌・コミック > ビジネス・経済・就職 > マネジメント・人材管理 > リーダーシップ・コーチングショップ: 楽天ブックス価格: 2,700円 本書に掲載されているパターン名の一覧をこちらにも掲載いたします。 日本語のパターン名に関しては適用フェーズ順となって
Web+DB Press Vol.78 「実践スクラム」 - kawaguti’s diary
Web+DB Press Vol.78 の特集が「実践スクラム」ということで、拝読いたしました！ 第1章 なぜスクラムをはじめる必要があるのか 栗林健太郎 (paperboy & co.) 第2章 スクラムチームの心得 柴田博志 (paperboy & co.) 第3章 スクラムの基本 家永英治 (永和システムマネジメント) 第4章 スクラムの実践 原田勝信 (mixi) 第5章 スクラムの導入 和島史典 (peparboy & co.) 第1章 なぜスクラムをはじめる必要があるのか 栗林健太郎 (paperboy & co.) ソフトウェアの正体は目に見えないもの、そして複数人が関わって作るためにコミュニケーションの課題がある、という点から、「ソフトウェア開発は難しい」という点を説明されています。その上で、なぜそこでスクラムが有効なのか、その有効な要素というのはどういうものか、と順に説明
ソフトウェアの死ってなんだろう - kawaguti’s diary
私はいちおう、ほとんどの期間をソフトウェアを作る側の人として過ごしてきたので、ソフトウェアの死ってなんだろうということをたまに考える。考えておかないと投資価値の設計ができないので、自分の労力を含め投資がままならない。けっこう大事な話だ。 WIndows XPが寿命を終えようとしている 世の中では、Windows XPのメンテナンスが終了する問題がニュースにでているが、XPは多くの利用者にとって、ハードウェアが壊れるまでは利用価値があるソフトウェア、ということだろう。世界最高峰の素晴しいソフトウェアだと言っていいのではないだろうか。でも、終わってしまう。一方で、Amazon Web Services や Salesforce.com、Github のようなクラウドサービスが継続課金モデルの中で改良を重ねている。 ハードウェアの死 ハードウェアであれば「正常に動かなくなったとき(実質的な耐用年
今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その1 - kawaguti’s diary
「Rakuten Technology Conference 楽天テクノロジーカンファレンス」 まで一ヶ月をきりました。私は今年も実行委員として皆様のご来場をお待ちしております。 個人的なモチベーション 会社としての判断はちょっとこの場で書くのはふさわしくないので書かないですが、超個人的に私のモチベーションは主に３つです。 登壇者が全員英語で話すふつうの技術カンファレンスをやる。 今年は、昨年あまりできなかった社内の事例のディスクローズをやる。 去年はアジャイルコーチをゲットしたので、今年はRubyistをゲットしたい。 やりたいこと1 : 登壇者が全員英語で話すふつうの技術カンファレンスをやる。 ぼちぼち英語の講演に通訳つける国も少なくなってきています。最先端のギーク達はもうとっくに英語を克服しているような気がしますが、これから高めていこうという人たちにもどんどん「必要な英語」に対応して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Netflix でガンダムを学ぶなら - kawaguti’s diary
どうしたら実現できるのか？ - kawaguti’s diary
よい仮説とは棄却しやすいものである - kawaguti’s diary
チームのフェイルオーバーアーキテクチャ - kawaguti’s diary