アジャイルメトリクス実践ガイド
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
2015 年 1 月 30 日に Viling Venture Partners で行ったグロースハックに関する講演資料です。 『君にグロースハックはいらない』というタイトルは別にグロースハックを dis っているわけではなく、いずれ必要になる方法がまとまっていると思います。ただ 74% のスタートアップの死因が premature-scaling という報告もあるように、あまり初期においてスタートアップが (細かなテクニックなどを中心に膾炙してしまっている) グロースハックの手法に力を入れてスケールしてしまうと、意味がないどころか自分の首を絞めるだけなのでは、という考え方を中心にまとめています。
あの日見たサービスの名前を僕達はまだ知らない
デブサミ2014での発表時背景画像。 http://event.shoeisha.jp/devsumi/20140213/
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件を捨てて検証に出よう。賃貸情報サイト"カリル"での 仮説検証型システム開発 | Livesense Inc.
