リスバーガー - Natural Software
CSM研修中に紹介されたリスバーガー、これはみんなに知ってもらいたいなー、と思い探していたら@kanu_さんが教えてくれました。 http://flux88.com/blog/don-t-make-squirrel-burgers/ これを会社の人に訳してもらって、公開の了承ももらったので載せておきますね。 ＃より良い訳があったら教えてください Don't Make Squirrel Burgers あなたのマネージャが席まで来て、話しかけてきます。 「なぁ、ジョー、ちょっといいかい。ヘルプデスクコールの動向をおさえるために新しいシステムを開発したいんだ。ナビゲートしやすいなめらかなユーザーインタフェースで、速くて、SAPの統合も必要だね。」 あなたは、似たシステムがないか熟考します。 「どれくらいかかるかな？」彼が続けます。 もちろん、あなたの本能は、概算して彼に折り返し連絡するよう囁き
主観重要、ビジョン重要@AgileJapan2010再演 | エンピツとキーボード
先日、2010/06/08(火)にAgileJapan2010基調講演の再演イベントに参加してきました。 AgileJapanで基調講演を行ったのは、野中郁次郎さんという方で、ScrumというAgile開発の手法には浅からぬ縁のある方です。 というのは、Scrumという開発手法の名前こそが、野中さんの論文の一文からとられているからです。 再演イベントは、その野中さんのお話を、チェンジビジョンの平鍋さんが記憶の限りお話してくれる、という聞き逃した身としてはとてもありがたい、イベントでありました。 以下にその感想をまとめたいと思います。 ちなみに、野中さんが発表に使用されたスライドは、以下で見られます。 http://www.slideshare.net/hiranabe/agilejapan2010-keynote-by-ikujiro-nonaka-phronetic-leadership
自己組織型チームを組織化する
原文(投稿日：2010/04/17)へのリンク Rashina Hoda 氏は、アジャイルの研究者で、 New Zealand、 WellingtonのVictoria University で博士を目指しており、米国 Louisiana State Universityから学士を取得している。 氏は、 New Zealand と Indiaで３年余り、企業ベースの博士号の研究の一部として、アジャイルのチームを調査してきた。彼女の研究成果は、世界中で出版されたり、発表されており、彼女は、Agile2008, Agile2009, そして XP2009 で発表した。 最近、５月に南アフリカの Cape Townで開催されるInternational Conference on Software Engineering (ICSE2010) に彼女の論文が受理された。世界中から３８０の応募があ
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
あなたの会社にスクラムマスターが必要な8つの理由
みなさんこんにちは。@ryuzeeです。 このタイトルで記事を書く約束を@katzchangと約束したので、書いてみたいと思います。 前提として、スクラムマスターはいないが管理職がたくさんいて、日々現場のメンバーが悩まされているようなシチュエーションを想像しています。 （かなり）現実の管理職を悪くステレオタイプ化していますが、スクラムマスターとの対比のためにあえてそうしています。 うちの管理職はもっとまともだ！とか言わないようにしてください。 管理職は部下を育てる責任、もしくは勝手に育つような環境を用意する責任がありますが、もう1つの大きな責任である「数字（※1）をあげる」というテーマが優先されてしまう。 （※1：ムリと分かっていても勝手に経営が決めて部門目標とかいう名の元に押し付けてきた売り上げと利益目標のこと）。→スクラムマスターはコーチ・ファシリテーター・メンターとして、チームの成長
どうやってプロジェクトマネージャは自組織のアジリティを向上させるか
チームが物理的に近い距離で一緒に働くようにする。 いつも可能とは限らないが、そうすることが好ましいレポートとかメールのような形式ばったコミュニケーションをやめて、対面のミーティングや参加者が分散している場合はビデオ会議することを推奨する個人の能力開発をする相互作用をサポートするためにツールを使う一人で働くことを好む人よりも一緒に働くことを楽しめるメンバーを選ぶ昨日やったことと今日計画していることを話すために頻繁に－毎日でも－10分から15分のチームミーティングを行うテストを開発作業に組み込むこと。 そして自動テストツールの利用を考えること。 これはビルドが終わった後にQAやテストをするプロセスとは対極にある実際の利用者を参加させるようにするチームを小さく保つ。極小ではなく、普通に小さく多様な経験や、問題解決へのアプローチ方法をもったチームメンバーを選ぶ開発作業や作業環境を頻繁にモニタリング
誰にでも心当たりのありそうな、アジャイルが失敗する理由7＋11
コンサルタントであるMartin Proulx氏のブログ「Analytical-Mind」に、「 Seven wrong reasons to adopt Agile」（アジャイルを導入する7つの間違った理由）」というエントリがポストされています。読んでみると、なんだかドキっとするようなことが書いてあります。 次の7つの理由、心当たりのある人も少なくないのでは？ We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we. 最近カンファレンスに参加したところ、アジャイルが人気らしい。他でやっているのなら、うちでもやるべきではないか Because Gartner and Forrester say so. ガートナーやフォレスターがそう言
[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例 - TDD.NET
先月、 デンマークの BestBrains 社からの視察団が来日されていました。 同社 Director である Bent Jensen 氏のプレゼンからハイブリッド契約方式を少しご紹介します。 BestBrains 社はアジャイル開発のコンサルティングをやっている会社で、 日本のアジャイル開発の現状や製造業を視察するために何度も来日しています。 [2008年] ITmedia オルタナティブ・ブログ: An Agile Way: BestBrains がデンマークから Change Vision に来社 [2009年] fkino diary(2009-08-24): Agile2009セッション紹介 Thursday AM編 ～ "Experiments with Agile Contracts in the Real World" そして今年、 2010年は 4月の第3週から 4週に
![[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例 - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/49580a5f674aa36f66a331dbb78ab28d3dc57e33/height=288;version=1;width=512/http%3A%2F%2Fbluewatersoft.cocolog-nifty.com%2Fphotos%2Funcategorized%2F2010%2F05%2F06%2F20100506_agilecontract01a.png)
スクラムで失敗する7つの方法
みなさんこんにちは。@ryuzeeです。 ジェフ・サザーランド氏のスライドが素晴らしいので抜粋・意訳にてご紹介します。 これは2007年の文書ですが、今読んでも全くもってその通りあてはまると思います。 1.プロダクトオーナーの失敗ポイントプロダクトオーナーが、ビジョン、ビジネスプラン、リリースのロードマップを持っていない プロダクトバックログが適切な順番で優先順位付けされていない。技術的な問題を含む、全ての仕事が含まれていない。スプリントプランニングに使えるようになっていない（適切なサイズになっていない、正しく見積もられていない、詳細化できるようになっていない） プロダクトオーナーがスプリント期間中に無断でどこかに行ってしまう 2.スプリントプランニングの失敗ポイントプロダクトオーナーがはっきりと思いを伝えないチームがプロダクトバックログから離れている。フィーチャーをスプリントタスクにブレ
私がアジャイルで嫌いな10のこと
みなさんこんにちは。@ryuzeeです。 10 Things I Hate About Agile Development!が良い記事なので、引用・意訳にてご紹介します。 アジャイルに関する誤解がよく分かると思いますので、くれぐれも真似しないようにしてください。 ただデイリースタンドアップミーティングをやっているだけで、「アジャイルをやっている」と言うこと。 別にそれは「アジャイルをやっている」わけではない。 これ以外にアジャイルを実践するためにもっと大事なことがある「アジャイル」の頭文字のAが大文字か小文字かを気にすること。 先頭を大文字で書いたらクールじゃないって言ってるのかな？ 本当の意味での違いは、「アジャイルメソッド」と「アジャイルである」という違いなのだ。 多くの人はたぶんこの微妙な違いを分かっていない。 みんながこの大文字と小文字の違いでもめるようなことは、私にはしゃくに障る
Agile Japan 2010 で話しました。 - ヲトナ.backtrace
二日目に「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 (組織、意識改革編)」というテーマで話しました。 最初は、もう少しマネジメント寄りの話の予定だったのですが、元々、現場の話しかできないし、本格的な導入が増えてきている事と始め方が重要な事をぜひ伝えたいと思い、こういう構成にしてみましたがどうでしたでしょうか? 折角、始めた or これから始めようとしている人達の助けに少しでもなっていればと思います。 当日の僕の話は平鍋さんに上手くまとめてもらったので、引用しておきます。 西村さん話を平鍋さん総括： Agileは本では広まらず、こうやればいいと指示をしても駄目で、それを経験した人を介してしか広まらない。自転車と一緒で、ちょうど、自転車の後ろをもってOKだよ、いけるよ、といってあげるのと一緒。 #aj10 http://twitter.com/KenTamagawa/stat
情報処理推進機構：ソフトウェアエンジニアリング：非ウォーターフォール型開発に関する調査結果公開
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
プロジェクトの特性に合わせた要件定義手法の選択
ソフトウェアの開発チームは、最良の方法による最良のソフトウェア開発を望んでいる。この要求を満たすため、多くのソフトウェア開発企業では、ラショナルソフトウェアの“Rational Unified Process”（RUP）に代表される、標準的なソフトウェア開発のプロセスを採用している。 開発プロセスは、アプリケーション開発のガイドラインや市場で評価されている手法を盛り込んだ実践的な方法論の集積である。例えばRUPはユースケースをはじめとする各種要件定義のテクニックを適用することで、製品が実現しなくてはならないユーザーニーズの理解を助け、開発チームが適切にソフトウェアを構築できるよう支援してくれる。さらに、RUPをはじめとする最新のソフトウェア開発プロセスは、反復性や成長性もソフトウェアライフサイクルの手法として規定しており、融通の利かない「ウォーターフォール」プロセスのアプローチよりも、開発
スプリント計画：ストーリーポイント VS 作業時間
原文(投稿日：2009/09/22)へのリンク スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて，決着の付かない議論が長く続いている。どちらの陣営も，自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して，それを元に時間見積を行う方法を好んで使用すれば，それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが，自らの好む方法とその理由について意見を表明している。 Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって，短期作業には向かないと考えているからだ。彼の意見では， シ
Martin Fowler's Bliki in Japanese - ヘロヘロScrum
@@ -0,0 +1,79 @@ +http://martinfowler.com/bliki/FlaccidScrum.html + +2009/1/29 + +//There's a mess I've heard about with quite a few projects recently. It works out like this: + +多くのプロジェクトで混乱が起こっているようだ。 +次のようなことになっているらしい。 + +// * They want to use an agile process, and pick Scrum +// * They adopt the Scrum practices, and maybe even the principles +// * After a while progress is
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
プログラマーにとってのテストの重要性
優れたエンジニアはテストコードをとても重視している、という話を本人たちから直接聞く機会が最近ありました。 オープンソース会の重鎮として知られる楽天のよしおかひろたかさんは「下手なドキュメントを書くくらいだったらテストコードを書くべきだ」「ソフトウェアはテストコードと本体のコードの両方が必要。テストコードがないのは未完成品」と、テストコードの重要性を話してくれました。「全部書き直したいような（他人の）ソースコードを見たときでも、テストを書いていると心が落ち着いてくる（笑）」（吉岡氏）。 JavaのフレームワークSeaserの開発者などで知られるひがやすを氏は、コードレビューのときに「テストコードを見る」ことがほとんどなのだそうです。「テストコードがちゃんと書けていればOK」（ひが氏）。 これは1月30日に行われた「Source Code Reading Workshop Japan 2010
ThoughtWorks社マネージングディレクターXiao Guo氏インタビュー―アジャイル開発を行うために組織文化をどう変えるか | gihyo.jp
ThoughtWorks社マネージングディレクターXiao Guo氏インタビュー―アジャイル開発を行うために組織文化をどう変えるか 2009年12月8日に開催されたAgile Conference Tokyo 2009で、基調講演のために来日したThoghtWorks社のXiao Guo氏にインタビューを行いました。ここにその模様をお伝えいたします。 Agile Conference Tokyo 2009のレポートはこちらです。 図1 Xiao Guo氏 アジャイル開発に組織を適合させるための3つの課題 Q：本日は基調講演をどうもありがとうございました。その中でも、組織文化についてのお話しを興味深く伺いました。日本でもエンジニアを中心にアジャイルプラクティスが知られるようになってきていますが、組織そのものをアジャイル化していくことはまだこれからなのが現状です。アジャイル開発は日本で一般的な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「サボっている作業員は悪くない」と怒鳴った「自主研」指導者 | JBpress (ジェイビープレス)
アジャイルの"ルール"を"ガイドライン"に変えられるか？