2010-11-02

スクラム道.01 に参加してきました

Agile scrumdo

スクラム道と呼ばれる、
スクラムを中心にアジャイルを探究する会に参加してきました。
http://kokucheese.com/event/index/4739/

初回の今回は、テーマは「ふりかえり」で、
話し手は [twitter:@nawoto]さんによる「KPT is harmful」というお題。

harmful な理由
- 意見が出ない
- Problem ばかりになる
- Problem出すと怒られる
- Try書くの難しい
- Try出すと、自分にふられるので出せない
- 現実的なTryが出せるProblemしか出さない
- etcl...etc...

といった、書物やWebの記事等ではさらっと、
"こうすれば良いよ"とやり方が記されているのだけど、
いざやってみると難しいなーとなってしまう「ふりかえり」の定番である「KPT」。
講演はここまでで、皆さんどうなの? という問いかけと共に、
スクラム実践者である参加者の皆さんと議論をしました*1。

参加して一番考えさせられたのは、
「型に囚われすぎるな」というメッセージと、
改めて「ふりかえりは目的が大事」という事。

アジャイルなプロジェクト、チームは目的を持って「改善」をするために「ふりかえり」という場を持つ。
「お客さんに対する価値を最大限出すために」に一番重きを置いて、実施するチームもあれば、
「チームが1つになるために」に一番重きを置いて、実施するチームもあれば、
「開発の課題や問題にチームで直面するために」に一番重きを置いて、実施するチームもある。

上記では、チームと書いたけど、同じチームであっても、
立ち上がり時や、熟練したチームになった頃、イテレーション終了後、リリース終了後、
その時々、異なる目的に重きを持って「ふりかえり」をすることもあるだろう。

「ふりかえり」をする上で「KPT」というやり方が難しいのなら自由にやれば良いじゃんって事で、

「KPTじゃなく、KP、PT、KTのみ」
「Kのみ、Pのみ、Tのみ」
「絵や気持ちをグラフ(バイオリズム形式)で描いた」
「ポストイットに挙げてグルーピング」
etc

また、「KPT」やる上でも目的に合わせて、

「偉い人をあえて外して発言しやすくした」
「お客さん混ぜた/あえてお客さんを外す」
「定期的にしない」
「Try1個でも良い。確実に出来るのを出す」
etc

といった、
既に自分達のチームに合わせて実践されている様々な「ふりかえり」方法を聞けましたよ*2。

もし、ただ単に義務的に「アジャイルでやってるからイテレーションの終わりに"KPT"しとこか」
という組織があるのなら、そもそも何の「改善」の目的に「ふりかえり」をするのかを、
今一度考えるのが大事なんだなー。

スタッフの[twitter:@Ryuzee]さん、[twitter:@nawoto]さん参加者の皆さんありがとうございました!

*1:あんま、発言してないかもw

*2:この辺の何如に自分達のチームの目的となる「改善」をするため、手探りでいろいろな「ふりかえり」方法を考える所がスクラムマスターの腕だなーっと勉強になりました

2010-10-25

すくすくスクラム #19 に行ってきた

suc3rum Agile

@ebacky さんによる、Agile 2010 で行なわれた、
"KANBAN AND SCRUM - MAKING THE MOST OF BOTH" の再演に参加してきました。
http://kokucheese.com/event/index/4912/

珍しく飲まれなかったんで自分用メモをばw

メモ

正確ではないです。誤りがあればご指摘下さい。

Kanbanの効果

信号システム
可視化
仕事量を制限

Kanbanの特徴

Kanbanボードは複数チームで使っても良い
- Scrumボードは1チームに1つ(であるべき?)
手法にルールが少ない分、自分達なりにカスタマイズ、合わせて使って行くことが大事
- プロセス(ルール数)： RUP(120+), XP(13), Scrum(9), Kanban(3), 何でも(0)
KanbanもScrumも現状の問題の透明性を高めるそれにより、より改善を促す
- Scrumでは、開発チームだけ改善となり、部分最適に落ちいる可能性があり、これは良く無い
Kanbanは、仕掛りを制限する
- 制限(仕掛りの上限)は自分達の経験をもとに出す*1
- 仕掛りの数が少ない：チームに怠け者が出る
- 仕掛りの数が適切：ときどきゆとりがある状態。タスクの流れが気持ち良い状態になる(らしい)
- 仕掛りの数が多い：開発者にゆとりが無い。ただただ過酷で、製品に対する気持ちが入らない
Kanban は進化させていく
- ルールが少ないが故に、Kanban自体を進化させて行くことが大事
- 自分達流のKanbanを作るのが大事

