2012年02月01日

[雑多]ゆる〜い読書会「プロジェクト・マネジャーが知るべき97のこと」

 先日、ゆる〜い読書会「プロジェクト・マネジャーが知るべき97のこと」をやってみました。
#参加していただいた皆さん、ありがとうございました!

◆きっかけ
 何気ないつぶやきに反応してもらったのがきっかけです。


◆やってみた
 みんなのコンテキストはプログラマーもいたり、最近開発から離れている人もいたり、Webな人、組み込みな人、Agileな人、テストな人・・・色々でした。
 それぞれ(過去には)プログラムを書いたことがあるという点は共通していました。

 やり方はこんな流れになりました。
・対象の話を1つ選ぶ。それを2組に分けて約10分間、ディスカッションする
 (分けたのは5人位までの方がこの手の話は盛り上がると思ったので)
・10分終わったら次の10分で共有。これで1サイクル
・2話位やったらくじ引きで組替え

 ディスカッションした話はこんな感じでした(ディスカッションした順)。
・20:集中する時間を取る
・7:スキルでなく素養のある人を加えよう
・34:60/60ルール
・12:すぐれた開発者を見つけるには
・19:休暇をキャンセルしない
・76:よいスポンサー、わるいスポンサー、ひどいスポンサー


◆感想
 どの話も「この点はこうしたらうまく行った(行かなかった)」など活発な話が飛び交い、盛り上がったように思います。
 良かった点は「こう書いているけど(実際には)無理やで」という声がほとんど出なかったことです。
 「難しいけど、その中でやるにはどうしたら良いだろう?」という感じで、前向きでした。

 もう1つはタイムボックスを決めて、1つの話をダラダラしない点も良かったように感じました。
#もっと深堀りしたかった話もあったかもしれませんが、そこら辺は各自のコンテキストをベースにやってもらえたら良いかなぁと。
 
 改善点…というか、「次はこうしてもいいなぁ」という点は「(ここN年は)プロジェクトマネージャだけやってる!」て方の意見も聞いてみたいことです。

◆最後に
 まだディスカッションしたい話もあり、(そのうち)第2回を開くと思います(私じゃなくても誰かが)ので、興味がある方はぜひお話しましょう。
タグ:勉強会
posted by yohhatu at 09:34 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年01月17日

社内読書会をやってみて

※この記事は新しいブログに移行しました。

移行先は【社内読書会をやってみて – サウスポーなエンジニアの独り言】です。
タグ:agile 勉強会
posted by yohhatu at 20:17 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月24日

[仕事]チームへのRedmineの効果

※この記事は新しいブログに移行しました。

移行先は【チームへのRedmineの効果 – サウスポーなエンジニアの独り言】です。
タグ:redmine
posted by yohhatu at 17:14 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月19日

[雑多]priomoPDFのちょっとしたTips2つ

勉強会やセミナーで作ったパワポをPDF化する時に「primoPDF」を使っています。
※参考:priomoPDFの公式ページ
 .NET Framework 2.0 以上が必要かつWindows専用ですが、無料ですので。
 で、その「primoPDF」のちょっとしたTipsを2つほど書きます。

***********************

◆1:変換時の余白の調整方法
パワポをデフォルトのままPrimoPDFでPDFに変換をすると画像1のように、周囲に余白が残ってしまいます。
※元のパワポはもちろん周囲に余白はありません。
【画像1】
画像1.png

 周囲に余分な余白があるとイマイチですよね。
 というわけで、これを画像2のようにする設定です。
【画像2】
画像2.png

【設定】
パワーポイントのスライドの縦/横を入れ替えた数値にします。
デフォルトなら以下のように設定すればOKです。
「Width: 190.50 Height: 254.00」
余白設定_01.png

参考:PrimoPDFでPowerPointファイルをPDF化する際に余白を消す方法@msakaiさんのマイページ

◆2:文字の欠落の防止
 最近バージョンアップして4.1にしたところ、(いくつかのスライドで)文字が欠落するようになりました。
 何度やっても同じスライドの同じ文字で欠落します。

 ホントは↓な風に見えて欲しいのに・・・
文字欠落_02.png


 …↓な風になっています。
文字欠落_01.png


 Google先生に以下のサイトを教えてもらいました。
参考:PrimoPDFの新バージョンにおける文字化け対応について@PDF無料活用クラブ

 それの対応方法は以下のサイトにあるように…
