スプリント1を始める前にどんな準備をするか
みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい
ふりかえりをうまくやるコツ
チームはスプリントの間ベストを尽くしたと信じよう最初にファクトデータを集めよう議論するのではなくて、ファシリテーションのテクニックを使ってファクトデータを集めようまずは良い雰囲気を作ろうふりかえりの内容を承認しようこの先改善するためにできることを見つけるためのブレストのセッションを設けよう未来に焦点を当てよう。チームが改善すべき問題とスクラムマスターが改善すべき問題を分離しよう 大事なのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し（すぎ）ないことです。 チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがあります。 アジャイルの基本理念の1つに「オープンであること」がありますが、それがなくなると、チームとしての力が結集できなくなります。 またふりかえりのファシリテーター役は、チームを非難しないことも大事です。 スクラムマス
マイクロサービスに関する資料のまとめ
世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2014年5月に公開Martin Fowlerのブログは翻訳が可能で、日本語訳を公開してくれている人がいる。こちら単純に言えば、「マイクロサービスとは単一のアプリケーショ
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
2015年のふりかえり
大晦日に寿司をたらふくたべているみなさんこんにちは。我が家も寿司です。 いよいよ2015年も最後の日ですので今年1年を整理しておきます。 トピック 10月末でAWSを退職して、現在絶賛サバティカル中 [PR] 2016年1月と2月にスポットで支援できると思うのでお気軽にお声がけください(すいませんが長期のコミットはまだできませんのでご了承ください)。なおご支援の例としては以下のとおりです。 スクラムやアジャイル、DevOpsに関する集合トレーニングの実施(このような資料を使います) スクラムやアジャイル、DevOpsに取り組んでいる現場でのオンサイトコーチング 改善を必要としている現場での問題の整理や改善の流れの立案 クラウド導入に関するアーキテクティングや標準化の支援 社内勉強会や相談会の実施 その他チームビルディング・採用・評価などに関するコンサルティング ブログ 2年半前に会社が変わ
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
スローテストを解消する12の方法
みなさんこんにちは。@ryuzeeです。 システム開発において一番コストが高いものは人的リソースであることがほとんどです。 したがって開発者の時間効率をあげるためにできることは色々と取り組む必要があります。 例えば個人の開発マシンが遅くてビルドやテストに時間がかかるとかもっての他です。 一日10回ビルドして一回のビルドに5分かかるとします。 これを高性能なマシンに変えたら2分になったとすると、(5-2)1020=10時間。 時間単価5000円として一ヶ月あたり合計50000円の節約になります。 同じことがCIやテスト自動化にも言えます。 CIサーバのハードウェアを高性能なものに変更する会社のあまったPCを使ったりして遅いテストを待つのはバカバカしいの一言だ。 CIサーバを複数台で構成する上の話と同じような話。Jenkinsは複数台構成を取ることができるし、多分他のCIも同様だ。 CIサーバ
PHPの外部ライブラリの管理にComposerを使う | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 ComposerはRubyでいうところのBundlerのようなもので、アプリケーションが必要とする外部ライブラリを、そのアプリケーション固有の状態で一元的に管理してくれるツールです。 PHPではPearのようなコマンドを使ってライブラリをインストールすることが一般的ですが、アプリケーションによって必要とするバージョンが違う、といったケースでは問題が起こりやすくなります。 例えば手動でインストールをしていた場合、将来的にライブラリの配布が終わってしまったり、特定のバージョンが配布されなくなると困ってしまいます（したがって、インストールしたバージョンは構成管理の対象とするべきで、常に環境を再現可能にしなければいけません）。 Composerを使うことで、そのような問題からは簡単に解放されます。 なお、ComposerはPHP5.3.2以降で利用可能です
速報 Packerでさまざまな仮想マシンのテンプレートを作成する
続報で、VagrantのBoxの作り方について書きました。こちら Vagrantの作者であるHashimotoさんが新たにPackerというツールをリリースした(昨晩！)ので速攻ご紹介。 このツールは、Amazon EC2のAMIやVirtualBoxやVMware用のOSのイメージを一貫性のあるインターフェイスで簡単に作ってくれるものです！たとえばVagrantの場合は以前はPatrickさんが作成したVeeweeを使うことが定番だったのですが、今後はそれに変わるものになってくるかもしれません。 (現時点はまだバージョン0.1なのでこれからどんどん良くなると思います！) インストールhttp://www.packer.io/downloads.html からビルド済みのファイルを入手します。もしくは自分でビルドすることも可能です(ビルドにはgoなどのツールが必要です)。 ファイルはzip
続報 PackerでVagrant用のBoxを作成する
Packerってなに？という人は前回のエントリを先にどうぞ 0.10と0.11だと作成されたVagrantのboxの中のディスクイメージの命名の問題があります(詳細はこちら)。ソースを持ってきてビルドしたPackerを使えばとりあえず問題ありません。→0.12で修正されました！ 前のエントリで紹介したPackerですが、Vagrantのboxの作り方が把握できたので紹介しておきます。 今回はUbuntuのboxの作成を例にして解説します。 なお、CentOSの例は以下に置いておきました。 まずは設定ファイルです。前の記事で紹介したものより長くなっています。 { "builders":[{ "type": "virtualbox", "guest_os_type": "Ubuntu_64", "iso_url": "http://releases.ubuntu.com/12.04/ubunt
スクラムで陥りがちな罠24個
みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下にあがっているような症状があるのであれば、もう一度原理原則に立ち返って考えなおしてみるべきでしょう。 過剰な準備や計画作成：スクラムにおいては定常的な大きな前払いの計画作成は必要で
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
Jenkinsでビルド・パイプラインを作る
Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 ＃12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの１つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。（
CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
【資料公開】CakePHP+Jenkinsによるアジャイル開発
みなさんこんにちは。@ryuzeeです。 2012年11月3日,4日の二日間にかけて行われたPHPMatsuri 2012で、登壇させていただきました。 その際の資料を公開しておきます。 内容は過去にやったワンクリックデプロイ勉強会の内容にCakePHPっぽい内容を追加した感じです。 大分前からこのあたりの話はしているのですが、まだまだデファクトスタンダードでどこの会社でもやっているという状況にはほど遠く、ようやく各社取り組み始めたところ、という感じな気がします（もちろん大分状況は変わってきた） 参加者の方に聞いたところ、環境構築含め自動化されているのは2名くらいでした。 せっかくフレームワークを使い倒して高速に開発できるようになっても、もっと他に高速化すべき箇所もあるし、そもそもその速度を継続できないと意味がない、いまそのあたりができていないならできるところから着実に改善していくといいん
VagrantとAmazon EC2でVagrantファイルを共用する
みなさんこんにちは。@ryuzeeです。 誰も興味なさそうなVagrantシリーズの第四弾。 さて昨日まではVagrantとChef Soloを組み合わせるパターンについて説明を行ったわけだが、せっかくローカルの環境構築を自動化できたので、これらの設定ファイルを利用してAmazon EC2上にも同じように環境を構築できるようにしよう。結構手順は長いが既にAmazon EC2を使っている人は色々飛ばせる手順がある。 なお今回の話は母艦がMacOS XもしくはLinux系OSで、かつ作成するインスタンスがUbuntuの場合のみ適用可能だ。インスタンスが他のLinux系OSの場合はbootstrapを書き換える必要がある。 EC2 API Toolsの設定EC2 APIのダウンロードEC2 API ToolsはAmazon EC2をコマンドラインから操作できる便利ツールだ。 2011/11/9時
Vagrantで簡単仮想マシン構築
VagrantはOracle VirtualBoxを利用した仮想マシンをコマンドラインから作成してくれるソフトウェアだ。 設定ファイルをRubyで書くことができ、Chef等とも連携できるので、開発環境をコマンドライン一発で作成することができる。更にはCapistranoと組み合わせてアプリケーションのデプロイも一括で行うことで完全自動でいつでもテスト環境をつくれたりもする。 仮想マシンを捨ててしまってもいつでも再構築できること、誰のところにでもすぐ同じ状態に展開できることは開発を進める上で非常にメリットがある。 以下ではまずはVagrantを利用した簡単な仮想マシン構築の手順を説明する（本当に説明したい内容はもっと違う話なのだが追って別のエントリで書いていくことにする） Oracle VirtualBoxのインストールhttps://www.virtualbox.org/にアクセスし左ナビ
VagrantとChef Soloを組み合わせて環境構築を自動化する
みなさんこんにちは。@ryuzeeです。 前回まではVagrantを使ってVirtualBoxの仮想インスタンスを簡単の構築するところまで説明した。 ただそれだけだったら予め作成しておいたイメージをコピーするのとたいして変わりがないので、あまり有難味を感じないかもしれないが、ここからが本番だ。 Vagrantの特徴として、PuppetやChefやChef Soloと組み合わせてインフラ部分の設定を仮想インスタンスの生成時に行うことができる。 流れとしては以下のようになる。 この原理上、仮想インスタンス側にVirtualBoxのバージョンと適合したVirtualBox Additionsがインストールされている必要がある。(ネット上から落としたboxの場合にはこれが古い可能性がある) 実際にためしてみよう今回はCentOS5を利用してDNSを設定するところを自動化する。 事前準備Vagran
[Agile]インセプションデッキ日本語版 | Ryuzee.com
インセプションデッキって何？って人はThe Agile Samuraiを読むと良い。 The Agile Samuraiの日本語版は@kakutaniさんや@nawotoさんが頑張ってらっしゃるので、期待して待っていよう。 簡単にいうと、インセプションデッキは10個の質問から構成されていて、プロジェクトを始めるにあたって、その質問に答えることによって、プロジェクトの全体像やこれからの方向性等を明らかにしてくれるツールだ。(逆に答えられないとするとその時点で結構ヤバイということでもある)。そしてプロジェクト期間中は見えるところに貼っておき、何か変更があれば随時更新していく。 詳細は本の著者であるジョナサンのサイトのThe Agile Inception Deckを見て欲しい。 公開されているインセプションデッキのテンプレートを日本語化してみた。 以下からダウンロードできる。ライセンスはC
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
