新刊『エンジニアリングマネージャーのしごと』発売のお知らせ
みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2022年8月26日に、新刊『エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法』が発売になります。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法著者／訳者：James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙出版社：オライリージャパン発売日：2022-08-26単行本（ソフトカバー）：376ページISBN-13：9784873119946ASIN：4873119944 原著はDr. James Stanier氏の『Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Need
スクラムで削除された5つのトピック
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムのフレームワークの中身はスクラムガイドで定義されていますが、登場以来ずっと同じ内容なわけではなく、何度か改定が行われています（2010年版、2011年版、2013年版、2016年版、2017年版）。過去の改定内容はこちらに記載されています。 過去の変遷においてよく議論になる5つの項目についてWillem-Jan Ageling氏が5 controversial topics that were removed from Scrumという記事にまとめています。 御本人から快諾いただきましたので和訳にて紹介します。 スクラム再発見の時間です。 5年かそれ以上前にスクラムを適用した
こんなスクラムには気をつけろ!?
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで
DevOpsに関する12のアンチパターン
みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います！ えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
ChefのCookbookのベストプラクティス
OpsCode社のシニアコンサルタントであるJulianさんがChefConf2013で話された内容が参考になるので、簡単に紹介します。 スライドはこちらに公開されています。 また動画はこちらです。 ここで出てこない話として僕がやるべきだと思うことは「テストを書くこと」です。 test-kitchenとserverspecの組み合わせがおすすめです。 ばかでかいレポジトリをつくらないいろいろなものをまぜこぜにしない たくさんのレポジトリに分割するのを怖がらない (opscodeも昨年opscode/cookbooksの巨大構成から、opscode-cookbooks/個別cookbookに構成を変えています) 個々のCookbookの連携はBerkshelf使えば大丈夫 全員が共用するような会社用Cookbookをつくらない関係ないプロジェクトのものが含まれると見通しが悪くなる 大きすぎる
Rubyで簡単にIEを操作する3つの方法
みなさんこんにちは。@ryuzeeです。 IEに関するテストを自動化したくて色々調べ中なので記録として公開しておきます。 確認している環境はWindows7 Professional 32bit版＋IE9。RubyはRubyInstallerを利用しています。 watirを使う方法watirはブラウザ操作のライブラリで、webdriverが出てくる前から存在しています。 過去から仕様が結構変わっており、現在では外部のライブラリ（win32screenshot）などを使わないとキャプチャが取れません。 さらに、win32screenshotは現時点では表示されている領域のみしか画像として保存できないので、検証目的で利用するには若干不十分と言えます。 ただ画面の要素の指定の仕方はwebdriverよりも楽です。 #-*- encoding: utf-8 -*- require 'rubygem
継続的インテグレーションアンチパターン
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCI
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カンバンのキホン