第18回すくすくスクラムに行ってきました
第18回すくすくスクラム 私がみた Agile 2010 はコレだ すくすくスクラムに行ってきました。今回はとてもキュートなお友達の発表なので楽しみだったのですが、Agile2010のFBだけではなく、「学生と社会人のディスカッション」が盛り上がったように思います。 その前に、クレヨンしんちゃんの話をさせてください。 前にブログにも書いたのですが、「クレヨンしんちゃん 嵐を呼ぶモーレツ！オトナ帝国の逆襲」は名作です。子供と観に行った親のほうが感動して泣いてしまったというエピソードもあるみたい。 今回のすくすくスクラムで、この映画を思い出しました。 ビアバッシュだったのでメモが少ないですが以下。 プロジェクト指向教育というのがあり、学部一年から大学院生まで一貫した教育でPMとかしているそうな IT業界の7Kで白熱ディスカッション 過剰品質なのがきつい 帰ろうと思ったらお客さんからメールが届く
私がアジャイルで嫌いな10のこと
みなさんこんにちは。@ryuzeeです。 10 Things I Hate About Agile Development!が良い記事なので、引用・意訳にてご紹介します。 アジャイルに関する誤解がよく分かると思いますので、くれぐれも真似しないようにしてください。 ただデイリースタンドアップミーティングをやっているだけで、「アジャイルをやっている」と言うこと。 別にそれは「アジャイルをやっている」わけではない。 これ以外にアジャイルを実践するためにもっと大事なことがある「アジャイル」の頭文字のAが大文字か小文字かを気にすること。 先頭を大文字で書いたらクールじゃないって言ってるのかな？ 本当の意味での違いは、「アジャイルメソッド」と「アジャイルである」という違いなのだ。 多くの人はたぶんこの微妙な違いを分かっていない。 みんながこの大文字と小文字の違いでもめるようなことは、私にはしゃくに障る
第5回 アジャイルな要求定義に求められるもの
本研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていきます。開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられるからです。今回は、アジャイルと要件定義の関係について考えてみます。 みなさんはもう十分に実感されているかもしれませんが、ここ最近の私は、アジャイル開発における要件定義の重要性を改めて認識するようになりました。アジャイル開発といえば、要件定義よりも「まずは作ってみる」といったイメージが強いかと思いますが、要件定義が重要な作業であることには変わりがないと考えています。 一般的に、アジャイルではユーザーが実施したいことを端的に表した「ユーザーストーリー」を作成し、開発を進めていきます。ですが、これまでの私が「それだけでは要件定義が不足している」と不安に感じていたのは事実です。 そんなと
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
Microsoft – クラウド、コンピューター、アプリ & ゲーム
在庫限り。人気のSurface Duo 2 が再入荷され、最大 36% OFF 中。ご購入はお早めに。
私がスクラムマスターを目指すわけ | エンピツとキーボード
2010/1/14(木)に、「Agile2.0 ～ アジャイルなチームで何を提供する？」という勉強会に参加してきました。 実はこの日は、純粋な飲み会としての新年会を開催予定でした。 が、その会をほぼ無理やり「勉強会に参加する新年会」と内容を変更して、参加してしまいました。 参加予定だった方には、少々、申し訳ないことしてしまったと思います。 しかし、この会に参加して、わたしが、なぜスクラムマスターになりたい、と考えていたのかがはっきりしました。 それは、スクラムなどアジャイルという開発手法が、 開発者と顧客をつなげることで楽しく良いシステムがつくれる と感じたからだったのです。 ＜顧客不在の開発現場＞ 私の周囲には、コーディングが好きな方とても多いです。 それは老いも若きも関係ありません。 なかには、60代になってもコーディングが好きで、現役でコードを書く方々がいます。 そうしたコードを書く
Agilo日本語版を公開しました
ということで、タイトルの通りですが、本日Agiloの日本語版を公開しました。 ちなみに、翻訳したことをagile42にメールしたら、直接ブランチ触ってよ。それと良かったら開発チーム入らないかい？というありがたいメールを頂いたので、それだけでワクワクです。 公開先はhttp://sourceforge.jp/projects/shibuya-trac/wiki/plugins%2FAgilo_jaになります。 繰り返しになりますが、ちょっくら特徴などを書いておきます。 Agiloとは AgiloはTrac上でアジャイル開発の手法の一つであるScrum(スクラム)を実施するためのプラグインです。 オリジナル版の開発はagile42という企業および開発チームで行われていますが、オープンソース版として公開されているバージョンを日本語化したのが、こちらで公開しているものになります。現在の日本語バージ
定量的なソフトウェア品質管理（pdf)
日科技連とSQiPの取り組み 1980年、日科技連では、日本におけるソフトウェア製品の品質向上と効果的開発の方法論の確立を目指して、「ソフトウェア生産管理研究委員会」（SPC, Software Production Control）を設置しました。 以来、「TQMとソフトウェア工学の結婚」を標榜し、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってまいりました。 2007年に、この活動が「ソフトウェア品質に関する活動」であると分かりやすくすることと、ソフトウェア技術職という専門的職業の矜持を大事にしたいという思いから、SQiP(Software Quality Profession)に改称しました。 1980年の設立当初は、メインフレーマーで培われたソフトウェア品質技術・施策を議論する場でしたが、現在はソフトウェア産業に関わるすべての方々が議論できる場になっています
スクラムの元になった資料 - [ハーバードビジネスレビュー] New New Product Development Game - kawaguti’s diary
アジャイルソフトウェア開発プロセスの１つであるスクラムは、日本人によるハーバードビジネスレビューに投稿された論文がきっかけで作られた、というのは、いまどき小学生でも知っている有名な話ですよねw。 [ハーバードビジネスレビュー] New New Product Development Game (1986) 竹内 弘高、野中 郁次郎 http://harvardbusiness.org/search/86116?legacy=true で、なんかこのあたりに(http://apln-richmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf) 置いてあったので読んでみました(2011年12月時点注記: すでに存在していないようです。)。 Fuji-Xerox, Honda, Canon, NEC, Epson, Brother, 3M, Xerox,
![スクラムの元になった資料 - [ハーバードビジネスレビュー] New New Product Development Game - kawaguti’s diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d1ce7a1dc491fc46a7a5c7b073262b322ee0cce/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F6653812171401680160%2F6653812171401681812%2F1466254596)
Agile2009四日目 - masayang's diary
The Kanban Game 永和システムズの安井さんによる講演。 "Kanban Game"を通じて、カンバン方式のプロジェクト計画管理を学ぼう、という企画。 いわゆる「スクラム板」よりも全体の見通しがよくなり、「これは使える」と実感した。 教材や遊び方はこちらにあるよ→安井さんのサイト The Dawning of the Age of Experience バンケットでの基調講演。 User Interface「設計」をもとにAgileの価値を考えるという内容。 細かい話はそのうち書くかもしれないし、書かないかもしれない。 でもJared M. Spool氏が指摘した企業文化の話はするどかった。 うまくいっている企業は、決して「核となる」部分を外注(Outsourcing)しない うまくいってない企業は、得てして企業文化を統一したがり、方法論に走る。そして、その方法論でうまくいかな
Agile2009三日目 - masayang's diary
本日聞いてきたお話 Scaling Scrum with Feature Teams 大規模SCRUMの話。 日本にも支社があるOdd-eによる発表。 「どんなに大規模になっても、Product Backlogは一つにまとめよ」 「The Product Ownerはどんなに大規模でも一人」 一人しかいなくて、しかも他の仕事が忙しいProduct Ownerが、膨大な量のProduct Backlogをどう管理するのか？ 一方、開発は複数チームに分けざるを得ない。 どういう根拠で開発チームを分けるのか？ 「大雑把な設計をし」「そのサブシステム単位で分ける」のが古典的な考え方。 だが、この段階での設計は非常に粗い。 その粗い設計を元にチーム分割する時点で、将来に向けての問題を埋め込むことになる。 そして問題が発覚する時点で手遅れ。まずいチーム構成のまま進むことになる。 Product Bac
Agile2009 - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/masayang/20090824/1251153985 http://d.hatena.ne.jp/masayang/20090825/1251243400 http://d.hatena.ne.jp/masayang/20090826/1251329661 http://d.hatena.ne.jp/masayang/20090827/1251415738 メモ それに比べて日本の将来は暗いなあ．この不景気で「いくらなんでも経営者も重い腰を上げるかな？」と思ったら，盛大に墓穴掘ってるくらいだし． http://d.hatena.ne.jp/JavaBlack/20090720/p3 http://d.hatena.ne.jp/JavaBlack/20090829/p3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
未完了、完了、スプリントの終わりに一貫して完了しているか？
かぬさんの自作プランニングポーカー - 虎塚
http://d.hatena.ne.jp/kimpo/20100206
アジャイルの"ルール"を"ガイドライン"に変えられるか？
Microsoft – クラウド、コンピューター、アプリ & ゲーム
https://www-607.ibm.com/support/partners/jp/webcast/play/play.wss?&keyword=&usergroup=null&mode=&uid=null&contentid=910&appid=null&checksum=941819ca
Edge Components 概念、計画とインストール / WebSphere Application Server
Agile2009カンファレンス日記 Day 2 - kawaguti’s diary