タグ

ブックマーク / www.ryuzee.com (15)

  • 【資料公開】マネジメント向けアジャイル開発概要

    みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし

    【資料公開】マネジメント向けアジャイル開発概要
  • 【資料公開】レガシーコードからの脱却

    みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品?だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に

    【資料公開】レガシーコードからの脱却
    jazzanova
    jazzanova 2019/10/05
  • 【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

    著者/訳者:David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士出版社:オライリージャパン発売日:2019-09-18単行(ソフトカバー):300ページISBN-13:9784873118864ASIN:4873118867 書は、David Scott Bernstein氏の『Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software』の全訳です。 著者のDavidはMicrosoftやIBMを含むさまざまな企業での開発経験をバックグラウンドに持つ、特にアジャイル開発における開発者向けの教育に情熱を注いでいる独立のトレーナー/コンサルタントです。 日にも、2019年のDevOpsDays Tokyoでの基調講演やScrum Allianc

    【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 【書籍紹介】Fifty Quick Ideas To Improve Your User Stories

    出版社: Neuri Consulting LLP (2014/10/12)Gojko Adzic、David Evans(著)価格: 1,191円(Kindle版)言語: 英語ASIN: B00OGT2U7M詳細を見る スクラムでプロダクトバックログアイテムを用意する際に、具体的にどのような書き方をするのかは特に決められていません。 「◯◯機能」といった書き方をすることもあれば、「プレミアム会員としてホテルの部屋を予約できる」のような書き方をすることもあります。 また、解決したい課題、期限、プラットフォーム、成功失敗の判断のためのKPI、リリース希望タイミング、リファレンス情報、関係者などを含めているような会社もあるようです。 いずれにせよ、仕様書ではなく、あくまで会話のための道具なので、ステークホルダーとの間やスクラムチーム内で、共通理解や合意が形成できるのであれば、どんな形でも構いま

    【書籍紹介】Fifty Quick Ideas To Improve Your User Stories
  • プロダクトオーナーのアンチパターン

    みなさんこんにちは。@ryuzeeです。 スクラムにおいてプロダクトオーナーは非常に重要な役割を果たしますが、一方でうまくやるのが難しい役割でもあります。 たとえばプロダクトオーナーには、ビジネス価値を最大化する、プロダクトのビジョンを周りに示して理解させる、プロダクトバックログを管理する、ステークホルダーをマネージする、開発チームの成果物の受け入れ可否を判定するといった多岐に渡る責任があり、限られた時間の中でバランスを取りながらやっていかなければいけません。 今回は、こういうのは避けようというアンチパターンを紹介します。 そもそも…多忙すぎるプロダクトオーナー不在のプロダクトオーナースクラムイベントに参加しないプロダクトオーナー単にマネージャーやリーダーという理由だけのプロダクトオーナーそもそも複数人で意思決定権限が分散されたプロダクトオーナープロダクトオーナーとスクラムマスターを兼任す

    プロダクトオーナーのアンチパターン
    jazzanova
    jazzanova 2018/03/13
  • スクラムガイド2017での変更点の紹介

    みなさんこんにちは。@ryuzeeです。 2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。 なお、スクラムガイド自体はこちらからダウンロード可能です。日語訳はさまざまな書籍の翻訳で有名な角征典さんです。以下の紹介に際して、スクラムガイド日語版の記述を引用しています。 実践に際して、大きな影響はあまりないと思いますが、とくに以下の2点が注目だと思います。 デイリースクラムで3つの質問を使うかどうかはチーム次第となった。大事なのはスプリントゴールが完成しそうかどうかを毎日検査して適応することレトロスペクティブ(ふりかえり)で出た項目を、次のスプリントのスプリントバックログに含めること以下、詳細です。 更新内容 スクラムの用途についてスクラムマスターの役割の定義を洗練させたデイリースクラムはス

    スクラムガイド2017での変更点の紹介
  • スクラムで開発チームが自由な取り組みをするには?

    みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します(ダメなものも混ざっています) 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する(✕)スプリントとスプリントの間に休憩を入れる(✕)フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する(△)スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする(◎)それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分

    スクラムで開発チームが自由な取り組みをするには?
  • 【資料公開】Chef ベーシックトレーニング

    みなさんこんにちは。@ryuzeeです。 これから新たにChefを学ぶ人向けに非常に基的なトレーニングの資料を作ったので公開します。 資料の構成は以下のとおりです。 まずDevOpsの文脈から自動化が必要な背景を説明Infrastructure as Codeについての利点を説明ChefのアーキテクチャChefの用語解説Vagrantで仮想マシンを2台使った一番単純なハンズオン(boxも用意済み)Serverspecを使ったCookbookのテストの書き方(VirtualBoxの仮想マシンの中でDockerを使っています)その他なお、2-3時間でさくっと触りながら全体像を掴むことを目的にしているので、網羅性はありません。 ハンズオン用のVagrantのboxには、あらかじめ、Chef DK(Development Kit)、Dockerなどが含まれており、すぐに触れると思います(ただしb

    【資料公開】Chef ベーシックトレーニング
  • デイリースクラムのTIPS (2016年版)

    みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、スプリントゴールの進捗を検査し、今後の作業計画を必要に応じて見直す(適応する)ことで、スプリントゴール達成の可能性を最適化することです。 毎日の検査と適応(高速なフィードバックループ)によって問題を早期に発見することでリスクを減

    デイリースクラムのTIPS (2016年版)
  • Docker + Capistrano3で簡単にWebアプリをデプロイする

    こんにちは。@ryuzeeです。 アプリケーションのデプロイを楽にするためにDockerを使いたいけど、別にクラスタは必要ない規模だったりクラスタの管理もしたくないという人は多いのではないかと思います。 そこで、今回は、DockerとCapistrano3を組み合わせて単にデプロイを楽にする方法を紹介します。 構成図まず今回の構成図はこんな感じです。AWS上での構成例になっていますが別にどの環境でもあまり関係ない普通のWebアプリケーションを想定してください。 実現したい要件次に実現する要件です。特に変わったことはありません。 いつも同じ方式でデプロイするダウンタイムなしでデプロイするデプロイに失敗したら簡単にロールバックできるようにするサーバが増えてもデプロイの方式は変えなくて済むようにするサーバを再起動してもサービスは自動で復旧する方式では方式を見ていきましょう。 Webアプリケーショ

    Docker + Capistrano3で簡単にWebアプリをデプロイする
  • プロジェクトが失敗する10の兆候

    今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

    プロジェクトが失敗する10の兆候
    jazzanova
    jazzanova 2016/01/06
  • Chefのレシピをサクサク書けるVim用スニペット

    タイトルのまま。僕はレシピの作成をVimを使ってやっているのですが、毎回似たようなコードを手打ちしていくのは頭おかしくなりそうなので、スニペット化していました。なんか需要がありそうなので公開しておきます。 コードはGitHubのryuzee/neosnippet_chef_recipe_snippetにおいてあります。 インストール方法大前提としてVimのNeoSnippetプラグインが必要ですので、適宜インストールしてください。 スニペットのインストールは、Bundleを使っている場合、.vimrcなどにBundleの追加とスニペットのパスの追加を行ってください(コードは折り返されているので注意)。 Bundle 'ryuzee/neocomplcache_php_selenium_snippet' let g:neosnippet#snippets_directory='~/.vim/

    Chefのレシピをサクサク書けるVim用スニペット
  • Sensuを使って自由度の高い監視システムの構築を行う方法

    SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります(公式サイトの記述を整理) シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象)を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens

    Sensuを使って自由度の高い監視システムの構築を行う方法
  • Chef ServerとCapistrano3を組み合わせて自動でデプロイ対象サーバを決める方法

    タイトルが長い… 例えばAWS上でAuto Scalingを使っていたり、Disposableなインフラを構築していると、アプリケーションのデプロイ先のIPアドレスやFQDNはなかなか固定できません。 このような状況下でCapistranoを使ってデプロイする場合、毎回デプロイ先のホストの情報を取得して、自分で設定ファイルを書き換えるとかまじありえねー、な感じです。 ここでは簡単にデプロイ先サーバの情報を自動で取得する方法を紹介します。 なぜChef Server経由でアプリケーションをデプロイしないかアプリケーションのデプロイもChef Server経由でやればいいじゃん?という声も良く聞きますが、個人的にはこれはやらない方が良いと思っています。 Chefはあくまでインフラやミドルウェアをしかるべき状態に収束させるために作られており、アプリケーションのデプロイ用には作られていません。もち

    Chef ServerとCapistrano3を組み合わせて自動でデプロイ対象サーバを決める方法
  • SensuのCommunity Pluginの一覧(日本語版)

    全国1億2000万人の監視マニアのみなさん、こんにちは。 Sensuは、非常にシンプルなアーキテクチャーで、さまざまなカスタムスクリプトを使っていろいろな監視を行ったり、メトリクスデータを取得することができます。メトリクスデータはさらにGraphiteなんかに送信してあげれば、どんどんグラフ化できます。このあたりの話が前提になっていますので、Sensuってなにそれ?な方は先に「Sensuを使って自由度の高い監視システムの構築を行う方法」をご覧ください。 チェックスクリプトを書くのは非常に簡単ですが、SensuではCommunity Pluginという形で非常にたくさんのプラグインが既に公開されていますので、今日はそれを紹介します。 Community Pluginの入手なにも考えず、git clone https://github.com/sensu/sensu-community-plu

    SensuのCommunity Pluginの一覧(日本語版)
  • 1