#RSGT2019 の歩き方 - うさぎ組
はじめてRSGT2019に参加する人、もっとたのしみたい人などたくさんいるとおもいます。ということで、RSGT2016 - 2018まで参加してきた身としての歩き方を紹介します。 本エントリは 「Regional Scrum Gathering Tokyo Advent Calendar 2018」（非公式）26日目の記事です。（は？） adventar.org confengine.com まず会場近くに宿泊しよう 基調講演はきいて損がない ランチでは隣の人に声をかける or さっさと食べてホワイエ（ホール外）でドリンクをのみながら声をかける ランチ後の講演はどれか2,3つ聞いて、それ以外はホワイエ（ホール外）でスピーカーをつかまえる or 休憩する 初日のネットワーキングパーティではここまで話した人をつかまえよう or 気になる人に声をかけよう 2日目もほぼ同様でOK 3日目のOSTは
なんちゃってアジャイルから、4年間アジャイル開発していたら15minスプリントになった件 #RSGT2019 - うさぎ組
概要 とりあえず次の動画をみてほしい。 ちまたのアジャイル開発チームはスプリントが1週間だが、私のチームは15minで回している。 学生や新卒に1日スプリントを教えている。彼らは5日程度で1日スプリントをマスターする。 15minスプリントを含んだプラクティスについてスライドにしてほしい、聞きたいという人は RSGT2019の公募にlikeしてほしい。かりにlikeはなくても、RSGT2019に参加しよう。 セッション confengine.com チケットはこちらから！11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019 www.youtube.com 概要 背景 スプリント期間の変遷 RSGT2019 参考書籍 生物系の参考書籍追記 背景 このチームが今までどんなふうに開発を経てきたのかはだいたい次のスライドにまとまっています。 簡単に
ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019 - うさぎ組
先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。 きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？ これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと チームにできるプラクティスは残るし、できないプラクティスは残らない。 というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 で
「開発現場で役立たせるための設計原則とパターン」をオススメできない理由 - うさぎ組
「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。 私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。 まず、件のスライ
ScalaMatsuri 2018トレーニングデイの感想。またはチュートリアルがひどかった件 - うさぎ組
ScalaMatsuri2018というScala言語のカンファレンスに参加してきました。といっても3日間のうちの1日目（というか0日目みたいな位置づけ）のトレーニングデイというものだけですが。 最近Scalaを使っているし、Scalaユーザーにいくつか聞けたらなぁーとかちょっと勉強したいなーって感じで。 2018.scalamatsuri.org 運営の方はおそらく大変だったと思いますがいろいろ対応してくださって助かりました。 ただ、自分が参加したチュートリアルセッションはひどかったです。自分もハンズオンで教えることがあり、失敗を幾度かしてフィードバックをもらっては改善してきました。ので、今回は私がフィードバックをする番だと思いましたので、このエントリにさせていただきます。 トラックとかモチベーションについて Scala入門ハンズオンのタイムライン Implicit入門 CTO座談会 まと
僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組
昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。（ちなみに就職したのは19歳のとき） →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇
テスト全体の良い書き方について。 #swtest_jp - うさぎ組
概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基本的に3段
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
