Ryuzee.com

10/30のOSC2009で発表したTraMの資料をアップしておきます。

Switching stories mid sprint
http://agilesoftwaredevelopment.com/blog/jackmilunsky/switching-stories-mid-sprint
を参照して、適当に抜粋。

・ストーリーの入れ替え要求に従わないことはプロダクトオーナーの軽視っていう意見もあるが、それは違う。
・ストーリーの入れ替えを受け入れ続けると、開発チームは混沌として、何もモノが出来あがらない。
・開発チームは、「なんでこんなに突然にストーリーの入れ替えをするのか」聞いてみるべきだ。
・2週間のスプリントで、今中間地点だとすると、たった5日前には、もっと重要度の高いものは無かったはずだ。
・で、こういう時は、プロダクトオーナーを呼んで詳細を説明してもらい、スプリントのゴールに影響がないように、ストーリーを容易に入れ替えできるかどうかは開発チームで決定すると良い。

難しいテーマなんだけど、ビジネス上の優先順位は、ちょっとした状況の変化で容易に変わりうる可能性はあるよね。
それを開発チームが何も考えず際限なく受け入れ続けると、何もモノは出来なくなってしまう。これはアジャイルだろうとWFだろうと同じ。またWFのほうが、阿呆な営業やプロマネが勝手に客にコミットしてしまう可能性がある分タチが悪いが、似非スクラムマスターがスクラムを理解していない時も似たようなもんかなー。

で、スプリント中にストーリーの入れ替えの依頼が来た場合は、「なんでそのストーリーはスプリント開始前は優先順位が低かったのに、急に高くなったのか？」を確認したうえで、「スクラムチーム自身が入れ替え可能かを判断する」というのが基本になる。
まぁ、日本の現場でやろうとしたら、ほとんどの現場は、アジャイルでやっている、といっても押し切られてしまうことが多いかもしれないんだけど、それは契約スタイルと顧客との信頼関係の問題にいきつくんだろう。

How Agile Are You? (Take This 42 Point Test)にて取り上げられているチームがAileかどうかをセルフアセスメントする42の質問を適当日本語意訳(かなり)してみた。
＃ちなみにチームが「Agile」か？というより、チームが「Scrum」か？といった方が良いと思われるので、その点留意すべきと思われますね。

1. チームに決定権限が与えられている
2. チームは、自己組織化されていて、目標を設定して達成することを管理(者)任せにしない
3. チームは成果物の提供に対してコミットし、責任を持つ。そしてチームがゴールに到達するために、あらゆるタスクに協力する
4. チームはプロダクトオーナーが誰であるかを知っている
5. それぞれのスプリント/イテレーションには明確なゴールが設定されている
6. テスターを含む全てのチームメンバーは、要件を抽出するワークショップに参加する
7. 要求事項の文書は十分にそろっている。そしてフィーチャーを実装できるレベルまで協力して詳細化する
8. テストケースが要求事項やユーザーストーリーごとに事前に用意されている
9. ビジネス上の価値によって優先順位付けされたプロダクトバックログやフィーチャーリストがある
10. プロダクトバックログに、チームによって作成された見積りが載っている
11. チームは自分たちのベロシティを知っている
12. ベロシティは各スプリント/イテレーションにどれだけのストーリーを含められるかの指標に使われる
13. スプリント/イテレーションは４週間またはそれ以下に区切られている
14. スプリントの予算はどれだけのプロダクトバックログ、フィーチャーをそのスプリント/イテレーションに含めることができるかを決定するために計算される
15. スプリント/イテレーションは、チームで合意している終了日に終了する
16. スプリントバックログ内の全てのタスクは１日以下のタスクに細分化される
17. 要求事項は、ユーザーストーリーとして記述されており、カードに書かれている
18. チームはポイントを使って見積る。そのポイントはプロダクトバックログ/フィーチャーリスト内の各項目の相対的なサイズを示している。
19. チームは、日々の進捗をトラッキングするためにバーンダウンチャートを利用する
20. ソフトウェアは各スプリント/イテレーションごとにテストされており動作する
21. チームは、スプリント/イテレーションの間、(周りから)混乱させられない
22. 変化はスプリント/イテレーションのあいだ、ずっと統合される
23. 自動化されたユニットテストが適切に実装されている
24. 自動ビルドと自動リグレッションテストがある
25. 予想よりうまくいった場合に、スプリント/イテレーションに含める追加タスクを決めている
26. プロダクトオーナーは、各スプリントに積極的に関わる
27. 全てのコードの変更は元に戻すことができ、またいつでもリリース可能である
28. テストはライフサイクルに統合されており、最初のフィーチャーのリリース時からテストをしている
29. 進捗を妨げる障害は、ホワイトボードに記録されて、ただちに解決する
30. 誰かが終わった！といったら、それは出荷可能(リリース可能)ということだ
31. チームは日々の進捗や問題を、分かりやすく見える化するためにホワイトボードを利用する
32. スプリント/イテレーションのゴールはホワイトボード上にはっきり書いてある
33. すべてのユーザーストーリーとタスクはそのスプリント/イテレーションの期間中はホワイトボード上に表示されている
34. たとえスクラムマスターが不在でもデイリースクラムは毎日同じ時間に実施しているか？
35. デイリースクラムは標準の３つのスクラムの質問(昨日何やった？今日なにやる？困っていることは？)に答えるようになっていて15分以内に終了しているか
36. スプリント/イテレーションの終了後に、製品のデモとスプリントレビューを実施している
37. テスターを含む全チームメンバーが、スプリント/イテレーションレビューに出席している
38. スプリント/イテレーションレビューにステークホルダー(顧客)が出席している
39. 各スプリント/イテレーションの終了後に振り返りを実施している
40. 各スプリントの振り返りでキーメトリクスのレビューと捕捉をしている
41. テスターを含む全チームメンバーが、スプリントの振り返り会に出席している
42. スプリントの振り返りで出たアクションが、次のスプリント/イテレーションで、前向きな影響を持っているか

