プロキシ環境でのClickOnce

ClickOnce

今回、お客様の端末がWindows7になってClickOnceでのインストール、バージョンアップができない(起動もできない)という現象が発生。
プロキシ認証環境での不具合に関してはWebに情報がいくつか出ているが、今回の現象は特にプロキシ認証に起因してはいないようだ。


ClickOnceは主にイントラ内使用を想定しているんだろうか。
インターネット経由の配布を想定しているのであればプロキシは当たり前のように使われているはず。
プロキシの設定(直指定、スクリプト指定、自動検出)によってデフォルトの状態で動作しないのであれば導入されないと思うんだけど。。。
うまく情報を探せない自分の問題もあるのだが、MSはもう少しこのへん整理した情報を出してほしいところ。
(まあインターネット経由で社内で使用するアプリを配布するのが特殊といえばそうかもしれないけど)


当初想定としては、.net frameworkに対して、IE設定を使用するような指定をすれば動くだろう、という位の認識でいたのだが、なかなか大変な作業となった。
割りとはまったので以下メモ。


お客様環境は、ブラウザのプロキシ設定で「自動構成スクリプトを使用する」が選択され、スクリプトのURLが設定されている状況。
デフォルトでは.net環境では、ブラウザのプロキシ設定が使用される*1ということだが、上記環境では設定されない事が判明。
とりあえず、自動構成スクリプトをみて、取得されるであろうプロキシサーバを明示的に指定してバージョンアップを行うよう対応し、暫定版として通常のインストーラで入れてもらうことで凌ぐことに。


その後、自動構成スクリプトから動的にプロキシを取得するよう対応すれば、ClickOnceでいけるだろうと踏んで対応を開始。

  • .ブラウザのプロキシ設定が自動構成スクリプト指定の場合、動的にプロキシサーバを取得できない。

　→http://www.codeproject.com/Articles/12168/Using-PAC-files-proxy
　　ここのコードを参考にして、プロキシ設定情報を取得し、デフォルトプロキシサーバを指定。
　　プロキシ設定スクリプトのURLはレジストリ(Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL)から取得。
　　(結果としてデフォルトプロキシ設定はClickOnceには関係なかったが、アプリ側でHTTP通信する際のProxy設定として必要な対応だったようだ。)
　　

  • .ClickOnceでのインストール時、WebRequest.DefaultWebProxyで指定したプロキシ設定が利用されない

　→http://msdn.microsoft.com/ja-jp/library/system.deployment.application.inplacehostingmanager.aspx
　ここを参考に、InPlaceHostingManagerを使用してインストールするためのプロジェクトを作成し、インストーラとする。(ただし、インストールしたアプリを起動はできないので、インストール後スタートメニューから起動してもらう)
　その際、Installer、SetUpなどを含む名前だとインストーラとみなされて、プログラム互換性アシスタントに、正しくインストール出来なかった可能性があるとか言われてしまうため、避ける。
　バージョンアップの時は、デフォルトプロキシを設定してからバージョンアップ(CurrentDeployment.CheckForUpdate()、Update())すれば今までは動作していたけど、カスタムインストーラでインストールした場合、TrustNotGrantedExceptionが発生してしまう。
　なので、バージョンアップ時にも、通常のClickOnceのバージョンチェック、更新は使用せず、InPlaceHostingManagerを使用してバージョンチェック、Updateをするように対応。


設定を自動的に検出する、WPADの場合は社内に環境が無いのでまだ未検証。
おそらく動的にプロキシ取得するのでダメだと思う。お客様環境によってはこちらも検証、対応しなければ。
しかしインターネット経由でClickOnceを導入してる人はみんなカスタムインストーラで対応しているんだろうか。。。謎だ。
(自分が上手く情報を探せていないだけかもしれないけど・・・)

今のところ、大体うまく動いているようだ。(一部問題がある端末もあるみたい。。。うーん)

*1:http://support.microsoft.com/kb/318140/ja、http://support.microsoft.com/kb/307220/ja 参照

明けましておめでとうございます＆2011勉強会振り返り

勉強会


今年が皆さんにとって良い年になりますように


