タグ

ブックマーク / kyon-mm.hatenablog.com (16)

  • なんちゃってアジャイルから、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 参考書籍 生物系の参考書籍追記 背景 このチームが今までどんなふうに開発を経てきたのかはだいたい次のスライドにまとまっています。 簡単に

    なんちゃってアジャイルから、4年間アジャイル開発していたら15minスプリントになった件 #RSGT2019 - うさぎ組
  • "エンジニアが使うべき便利な windows アプリ一覧" がほしい - うさぎ組

    誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール(チャットツールとか)は選ばないようにした。 エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?— 徳永広夢 (@tokuhirom) October 2, 2018 RapidEE cmder 7-zip clibor Chrome, Firefox Mate Translate WinMerge そしてこれジオシティーズなので、大丈夫なのかが不安です。 Git Everything Process Explorer などsysinternals系 Crystal Disk Info ここで触れていないけど、実質必須になりそうなもの RapidEE www.rapidee.com Windowsの“環境変数”をGUIで編集できるソフト。各

    "エンジニアが使うべき便利な windows アプリ一覧" がほしい - うさぎ組
  • 「開発現場で役立たせるための設計原則とパターン」をオススメできない理由 - うさぎ組

    「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。 私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。 まず、件のスライ

    「開発現場で役立たせるための設計原則とパターン」をオススメできない理由 - うさぎ組
  • Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた - うさぎ組

    2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。 speakerdeck.com カンファレンスのイベントページに書いたセッションの概要はつぎです。 Regional Scrum Gathering Tokyo 2017 - Scrumありがとう、そしてさようなら-Scrum 破- | ConfEngine - Conference Management Platform ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透

    Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた - うさぎ組
  • スクラムとかアジャイルのワークショップ 2017.05 版 - うさぎ組

    毎月スクラムに関する勉強会を開催していて、そこでワークショップをやることがあります。 また社内で勉強会をやることもあります。 そこでいままで実施したワークショップの一覧があるといいなぁとおもったのでまとめておきます。 yattomさん、みほらぶさん、角さん、たかえすさん、川口さんありがとう!!! カンバンゲーム バルンガ 紙ヒコーキ 振り返り プロダクトオーナーの意思共有 フィアレスジャーニー スプリント期間と見積もり nagoya-scrum.connpass.com カンバンゲーム カンバンゲーム ルール説明 from Yasui Tsutomu www.slideshare.net カンバンゲーム カード(全種類) from Yasui Tsutomu www.slideshare.net バルンガ 異文化コミュニケーション体感ゲーム「バーンガ」 from Jun Chiba www

    スクラムとかアジャイルのワークショップ 2017.05 版 - うさぎ組
  • Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt - うさぎ組

    3行まとめ Hacker Tackleっていう激熱なITデベロッパー向けのイベントで「アジャイルテスト」について講演しました。 みなさんがつらいのはわかるけど、解決したいなら気で取り組む必要があるので、参考になれば幸いです。 あと、アジャイルにテストしている人達といろいろ議論したいです。 Hacker Tackleとはなにか hackertackle.github.io HackerTackleは、プログラマのための総合技術イベントです。 「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。 イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。 ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか? なんかMMA感がありますが、

    Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt - うさぎ組
  • テスト(コード)レビューの方針 書きなぐり版 - うさぎ組

    牛尾さんのブログをはてブったら、「じゃぁ、その手を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト(単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」 僕のコメント「書いていません!」 僕のコメント「書きました!」 僕の主張 記事は僕の実験結果(経過報告)であり、

    テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
  • アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組

    はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。(言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを

    アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
  • テスト全体の良い書き方について。 #swtest_jp - うさぎ組

    概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。(実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基的に3段

    テスト全体の良い書き方について。 #swtest_jp - うさぎ組
  • うさみみエンジニアが2012年に買った技術書 - うさぎ組

    追加 2013/01/01 ここから 僕の読書方法Togetter 【うさみみさんのの読み方 - Togetterまとめ】 (2012年の【僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組】のときに「どのように読書しているか」への質問ツイートへの返答をまとめたもの) 追加 2013/01/01 ここまで なんかTwitterでつぶやいたら気になるとの事だったのでのっけてみます。 (個人的には他人のが気になるので、これを見た人が自分のを公開してくれるとうれしい とりあえず、新しく買ったり、借りたりして読んだ技術書は全部のっけます。 2011年に既に買っているものは省いています。 その中でもいいなって思ったのは前半で括りだしてみました。 「いいな」っていうのは「今の自分にぴったりだったな」っていう意味で良書かどうかはまた別かもね。 うさみみ的によかった新しく読んだ書籍たち

    うさみみエンジニアが2012年に買った技術書 - うさぎ組
  • TDDの自殺 #kyon_mmAdvent - うさぎ組

    はじめに 僕は熱心にTDDを勧めているエンジニアです。 ですが、この2年でTDDが銀の弾丸ではないことも気付き始めました。 その気づきの一つがこのTDDの自殺です。 先にFacebookで投稿したところ、評価をもらえたので投稿します。 「読み手を選ぶエントリーです、(`・ω・´)キリッ」 これを読んで「kyon_mmも落ちたものだ」と思ってもらっても構いませんし、「迷惑な話だ」ということであれば僕に猛抗議をしてもかまいません。 TDDとはなにか TDDは開発者を支援するフレームワークと定義します。 TDDは「開発者の意図を確認すること」「開発者が心地よいコードを書き始める事」を支援するフレームワークです。 TDDの基礎 TDDを支えるものとして次の要素があります。 客観的で頻繁にも実施できる検査群、確認し易い検査結果群、RED,GREEN,REFACTORのライフサイクル。 これらによって

    TDDの自殺 #kyon_mmAdvent - うさぎ組
  • DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組

    このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ4年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 (元請け会社の2人、当時同じ会社だった先輩、僕の4人) そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201

    DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組
  • MercurialのコミットでJenkinsにGradleでビルドさせたりする。構成説明編 - うさぎ組

    JavaプロジェクトをMercurialにコミットしたら勝手にビルドされてテストとかやってくれるのいいですよね! ということでやってみました。いろんなプロダクトを使ったので今回は全体の構成を説明する編です。 使ったプロダクト Java、Groovy(プロダクトコードおよびテストコード) JUnit、hamcrest(テストライブラリ) Mercurial(VCS) Gradle(ビルドツール) Jenkins(CIサーバー) PostgreSQLDBサーバー) FindBugsなどなど(静的解析ツール) いろんなJenkinsプラグイン 自動処理の流れ 1.Java、GroovyコードをローカルのMercurialリポジトリにcommit 2.MercurialがサーバーのMercurialリポジトリへpushし、pushされたMercurialリポジトリがJenkinsのジョブをコール

    MercurialのコミットでJenkinsにGradleでビルドさせたりする。構成説明編 - うさぎ組
  • TDDを明確に定義する - うさぎ組

    でもそんなのどうでもいいから最終的には皆自分のTDDを持てばいいのではと思っている 2012-08-30 12:27:33 via web あなたがTDDだとおもうものがTDDです。 ただしたにんのどういをえられるとはかぎりません。 2012-08-30 12:30:20 via Twitter for iPhone ということで、TDDを定義します。 はじめに TDDを定義し、それの基礎を明らかにし、リファレンスモデルを明にする。 そして、他の例も紹介してみます。 TDDとは何であるか TDDとはソフトウェア開発者向けフレームワークです。 RED -> GREEN -> REFACTOR のスパイラルモデルが根幹にあります。 RED, GREEN, REFACTOR は開発者のアクティビティになります。 僕の理解ではプロセスの部分集合がフレームワークであるから、プロセスと呼ぶ事もできるけ

  • 僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組

    昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。(ちなみに就職したのは19歳のとき) →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇

    僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組
  • 今春まともなエンジニアになりたい人が読む12冊+α - うさぎ組

    今春まともなエンジニアになりたい人とはつまり僕のことです。 ちなみに最近まで読んでいたのはこっち →「ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組」 読み返すのも含めてこれらをしっかりと読もうと思ってる書籍をあげてみます。 最後のほうにOOPの設計系の書籍について補足を書いておきます。 CleanCoder まだ半分くらいまでしか読んでいませんが、宣伝の通り全てのソフトウェア開発に関わる人に読んでほしいと思わせますね。 Clean Coder プロフェッショナルプログラマへの道 作者: Robert C. Martin,角征典出版社/メーカー: アスキー・メディアワークス発売日: 2012/01/27メディア: 大型購入: 12人 クリック: 645回この商品を含むブログ (36件) を見る いかにして問題を解くか 数学を題材に扱いながらも一般的にどのように目の前

    今春まともなエンジニアになりたい人が読む12冊+α - うさぎ組
  • 1