(1) 「スタート」→「コントロールパネル」→「プリンタとFAX」でPrimoPDFのドライバをクリック。
(2) メニューから「プリンタ」→「印刷設定」で、「レイアウト」タグ内、「詳細設定」をクリック。
(3) 「Primo PDF詳細オプション画面」がオープンするので、「ドキュメントのオプション」→「PostScript Options」→「True Type Font Download Option」をOutlineに。

こんな感じです。
文字設定.png

***********************

 以上です。
タグ:tips
posted by yohhatu at 23:02 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月15日

[雑多]WindowsでのRails3環境構築の続き

 エントリ「WindowsでのRails3環境構築」の続き・・・というか、エラーが発生したので、それの備忘録です。

◆現象
 irb、rails console を実行した際に以下のようなエラーが発生する
・・・Ruby193/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2111:in `expand_path': non-absolute home (ArgumentError)

◆対処法
 ほぼそのまま「◆参考」のブログの通りでした。
 私の場合は環境変数HOMEを削除すれば無事動きました。

 Cygwinはちょっと試しに入れてみたのですが、使っていないでこの際キレイにしておいた方が良いと思っています。

◆参考
Ruby irb Windowsのエラー対処法@Maorin Blog

◆余談
 ちょうどペアプロしている最中にこの現象に出くわしました。
 ペア相手は普通に動いていたので「(Railsが悪いわけでなく)自分の環境が原因だろう」と早く切り分けができました。
タグ:Rails 備忘録
posted by yohhatu at 22:59 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月10日

[仕事]Redmineのチームでの使い方を紹介

※この記事は新しいブログに移行しました。

移行先は【Redmineのチームでの使い方を紹介 – サウスポーなエンジニアの独り言】です。
posted by yohhatu at 00:19 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月06日

[仕事]Jenkins「さん」

 今のチームのJenkins「さん」とは約2年位の付き合いです。
#日本Jenkinsユーザー会はこちら

 私はよく「Jenkinsさんが怒ってるで〜」と「さん」付けで呼んだりしています。
#ITSではRedmineを使っているのですが、それは「さん」付けではありません。

◆なぜかな?
 あの執事の風貌も関係ありますが、シンプルにJenkinsさんをチームメンバーの一員として思っているからだと思います(少し痛いですが・苦笑)。
 
 ただマジメに、それくらいチームに無くてはならないのです。

 人力だと時間がかかる(そしてミスもしやすい)チェックやテストなどの作業を何回、何十回もしてくれます。
 また夜遅く/朝早くなどこれまた人では難しい時間でも平気です。

 そういうのをやってくれるだけでなく、結果も「この辺がおかしいですよ」と割と親切に教えてくれたりします。

◆感覚的なものですが・・・
 うまくCIが回っているチームほど、Jenkinsさんをチームの一員と思っているように感じます。
 うまく使いこなせていない所は「Jenkins設定めんどくせ」「Jenkinsがエラーを通知しているけど、修正は後で良いよね」というようなおざなりな感じだったりします。
#Jenkinsではなく「CI」を活用しきれていないのですが…

◆そんなJenkinsさんの勉強会があります
 第2回大阪Jenkins勉強会が…来年…2012年2月10日に開催予定です。
 まだ先の話ですがご興味のある方は覗いてみてはいかがでしょうか?
タグ:Jenkins
posted by yohhatu at 22:04 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年12月01日

[仕事]WindowsでのRails3環境構築

 Windows上でのRails3の環境構築に毎回ちょっとはまって、同じようにググって解決しているので自分用備忘録です。
#間違いあったら指摘してくれると嬉しいです。

◆ゴール
Ruby1.9.3 + Rails3 + SQLite で動くアプリの動作確認をする。

◆Rubyのインストール
 ダウンロード先はこちらで「RubyInstaller」を選択します。

 インストールは任意の場所で良いですが、全角文字やスペースがあるパスは避けた方が良いと思います(私は「c:\myapp\ruby193」のようにしています)。

 コマンドプロンプトで「ruby -v」でインストールしたバージョンが表示されればOKです。
ruby 1.9.3p0 (2011-10-30) [i386-mingw32]

※うまく表示されない場合は<インストール先フォルダ>\binにPATHが通っているか確認してみてください。

◆Railsのインストール
gem install rails

 インストール後、コマンドプロンプトで「rails -v」でインストールしたバージョンが表示されればOKです。
Rails 3.1.3
 
◆SQLite3のインストール
 こちらの「Precompiled Binaries For Windows」から「sqlite-dll-win32-x86-3070900.zip」(dll版)をダウンロードします。
 展開したsqlite3.dllを\binにコピーします。

 コマンドプロンプトで…
gem install sqlite3

 …とします。

◆Railsのアプリ作成
 適当なディレクトリを作ってコマンドプロンプトで以下を実行します。
rails new sample

 この時にjsonのbundleで失敗することがあります。
Installing json (1.6.2)
Gem::InstallError: The 'json' native gem requires installed build tools.

 この場合はDevKitのインストールして対応します。

◆DevKitのインストール
 こちらから「DevKit-tdm-32-4.5.2-20110712-1620-sfx.exe」をダウンロードします。
 解凍してコマンドプロンプトから以下のコマンドを実行します。
ruby dk.rb init
ruby dk.rb install

 この後…
rails new sample

 …を実行します。

◆動作確認
 http://localhost:3000にアクセスして「Welcome」画面が表示されればOKです。
タグ:Rails
posted by yohhatu at 23:31 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年11月27日

[仕事]LT「勉強会へ行こう」を話してみて思ったこと

 チームの合宿で「勉強会へ行こう」というLTをしました。

◆言いたかったこと

 10人ちょいのチームで「勉強会に参加したことがある」方は(私も含めて)3人でした。
 シンプルに「勉強会というのがあるのですよ。行ってみてはどうでしょうか?」と言いたかったわけです。

 LTが終わった後、ある方が…
「勉強会というのが世間にこんなにあるとは知らなかった。たぶん社内では(『興味ある/なし』の前に)勉強会の存在を『知らない』のが多いと思う。なので、こういう情報を知ればそれなりの数が興味を持つと思うよ」
 …と言っていました。
 こういう声は嬉しく思いました。

◆もう少し考えてみました
 そういう声を聞けたのは嬉しいのですが「そういう勉強会の存在を知ったとして、行くのだろうか?」と考えてみました。
※これまで何度か勉強会のお知らせをしたり、誘ってもなかなか行動につながらなかったのを経験しているので(苦笑)。

 (良いかは別ですが)「SIerのSE」のよく見かける姿勢として【担当するお客様の業務を理解し、お客様の課題や問題を論理的に破綻無くITシステムを使って(時には使わずに)解決する】ことを役割の1つと考えているように感じます。
 そして、そこには「こういう(今までやってなかった)考え方を使って・・・」とか「○○という新しい技術で・・・」という発想はあまり多くありません。

 それよりも業務知識、ヒアリングスキル、ファシリテーションスキル、そして開発チームと共同していくスキル※に重きを置いています。
※本来はこれは「チームビルディング」スキルであって、(元請け-下請け構造に基づく)丸投げでも、Excel上だけの進捗管理・収支管理ではありません。

◆周りの勉強会を見ると・・・
 私が知っている勉強会のタイトルや概要を「勉強会に出たことがないSIerのSEの目」で見ると「自分のお客様や業務に関係がない」と思ってしまうのでは?と感じました。
#もちろん「新しい技術や考え方を身につけなくて良い」というわけではなく、これは大きな課題であり変えていく必要のあることです。

 では、もし業務に関係する勉強会…例えば「ヒアリングスキル勉強会」や「生産管理を学ぶ勉強会」…があったとしたら「自分をレベルアップをするために参加するか?」と疑問が浮かびました。
#「うちは特殊だから当てはまらないよ」とか「業務で忙しいし・・・」とネガティブな声が聞こえてきそうですが(苦笑)。

 「そういう勉強会があるよ!」って方は声をかけてもらえると嬉しいです。

◆最後にもう一度言いたかったこと
 自分の業務に関係あることならより良いですが、そうでなくても社外の方の話を聴いて、(あわよくば)自分の意見を伝えて議論するというのは(勉強会に出席する)時間以上に価値があります。
 ので、(食わず嫌いの前に)一度でも勉強会に顔を出してみてはいかがでしょうか?
posted by yohhatu at 07:23 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年09月29日

[雑多]UbuntuでGoogle日本語入力を使う方法

久しぶりにサブPC(Ubuntu)をさわった時に調べたことがあったので、自分の備忘録です。

***********************

◆UbuntuでGoogle日本語入力を使う方法
 Ubuntuでは標準で入っている日本語入力が入っています。

 が、その使い勝手がいまいち…先頭文字を英語で打っても次の文字がなぜか日本語になっている等…でした。

   なので、Google日本語入力を使えないか?と思って調べたら以下の方法でできました。

※試したのはUbuntu11.04です。

 まずはGoogle日本語入力がインストールできます
sudo apt-get install ibus-mozc
 次にibusを再起動します
killall ibus-daemon
ibus-daemon -d -x &
 その後、ibusの設定画面を起動します
ibus-setup
 表示された設定画面で、「インプットメソッド」タブ→「インプットメソッドの選択」で"Mozc"を設定すればOKです。
***********************

 意外と簡単でした。
タグ:ubuntu 備忘録
posted by yohhatu at 20:28 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年09月15日

[仕事]インセプションデッキ書いてみた

※この記事は新しいブログに移行しました。

移行先は【インセプションデッキを書いてみた – サウスポーなエンジニアの独り言】です。
タグ:agile 仕事
posted by yohhatu at 23:31 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年09月10日

[仕事]「Scrum Boot Camp in 関西」に参加してきました

 「Scrum Boot Camp in 関西(通称:Scrum BC)」に参加してきました。

 最初は「Developers Summit 2011 Kansai(通称:デブサミ2011関西)」に参加するつもりでしたが、この「ScrumBC」が併催されると聞いて、(申し訳ないなぁと思いつつ)キャンセルしてこちらにしました。

 コーチ陣はScrum界隈でよく知られた方が6人もいるという豪華な陣容でした。

 参加者…30人ちょい…もほぼ時間通りに集まり、意識の高さが伺えました。
 見渡してみると、プロジェクトリーダー的役割で活躍して(そして苦労して)いる方が多そうな印象でした。

#スーツ率は1/3くらいで、同じグループの方に聞いてみると「普段は私服だが勉強会ではスーツが習慣」な方もいたり、「勉強会に出るのが初めてでどんな格好か分からなかったのでスーツ+ネクタイ」の方もいました。

***********************

◆チームビルディング
 このグループ分けの方法、デイリースクラムをやって距離感を縮める、「ランチ一緒に行ってみてね〜」の薦めなど、参加者がうまく入れるようにする仕掛けに感心しました。
#これは自分達の組織の社内研修などでも取り入れると良いと思いました

◆Scrum概論(原田騎郎(@haradakiro)さん)
 Scrumの流れをデイリースクラムやスプリントなどの「タイムボックス」、プロダクトバックログやスプリントバックログなどの「インプット」の観点からの説明してもらいました。

 自分の気づきは、スプリントレビューの説明から「一種の進捗確認だが、WFの進捗確認との違いは実際に『動くモノ』を見せる点」という件。
 最近スプリントレビューでのチーム内デモを充実し始めたので、余計に実感できました。

 後は「Inspect and Adapt(検査して適応)」の話。
 自分達のチームに当てはめたときに「適応」に対してはもっとうまくやれる部分があると思いました。
#ちなみにこの「検査して適応」は午後の「紙飛行機ワークショップ」で強く実感しました。

 また「スクラムマスター(SM)はチームが能力を最大限発揮できるようにする」のが役目の1つだと再認識し、自分達のチームに「開発に集中できているか?」をゆっくりディスカッションしてみたいと思いました。

◆紙飛行機ワークショップ
 とにかく印象に残っています。

 端から見ると30人以上の大人が必死に「紙飛行機の効率良い作り方、飛ばし方」を議論して、走り回って紙飛行機を飛ばしまくっている姿は面白いかも…と思いましたが、みんな真剣でした(もちろん自分も)。

 自分達のチームは1回目は全然ダメで、それを「検査して適応」し、2回目では良いアウトプットができました。
 制約を外すことができた3回目でも、役割分担(飛行機を作る/整える/運ぶ/飛ばす)を行い、さらに良いアウトプットができました。
 最後の制約が戻った4回目では、それぞれのアウトプットのスピードがアンバランスになりタイムロスが出てしまいました。

 「スプリントの途中でもすぐに役割毎のリソースを調整すれば良かった」とグループのフリカエリで出ていました。
 
◆Artifact+PBI作成ワークショップ(川口恭伸(@kawaguti)さん)
 バーンダウンチャート、ストーリーカードのお話、そこからプランニングポーカーを使った見積もりのワークショップ…という流れでした。

 プランニングポーカーでの見積もりは、(自分達のチームでもやってことがありますが)ほぼ例外なく、参加者のワクワク感が一層高まり、楽しそうにやっていました。

 「見積もりの数字の違いに驚く」→「その違いをディスカッションして埋めていく」→「見積もりの数字が合う」=「チームで共有できる」というのをすごく実感できました。

 また悩みだった「ストーリー間の前後関係を考慮した数字にするか?」の回答を得られました。

 結論は「依存関係がない」前提で見積もるのが良いということです。

 依存関係があるとタスク同士が結合し柔軟性がなくなり、プロダクトバックログの優先順位を自由に動かせなくなります。
 また結果的に(前に作ったストーリーを参考に)早くできたのであれば「チームが工夫して」でVelocityが上がって良かったね…というロジックの方が前向き…ということです。

◆その他1
 (たぶん)QAの会話で印象的だったのが「WFとAgile(Scrum)ではお客様とのモメ方が違う」というお話でした。
 WFでは最後になってドカン!!と「自分がほしいのはこんなのではない」ともめますが、Agile(Scrum)ではスプリントレビューやプロダクトバックログを見直すタイミングで小さなもめ事がちょくちょくあるいう内容でした。

 その小さなもめ事は、プロダクトが出来上がっていくうちにバラバラだったそれぞれのイメージが共有されていく故に出てくる健全なことで、むしろ、そういう意見の相違や小さなもめ事が出ないことは「お客様が本気になっていない」可能性がある…というのが印象的でした。

◆その他2
 ランチでもグループでのディスカッションを通じて、自分達のチームの、今に至るまでのポイント、これまでの改善点を洗い出すことができました。

 また「Agile(Scrum)は属人性がすごく高いのでは?」「レベルの高低がありすぎて、(ファンクショナルチームを実現できるような)スーパーマンみたいな人ばかりでない」と疑問が出ていました。
 この辺りは自分も悩んでいる所だったりします。

◆その他3
 それぞれのコーチにも特色があり、(大きな違いではないけど)それぞれの意見もしっかりあって良かったです。
 コーチ陣自体が非常に良いチームな印象でした。

***********************

 (最後は駆け足気味でしたが)本当に盛り沢山で気づきもたくさんあって充実した「ScrumBC」でした。

#「AgileSamurai」の監訳者の一人である西村直人(@nawoto)さんと久しぶりにお会いして、サインももらったり、Blogなどで多くの情報発信をして「いつかお会いしたいなぁ」と思っていた吉羽龍太郎(@ryuzee)さんと初対面を果たしたり…とその点でも満足できました。

 今度は現場、チームで実践している方達同士での、どんな悩みがあって、それにどんな工夫をしているのかガッツリ、もっとディスカッションしたくなりました。

 最後になりましたが、スタッフ、コーチ、参加者の皆さん、良い時間をありがとうございました。
タグ:勉強会 agile
posted by yohhatu at 03:57 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年08月31日

[仕事]人によって違う「ゆっくり」

※この記事は新しいブログに移行しました。

移行先は【人によって違う「ゆっくり」 – サウスポーなエンジニアの独り言】です。
posted by yohhatu at 23:22 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年08月16日

[仕事]「redmine_graph_activities」を入れてみました

Redmine Graph Activitiesプラグインを公開します! http://t.co/UkgYvB9 何かおかしいところがあったら教えてください。(ド素人なので...)less than a minute ago via ついっぷる/twipple Favorite Retweet Reply


 というツイートを見て「redmine_graph_activities」を入れてみました。
#今のところ(まだソースは読んでいませんが)1.2.0と1.0.1で動いています。

***********************

 「最近4週間の活動」ビューをだけ眺めてみても、行動特性のような傾向が見えてきて面白いです。

 「朝型/夜型」「こまめなコミット派/(良くないですが)一括コミット派」「キッチリTiDD派/ゆるゆる派」のようみたいな感じが見えたので少し書いてみます。

 私は出社時間が早いので、チケット更新、コミットとも午前中の7時〜11時台に集中しています。
 そして14時頃を境に疲れてくるのか、特にコミットの回数が減っていく傾向にあります。

 プロダクトのメイン開発者であるAさんは、コミット回数はどの時間帯も安定しています。
 また、チケットの更新は一気にする性格らしく、夕方くらい…16〜17時頃に一気に更新しています。
 一方、出社時間直後(=前日のコミット忘れ?)と夜遅めのコミットが多いのが心配だったりします。

 Bさんは満遍なくコミット、チケット更新ともしていて、しかも19時以降にほとんどなく、(少なくともこの4週間は)残業をほぼせずに進んでいることが分かります。
 素晴らしいです。

 チームで一番の若手(1年目)のCさんはチケット更新とコミット数がほぼ一致しています。
 (詳細にチケットを見て分かったのですが)TiDDをビシッとやっていて、良い感じです。

 Dさんは(メインの)チケットの粒度がかなり細かく割っていた(そういう類のタスクでした)ので、1回のコミットで複数チケットを片付けているようなグラフでした。
#本来、1回コミットでは、できるだけ1つのチケットを対象にした方が修正箇所が明確で分かりやすいので。

 マイペースなキャラが印象的なEさんは午前中はチケットの更新が多くコミットはほとんどなく、午後にコミットが多くなっています。
 どうやら午前中は仕事の段取りをして、午後から一気に着手…という感じのようです。

***********************

 これを「コミット数が少ないからダメじゃないか!」などというアンチパターンに使うのでなく、お互いのクセや傾向を知ることで、チーム力が上がったりするかなぁと思っています。
#まだアイデアレベルなので試してみて、また報告してみようかと思います。

 最後になりましたが、作者のM/e(@me_umacha)さんありがとうございました。
ブログ:Redmine Graph Activitiesプラグインのご紹介(TitleNotFoundException)
タグ:redmine
posted by yohhatu at 20:28 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年08月06日

[仕事]仕様凍結のつぶやきのその後

※この記事は新しいブログに移行しました。

移行先は【仕様凍結のつぶやきのその後 – サウスポーなエンジニアの独り言】です。
posted by yohhatu at 23:02 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

[雑多]「Scrum入門」(SEA関西プロセス分科会)に行ってきました

 大阪ではあまり開催されていない「Scrum」の勉強会がある…とのことで行ってきました。
ソフトウェア技術者協会(SEA)関西支部 プロセス分科会

#ちなみに、この勉強会、(自分の)TLでほとんど流れておらず、ATNDなどでの募集でも無かったので、申し込んだものの直前になるまで「本当にあるんだろうか?」と思っていました。

 自分が参加している今のチームは、(「Scrum」とあまり口にしていませんが)Scrumな開発に割となっています。
 ですので、自分の知識や考え方、動きの再確認などができれば良いなぁと期待して行ってきました。

***********************

■講師と参加者
 原田さん(@haradakiro)さん、アシスタント(?)が@e_yamaneさんでした。

 参加者は20名程度でほとんどが私服でした。
 (自分が似たような勉強会に出てせいもありますが)数人知っている方もいました。
#ノートPC率は低かったです…というかワーク中心だからみんな持っていたけど出さなかった感じかも。

■アイスブレイク
 お互い…特に講師が参加者のことを…知ろうということで「Scrum(を含めたAgile開発)をどれくらいやっているか?」「コードを書いているか?」などの質問のやり取りからスタートでした。

 よくある「挙手」ではなく、会場の両端をそれぞれ「よくやっている」「未経験」などに見立てて、どこに立つか…というやり方でやりました。
#ある程度シーンを選びますが、体を動かすという点では良いなぁと思いました。

 「コードを書いているか?」で、ほとんどYes側にいなかったのがちょっと意外でした。

■最初
 まずはScrumが出来上がった歴史的経緯、同じAgile開発の1つであるXPとの関係性などのお話がありました。

 それから、この勉強会の「Working Agreements(作業合意)」を決めました。
 「○○時に撤収も含めて完了する」「休憩は○○時に10分取る」というようなものです。

 実際のPJなら「デイリーミーティング(朝会)は9時15分にカンバンの前で行う」などの働き方に対するチームの合意のようなものと感じました。
 (チームが成熟しない、慣れないうちは)これをいつでも見える場所にあるのが大事だとも思いました。

 チームが良くない時はこの「Working Agreements」が無かったよなぁと思い返していました。
#例えば、朝会の時間がいつもバラバラだったり、ある時/ない時があったり…。

■ワークショップ:マルチタスクの大変さ
 「マルチタスクの大変さ」を実感するというものでした。

 「2の倍数」「3の倍数」をそれぞれ別々の紙に1分間で書き出していきます。
 1回目はそれぞれ交互に…Aの紙に2、Bの紙に3、またAの紙に4と書く…書いていきます。
 2回目は30秒毎に…Aの紙、Bの紙…書いていきます。

 結果は(個人差はありますが)1.5〜2倍で2回目の方が多く書けていました。

 実際のPJでは1回目のような効率の悪いマルチタスクな状況によくなっています。

 「(実際のPJではマルチタスクになりがちだが)これをいかにマルチタスクにならずにシングルタスクを維持しているか?(いけるか?)」というディスカッションを個人/チームの視点でもう少ししてみたいと思いました。
#これはそのうちブログに書こうかなと思います。

 そのマルチタスクつながりで、「コンポーネントチーム」でなく「フューチャーチーム」にしていけば良いかも…という話をしていました。

 コンポーネント…画面、ロジック、DBなどの階層…でアサインせず、会議室登録機能…ここには画面、ロジック、DB、ドキュメント…1つの機能を作り上げる全てが含まれる…などの「機能」単位でアサインするというものです。

 「多能工」(さらにその中で自分の得意な分野、層があると尚良し)が多い、またチームがそれを目指すのであれば出来る…と感じました。
#今のチームはこれに近い形まで行っていると思います。

 いくつか聞いた話では、なかなかこれは難しく「壁越しに設計書やコードを投げあっている」状況のような所もあるようです。

■その他のお話
 そのワークショップの後は「Doneの定義」「Velocity」「優先順」のお話を少しずつ。
 特に「Doneの定義」の計算ドリルの例が分かりやすくて良かったです。

 宿題「計算ドリル」における子供の「Doneの定義」は(早く遊びに行きたいので)「計算ドリルに答えを書き込んだこと」になる。
 でも親のそれは「答え合わせをして、間違えた箇所をもう1度やる(できれば、『なぜ』を理解して)」となる。

 この「Doneの定義」の合意ができていないと「こんなはずじゃなかった」が後になって発生するというわけです。
 これは仕事でも上司と部下、PM-PL-メンバー、発注者と受注者でよく起きていることだと思います。

■ワークショップ:見積り
 メインのワークショップです。
#事前に参加者から「今日聞きたいことはなんでしょう?」と聞いていた中から選びました。

 不確実性のコーン※のお話の後、「会議室予約システム」を題材にプランニングポーカーを使って見積もってみましょうという内容でした。
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」にこの話は出ています。

#私達のグループは5人で、うち3人がプランニングポーカー未経験だったで、その方々のワクワク感が伝わってきてきました(ワークショップ本来の目的とは違いますが)。

 いざ、やってみるとそれぞれ違う数字…見積もり…が出てきます。

A:「この数字の根拠はどんな感じですか?」
B:「○○という仕様、機能もいるだろうと思って…」
C:「(少ない数字を出した人が)あ、それは私いらないて思っていました」
D:「プロダクトオーナーに聞いてみないと分からないですねぇ。確認事項ですね」

 …という様な会話がたくさん出てきて、見積もり行為そのものよりも、それ以上に「チーム内の仕様の共有」や「足りない機能/不確定な仕様を洗い出し」という側面が強いと思いました。

 これを実際に導入するキモはプロダクトオーナーが側にいる…何か疑問があったらすぐに聞けるような状況になっている…のがその1つかと思いました。

 このワークショップの途中で時間が来てWorking Agreementsの通りに終了しました。

***********************


 懇親会でも(料理そっちのけで)色々な方とお話しましたが、「優秀/成功しているチームへのやっかみはある。またそういうチームだからこそ人貸しを要求されたりする。その場合に…」というような話題などは興味深かったです。

 後、Twitterでのやり取りはあったけど、実際に面識の無かった方とも会えたり、@kuranukiさんと共著で本を書いた方とお話したりもしてなかなか面白かったです。

タグ:勉強会 SCRUM
posted by yohhatu at 01:11 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2011年06月22日

[仕事]社内研修で思うこと

※この記事は新しいブログに移行しました。

移行先は【社内研修で思うこと – サウスポーなエンジニアの独り言】です。
タグ:考察 研修
posted by yohhatu at 16:26 | Comment(1) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。