さて、一昨年の7月に開発に復帰して1年半ほどたちました。
去年は最初の大きなプロジェクトのリリースもあり、また役職にも付き、仕事的にはそこそこ成果が出た年でした。
(ただうちの会社は11月が期初で、この2ヶ月はだめだめだったりしますが)


IT関係の勉強会も昨年は積極的に出るようになり、刺激を受けた一年となりました。
だいたい月一回ペースで参加してました。
（後半は、家の都合から途中退席ということが何回かありましたが）

勉強会の鬼をみならって、印象に残っているイベント、セッションを上げたいと思います。


・1/27、DevLove「我々は、テストで世界を繋げる」のRyuzeeさんのセッション
　テスト自動化、CIに関してのセッション
　なんとなく導入していたCIに関する知見を得られたのがよかった。
　セッション後、前日に（TFS、テスト自動化関連の）JaSSTの公演を聞いたtomohnさんと同じテーブルになったのも印象に残っている。


・2/9、jQueryモバイルで簡単！ スマートフォンサイト作成
　銀座アップルストア、80人程度のキャパで200人近く集まった。消防法は大丈夫なのか？
　それだけjQueryMobileに対する注目度が高かったんだと思う。
　これに参加したお陰で3月末のスマフォ向けサイトを無事リリースできた。


・2/17,18デブサミ
　【18-B-7】未来のために私たちの帆を立てよう
　デブサミは相変わらず色々面白いセッションがあったんだけど、このセッションは参加型だったのと、岩切さんの熱さにやられました。


・4/9DevLoveDDD
　増田さんのセッション
　当たり前のようにDDDを実践している様が伝わってきました。
　リファクタリングを俯瞰的にみるとDDDになるというのが目からウロコでした。
　一度ちゃんと講義を受けたいです。


・4/15AgileJapan2011
　當仲さんのセッション
　エンジニアはスターだ！ハッピーメーカーだ！
　そのとおりになれるよう頑張らないと。


・9/2F#読書会
　自分にとってはこれに参加するために実践F#を買って取り組んだのが大きい。
　F#おもしろいけどまだIDE環境が整備できてない。。。
　はやく整備しなきゃ。


・9/3XP祭り
　懇親会で@Shinyaa31さんと話せたのが大きい。
　また、@pocketberserkerさんにscmbcに誘ってもらったのも大きかった。


・9/19アジャイルサムライ他流試合
　ワールドカフェもよかったけどやはり角谷さんの熱いセッションが良かった。
　またデブサミで話し聞けるので楽しみ。


・10/16Jenkins第4回勉強会
　懇親会で@takaesu0さんにReSharper教えてもらったのが大きい。
　いまでは必需品になってます。


もちろんここに書いていない勉強会もありますが、こうして振り返ってみるといろいろな経験、出会いの上に今の自分があることを再認識しました。


来年はもっとOutputできるようにしたい。
技術的にはAWS、Hadoop、F#への取り組みで結果を出したい！

【C# Advent Calendar 2011 12/19】　Windows.FormsだってTDD！

C# NUnit NUnitForms

このエントリはC# Advent Calendar 2011の19日目のエントリとなります。
18日目はkkamegawaさんの.NET 4.5でのTPL改良についてです
20日目はzoetroさんのReactive Extensionsでセンサプログラミングです


今月に入って、テストのないレガシーなWindows.Formsのやっつけコード(とバグ)を量産しているmasakitkです。
11月にはAdventCalendarのネタを考える時間があったのですが、忙しくなってどこかに吹き飛んでしまいました。

ということで、NUnitFormsをつかったWindows.FormsのGUIまわりのTDDについて書きます。
手順としては、

といった進め方になります。
UIがないと、まずテストを書いて、そこからプロダクトコード(クラス、メソッド)を生成して、といった流れになるかと思いますが、UIに関してはやはり最初にデザインだけお絵かきをしたほうが手間がないかと思います。
なお、事前にインストールが必要なものは、VisualStudio2010Express、Nunit2.5.10です。

  • まずはUIのデザインを行う。

プロジェクト名は何も考えずに、「TddFizzBuzz」とでもしておきます。
Windowsフォームアプリケーションのプロジェクトを作成してください。
で、Form1を削除して、FizzBuzzFormクラスを追加し、以下のような画面デザインを作成します。
DataGridViewには、列の設定などは行いません。

