「みんなのPython勉強会」では、Pythonを中心としてプログラミングを様々なシーンに生かす方法を一緒に学んでいます。今回は初級、中級のサーバーサイドエンジニア向けに、開発現場のアドバイザーでもある長沢氏がアジャイルとDevOpsについて話しました。後半はアジャイルとDevOpsをどう取り入れればいいかについてです。 従来の開発計画とアジャイルの計画の違いやっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。 従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見積
このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 （品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。） --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル
最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
業界のスペシャリストが語るDevOps 鈴木いっぺい氏（以下、鈴木）：みなさん、おはようございます。DevOpsをテーマとさせていただきたいと思っています。50分の間、ぜひお付き合いのほど、よろしくお願いいたします。 牛尾剛氏（以下、牛尾）：DevOps！ 吉羽龍太郎氏（以下、吉羽）：お約束ですね（笑）。 鈴木：お約束の雄叫びを毎回させていただいています。これはもう今年の5月に行った、マイクロソフトさんの「de:code」のイベントからの恒例とさせていただいております。 というのも、DevOpsというキーワード、みなさんそれぞれいろいろな思い入れがあると思うんですけれども、この言葉が1人歩きする状況というもの、とくに日本において、みなさんDevOpsという言葉をいかに違う定義で取られているかということを、非常に懸念している方々もおりますし、なんと捉えていいか非常に難しい課題だと捉えている方
このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN
DevOpsはエンタープライズのスタートアップへの憧れ と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ？そもそもあってるっけと思いFacebookストーキングしたら違ってた。 "DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。 自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下（Dev部門、Ops部門、ビジネス部門、...and so on）においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近
実践事例や有識者へのインタビューを通じて国内のDevOpsトレンドを俯瞰してきた本特集。今回はSIer、ITアーキテクトの観点からDevOpsのあるべき姿を探る。 DevOpsは理想論？ スローガン？ それともただのバズワード？ 2013年、「DevOps」という言葉の認知度は大幅に向上した。市場環境変化が速い現在、ビジネスニーズの変化をITサービスに反映させるためには、開発・運用のスピードが大きなカギを握る。その点、「開発部門と運用部門が連携してITサービスのリリースサイクルを加速させる」というDevOpsの基本概念は非常に合理的であり、大方にとって理解しやすいものだ。 ただ、この言葉を半ばバズワードとして受け止める向きも少なくない。確かに「開発と運用が連携する」という概念は、納得しやすく理想的なものではある。だが実際には、多くの企業において「開発を外部に委託している」「ガバナンスやセキ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く