Kanban と Scrum

	Scrum	Kanban
ロール	チーム、プロダクトオーナー、スクラムマスター	特に定めない
アウトプットのタイミング	タイムボックス毎に出す*2	チームの能力により出すタイミングは異なる
タスクの明白さ	スプリント毎に収まるように、分割したり調整する(?)	タスクのありのままが見える
		明示的に仕掛りの数を制限出来る
変更要求	スプリント中は変更を受け付けない	常に受けいれる*3
完了タスクの状態	スプリント毎にリセット	常に残る(?)
適するチーム	機能横断チームを好む(?)	専門家チーム、総務チームも好む(?)
見積りの仕方	フィーチャはストーリーポイント、タスクは日数	フィーチャは大、中、小で、タスクは数だけ数える
バックログ	必須	置いても良い*4

大事なこと

ゴールを把握する
ツールに良し悪しは無い
- 状況によって使い訳が大事
- その時の状況が悪いからと言って、駄目と判断するのは良くない
ツールも1つにこだわらない
- 自分の世界を狭くするよ
挑戦することを諦めない、失敗も悲観しない
大切なのは、プロセスじゃなく、プロセスを改善すること

ワーク1

リードタイム(1つのタスクが完成する時間)が3 のチームと 20 のチームのどちらに改善をするべきか。

ワーク2

ゲーム1)
- 参加者(グループメンバー)の名前を1文字ずるを並行に書いていく。リードタイムをはかり、良かった点と改善点を出す
ゲーム2)
- 参加者(グループメンバー)の名前を1人ずつを順に書いていく。リードタイムをはかり、良かった点と改善点を出す
ゲーム1、ゲーム2を比較して、違いを討論する

ワークのアウトプット

感想、チーム内での話合いなど

印象としては、講演中何度も言葉を変えて出た、
"ツールに縛られるな"と"自分達に合うように改善していく"という事。

また、元々"vs" とされていたのは、
それぞれの特徴や違い、類似点を明確に説明するためで、決して戦わせるという訳では無いのでしょう。
そういう意味では、個人的には、"and" よりもしっくりくる。

グループ内に、Kanbanを実践されている方がいましたので、
話を聞かせてもらいました。

Q. 見積りは大、中、小だけど、お客さんに納得して頂けるものなのか?
- A. お客さんにも、だいたいの大きさで説明して、それで納得して頂いている。開発チームへの信頼が大事
Q. 仕掛りの制限はどのようにしていますか?
- A. リソースを用いている。5人チームだと5つまで。

帰りがけに、 @haru01 先生が、"WFでもKanbanは使えるよ" とおっしゃってました、
今度、詳しく聞きたいです。

*1:動的に変えるのは良くないらしい。制限を設けた意味が無くなる

*2:「この特性故、お客さんとの確認やレビューのタイミングは取りやすい」と

*3:ただし、チーム内に余力があれば

*4:「バックログが無くてもちゃんとしたものから作るのは、自主的に、紳士的に必要な機能から作るから。スクラムもそうだろ?」と

2010-10-03

アジャイルについて記事を書きました

Think ITさんでアジャイルに関する記事を執筆させて頂きました。
「アジャイル実践1、2、3」

執筆するという事も初めてですし、
週1回の連載という事もありまして、毎週いろいろ大変でしたが*1、
無事先日、最後の記事も公開されました。

全4回で以下の様な内容です。ご興味がございましたら、お読み下さい。

僕は、"アジャイル"という事について、
本を読んだり、コミュニティに参加してからではなく、
実践していたプロジェクトに新人の頃からたまたま運良く配属して... なので、
正直な所、他手法と比べてどうだとか、そういうお話は見聞きした範囲でしか語れません。

ですが、逆に、そういう人間、それも経験も浅い若造が自身の少ない体験を淡々と記事にする。
という事をコンセプトに好き放題、書かせて頂きました(笑)

今回記事を書くにあたり、初めて"アジャイル"
いや、"XP"について触れた頃の事を思い出しました。

最初に会社に入った時、当時プロジェクトリーダーであり、上司であった @kuranuki さんから、
"XP" についての5つの価値*2を聞いて、なんと言いますか、
良い意味で、その人間臭さに驚きました。