お題としては、XP祭り2011のTDDBCミニに参加した際のお題だった、FizzBuzzにしたいと思います。
アプリの仕様としては、テキストボックスに数値を入力し、ボタンをクリックするとグリッドに1からその数値までのFizzBuzz変換結果を表示する、といった仕様とします。
DataGridViewは、自分自身がFizzBuzz結果を取得できるよう、カスタムコントロールにします。
ユーザーコントロールを追加し、継承元のクラスをUserControlからDataGridViewに変更し、Designer.csの33行目(AutoScaleModeに代入している行)を削除する、というほんとにこんな手順でいいのか？という感じで作成します。
(ソースはこのへん)

名前は以下のようにしておきます


　TextBox：maxNumberTextBox
　Button：fizzBuzzButton
　DataGridView：fizzBuzzDataGridView


これでテストを書く準備が出来ました。

  • テストを書く(Nunit、NunitForms)

テストプロジェクトを作成しましょう。
クラスライブラリのプロジェクトで、名前は「TddFizzBuzzTest」とします。
先ほどのTddFizzBuzzプロジェクトへの参照と、System.Windows.Formsの参照、
およびNunit、NunitFormsの参照を追加します。
ソリューションの下にlibディレクトリを作成して、そこにライブラリを格納します。
NunitFormsはダウンロードサイトに行くとやたら古いですが、最新のソースからビルド
するか、ビルドしたものがgithubに上げたサンプルに含まれていますので、それを使ってみてください。


Nunit
http://www.nunit.org/?p=download


NunitForms
バイナリ（古い）
http://sourceforge.net/projects/nunitforms/files/nunitforms/
ソース（svn)
https://nunitforms.svn.sourceforge.net/svnroot/nunitforms


参照設定が終わったら、もともと出来てるクラスを削除して、「FizzBuzzFormTest」クラスを追加し、以下のコードを記述します。

using System.Windows.Forms;
using NUnit.Extensions.Forms;
using NUnit.Framework;
using TddFizzBuzz;

namespace TddFizzBuzzTest
{
    [TestFixture]
    public class TddFizzBuzzTest
    {
        [Test]
        public void Test01_10までのFizzBuzz結果の確認()
        {
            var target = new FizzBuzzForm();
            target.Show();

            new TextBoxTester("maxNumberTextBox", target).Enter("10");
            new ButtonTester("fizzBuzzButton", target).Click();
            var dataGrid = new Finder<DataGridView>("fizzBuzzDataGridView", target).Find();
            AssertForOneRow(dataGrid, 1, "1");
            AssertForOneRow(dataGrid, 2, "2");
            AssertForOneRow(dataGrid, 3, "Fizz");
            AssertForOneRow(dataGrid, 4, "4");
            AssertForOneRow(dataGrid, 5, "Buzz");
            AssertForOneRow(dataGrid, 6, "Fizz");
            AssertForOneRow(dataGrid, 7, "7");
            AssertForOneRow(dataGrid, 8, "8");
            AssertForOneRow(dataGrid, 9, "Fizz");
            AssertForOneRow(dataGrid, 10, "Buzz");
        }

        private static void AssertForOneRow(DataGridView dataGrid, int rowIndex, string expected)
        {
            Assert.That(dataGrid["FizzBuzzValue", ToZeroBased(rowIndex)].Value, Is.EqualTo(expected));
        }

        private static int ToZeroBased(int rowIndex)
        {
            return rowIndex - 1;
        }
    }
}

デバッグビルドをして、（構成マネージャの出し方は、ツール→オプション→左下の「すべての設定を表示」をチェック、その後、プロジェクトおよびソリューションの全般「ビルド構成の詳細を表示」にチェック）Nunitランナーでテストを実行しましょう。(64bitOSの方は、nunit-x86.exeから実行)
すると、

TddFizzBuzzTest.TddFizzBuzzTest.Test01_10までのFizzBuzz結果の確認:
System.ArgumentOutOfRangeException : インデックスが範囲を超えています。負でない値で、コレクションのサイズよりも小さくなければなりません。
パラメーター名: index

と表示されるかと思います。
グリッドに1行も表示されていないので当然です。
これから実装に入りましょう。

  • 実装を行う