原文は以下の通りだ。

1. The team is empowered to make decisions.
2. The team is self-organising and does not rely on management to set and meet its goals.
3. The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
4. The team knows who the product owner is.
5. Each sprint/iteration has a clear goal.
6. All team members, including testers, are included in requirements workshops.
7. Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
8. Test cases are written up-front with the requirements/user story.
9. There is a product backlog/feature list prioritised by business value.
10. The product backlog has estimates created by the team.
11. The team knows what their velocity is.
12. Velocity is used to gauge how many user stories should be included in each sprint/iteration.
13. Sprints/iterations are timeboxed to four weeks or less.
14. Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
15. The sprint/iteration ends on the agreed end date.
16. All tasks on the sprint backlog are broken down to a size that is less than one day.
17. Requirements are expressed as user stories and written on a card.
18. The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
19. The team generates burndown charts to track progress daily.
20. Software is tested and working at the end of each sprint/iteration.
21. The team is not disrupted during the sprint/iteration.
22. Changes are integrated throughout the sprint/iteration.
23. Automated unit testing is implemented where appropriate.
24. There is an automated build and regression test.
25. Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
26. The Product Owner is actively involved throughout each sprint.
27. All code changes are reversible and it is possible to make a release at any time.
28. Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
29. Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
30. When someone says ‘done’, they mean DONE! (ie shippable).
31. The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
32. The sprint/iteration goal(s) is clearly visible on the board.
33. All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
34. Daily scrums happen at the same time every day ? even if the scrum master isn’t present.
35. The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
36. There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
37. All team members, including testers and Product Owner, are included in the sprint/iteration review.
38. The sprint/iteration review is attended by executive stakeholders.
39. There is a sprint retrospective at the end of each sprint/iteration.
40. Key metrics are reviewed and captured during each sprint retrospective.
41. All team members, including testers, are included in the sprint retrospective meeting.
42. Actions from the sprint retrospective have a positive impact on the next sprint/iteration.

というタイトルを先に思いついたので適当に書く。

アジャイルだから仕様変更は自由だよね？

スプリント中で実装中のストーリーの変更とスプリント内で実装する機能の追加は勘弁してください。
それ以外のストーリーの追加は歓迎しますが、変更や追加を行えば行うほど費用はかかります。無制限・無費用な変更なんてあり得ない。

アジャイルだから画面から決めるんだよね？

ダウト。何を表示したいか、何をさせたいかは決めるけど、コテコテに画面遷移やUIから決める必要は無い。UIの層は一番変更かけやすいし、終わりが無い。UIがビジネス上の大きな価値を持つので無い限り、UIの細かい調整は後回しだ。

アジャイルだからウォーターフォールでやるより早く終わるよな？

そもそも「プロジェクトが終わる」の定義って何？チームの生産性、プロダクトオーナーのプロジェクトへの協力とか変数が一杯ある中で、どうやって保証するんだっけ？言えるのはWFはリスクがプロジェクトの後半に集中するが、アジャイルはリスクが一定だ、ってこと。プロジェクト完了のスケジュールは確率分布でしかない。「熊とワルツを – リスクを愉しむプロジェクト管理」を読もう。

アジャイルだから計画立てないんだよね？

むしろアジャイルの方が計画的なんだが。リスクを均等にするという考えのもと、タスクを制御可能な単位まで落とし込み、自分たちの生産性と照らし合わせながら実現可能なものを積み上げていく。計画には優先順位があり、規模も相対的に算出されている。WFで怪しいプロマネが適当にMS Projectで線を引いて、それが客まで独り歩きして、みたいなのとは大きく違う。「アジャイルな見積もりと計画づくり」を読もう。

アジャイルだからウォーターフォールでやるより安くできるよな？

デマルコのデッドラインみたいに、同じプロジェクトを複数のチームでやってみて比較してみてください。この手の比較は、ゴールが完全に一緒でない限り成り立たない。

アジャイルはテスト不要なんだろ？

人力でテスト仕様書を大量に書いてテストする、ということは無いかもしれないけど、テスト自体は自動化を中心にして毎日やってるんだよね。ただ結合テストだとか総合テストだとか、何階層もテストはしない。そもそも結合テストと総合テストの区別もよく分からん。

アジャイルだからドキュメント不要だろ？

動作するソフトウェア＞ドキュメントという価値観を言っているだけで、ドキュメント無しで良いなんて一言も言っていない。

アジャイルだから同時並行で複数の案件できるよね？

まさか！同時に複数の仕事やると、スイッチングのオーバーヘッドもあって生産性落ちるだけだし。スクラムマスターが他の仕事一杯抱えているチームは危険信号。目が届かなくなり始めたら一気に崩れる可能性あり。

アジャイルって一人で何でもやるんでしょ？一人でなんでも出来ないといけないんでしょ？

一人じゃなくてチームです。たとえ一人プロジェクトでもチーム。ゴールを目指せるチームを作れば良くて、個人の能力のバラつきや得意不得意は当然ある。技術的なレイヤーで分業して人の範囲に口を出さない、とかいう縦割りではなく、人のタスクも把握する、口を出す、助ける、一緒にやるというのは必要。

たまに朝会でるから状況教えてよ！

出席する分には構わないが黙ってろ。よくあるダメパターンは管理職がふらっとやってきて、言いたいことだけ言ったり、ダメ出しだけしていくやつ。チームの自律性に任せなさい。チームは全員でプロジェクトの成功の責任を担って行動している。

cakephpではSchema機能を使ってテーブルを作成することが出来る。
で、ついでにマスター系データもまとめて登録する方法が【CakePHP】お手軽便利なCakeSchemaに載っている。
ただ載っている方法には若干問題がある。

• そもそもcakephpでは、テーブルを使わないモデルでは$useTable=falseに設定しないといけなくて、それ以外の場合は、モデルへのアクセス時にテーブルが存在しないとエラーが発生する。
• 従って、初期データを保存するためのモデルがアソシエーションが設定されているモデルだと、関連モデルのテーブルがまだ作成されていない場合にアクセスすると、その時点でエラーになってしまう。作成する順番だけを変えれば良いケースもあるだろうけど、相互参照しているようなモデルでは無理。
• つまり、アソシエーションがある場合は先にテーブルを生成しなければならず、schema.phpのafterメソッドで、都度データを入れることはできないような気がする。(unBindModelとかしてみたけど、そもそもモデルのロードで先にエラーになるので、そもそもダメ)

ということで僕なりにアレンジしたのが以下の方法。
schema.phpのafterメソッド

肝は、全部のデータを最後のテーブルの作成完了後に作る、というだけ。
NameとかFileとか除外しているところはin_arrayで除外した方がいいけど、まぁいいか。

• 初めてのチーム
• 僕を除いては、初めてのフレームワーク
• 僕を除いては、初めてのアジャイル
• 一部メンバーは初めての言語

という条件下のもとでプロジェクトを進めている。（こえー。）

実測6日間の第1スプリントでの完了ストーリーポイントは9ポイントなので、チーム全体で一日1.5ストーリーポイントだった。
今回のスプリントでは僕はほとんどコードを書いていない(※1)が、これは僕自身を除いたチームのベロシティを把握したかったからで、意図的にそうしてみた。(ちなみに自分のベロシティは把握している)
チームの中で、経験者が限られている場合、ベロシティは、その経験者のベロシティの合計値と近似してしまい、チーム単位での生産量が見えにくくなってしまうし、経験者に頼り切ってしまう構図になりやすい。
初期の段階こそ、目先の作業ではなくチームに投資しておいた方が良いと思う。

第2スプリントのスプリントバックログも控えめな量にしておいたが、うまくいって「おかわり」してくれるといいなー。
この第2スプリントが終了すると、本番デプロイ希望日に、希望しているだけのフィーチャーを用意できるかできないかの目途がほぼ分かるだろう。
そしてその時点でデプロイする対象を減らすか、スケジュールを伸ばすかと顧客と交渉することになる。

逆に言うと、初めての言語、初めてのチームで、決まった量のモノを決まった期日までに作る約束するなんて無謀極まりない、ということになる。意外とそのことを分かっていない人が多い。

※1.もちろんコードレビューは毎日やっているので、僕の思想は反映されているのだけどね

今の案件では、僕の下にいる二人はcakephp初めて、ということもあり、コードレビューを頻繁に行っているんだけど、いちいちメールでレビューコメント書くのも面倒だし、レビューをお願いする方も面倒だろう、ということで、PeerReviewPluginを入れてみた。ReviewBoardやCodeStrikerも良いが、同じプラットフォーム上で出来るってのは利点なんだよね。

PeerReviewPluginのイメージはこんな感じ。

ところが、レポジトリからレビュー対象のソースを指定する箇所のリンク先URLがおかしくて、ずっと動かない。ググっても分からない。

仕方なくｔｗｉｔｔｅｒ上で聞いてみたところ、TraMのバグであることが判明してしまった。

前置きが長いけど10/9コミットのTraMで以下の問題を修正しています。

PeerReviewプラグイン等一部のプラグインにおいて、TraM経由で利用すると、リンク切れ等の事象が発生する。旧バージョンのTraMで解決するには、trac.iniでbase_urlを指定する必要がある。

お手数ですが利用者の方で特定のプラグインが動作しないような問題があった方は更新をお願いします。

Agile101より引用してかなり適当に意訳。

ウォーターフォール

• プロジェクトの終了直前のデプロイまで、何の価値も実現できない
• テストを最後に残しているため、最後の最後まで問題の発見が遅れる
• 要求事項が変化しているかもしれないのに、ステークホルダーへの提案をしない
• 計画に大きく依存しているため、(計画に失敗していると)プロジェクトの失敗に結び付きやすい
• プロジェクトマネージャの力量に依存している

フェーズ分割型ウォーターフォール

• 従来型WFに比べればリスクは少ない
• よくある問題はボトルネックの発生。
• 若干の工程の遅れをテスト工程まで引きづり、結果として最後に想像以上に解決の時間を要することになり、結果プロジェクトの終了時期を守れない
• 見積もりは難しいのでオーバーコミットメント(過剰な約束)する可能性がある
• フェーズでの見積もりは他のフェーズの見積もりと独立して行われるが、各フェーズは密接に絡み合っている
• プロジェクトの危険サインはフェーズの終了間際にならないと分からない

Scrum

• 独立した価値ある小さな機能ごとに完全にテストされたものをリリースする
• それによってもし機能が誤っていても、他の機能へのインパクトを極小化することができる

リーン

• 次の機能の選択や開発を行う前に、前の機能の選択、開発、テスト、デプロイを全て完了させる
• それによって機能レベルでのリスクが、他の機能に関連しないよう独立させる
• 「無駄を省く」という基本思想のもと、必要になるまでは何もしない

個人的にはScrumとリーンの境界線がよく分からんという気がするかも。

元ネタはRecommended Agile Project Management Software(英語サイト)から。
オンラインアンケートでプロジェクト管理ツールのどれを推奨するか集計したもの。

■Rally

http://www.rallydev.com/で提供しているSaaS形式のScrum支援プラットフォーム。少人数向けの無償トライアルあり

■VersionOne

http://www.versionone.com/で提供しているSaaS形式のScrum支援プラットフォーム。少人数向けの無償トライアルあり

■Mingle

あの有名なThoughtWorksが提供するインストール型のScrum支援ツール。JRubyで出来ているとか。

■tinyPM

http://www.tinypm.com/で提供されているサーバインストール型のツール。オープンソースのコミュニティエディションと有償エディションがあるようだ。機能紹介はこちら

■Agilo

Agile42が提供するTracプラグイン。PROと呼ばれる有償エディションとオープンソースエディションが存在する。

■JIRA Greenhopper

JIRAのプラグインとして提供されるツール。プランニングボードとか見るとかっこいい。詳細はこちら

■Microsoft Team Foundation Server

こちらを参照。Scrum専用というよりはVSS系開発専用な気がするがどうなんだろうか

■Pivotal Tracker

詳細はこちら。Webサービスとして無償で提供されており、アカウントを作成してプロジェクトを開始すると、ストーリーベースのイテレーションプランニングやベロシティ測定なんかが出来る。日本語で使っている人もいた。

■ScrumDesk

詳細はこちらを参照。Webアプリ型のツールで、SaaS型、パッケージ型のどちらの形態もある。５ユーザーまでなら無償で利用できるようだ。

いくつかはもうちょっと深堀して紹介したいと思う。

現在配布されているAgilo0.8.3は、スプリントを追加する際に、日付の形式エラーになってしまう問題がある。

ソースを修正して解決したので、修正内容を記録として残しておく。

対象のソース　agilo/utils/days_time.py

ソースを修正する必要があるので、入手の際はPROモジュールを含んだバイナリではなく、ソースコードを入手して自分でコンパイルしてインストールする必要がある。

« 前の記事 

日記 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 情報共有