編集可能

日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」

2012年11月16日(金) 10:00~12:00 に開催されました、日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」のつぶやきまとめです。 http://www.juse.or.jp/software/400/#06
11
あきやま☀️ @akiyama924

今日のSQiP研究会の特別講義は、細谷泰夫さんです。楽しみです! ちなみに特別講義は10,500円で研究会に入っていない人でも参加可能です(あまり知られていないらしい)。 http://t.co/qQzB35Am

2012-11-16 09:10:37
あきやま☀️ @akiyama924

細谷さんの特別講義はじまり~。ツイートのOKもいただいたのでツイートします。

2012-11-16 10:03:37
あきやま☀️ @akiyama924

細谷さん「(付箋を配りながら)“アジャイルと品質”というテーマで何を知りたいかを近くの4人で話し合ってこの付箋に書いてください。

2012-11-16 10:07:56
あきやま☀️ @akiyama924

参加者が講義に主体的に取り組む効果と、付箋を元にプレゼンを動的に組み立てることによる満足度向上(後から質問をもらっても手遅れになる)を図る手法らしい。

2012-11-16 10:11:41
あきやま☀️ @akiyama924

細谷さん、黒板に縦線を引き、「To do」と「Done」に分割。読み上げながら集めた付箋を「To do」側にペタペタ貼って、講義で説明するたびに、「Done」へ移動していくとこのこと。「かんばんボード」ですね!

2012-11-16 10:18:34
あきやま☀️ @akiyama924

付箋に書いてもらった聞きたいことの中で最優先をマークしてもらってから集めていました。

2012-11-16 10:19:39
ゆにまる⛳️ @Unity1004

細谷さんの講演なう。講演自体がアジャイル開発!?

2012-11-16 10:21:55
あきやま☀️ @akiyama924

18枚集まりました。みんなが書いている間に細谷さんと雑談していたのですが「この進め方自体がアジャイルですねー」って言ったら「そうですねー。アジャイル界隈では結構やってますよ」とのこと。

2012-11-16 10:22:11
あきやま☀️ @akiyama924

細谷さん「アジャイル開発ってなんですか?」 鷲崎先生「お客様と寄り添いながら開発を進めること?」

2012-11-16 10:23:34
あきやま☀️ @akiyama924

細谷さん「識者が集まっても、アジャイルマニフェストに同意してたらアジャイルなんじゃないかということくらいしか、共通点がないようです。 http://t.co/jDuVXver

2012-11-16 10:24:57
あきやま☀️ @akiyama924

細谷さん「アジャイルにすると広くなってしまうので、今日は、品質向上の取り組みの一つとしてのスクラムにスコープを絞ってお話ししたいと思います。

2012-11-16 10:25:48
あきやま☀️ @akiyama924

細谷さん「スクラムには3つの原則があります。まず『透明性』です。スクラムは透明性を大切にしています。傾きかけているプロジェクトでは悪い報告を挙げるタイミングを気にしたり『お客様に言えない』とかいうことが起こります。スクラムでは包み隠さず透明にします。

2012-11-16 10:28:10
あきやま☀️ @akiyama924

細谷さん「2つ目の原則は『検査』、3つ目は『適応』です。メトリクスを取ることも重視しているんですよ。

2012-11-16 10:29:49
あきやま☀️ @akiyama924

細谷さん「スクラムでは、3つのロールがあります。プロダクトオーナー、スクラムマスタ、チームです。

2012-11-16 10:30:27
あきやま☀️ @akiyama924

細谷さん「プロダクトバックログで重要なのは、要求をリスト化すること、重要度が重複しないことが大切です。優先度ではなく優先順位とすることが重要です。

2012-11-16 10:31:38
あきやま☀️ @akiyama924

細谷さん「優先度だと、タスクに、だんだん重要度Aが増えてくる、、、そのうちAばかりになると、特Aが出てきて、『Aはやらなくていいよね』なんて話になって、さらに特々Aなんてできたりして(笑)

2012-11-16 10:33:29
あきやま☀️ @akiyama924

細谷さん「豚と鶏の話知ってますか? http://t.co/8tM4RQZS

2012-11-16 10:36:14
あきやま☀️ @akiyama924

細谷さん「品質の問題が発生する要因として、『階層構造+オーバーコミット』があると思っています。オーバーコミットはスコープとコストに矛盾がある状態です。上の階層から実行部隊に矛盾が落ちてくる。この矛盾を上に上げて解消するためのロスがある。その間に現場で突貫工事していませんか。

2012-11-16 10:41:49
あきやま☀️ @akiyama924

さっき控室で『階層構造+オーバーコミット』ってその通りですね。初めて聞きますが、、、といったら、細谷さんのオリジナルな課題認識だそうです。

2012-11-16 10:43:29
あきやま☀️ @akiyama924

細谷さん「『階層構造+オーバーコミット』の問題を解消する方法としてスプリントがあるのではないかと考えています。優先順位を立てて、現場が、工数的にできる分だけにスコープを絞り開発をしていく。『甘いんじゃないか』という見方もあるかもしれないが、トータルとして効率が良くなるという考え。

2012-11-16 10:47:48
あきやま☀️ @akiyama924

細谷さん「スクラムの見積もり方法は、カードを使います。

2012-11-16 10:51:15
あきやま☀️ @akiyama924

見積のカードってほとんどフィボナッチ数列なんですよね。0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100から、一つのユーザーストーリーの工数を選んでいく方法。

2012-11-16 10:53:21
あきやま☀️ @akiyama924

細谷さん「オーバーコミットすると突貫工事になり、成果物はきたないものになります。いったんきたなくなってしまったソフトウェアをきれいにするのは難しいし、非常に手間がかかります。

2012-11-16 10:54:36
あきやま☀️ @akiyama924

細谷さん「フレームワークとは、サッカーで言うとルールにあたります。ルールに従わなければサッカーになりません。

2012-11-16 10:57:15
残りを読む(30)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?