FizzBuzzForm上のfizzBuzzButtonのClickイベントに、以下のコードを書きましょう。

        private void fizzBuzzButton_Click(object sender, EventArgs e)
        {
            fizzBuzzDataGridView.ShowFizzBuzzRows(int.Parse(maxNumberTextBox.Text));
        }

上記コードを記入したあと、ShowFizzBuzzRowsのメソッドスタブを作成し、FizzBuzzDataGridViewに以下のコードを追記します。
メソッドスタブの作成等の補完は、VisualStudioだと「Ctrl+.(ピリオド)」が便利ですね。(今はReSharperのAlt+Enterに慣れてしまっていますが)

        internal void ShowFizzBuzzRows(int maxNumber)
        {
            DataSource = FizzBuzzService.GetInstance().GetFizzBuzzList(maxNumber); 
        }

そしてFizzBuzzServiceクラスは、こんな感じにします。

using System.Collections.Generic;
using System.Linq;

namespace TddFizzBuzz
{
    class FizzBuzzService
    {
        internal static FizzBuzzService GetInstance()
        {
            return new FizzBuzzService();
        }

        internal List<FizzBuzz> GetFizzBuzzList(int maxNumber)
        {
            return (from i in Enumerable.Range(1, maxNumber)
                    select new FizzBuzz(i)).ToList();
        }

        public class FizzBuzz
        {
            int _number;
            internal FizzBuzz(int number)
            {
                _number = number;
            }

            public string FizzBuzzValue
            {
                get
                {
                    return _number % 15 == 0 ? "FizzBuzz"
                        : _number % 5 == 0 ? "Buzz"
                        : _number % 3 == 0 ? "Fizz"
                        : _number.ToString();
                }
            }
        }
    }
}


この状態で、テストを実行すると緑になっているはずです。


実際には、DataGridViewで無名クラスのListを返すようにしてテストを緑にしてしまったのですが、そのあとリファクタしてサービスクラスを切り出しました。
ここまででRed-Green-Refactoringの1サイクルです。
それほど手間なく、UIのテストがかける感じがしませんか？
メッセージボックスや、モーダルウィンドウも割りとスマートにテストできます。
＞http://d.hatena.ne.jp/masakitk/20110516/1305548197　参照


ここまでのソースは(なれないgitを使って)githubにあげましたので良かったら見てください。
https://github.com/masakitk/TDDSample


画面周りは仕様がよく変わるし、UIテストはコストに見合わないとよく言われますが、Windows.Formsの業務アプリなんかだとそこまで頻繁に変わるものでもないかと思います。
WebだとSeleniumとかを回帰テストとしてメリットを見出して使っているところもそこそこあるのではないでしょうか。Windows.Formsだって同様のことは可能ですし、同様のメリットはあると思います。
UIAutomationを使えば、操作を記録して自動回帰テストとして利用できるようですが、エンジニア的には先にテストを書きたいですよね。
ただ、TDDの肝はテストとコードを素早いフィードバックサイクルで回していくというところかと思いますが、GUIが絡むとサイクルは遅くなる印象があります。
が、機能テストとして先にテストを書いて、実装を書く、という進め方はありなんじゃないかなーと思っています。


また、今回の例でいえば、FizzBuzzServiceをモックにしてしまえば、プレゼンテーションレイヤの単体テストとすることも出来るかと思いますが、やはりUIを絡めたテストはエンドtoエンドテストとしての活用が有効ではないかと感じています。


C# Advent Calendar 2011、次は、@zoetro　さんです

プロキシ設定がある場合

ClickOnce

お客さんからWindows7にOSが変わって、ClickOnceのアプリがインストール、Updateできないとの連絡があった。
XPの時は問題が出ていなかったみたいなんだけど、なんだろう？


IEの設定では、プロキシの自動検出、構成スクリプトでの検出の両方にチェックが入っているとのこと。
インストールページは見れるけど、.applicationファイルを見に行く時に、サーバの名前解決ができていないようだ。
.netF/Wが、アプリをダウンロードする際にプロキシが適用されていないっぽい。
なんとかしてプロキシを適用する方法をいろいろ考えてたんだけど、それより別のexe作って、WebBrowser経由でRequest送ればいいのでは？という視点で対応中。
インストールは別のWindowsFormsのプロジェクトで、更新は自動更新をさせないようにして、アプリ起動時にアプリから更新するような形で検討中。
行けそうな雰囲気だ。


