プラクティス: ポリシー(方針)の階層 #nNote

プラクティス (practice)

実践。

「価値観(Values)」に由来する「原則(Principles)」を支持し実現化するやり方(Practices)。

2013年11月6日 (水)

今日のさえずり: Dropbox を Cloud Folder としていったん保存して、 iFiles で Google ドライブにコピーするという方法

2013年11月06日

08:01 あ、Flickr Pro のサブスクリプション分取ったよってメールが届いてた。Pro 続けるかちょっと迷っていてまあ続けてもいいかなと思っていたぐらいのやつ。
08:17 “ビールでご飯を炊いてみた。その味は…: 地ビール会社で働く広報の日記” http://bit.ly/HIe8bL
08:17 「CPANに上げるモジュールの場合」 / “CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々” http://bit.ly/HyvDMc
08:29 Google+ カスタム URL 設定した。名姓で妥協した。
13:00 I'm at お弁当の大臣 http://4sq.com/1bapb5o
14:13 “サーバサイドからクライアントサイドのJavaScriptを呼び出す際のベストプラクティス - kazuhoのメモ置き場” http://bit.ly/17Lzuzq
20:47 iThoughts/iThoughtsHD で書いたマインドマップの PNG ファイルを Google ドライブに上げるの、Dropbox を Cloud Folder としていったん保存して、 iFiles で Google ドライブにコピーするという方法に到達した。

[ permalink ]

[ 11月6日全て ]

2014年7月9日 (水)

ざっくりわかるアジャイル開発勉強会

スクラムおじさんの、はらかち氏によるアジャイルソフトウェア開発についての勉強会「アジャイル開発勉強会」。マスター・センセイよろしくお願いします。

価値・原則・プラクティスが大切、原則があってプラクティスを実行して価値が生まれると。アジャイルサムライでこの原則を学びましょうということで、アジャイルサムライ第1章「ざっくりわかるアジャイル開発」を輪読。音読で順番に読むのかなり久しぶりだけれど、復習にいいかも。

アジャイルサムライ

気付き

計画は変えていくけれど、立てないわけじゃない(はらかち氏)。

「アジャイル開発の原則: 『顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。』 p.8」はユーザーサポートでも「顧客満足を最優先し、価値のある回答を早く継続的に提供します。」と言い換えて原則とすべきだなーと。

スライド (はらかち氏)

20140709 アジャイル開発勉強会 from Katsunobu Harada

http://www.slideshare.net/harakachi/20140709-36813334

[ permalink ]

[ 7月9日全て ]

2014年7月24日 (木)

今日のさえずり: コードレビューよりもペアプログラミングした方が的確に伝わる気がしてきた

2014年07月24日

00:46 「『メルカリはカスタマーサポートがすごい』というイメージが定着する状態まで持っていけるように努力をしています。」 / “メルカリの米国展開はどうなるか、国内フリマアプリ市場のこれからは--山田氏に聞く - (page 2) ...” http://bit.ly/1qA4iy2
06:55 ラジオ体操今日も。
18:42 今日もザザッとくるのか……。
18:47 「雨男じん」が外で出ていった。しばらくもうダメだ。
21:25 コードレビュー繰り返すよりもペアプログラミングした方が早くかつ意図が的確に伝わる気がしてきた(ただし相手が Emacs 使いに限る)。
23:33 とりあえずリーダブルコードの「2章名前に情報を詰め込む」と「3章誤解されない名前」を20回ぐらい読むとキラキラネームが減ると思う。
23:46 「県警音楽隊は演奏しながら、インターネットトラブルに巻き込まれないように呼び掛けた。」 / “サイバー犯罪防止でセミナー | 宇部日報社　このまちメディアWeb” http://bit.ly/1nwcT17
24:57 “Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々” http://bit.ly/1uj3D5L

[ permalink ]

[ 7月24日全て ]

2015年5月13日 (水)

レクサー・リサーチ開発同窓会

rimage:/nDiki/Flickr/17034996273.jpg

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグスダイニング神楽坂)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

http://www.cogsdining.com/

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

プロジェクト
- ソフトウェアかんばん
- ITS (影舞・Redmine) の利用
  - BTS やコミットメント・リストとして。
- スタンドアップでの朝会
- すごい会議
- 成果物完成毎の記念撮影
情報共有
- 社内 Wiki
  - 2002年3月初設置。
- 社内 Blog
  - 2006年あたり(記事)
開発ツール
- バージョン管理 (CVS・Subversion・Git)
- pLaTeX2e を使ったドキュメンテーション
その他
- 書けなくなったホワイトボードマーカーはその場で床に投げ捨て

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

[ permalink ]

[ 5月13日全て ]

2015年8月28日 (金)

今日のさえずり: 「なんで吉野家なのに2階あんの? なにこの都会。」

2015年08月28日

07:46 LED シーリングライト注文。
09:17 電車が駅に近づいてスピードを落としたところで、車掌さんが「○○駅です。どうぞ良い一日をお過ごしください。」とアナウンス放送したので、今日は良い一日にします。
09:36 「これ自体が山手通りなんじゃないのー?」(違います)
11:10 “情報処理学会デジタルプラクティス - 進化し続けるコールセンタへの道：ITpro” http://nkbp.jp/1ImOroW
11:10 “情報処理学会デジタルプラクティス - コンタクトセンタ運用効率化の取り組み：ITpro” http://nkbp.jp/1NDv6YI
14:22 「なんで吉野家なのに2階あんの? なにこの都会。」

[ permalink ]

[ 8月28日全て ]

2017年2月7日 (火)

第14回エッセンシャルスクラムを読む会

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の14回目。今日は第14章スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

事前にきちんと計画を作れると思うな
計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]

[ 2月7日全て ]

2017年3月14日 (火)

第19回エッセンシャルスクラムを読む会

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の19回目。今日は第19章スプリントプランニング。ここから「第IV部スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]

[ 3月14日全て ]

2017年4月14日 (金)

第23回エッセンシャルスクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャルスクラム」を読みたい人が集まる勉強会の23回目。第23章未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャルスクラム」と「エッセンシャルスクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャルスクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

エッセンシャルスクラムを読む会のふりかえり

エッセンシャルスクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては