カテゴリー: Agile

  • CheckiO

    CheckiO

    http://www.checkio.org/
    先日、twitterで紹介されているのを見かけて登録してみました。

    詳しくはこちらの記事をどうぞ。
    http://plus.appgiga.jp/masatolan/2014/02/13/50594/

    テストファーストの練習になるし、
    そもそもブラウザだけでプログラミングができるし、
    問題を解くと、パブリッシュされている他の人のコードも読めるし。

    一石二鳥、三鳥、いやそれ以上かも。

    そうそう、英語の勉強にもなります。
    特にPythonやったことない人におすすめ。(え

  • JUnit勉強会を開催しました。

    3月12日の夕方からJUnitの勉強会を開催しました。

    イベントの案内ページはこちら。
    JUnit勉強会 in 松山 – “REVIVAL” #season1

    教材は、”JUnit” や “Tutorial” といったキーワードで検索したネット上の記事と
    WEB+DB PRESS Vol.69, そして「JUnit実践入門」を辞書的に(?)使いました。

    セッション1

    Eclipse, JDKなどは各自インストール済みだったのでプロジェクト作成から開始。
    JUnitライブラリの組み込み方や、テストクラスの追加の仕方などうっかりミスがあったり。それとAssertThatですが、参考にしたTutorial記事のimportの仕方に引きずられていたようで、勉強会のあとでimportの記述の仕方を見直したところ問題なく利用できました。

    振り返りの様子
    2013-03-12-junit-s1

    参考
    The Hamcrest Tutorial
    JUnitMatchers(JUnit API)

    セッション2

    ParameterizedTestやTemporary Folder、@Ruleなど。
    何となくキーワードをながめるだけではよくわからなかったりしますが、仕事のどういう場面で使うとか解説してくれる方がいてとても勉強になりました。逆に、あまり使っていないこともわかったりして、今後の仕事で使ってみたいなど刺激にもなったようです。

    振り返りの様子
    2013-03-12-junit-s2

    セッション3

    EasyMockをテーマに議論しました。
    そして全体を通しての振り返り。今回はTutorialに沿って進めてみましたが、次回は実際に課題を決めてテスト->コーディングを繰り返してみたいと思います。

    振り返りの様子
    2013-03-12-junit-s3

    コーヒーブレイク

    たまたま誕生日の方がいらっしゃいましたので、サプライズパーティーとなりました。
    2013-03-12-junit-c1

  • アジャイルサムライ読書会の予習

    バーンダウンチャート

    縦軸は残作業の総量
    横軸は時間(イテレーション)
    順調に進めば右下がりとなり、ゼロになればプロジェクト完了

    右下がりにならない、すなわちチームのベロシティが下がっている
    プロジェクトの状況を可視化できる
    思ったほどのベロシティにならない場合は計画の見直しをするなど

    右上がりのバーンアップチャート形式でも可能

    途中からアジャイルにしていく
    まずはインセプションデッキの作成から

    チームメンバーの入れ替えはベロシティが下がる前提で

    時間が足りない場合はスコープの調整
    無理をするのではなく信頼関係の構築

    パーキングロットチャートについては
    「アジャイルな見積りと計画づくり」を参照

    イテレーションの運営

    アジャイルなイテレーション
    毎週価値のある成果を届ける
    実装開始直後から動く状態
    結合した状態で進んでいく

    分析・設計、開発、テスト

    ペルソナとは
    ソフトウェアのユーザを役割ごとに簡単に説明したもの
    リアルな人間が具体的に解決したい課題を持っている

    ペアプログラミング
    分析やテストもペアでやってみる

    イテレーション・ゼロ
    実装に着手するまえの段取り、環境整備

    カンバン
    カードを使って組み立てラインでのパーツ補充の工程を調整する仕組み
    仕掛り(Work In Progress)にできる作業に上限を設ける
    すなわち、チームが同時に着手できる作業の数
    イテレーションが必要ない(タイムボックスは関係ない)
    運用やサポート業務に向いている

  • アジャイルサムライ読書会 – 8章前半のふり返り

    昨日22日のアジャイルサムライ読書会のふり返りです。

    今回は8章の途中まででした。
    前回参加できなかったこともあって、久しぶりの参加でうっかり予習を忘れてしまいました。流し読みでもいいから、読んでいかないといけませんね。反省。せっかくの勉強会。皆さんの時間を無駄にしないように。他にもいろいろ勉強したいこともありますし。

    さて、8章はアジャイルな計画作りです。

    プロジェクトの途中で主力のメンバーが何らかの都合で外れてしまうとか、まぁありそうなお話ですね。そうでなくても多少のマージンを見ていたとしても、現実には全員がほぼフル稼働状態で期日が迫るに連れて残業が慢性化していて休日も…。何とか間に合わせようと、安易にコードをペタペタと膨らませて、どうにもならなくて他のところから人をかき集めて…。それで何とかなったとしても、その後の運用・保守を考えるとぞっとします。いや、ぞっとしないかも。慣れてるから。(汗

    (コラム記事には「プロジェクトをクビに…」という最悪のお話も書かれていて “逆に” 安心できます。)

    このあたりを読んでディスカッションしたこと。

    リリースの期日に間に合いそうにない場合に、期日を調整するのかスコープを調整するのか。経験上、心苦しい会議をして期日を延ばすことが多かった。じゃあそれでその後うまく行くのか。結局、そのような状況になる時点ですでに無理やりのコーディングになっていたり、超過勤務の日々を過ごしていて期日が延びたからといって
    特にモチベーションがあがるわけでもなく。
    それよりは、スコープを調整して期日にリリースすべき。そうすれば新たなモチベーションの元に次のリリースに向けて開発を進めることができるはず。

    5章でも出てきたけど「スコープを柔軟に」することがポイント。じゃあなんでも削れるのかというともちろんそんなはずはないですよね。そこで出てきた言葉がMMF(Minimal Marketable Feature Set)。リリース単位のことをこのように表現されています。要するに価値のある機能を厳選して最初のリリースに含めるということです。そうすることで、期日が迫ったときにスコープを調整しやすい状態にできるわけです。

    それともうひとつディスカッションしたこと。それは個人の成果物に対する評価について。例えばある程度の規模のコーディングをすれば一定の割合のバグが発生するはず。言い換えれば、バグがなければ上司にとっては都合が悪かったりするわけです。これは何が問題かというと、個人の生産性を測っていること。すなわち生産性の高い人と低い人が同じ割合でバグを発生しないといけないのか、というまぁナンセンスなお話です。そうじゃなくてチームの生産性、この本ではチームのベロシティという表現がされていますが、このベロシティを評価して維持あるいは良くすることが重要です。どうしてもベロシティがあがらない場合、それは開発環境に問題があるのか、チーム内のコーディングの仕方に問題があるのか。そこの見通しがないと期日とかスコープの調整もできません。

    だいたいこのあたりまで。

    ということで、次回は少し先まで読んでから参加しようと思います。

    さて、この読書会のほかに、今年はいろいろな新しいセミナー・イベントに参加することができました。その大半は無料で参加できるもので、有志の方々が自主的に企画して開催されています。来年にはさらに新しいセミナーの計画もされています。そういう状況の中で考えてほしいこと。それは、無料で気軽に参加できるからといって甘えてばかりではいけないということ。開催する側は日常の仕事をしながら、身の回りの人も含めて少しでも良い仕事をしたいと思って努力をしていると思います。もちろん自分自身の勉強目的があります。なので、自分の都合だけで参加するとかしないとか、そういうことではなくて、なんとか時間を調整して積極的に参加するとか、参加できなくても周りの人への告知を協力するとか、何かできることがあると思います。もちろん強制されることではありませんが、これからの各種勉強会の益々の充実に期待するとともに、小さなことでも何かできることがあれば協力していきたいですね。

  • コードリトリート開催しました

    Global Day of Coderetreat 2012
    松山で記念すべきイベントを開催することができました。

    2012年12月8日は “Global Day of Coderetreat 2012” ということで、Coderetreatが世界各地で同時開催されました。
    国内では東京、大阪、松山、福岡の4ヶ所。

    Coderetreatとはプログラマのスキルアップのためのイベントです。
    午前・午後合わせて6つのセッションがあって、すべてペアプログラミングを行います。
    また、セッションが終了したら書いたコードをすべて削除します。それとTDDでのプログラミングを基本とします。
    オブジェクト指向が使えるものであれば言語はとくに制限はされません。
    ファシリテータによって、セッションごとに制約が設定されます。セッションごとに毎回ペアを入れ替えます。

    初めてのイベントで、ちゃんと開催できるかどうかいろいろ不安がありましたが、経験豊富なファシリテータ @haradakiro さんによってペアの進行状況をみながらきちっと形にしていただきました。

    参加してみての感想。
    テストファーストで、余計なコードを書かないということが体感できた。
    ペアで作業すると確かに集中力が高まる。
    とにかく小さく書くこと。コメントにたよらないということ。
    コードをわかりやすく書くことで意思疎通ができるようになる。

    最初のうちは、相手がやろうとしていることや自分がどうしたいのか、などの意思疎通が難しくあっというまにセッション終了となってしまいました。セッションを重ねるたびに慣れてはきたものの、完成させるには至らず。スキル不足を痛感させられるイベントでした。
    基本的な言語のスキル、テストツールを使いこなすこと、そして小さく作ること。このトレーニングを習慣づけることでソフトウェアの品質は格段に向上しそうです。

    今後、松山ローカルでもCoderetreatのイベントを継続して開催したいと思います。
    皆様のご協力・ご参加をよろしくお願いします。

    開催当日の会場/昼食/おやつスポンサー

    • 株式会社アトラクタ
    • 株式会社ウイットプラン
    • 合同会社カルチャーワークス

    ありがとうございました。

    当日の各地の様子
    http://coderetreat.org/photo
    GDCR公式サイト
    http://globalday.coderetreat.org/
    GDCR12のアナウンス
    http://coderetreat.org/profiles/blogs/announcing-global-day-of-coderetreat-2012

  • 12月8日土曜日に松山で初開催!!Coderetreat in Matsuyama

    12月8日土曜日に松山で初開催!!Coderetreat in Matsuyama

    12月8日(土曜日)にコードリトリートというイベントが松山で開催されます。
    この日は “Global Day of Coderetreat” すなわち世界で同時開催というとても大きなイベントになっています。

    ↓↓↓ご参加の申し込みはコチラ↓↓↓
    Global Day of Coderetreat in Matsuyama

    まだ席に余裕がありますのでご参加可能な場合はお早めにどうぞ。
    国内では、東京・大阪・松山・福岡の4会場がこのイベントに参加しています。(11月28日時点)

    今回はファシリテーターの @haradakiro さんに松山に来ていただいての開催です。
    イベントに向けての丁寧な記事が公開されていますので是非お読みください。
    Coderetreat ファシリテーターガイド
    なぜコードリトリートに参加するのか?

    参加費は無料です。昼食やドリンクのサービスもあります。
    普段のお仕事仲間、企業でのまとまってのご参加も歓迎です。
    この機会に是非ご参加ください。

    ご不明な点などございましたら @twikaz までお気軽にどうぞ。
    皆様のご参加をお待ちしております。

  • ユーザーストーリー – 明日の予習

    明日はアジャイルサムライ読書会に参加予定。
    ということで、たまには予習をしながらブログを書いてみるなど。

    まず最初に、文書化の難しさ。

    大量のドキュメントを作ったところで、時間が経てばやりたいことも変わってくるし、人が書いた文書を正しく理解するのは難しい。あるいは文書で他人に正確にものごとを伝えるのもなかなか難しい。

    「要件」を信じない。

    要件定義にかかれている項目のうち80%は必須ではない?
    (参考文献 XPエクストリームプログラミング入門 第2版
    必ず実現しないといけないことと、そうでないことの切り分けをしないまま「要件」としてまとめてしまっているので、本筋が見えにくい、という感じかな。

    そこで「ユーザーストーリー」

    インデックスカードに書き出す。
    フィーチャーの本質となるキーワードを書く。
    わかりやすくシンプル。
    ぱっと読んでおいしいと思えるもの。

    「6つの要素」

    Independent, Negotiable, Valuable, Estimatable, Small, Testable

    ユーザーストーリー vs 要件定義書・仕様書

    「要件定義」はそれを作る時点での情報を固定化してしまうところを問題視している感じ。
    それにくらべてユーザーストーリーは柔軟で無駄がない。

    ユーザーストーリーの「テンプレート」

    だれのためのストーリーで
    なにをしたいのか
    なぜそうしたいのか

    そして「ストーリー収集ワークショップ」の開催

    フィーチャーリストの作成。
    ワークショップでは開発チームと顧客が一緒になってユーザーストーリーを書く。

    と、こんな感じの内容です。

  • アジャイルサムライ読書会 – インセプションデッキ

    本日の読書会のふり返り。

    「第4章 全体像を捉える」を読みつつワークショップ形式で行いました。
    この章では3章で説明のあったインセプションデッキをひとつずつ理解して具体的に作成していくことを目的としています。
    ちなみに、インセプションデッキとはプロジェクトの全体像が把握できるように10個の設問を作成し、それぞれを1枚のカード(スライド資料)にするものです。これからスタートするプロジェクトにおいてチームおよびステークホルダで認識をそろえることを目的とします。また、プロジェクトの進行状況によっては改訂する必要もあります。

    1. 我われはなぜここにいるのか?
    2. エレベーターピッチを作る
    3. パッケージデザインを作る
    4. やらないことリストを作る
    5. 「ご近所さん」を探せ
    6. 解決案を描く
    7. 夜も眠れなくなるような問題は何だろう?
    8. 期間を見極める
    9. 何を諦めるのかはっきりさせる
    10. 何がどれだけ必要なのか

    で、本日は仮のプロジェクトを想定して「我われはなぜここにいるのか?」と「エレベーターピッチを作る」について学びました。

    • 「我われはなぜここにいるのか?」
      ここで思ったのは、例えば業務系システムを開発する場合、開発側の人は現場(いわゆるエンドユーザの作業場所、環境)に出向くケースが少なくて、現場に行く人は限られていたり、あるいはステークホルダ側の担当者も特定の人に固定されていて、現場を知らないまま進行していくケースが多いのではないかということです。本に書いているトヨタの設計事例や請求書発行の事例など、チームのメンバーがそれぞれ現場に行って実際に見ることで何が必要かということをしっかりと把握できると思います。そして、それを体験して終わり、ではなくて、1枚のカードに簡潔にまとめておくことが重要です。
    • 「エレベーターピッチを作る」
      ここでは、上の「..なぜここ..」を踏まえてプロジェクトの本質を簡潔に明確に表現します。
      例えば、営業的な立場の人は、顧客にプレゼンテーションを行う場合に、このエレベーターピッチ的な資料を作るケースが多いと思いますが、開発側の人は要件とか機能定義から始まってしまうケースが多いのではないでしょうか。さらには、技術的な専門用語を書き並べたものとか。
      どうしても普段の仕事柄そのようになりがちですが、ここではそのような専門用語を排除して特に業務やシステムに関する知識がない人にとっても明確にその必要性が伝わるようにまとめる必要があります。

    時間の都合もあって、それぞれを仕上げるところまではできませんでしたが、今回勉強会に参加した皆さんは普段のお仕事の中でそれぞれ問題意識を高く持っていらっしゃるようで、いろいろと意見交換ができて充実した内容になりました。

    私自身、これまではざっと本を読んで行く程度でしたが、次回からはもう少し下調べをしていくこと、それと与太話で脱線をしないようにしたいと思います。

  • アジャイルサムライ読書会

    アジャイルサムライ読書会松山道場 #4に参加してきました。
    ウェブサイトはこちら
    http://agile459.doorkeeper.jp/

    今回は第3章を読み進めました。

    終了後の振り返りにおいて、参加者みなさんからの意見にもあったのですが、
    自分で本を読むだけでは良くわからなかったり、頭に入らなかったりするのが、
    こうして、それぞれの組織で仕事をされている方々と意見を交換することで、
    理解が深まったり、気がついたりする、ということ。

    それと、歳を取るにしたがって、頭だけでは理解することが難しくなって、
    体を動かすことを組み合わせると理解しやすいとか。
    はい、そうですねぇ。ご指摘の通り。

    歳はともかくとして、それぞれの立場とか携わっている仕事に照らして
    本に書いてあることを解釈すると、いろいろな見方や意見がでてきます。
    それがとても勉強になります。

    中には着々とアジャイルの手法を実践されている方もいらっしゃって
    うらやましいなぁ、と思いましたが、その一方で、机の並べ方とか
    壁面の使い方など、職場環境に関する共通の問題もあって、事務所の
    デザインも重要な要素と感じました。

    次回からは、単に読み進めるだけではなくて、具体的なテーマを決めて
    実際に手を動かすワークの要素が入ってくる予定です。

  • アジャイルな開発

    せっかくなので、たまにはスマホアプリから投稿してみます。

    例えば一年がかりである程度の規模のシステムを開発する場合。

    お客様としてみれば、一年後にシステムが完成する(かも知れない?)までは開発側との打合せが続くわけで、本来の業務とは別の負担になる。

    そもそも業務を改善するためにシステムを開発するはずなのに、業務が改善されないまま、さらに上記の負担増に耐えながら完成を待つことになる。

    それよりは、打合せの成果を少しずつでも実現して、部分的にでも稼動させることで、従来、完成まで負担でしかなかったものを、メリットに変えていくことができる。

    また、そうすることで開発過程をお互いに把握できるようになるため、途中での仕様変更についても無理のない調整(相談)ができるようになる。

    そんな気がする今日この頃。