追記
#この件、ちょっと手が回っていないが今のところまだダメ。(2011/12/17)

#原因がわかってきた。解決間近か？(2011/12/27)

2011/11/19 SCMBootCamp in Tokyo 2

勉強会

途中参加の途中退席という中途半端な感じとなってしまいましたが参加してきました。

  • 参加前の状況

XP祭りの懇親会に向かう途中、@pocketberserkerさんにscmbcなるイベントがあって2回目を計画中ということを教えてもらい、その存在を知りました。


一応入門GITをパラパラ読んで、今のsvnリポジトリからgitのリポジトリに同期してgitでTFSでいうゲートチェックインみたいなことをやりたいなー、と思いちょっとやってみたところ、日本語化の壁に跳ね返されて断念していたという現状があった。
しかも、ここ3ヶ月くらいは本も読み返していない。ヤバイか。。


今週頭に次男が熱けいれんを起こして、治ってきたと思ったら今度は上の子が熱発。
おまけに奥さんダウンで金曜午後半休で家事育児やるという、これは無理かという状況だったが、奥さんのお母さんが来てくれてなんとか中途半端ながら参加できた。

  • 参加当日


最近、家族稟議を通して購入したノートPCを勉強会で活躍させる機会が来た！！
(購入後、何度か勉強会でましたが、今まで通りノートにペンでメモってました)
しかし会場についてネット接続に手間取ってしまってせっかくの藤原さんの話はあまり聞けてなかった。
そのなかでも、TFSのゲートチェックインみたいなことをやってるような話があって、いいなーと思ったり。
あとPCで#scmbcを追ってると裏で色々議論があって楽しい。


@bleisさんのわかりやすいgit入門、mercurial/bazaarにわかれたセッションは、mercurial側に。
これもわかりやすいtroterさんのセッションでした。
お二方の資料はこちら。

http://www.slideshare.net/bleistift/scmbc-git-10226700
http://troter.jp/scmbc-201111-mercurial-introsession/


この後、お弁当タイムを経て、演習へ。


うちのチームの講師役には神速さん。(良い人オーラがでてました。)


1syoさんがgit使ってた以外は、自分を含めほぼ未経験のチーム。
最初は普通にclone、add、commit、push、pullなどを使います。
自分の端末(windows7)は、msysgitと、gitで両方クライアントが入っていて、日本語設定が変なことになって神速さんに助けてもらいました。(ユーザーホームディレクトリの.gitconfigにnkfの設定をした)


でもcheckoutとかresetとか、変な使い方をしてpushできなくなり、レアな状況になってますとのことで、またまた神速さんに助けてもらいました。
コミットグラフがA列車みたいというtweetがでてましたが、確かになつかしのA列車(最初のやつ、はるか昔X1で遊んだ)を思い出しました。


3度目の演習に入ったくらいで、奥さんからHelpメールがきたのでここで途中退席。
残念でしたが、参加できただけでもありがたい状況だったのでしかたなし。


今まで日本語対応とかで断念していたけど、windowsでgitを使っていく覚悟が出来ました！
講師の方、スタッフの方、同じチームの人(特に神速さん、1syoさん)ありがとうございました！
bleisさんがゲートチェックインみたいなことやってるといってたので自分のとこでも出来るはずだ。がんばろう。

11/9 平鍋さんのリーンスタートアップの話

agile

聞いて来ました。
受託開発やってるから場違いかもしれないけど、平鍋さんの話なら現場に持って帰れるものがあると思って参加。


ただこの日はお客さんが来社されていて、6時前から打ち合わせで6時45分頃に会社を出た。
自転車で小滝橋から神泉まで25分、19:10過ぎに到着。
正面ドアが開かずに人が出るのを待っていたら、同じく参加される方に裏口に案内してもらいました。
主に金銭面の理由から懇親会はパス。

