Agile Tour Vietnam (HCMC and Hanoi)に行ってきました。 - haradakiro's blog
行ってきました。 30度超えの街から、最低気温が4度とかに帰ってきたので、すっかり風邪気味です。 Agile Tour Vietnam は、今年で三年目の参加ですが、ホーチミンの開催は参加者が300人を超え、すっかり大きなイベントになりました。大きくなるにつれ参加者の層も広くなって、街の活気と同じく、参加者にも活気があって楽しいです。 Agile Tour Vietnam では、Kaizen Basics というワークショップと、TPS, Lean and Kaizen というトークをやってきました。トークのほうのスライドはこちら。最後のコミュニティの写真は、Agile Tour Hanoi 2013 のオーガナイザー、ボランティアの皆さんです。 TPS Lean and Agile - Brief History and Future from Kiro Harada 人と集まって仕事を
Mike Beedle 氏の認定スクラムマスタ研修を開催します。 - haradakiro's blog
来年の年始、1/14-15に開催されるRegional Scrum Gathering Tokyo 2014に、Mike Beedle氏がキーノートスピーカーとして来日します。 その来日に合わせて、1/9-10 と 1/16-17 に Mike氏による認定スクラムマスタ研修を開催します。詳細資料はこちら。 Mike Beedle 氏は、スクラムを作った Jeff Sutherland / Ken Schwaber 以外で、初めてスクラムを適用した人です。しかも、スクラムの説明にあるように小さなチームからのスタートではなく、トラブルに陥った２００名を超えるプロジェクトを立てなおすためにスクラムが使われました。 氏の研修は、Enterprise Scrum (企業のためのスクラム)となっています。 ソフトウェアに限らず、さまざまなビジネスがいかにアジャイル・リーンという方向性に向いてきたかを
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
デイリースクラムで ScrumMaster がやるべきこと - haradakiro's blog
デイリースクラムのやり方は、いろいろなところに書いてあるし、チームによっていろいろ工夫をしていると思うので、ここでは書かない。 Scrum Guide にも書いていないけれど、ScrumMaster が絶対にやるべき重要なことがある。 メンバーの顔色を確認することだ。メンバーの体調を計測することだ。それだけでも、ScrumMaster がフルタイムの役割である十分な理由がある。 メンバーの体調は、常に気を配っていないと気付くことはできない。デイリースクラムの３つの質問に気を遣うと同時に、ScrumMaster はメンバーの体調についても十分注意を払う必要がある。 どうも風邪薬や栄養剤のCMのおかげで、体調が悪くても会社にいくべき、のような風潮がある。でも、この時期、インフルエンザのメンバーを一日出社させてしまったら、そのスプリントは終わりだ。チームが全滅するだろうし、他のチームにも迷惑をか
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
Coderetreat ファシリテーターガイド - haradakiro's blog
Coderetreat へようこそ Coderetreat は、一日中集中して練習するイベントです。ソフトウェア開発と設計の基礎に重点を置いています。開発者を仕事を片付けなければならないというプレッシャーから開放して、集中して練習する機会を提供することで、非常にスキルの向上に有効なことが示されています。モジュール設計、オブジェクト指向設計の基本原則を練習することで、将来にわたって変更コストを小さくするコードを書くスキルを改善できます。 ファシリテーション Coderetreatにはファシリテーターが必ず必要です。ファシリテーターの責務は、一日の概要を説明すること(私の解説ビデオを参考にしてください)、セッション中にペアをガイドすること、セッション間の振り返りと、終わりの会をリードすること。このページでは、一日の概要スケジュールと、効果的なファシリテーションのコツを説明します。ブログにも c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
