真面目な人を本気にさせる方法
先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 本気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ
フィーチャーチーム
フィーチャーチームは、“組織の既存の枠やコンポーネント等にとらわれず、多くの顧客 のフィーチャーを1つずつ完成させる長寿命のチーム” です。フィーチャーチームは、大規模開発でアジャイル開発を実践するために必要不可欠です。フィーチャーチームがなければ、（その代わりに、コンポートネットチーム、コード所有権に基づく、もしくは１つの機能に基づくグループ、アナリストグループ、プログラマグループ、テストグループ等に分類）あなたの組織は、結果的に逐次的開発サイクル（ウォーターフォール, ...）となり、非常に多くの無駄を生み出したり、部分最適化を行います。フィーチャーチームは、多く無駄を取り除くと同時に、変化と挑戦を求めます。 フィーチャーチームは大きなプロダクト開発で長期間、活躍します。例えば、テレコムシステム（Ericsson）やコンパイラ開発（Microsoft）等。フィーチャーチームが仕事
スクラムのスクラム - 問題と価値
Agile Estimating and Planningの著者のMike Cohn氏(リンク)が「スクラムを大きなプロジェクトチームに適用させるのに重要な技術」と説明しているのが、スクラムのスクラムミーティング(the Scrum of Scrums: 以下SoS)である。これらのミーティングをすることで、いくつかに別れたチームが仕事について議論したり、チーム間で統合が必要な箇所や、オーバーラップしている箇所にフォーカスすることができるようになるのである。 Allan Shalloway氏(リンク)は"Lean Software Development: Scaling Agile to the Enterprise"(リンク)という書籍を執筆している。彼は「チーム間の調整にスクラムのスクラム(成功経験あり)と、スクラムをエンタープライズにスケーリング(これに関しては、何人かの人がいくつ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 （本記事は「「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional S
今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 － Publickey
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化（Semantic Diffusion）が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」について。 土木や建築に由来するのが「計画駆動開
アジャルーム配備の産総研入りたい! - 角谷HTML化計画 (2005-11-05)
■1 Agile Web Development with Rails(AWDwR)読書会＠東京 第0回 (あとで書く)書いた 昼前に妻と息子と近所の公園に出かけて、ベンチで昼ごはん。その後、妻子を公園に置き去りにして、Ruby業務チームの集まりへ。業務チームの集まり、といっても高橋さん(日本Rubyの会会長)とogino.さん(Rubyヲチャー)は業務チームだろうが基盤チームだろうと参加しているわけだが。ちなみに、基盤チームとか業務チームとかいうのは私の勝手な便宜上の分類。 「今後の進め方を決めよう」の会なのに30人も来ちゃうのがすごい。ポジションペーパー発表はdanさんのが印象に残った。「最後は君の強さと俊敏さが勝る」というフレーズは私もXP祭りのトークスで使ったので勝手に親近感。ここで「俊敏」という語を選んだ林完治の字幕センスに感謝したい。transcriptでは「they will
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft Word - xp-card.doc
Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」
モデリングもしないでアジャイルとは何事だ