久々に（前職場のあった）渋谷から自転車で〜世田道〜多摩サイ経由で帰る道中、今日の話に関して色々考えてました。
とりとめなく考えたことを垂れ流します。

  • agileの外側、要求を決めるところまで含んでいるのがリーンスタートアップ。
  • 要求を決めるところは今までAgileで言及されていなかったところ？
  • 例えばスクラムだとプロダクトオーナーがプロダクトバックログを作るのかな。
  • 実務でも問題になっていて、お客さんが仕様を決めてくれないから作れないという今の現状をどうすればよいか？
  • アジャイルサムライで一番自分に刺さったところは、顧客とゴールを共有するという事。
  • システムの仕様をお客さんに決めてもらうのはお客さんのゴールと、作る側のゴールが別になってしまうのでは。
  • お客さんはシステムが出来上がることがゴールではない。
  • できたプロダクトで価値を得るところがゴール？もっとその先？
  • 昔ウォーターフォールでやってたときは、現状分析3ヶ月、新業務フロー作成3ヶ月とかかけてお客さんと一緒に業務、システム仕様を決めていったけどアジャイルはそうじゃないよな。
  • 何を作ればよいか決めるところから仮設を立てて、try&errorを繰り返して少しずつ発展させるというのがリーンスタートアップかな。
  • そして失敗すること（で得られる学び）に価値がある。
  • XP祭りで浜さんがいっていた、「一度は客と喧嘩しろ」みたい
  • そういえばうちの社長も、どれだけ早く失敗するか、というようなことを言っていた。
  • どちらも失敗から何を学んで、成功体験に持っていくか、と言う所が重要なんだろう
  • これを受託開発に活かすことはできる？
  • 業務システムで、細く早く回すにはパイロット的に試行錯誤するチームを作るのかな？
  • お客さんの体制を巻き込まないとむりかな。
  • ある程度しっかりした組織になってしまうと、細く早くは難しいのかもしれない。
  • 現状、複数の支店があり、各々業務の運用が統一されていない。
  • 統一するには、ある程度時間をかけて業務を整理しないと？
  • 細く早くなら、統一せず各々の支店毎にサイクルを回したほうがいいのかな？
  • 開発中はこのサイクルを回すことでいいと思うけど、それほど変化の早くない業務だとリリース後はどこかのタイミングで振り返りをして、そのフィードバックで2次開発とかなのかな。


などなど。
もやもやは続く。。。
なにかしらの形で今の現場にフィードバックしたい。

第4回スクラムプロダクトオーナー勉強会

agile

参加してきました。
ワークショップ中心なので、メモはなく記憶を頼りに書きます。
（最後のKPTは写真とっとけばよかった・・・）


XPでagileを知ったのですが、Scrumについて全然しらずに今まで勉強とかしてませんでした。
が、

  • アジャイルサムライの他流試合のワールドカフェで隣になった方が@fullvirtueさんで、PO勉強会の主催者をされていた
  • ちょうと今の案件で要件を決めていくところで、いろいろな方の知見を吸収できればと思った。
  • 朝、電車の中てtwitter見てたらキャンセルが出て、1名参加できるとのことだった。
  • 続き物の勉強会だけど、途中参加でもフォローできるのでOKらしい。

という理由で当日参加を決めました。


18:45に浜松町のTISと言うことは、会社を定時の18:00にでても、普通に歩いてたらギリギリ間に合わない感じなので、会社から高田馬場までと浜松町からTISまでは軽く走った。18:06に会社を出て、TISついたのは18:52。


ほとんどがワークショップで手を動かす勉強会で、内容としては飲み会開催までの想定フローがあって、そのフローをもとにユーザーストーリーを作り、見積もりをする、という流れでした。


まず、やってしまったのが主賓、出資者の都合を聞いて、日付、予算、場所を確定してから参加者に参加可否を聞くというフローをちゃんとか解していなかったこと。
ふつう参加者の日程はきくよなーとかおもって、フローに外れたストーリーを作ってしまった。


あと本来は、ストーリーを書いた付箋の裏に、完了条件を書くはずだったのだけど表を書くだけでも時間に遅れ気味だったのでそこまで出来なかった。


