うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

Scrumのカンファレンスに参加してきた #RSGT2018

Scrumのカンファレンス(ギャザリング)に参加してきました。

2018.scrumgatheringtokyo.org

なぜ参加しているのか、今回どんなイベントだったのか、僕にとって何がよかったのか。を書こうと思います。 日本でアジャイルに興味がある方ならぜひ参加してみるといいと思います。

  • なぜ参加しているのか
    • 自分がなぜRSGTで発表するのか
  • どんなイベントだったのか
  • 僕にとって何がよかったのか
    • 参加してよかった3つのこと
  • まとめ
続きを読む

ソフトウェアコードのはじめかた

  • プロジェクト名や名前空間の雑さはIDEなどの強力さを考慮して決めること
    • IntelliJ IDEAなど => 名前空間やファイル名変更が強力なので、雑に決めてもあとから変更できる
    • Vimのみ => 名前空間やファイル名変更が
  • プロジェクトをつくるときは次の手順でやること
  • 要件を確認してアーキテクチャと単語の整理
    • noteという名前空間をつくり、そこにメモ書き用テストファイルをつくる。
    • 要件をテストコードにはりつける
  • 要件の一部をテストコードに翻訳する。簡単なケースだけでいい。 : RED
  • プロダクトコードを仮実装する。 : GREEN
  • 他の入出力のケースをテストに追加する。三角測量。 : RED
  • プロダクトコードを修正する。 : GREEN
  • テストコードをリファクタリングする。 : GREEN
  • 何をクラスとして切り出すかは、何をつくりたいのかを定義している段階できまるので、コードをかきながら決めないほうがいい。
  • テストコードはできるだけ長く書きはじめていく。テストコードは動的構造を記述する部分であり、プロトコル定義ツールとして使う。
    • 小さいテストコードはあくまでデバッグのサポート、型システムのサポート程度に考えて記述する。
  • 静的構造はプロダクトコード側で記述できる内容なので、プロダクトコードのリファクタリングや大枠の設計でおこなうようにする。
  • テストコードとプロダクトコードの設計がかたまったら、noteにあるテストコードを適切な名前空間にきりだしてあげる。
    • ユースケースを確認するようなテストは userguide, デバッグサポートのテストは developerguideなどがわかりやすい。ただ、developerguideのほうはビルドツール、IDEなどの連携をかんがみて、プロダクトコードと同じ名前空間にしたほうが便利なときもある。

Scrumが難しいのは幻想-情熱の再定義- を講演してきました。 #RSGT2018

私が所属しているチームは2017年にいろんなプラクティスを実践してきました。その内容をRegional Scrum Gathering Tokyo 2018で発表しました。

2018.scrumgatheringtokyo.org

confengine.com

発表内容の概要

私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。

このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。

チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、

なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。

結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。

チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。

スライド

speakerdeck.com

2017年の資料

Scrumありがとう、 そしてさようなら -Scrum 破- #rsgt2017 // Speaker Deck

2016年の資料

Scrum,Test,Metrics #sgt2016

Spockのレポート生成はHTML, Markdown, Asciidocできるし、カスタムも出来るんだぜ

GroovyのテスティングフレームワークであるSpockは標準ではレポート生成機能はありません。 多くはGradleでビルドしたときのxmlやhtmlを利用していると思います。

Spockにはspock-reportという拡張ライブラリがあり、これを依存関係に追加するだけでテスト結果のレポートを独自に追加で生成できます。 しかもなんと、HTMLだけではなくMarkdownやAsciidocとして生成することもできます。 また、最新のspock-reportではテストコードからレポートに文章を追加することも出来るようになりました。

今回はそんなspock-reportの便利機能をいくつか紹介します。

github.com

本ブログで説明しているサンプルコード全部入りのspockおよびspock-reportのプロジェクトテンプレートはこちら。

github.com

本記事はG* Advent Calendar 2017の16日目になります。

G* Advent Calendar 2017 - Qiita

  • 最低限の使い方
  • レポートをMarkdown/Asciidocとして生成する
  • テストコードから説明を追加する
続きを読む

Spock1.1の新機能紹介

SpockというGroovy言語で記述するテスティングフレームワークがあります。 今回は2017/05/01にリリースされたバージョン1.1の新機能のうち3つを紹介します。

Spock リリースノート

本記事はG* Advent Calendar 2017の14日目です。

  • verifyAll メソッドによる(Soft Assert)
  • where句のデータテーブルで左側の値を参照できる
  • @PendingFeatureで未実装機能マーカーでテストを実行しない
  • その他
続きを読む

GroovyのAST変換事情

Groovy言語ではAST変換をサポートしているのでその昔からAST変換をつかったライブラリがそこそこあります。 アノテーションでコード生成やボイラープレートなどの短縮、コード検査があります。

今回はAST変換の書き方というよりどういった成果物があったり、参考になる情報をまとめておきます。 本記事はG* Advent Calendarの12日目になります。

G* Advent Calendar 2017 - Qiita

  • AST変換の方法
  • AST変換の事例となる実装
続きを読む

メールのテストとか気になっているやつ

メールのテストを中心にまとめました。

  • メールのテストのためのSMTPサーバ SaaS
  • メールのテストのためのSMTPサーバ OSS
  • メールのテストで気にすること
  • Gmailにおける迷惑メール判定の見方
  • 証明書の情報を確認
続きを読む