そして、初めて参加した社外のイベント XP祭り2006。
最後に参加者の皆さんで、「Dear XP」という歌を歌っているのを見て、
"XP"って、活気があるな! そして、楽しい! と感じました。

新人の時のそういう経験が今の自分を形作っているんだなぁ、
と、5年目の今の自分を見て改めて実感します。

最後になりますが、今回、機会を下さった@kuranuki さん、@blackaplysia さん、
いろいろ相談にのって頂いた、@sobeit さん、
そして、締め切り前に仕事をいろいろ調整してくれたチームの皆さん、
ありがとうございました。

*1:本当に大変だったのは編集部の方だと思いますがw

*2:コミュニケーション、シンプル、フィードバック、勇気、リスペクト

2009-12-13

Devlove2009Fusion 世界一言語トークスでトーカーしてきました

イベント ruby devlove

「Ruby」についてです。

ぼくにもできたよ! Rubyを使ったデブラブハック

View more documents from NaokiNishiguchi.

Ruby 界では凄い人がたくさんいらっしゃるのですが、
御縁があり今回、発表させて頂きました。

開始前はちょっと緊張してたのですが、
会場のみなさんが、とにかくあたたかい雰囲気だったので、
救われました!(ありがとうございます)

しかし、資料のコードが小さすぎて見えにくいね。
次こういう機会があれば、もっと気をつけねば。

個人的に世界一だと思ったのは、「Scala」です。
(実は牛尾さんの発表初めて見たのですが凄かったです。宗教か?)

一番使ってみたくなった言語はよしおりさんご紹介の「Python」です。

スタッフ、参加者、発表者の皆さんありがとうございました&お疲れさまでした。

ところで、去年立てた今年の目標も年末にしてやっと完了か!?
http://d.hatena.ne.jp/nsgc/20081208/1228739741

私の来年の目標はＬＴデビューです。

2010年の目標は、
「私の英語力をなんとかする」
本は無理ですが、何かの記事とか和訳とか出来るように。。。日々精進。

2009-09-09

KINESIS キーボード体験キャンペーン

レポートキャンペーン

借りた人が皆、「KINESISは良い」という評価する、
KINESIS キーボードを2週間程借りてみた。

ニュータイプ専用機みたいな下記キーボードを、
ザ・オールドタイプな私が使ってみた感想をば。

比較対象:マイルドセブン1 ロングボックス及び HHK Pro

使いはじめた<序盤>

見た目はあれですが、意外とごく普通の英字配列のキーボードです。
つまり、英字の入力はさほど難なく可能です。

写真を見て頂くと分かるかと思いますが、
Delete, BackSpace, Alt が左親指、Enter, Space, Windows は右親指で押せる辺りにあります。
また、Ctrl が丁度、左右のそれぞれ親指で押せる辺りにあり、
この構造が所謂、エルゴノミクスキーボード*1 と呼ばれる所以だと思うのですが、
とにかく、Emacser な私は、Ctrl を押そうとして、左Shift を押すという問題が多発しました。

それに、Alt を親指で押すと、
Windows のタスク切り変え(Alt + Tab)や、Emacs の操作系(Meta + x) がとにかく押しにくく、
指の長い外国人用なのかorz
と、とにかく辛かったです。

使ってみている<中盤>

上記の不満を id:ursm さんに相談したところ、
「Remap すれば良いよ!」とナイスご意見を頂きました。

早速教わりながら、
右にある、Windowsキーを ALT に、
左にある Homeキー、右にある Page Up を Windows に変えると、
とても使いやすく便利に!! とにかく、キーボード内で好きなように配備出来るRemap は強力です。

上で書いていた Ctrl 押し間違え問題は慣れてくると問題無くなります。
それに、CapsLock を Ctrl に変える事も可能ですが、
それはせっかくの KINESIS の特徴を潰すことになるので、敢えてそのまま親指で使いました。
左手の小指を潰しやすいと言われる Emacser には、特に親指Ctrl はお勧めですよ。
例えばカーソル移動、
上下は、左親指Ctrl と p, n (右手)で、
左右は、右親指Ctrl と b, f (左手)という様にすると、
バランスが取れて、手首や指に非常に良いそうですよ。

ただ、ずっと許せなかったのが、=, + の位置
頭では分かってみても、彼らが左上に鎮座しているのは慣れなかった。

後、Typo がしょっちゅうでした。
気を許した時の、コミットメッセージが酷かったです*2。