そのあと、ストーリーのまとまり（Epic？）を整理してどこからリリースするかを決めた。
うちのチーム（チームの方の名前メモってませんでした。@amameciさんはインパクト強くて覚えてました）では、日付、場所確定と、参加者への参加確認の2つを優先させることに。
その2つのEpicのリリースを分けるか、まとめて1回にするかという話になって、周りの人はこれくらいの作業なら絶対量少ないからすぐできるし1回にまとめちゃえばいいんじゃない？という感じでしたが、Epicに優先度があるならその順にリリースしては？という意見を伝えて2回リリースにしてもらった。


その後プランニングポーカーで見積もり。
ちゃんと専用のカードが用意されてました。
ちなみに、実業務では100均のトランプの1,2,3,5,8,13でやってます。（ぱっとみほんとにトランプやってるように見られてしまうのが難点）
基準となるストーリーとポイントを決めて見積もっていくけど、どれもそれほど変わらないかんじで1〜3の間に全て収まった。あまりポイントが下に寄り過ぎると、規模の比較がうまく機能しないと思うのでちょっと失敗したかなと感じけど、チーム内の他の人はなるべく小さく揃えるようにしているという人もいました。
割と皆さんRailsでつくるならすぐできるから、この題材では小さいポイントばかりになるのはしょうがないといった雰囲気があった感じ。
後から自分が、受け入れテストは書く想定ですか？とか聞いて、そこで完了基準が共有できてないよねーとかいいう話に。


ある程度見積もりを終えて、KPTで振り返り。
個人的にはいろいろと課題を感じて(まあKPTだとだいたいそうなるのですが)Problemが多かった。

  • 完了基準(受け入れテスト内容)が共有できていなかった
    • (Try:見積もり対象のストーリーを絞ってでも完了基準を共有する)
  • 小さいポイントばかりで、基準となるストーリー、ポイント設定を誤った。
    • (Try:真ん中くらいのストーリーを5ポイントととする？)
  • 想定作業フローをちゃんと理解していなかった。
    • (Try:フローの読みあわせをする)

あと他の方からは

  • もう少しストーリーの価値について考えると良かったのでは

という意見もあり、これは今やっている実務で強く意識しないといけないよなーと思いました。
(年に2回しか使わないのに、凝ったメンテナンスの画面がほんとにほんとに必要なのか？)


いくらか時間が押して勉強会が終了し懇親会に。
懇親会の席も勉強会同様カードを引いて決めたのですが、右隣には勉強会マニアでレポート職人の@shinyaa31さんが。もちろんすでにさすがのレポートが上がってます。(XP祭りでも隣でしたがその時はまだレポート職人とは知らなかったです)
勉強会情報や仕事の状況などいろいろ話して、その後左にいた方とも話す。
その方はゲームを20人くらいのチームで開発していて、スクラムやってますとのこと。
20人て多いなー、と思って伝えたら、みんなからそう言われるけどそれしかやったことないから、という感じでした。でも朝会は全員参加で10分程度、タスク作るときとかは全員ではなくてその中でもチームごとみたいな感じでやっているとのこと。やはりみんな現場に合わあわせて工夫してるんだなーと思いました。
あとはゲームだと、仕様をきめるプランナーの人が同じチームにいるので、その点ではスクラムに適用しやすいのではという話もありました。業務システムだと、お客さんが要件をまとめる所がこれまた大変なのでその点は羨ましいな、とおもったり。
でも要件まとめるところもやりがいはあるとこだよなー、今回そこまで入り込めてないけど、と思ったり。


切り上げる直前くらいに、fullvirtueさんが今回の勉強会についての意見を募っていたので、完了基準がかけなかったことをお伝えして、23:00過ぎに切り上げて帰りました。
fullvirtueさん、関係者の方、参加者の方、どうもありがとうございました！！
次回も仕事調整して是非参加したいと思います。

最後にちょっと感想を付け加えときます。

  • 実業務で試行錯誤しながらやっているプランニングポーカーとか、ストーリーの粒度とかはそんなにぶれてはいない感じでちょっと安心した。(安心しても仕方ないですが)
  • 実業務ではストーリーを付箋とtracのチケットに入れていて、受け入れテスト内容にパターンが有る場合はチケット上にデシジョンテーブルのようなマトリクスで表現して入れているので、付箋の裏に全部かくのはちょっときびしいかなと思った