Ryuzee.com

Scrumやアジャイルな開発プロセスをコントロールできるツールは、AgiloやTeamTrickやExcel含めて色々試してみたんだけど、AgiloはPython＋Trac、TeamTrickはRubyなので簡単にレンタルサーバでは動かないし、Excelはファイルサーバでみんなで突っつくなんてそんな怖いこと出来ないし、ということで、なかなか立ち上げが容易で、完全に満足できるようなものが無いというのが実情。
だったら自分で作ってしまえ、ということで、現在PHP＋MySQL(PostgreSqlでもSQLiteでも動作するはず)で動作するオープンソースのScrum管理ツールを作っている。

以下がそのスクリーンショット。
基本的な機能はTeamTrickの移植で、CakePHPで作ったらあっという間にある程度まで出来た。

しばらく開発を進めて、気が向いたら公開する（かも）

先日のAgile Day2以降に聞かれることが多いので、参考になる資料をまとめておく。合計10分ちょいあれば概要は理解できると思う。

マイク・コーン氏のScrum紹介資料の邦訳(拙訳)。CCライセンス。パワーポイント版

Scrumの概要を５分ちょいでまとめた動画。(英語だけど分かると思う)

Scrumマスターとは（誤解注意ｗ）

3/19に新宿のマイクロソフトさんで行われたAgile Day2で、1セッション50分頂き、アジャイルな開発プロセスを導入する前に考えてほしい点についてお話してきました。
以下にスライドの資料を公開します。
質問等があれば、コメントかTwitter等でご連絡ください。

#　追記。PDFもダウンロードできるようにしました。

How To Be An Agile Leaderより抜粋してまとめ。

• リーダーは強いビジョンを持つ必要がある
• リーダーはビジョンの中に揺らぎない信念を持ち、チームを前に進め、困難に打ち勝つために約束・決定することが必要
• リーダーはヴィジョンの素晴らしさを共有するために、十分なエネルギーと熱意を注ぐべきだ
• リーダーは他人が追求するのに価値があると確信するように、ビジョンを明確化することができる必要がある。
• リーダーは人の話を聞いて対応できる必要がある
• リーダーは問題解決能力を持っている必要がある
• リーダーは多くの邪魔が入ってもゴールの達成に集中する必要がある
• リーダーは決定を下すことができる必要がある
• リーダーは周りに教えることを厭わない、よいコーチである必要がある
• 信頼と正直であることは何にもおいて重要で、リーダーは信頼に足る必要がある
• リーダーはアジャイルの原則を理解しておく必要がある
• リーダーはアジャイルのプラクティスを十分に積んで、色々な状況に対応できるように幅広いシナリオを持っている必要がある

まぁ別にアジャイルなチームに限らない。
周りの人がチームについてくるかどうかは、チームもしくはリーダーについていくだけの価値があるかという軸で判断されるということ。

自分にプレッシャーをかけるために予告してみる（ｗ

3/19にマイクロソフトさんで、Agile Day2というイベントが開催されます。前回1月にマイクロソフトさんの日本法人としては初のAgile関連セミナーであるAgile Dayが開催されましたが、今回はその第2回目のイベントになります。
僕は第１回はLTでしゃべりましたが、今回は１セッションいただいて、「Agileな開発プロセスを導入する前に考えなければならないこと」(仮)というテーマでお話する予定です。
内容は、若干バズワード化しつつある「Agile」の導入について、導入を考えている、なんとなく興味がある、という人たちに、事前に考えるべきポイントの概要をお伝えすることです。答えは現場や環境によって様々だと思うので、あくまで考える軸を提供したいなーと思っています。

このイベントでは、その他に、マイクロソフト長沢さんによるマイクロソフトでのアジャイルへの取り組み、IBMのエバンジェリスト玉川さんによる大規模アジャイルの話、すくすくスクラムの今村さんによるScrumを体験してみるワークショップが実施される予定です。申し込みはマイクロソフトさんのサイトから。

以下ちらみせ興行（作成中ですので実際には出てこないかもしれませんｗ）

よし、プレッシャーかかってきたｗ

先日のオープンソースカンファレンスなどでも紹介しているAgiloについて、現在i18n対応を実施中。もうソースの修正は終わっていて鋭意テスト中です。

もともとの経緯は、
・日本語化対応した際に、Agiloを作っているドイツのAgile42社に、日本語版作ったよー、ってメールしたら
・じゃあ国際化担当よろぴこ、って言われたｗ
・別のユーザーさんから俺スペイン語対応するから、早めに頼むわ、って言われたｗ
って感じ。

現在Shibuya.tracで公開しているバージョンは、Tracが持つtranslation機構を使いつつ、他の言語を使うことは想定しないでカスタマイズしていたので、現在は、どんな言語でも簡単に対応できるように、日本語化部分の整理や言語処理の分岐などを追加中。これが終われば現在Shibuya.tracのSourceforgeにアップしている日本語オリジナル版の役割は終了する予定。

なお、現在本家で公開されているAgiloの最新のバージョンではバックログ画面のUIが新たに１つ追加になっている。新たな画面ではAjaxを使ってサーバサイドからJSONのデータを取得して画面に描画するようになっており、将来的にはFlashを使ったUIなどを考えているのではないかと思われます。

また、まだ紹介していなかったけど、Agiloでは各種バックログの一覧画面から直接項目が編集できます。スプリント計画ミーティングの際の、対象ストーリーの選択や見積もり、残作業時間の更新に非常に便利。

一覧画面での一括編集は、管理画面のバックログ項目を選択して行うことができる。下記の画面で、編集可能にチェックがついているものは一覧画面で編集できるし、また一覧に表示する項目も自由に設定可能。

ということでもう少々お待ちください。

78 Things I Have Learned in 6 Years of Agile Coachingの78個を適当翻訳。

「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられている。

1. アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2　(訳注：ちょっと意味わからん)
2. 分散したチームでは各サイトごとに愛とスクラムマスターが必要だ
3. フットボールテーブルはあなたの最良のアジャイルなツールのうちの1つかもしれない
4. 地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だ
5. ローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。
6. プロダクトオーナーを持つことは譲れない
7. 積み荷崇拝スクラムを回避しなさい！
8. アジャイルチームには楽しさが必要だ
9. 最高のアジャイルチームと企業ができるかどうかは奉仕するリーダー次第だ
10. 本当にアジャイルな文化を持つことは、チームが独力で作ることができる以上のことだ
11. アジャイルな開発は、あなたが喜んで時間と費用を費やす場合のみ、費用の削減につなげることができる
12. アジャイルの醸成と拡大のための素晴らしいアプローチはリーンの「Flow Pull innovate guidance」だ
13. バーンダウンチャートはチームの完了へのコミットメントに関係しており、個人のパフォーマンスやタイムトラッキングに関係しているわけではない
14. あなたのスプリントバックログが製品価値の提供を反映していることを保証しよう
15. エスカレーションは継続的なプラクティスの改善においては、アジャイルでもリーンでも役に立たない
16. 成功のためには、あなたの上司から必要以上の小切手帳をもらってくる必要がある
17. 他のチームに拡大を試みる前に、あなたのアジャイルチームのプラクティスを醸成しなさい
18. スタンドアップミーティングの明確な終わりの印を持たないことは、問題の発生につながりやすい
19. Flowのリーンの原則は、アジャイルチームが彼らのプラクティスをしっかりさせるためのガイドをする
20. リリースのビジョンについて本当にコミットしたいなら、リリース計画ミーティングに全員同席させよう
21. コマンドコントロールのスクラムマスターはチームの知力を減らしてしまう
22. 同じ場所にいるチームは、分散しているチームに比べて、より簡単により早く、高いパフォーマンス、高い信頼を得られるようになる
23. 開発場所への訪問、IM、Skype、Facebook,Yammer、ビデオ会議、その他の技術を使った頻繁なコミュニケーションは分散チームが仲良くし、愛を感じることを助ける
24. アジャイルチームでは、チームが素晴らしくなり永続するために、健全な摩擦が起こる
25. ベロシティはチームのもので個人のものではない
26. 「かんばん」はチームが継続的に価値を流してることを測定する新しい指標となっているので、注意を払わなければならない
27. プロダクトオーナー不在もしくは多すぎるプロダクトオーナーは、アジャイル風になってしまう：優先順位や受け入れに際して定義可能な意思決定がない
28. プロダクト会議はステークホルダーを管理したり、バックログがひっかきまわされるのを最小化する効果的な方法だ
29. ストーリーポイントはチームがカレンダー時間やチームメンバー数とストーリーの複雑度、努力、疑問を分離するのを助ける
30. ストーリーはお互いに相対的なサイズを持っている。タスクだけが努力見積もりを持っている
31. うまく書かれたストーリー（小さくて、役割に対する利点について書かれている）は嘘をつかない。要求は、内容がおおざっぱであるため、嘘をつくことがある
32. プロダクトバックログは常に優先順位付けする
33. プロダクトバックログはタスクリストではない。タスクはチームによる見積もりと計画が終わって初めて登場する
34. アジャイルは、従業員のQOLを向上させる
35. 素晴らしいチームは協力的なメンバーから成り立っている
36. アジャイルは放置されてしまうメッセージは作らない
37. ペアプログラミングはチームの気づきとコードの完全性を向上させる
38. チームの完全なコミットメントを取る際は、同意をとるようにし、強制的な約束やコマンドコントロールはしない
39. 効果的なチームミーティングには仕組みと訓練が必要だ
40. アジャイルの価値と原則についてコミットしよう。あなたのプラクティスはそれに従うことになる
41. 透明性はアジャイルの長所であり、懲罰のためではない。
42. アジャイルとはコミットメントに関することであり、ツールに関することではない。ツールはチームのコミットメントとそれらの可視化をサポートする
43. 孤立状態で決定を下すプロダクトオーナーはアジャイルではない
44. アジャイルチームはストレス満載な場合でも敬意と思いやりを発揮する
45. 振り返りをしないチームはアジャイルではない
46. 振り返りは非難することではない
47. 振り返りはプロセスとワーキングアグリーメントの継続的な改善をもたらす
48. もしチームのワーキングアグリーメントがないのであれば、すぐ作ろう
49. もしワーキングアグリーメントを壁に掲示してないなら、すぐ掲示しよう
50. ベロシティを知るまでは、あなたが使うキャパシティは積極的におさえるようにしなさい
51. アジャイルな経験をブログに投稿しなさい。あなたが思うより多くの人があなたの経験を聞きたがっています
52. テスト駆動開発は単によいコードを作るだけではない。よりうまく受け入れてもらうためのより良い会話の場を作ります
53. アジャイルアーキテクトとプロダクトオーナーはプロダクトバックログの順位付けのために、一緒に作業する
54. アジャイルチームにはリリーススケジュールのリズムに組み込んだ形で「hackathon」のようなブレイクを与えよう
55. キャパシティの利用状況が高いのは悪いことだ
56. 品質はみんなの責任だ
57. 素早く小さいインクリメントをすることは我々の作業について情報を与え、より早くフィーチャーのセットを生みだす
58. リーンは私のアジャイルランゲージに大きなインパクトをもたらした
59. 「一番の人を雇用する」という言葉はアジャイルにおいては陳腐だ
60. 賢く雇用し、安く雇用しない
61. 新たなメンバーを雇用する時は、チームの同意が必須だ
62. 5段階の計画を利用しよう。ビジョン、製品ロードマップ、リリース計画、イテレーション計画、そして日次計画だ。
63. リリース計画は私のお気に入りのアクティビティのひとつだ
64. チームと利害関係者は次のイテレーションを見通すためにリリースプランニングに出席する
65. FYI、よいブレインストーミングは大量のポストイットとノートと賢い人たちが必要だ
66. ファシリテーションスキルに注意を払え。あなたは意思決定を乗っ取ってはいけないし、他人にそうさせてもいけない
67. アジャイルミーティングを集中した、目的に沿った、タイムボックス化された状態に保ちなさい
68. アジャイルミーティングにおいては電子機器はOFFにしておこう。集中したミーティングは生産的で、時間通りに終わる。
69. アジャイルにおける最大のコストカットレバーは「優先順位付け」だ。
70. 新しいプラクティスを試すことを恐れるな。あなたのベロシティと品質は新しいプラクティスを導入したあなたに感謝することになるかもしれない。
71. アジャイルはソフトウェア以外にも有効だ。組織の内外で活用しよう
72. 古いツールは新しいトリックへの対応に立ちはだかっている。MS Projectはアジャイルへ進む道ではない。
73. チームのアイデンティティは重要だ。個人のヒーロー性は危険だ
74. 振り返りにおける個人の感謝は、アジャイルチームの信頼を成長させる場を作るすばらしい方法だ
75. アジャイルへの成熟度は、CMMIのような成熟度モデルではない
76. アジャイルとウォーターフォールの論争は終わった。価値あるものを提供し続けることに注力しなさい
77. アジャイルはスピードをあげるために、スピードを落とすよう我々に要求する。
78. 私はアジャイルが大好きだ

 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有