ざっくり理解するSRE - Qiita
昨今では自社のプロダクトやシステムのエンゲージメント向上のために、「DevOps」や「アジャイル」といったキーワードのもと、大小さまざまな企業がシステムやアプリの開発手法の改善を試みています。その中において、最近だと「SRE」というキーワードを聞く頻度も多くなってきたかと思います。 しかしアジャイルやCICDなどと比べ、SREについては「言葉は知ってるけど具体的になんなのかはよくわからない」という方もいるのではないでしょうか？ここではそんな方々向けに、SREの最初の一歩となる概要について、独自の解釈を交えつつまとめていきます。 ここで話すこと SREって何？ なぜSREが必要？ SREってどんなことするの？ ここで話さないこと SREの技術の具体的なところ（k8sやAPMの導入手順、設定方法など） プラクティスの実践例・具体例（アーキテクチャ、各種設定値、モニタリング指標など） TL;DR
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
スクラムを個人戦にしてしまう方法 - 海と山が好き
スクラムではチームの成果にフォーカスする。 そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。 いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。 逆に、チームでバラバラと仕事を進めるわけではない。 イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか（１つに決まっている）、チームはどのボールに向かっているのか（１つに決まっている）を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。 なぜチームで仕事をするのか 5つの機能がスプリントのスコープに入っているとする。 5人でこれらに取り組むとする。 効率を重視したこれまでのやり方で言えば、各自が分担してそれぞれの機能の開発を進める。 この場合、それぞれが進める中で、 レビューが必要になる
「きょん、やっとむ、Ryuzeeらと語るアジャイル開発の本質」参加レポート #densohack - Qakink blog
イベント概要 先日、アジャイルの本質について語るイベントが日本橋で開催された イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」 アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り 会の後半では、参加者を交えたディスカッション（フィッシュボール形式）も行われた イベント詳細はこちら：https://connpass.com/event/96750/ 登壇者 やっとむさん「アジャイルってなにが美味しいの？」 きょんさん「目的論からのアジャイル～手段を目的化すること～」 ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」 感想を一言で言うと タイトル通り、内容が本質すぎて辛かった 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした 「アジャイルってなにが美味しいの？」 by やっとむさん 登壇資料 そもそもア
アジャイルFAQ | ワイクル株式会社
コンサルや研修しているときに聞かれた質疑応答の一覧です。ひとまず2017年にいただいたものをまとめました。 Q. 1人でスクラムを始めたいと思いますができますか？ 「スクラム」はできないですが、スクラムのなかの特定の手法は可能です。たとえば、バックログを作って上から順番にやっていくとか、定期的にふりかえるとか。 Q. 遠隔チームでのスクラムはデジタルツールを使えば可能？ 「最初のうちは同じ場所で、慣れてきたら離れて」が基本 チームの成熟度次第なので、最初からうまくできるチームもあります Q. チームの相乗効果を上げるにはどうすれば？ チームの数だけやり方がある。 チームだけの文化や言語を作っていくことが重要かも。「一緒にご飯を食べる」というのは鉄板です。 『Team Geek』オススメです！！！！！（宣伝） Q. 開発チームがステークホルダーに直接アクセスするのはNG？ あとでPOに情報共
チームの生産性を上げるために新規事業チームがやっていること - Gunosy Tech Blog
こんにちは、新規事業開発室のエンジニアの@__timakin__です。上記は生産性が全く上がっていない様子です。 forkwell_meetupというイベントにところで「チームの生産性を上げる的な話をしてください」というフリをされたので、偉そうな話をして来ました。 forkwell.connpass.com 発表について スライドは以下の通りです。 speakerdeck.com 冒頭の方に実際のSlackのチャンネルやカレンダーの様子を載せましたが、だいぶフランクにやりとりが行われています。 新規事業へもともと興味がある人間が集まると、そこまで強制しなくてもリサーチする流れが生まれますし、逆に言えば採用の段階で新規事業の立ち上げコストというのは決まってくるのだなと思います。 生産性とは 生産性とはなんぞやという話だったのですが、僕個人として言いたいのは「生産総量ではなくて投資効率性ですよ
無料で整える趣味チームの開発環境 - Qiita
趣味チーム？ 趣味チームに所属している方はいらっしゃるでしょうか。 お仕事関係なしに友人たちと趣味で開発するような人たちです。 趣味と言えどもチームですから、チームで使える開発環境を整えたくなります。 「 趣味チームの開発環境を整えたい 」 そう思った時に課題になるのが お金 です。 もちろん投資だと思ってお金を出せればいいのですが、基本線は趣味ですから中々そうもいきません。 ここはひとつ趣味の一環として、 無料縛り という制約を貸した上で、趣味チームの開発環境をどこまで整えられるのかを考えてみたいと思います。 環境イメージ 先にネタばらしをしておくと、以下のような感じに落ち着きました。利用量の制限はありますが 無料 です。 簡単に言うと以下のようなことができます。 メンバ数 制限なし プライベートリポジトリ 作成可 任意のデバイスからのチャット(～1万メッセージ)、ファイル共有(～15G
チーム開発における「ニワトリ」が適切に鳴くために - 病みつきエンジニアブログ
アジャイルやスクラムとかの文脈で「ニワトリ」と「ブタ」という概念がある。 その言葉自体は結構ググれば出てくると思うんだけど、一つ寓話を引用してみる。要は、「ニワトリとブタ」のプロジェクトメンバーが「ハムエッグ」を作る上で、「ブタ」は自分の身を削っているのに対し、「ニワトリ」は身を削っていないですね、ということ。 ニワトリとブタがいた。 ニワトリは「さあ、レストランでもやろうよ」と言った。 ブタはよく考えてから「レストランの名前は何にしようか」と言った。 ニワトリは答えた。「ハム・エッグさ」。 ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」 recompile.net ※ 原典は シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」？ 原義からずれるかもしれないが、自分は「ブタとニワトリ」をこう解釈している。 ブタ・・・開発チームのメンバーであり
チーム開発を始める時に決めること - GeekFactory
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
自分の失敗を完璧にフォローされて涙が出るレベルな件｜NZ MoyaSystem
いま勤めている会社ではアジャイル開発を取り入れており、2週間を1スプリントとして管理しています。 各スプリントの終わりにはチーム内での実績報告とレビューを行います。今日はそのレビューでの話。 超絶無能だった自分 そのスプリントでの自分のパフォーマンスは最悪でした。 とある一見単純なバグ修正を、鼻歌交じりで「ふふ〜ん」とコミットしたら、 「残念！ こっちの機能が壊れてます。やり直し :)」 とリーダーからあっさりコードレビューで却下される始末。コードレビュー前に当然走らせておくべきユニットテストの結果確認を怠っていたので何も言い訳できませんごめんなさい……。 で、またコーディングのやり直しとなるわけですが、やればやるほどユニットテストが壊れていくんですよ……。 あちらを立てればこちらが立たず地獄。もともと様々な条件にうまーく対応するように書かれているデリケートな処理なので、ヘタにいじれない部
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
翻訳：Haskellと過ごした4年間〜ファウンダーの観点から〜 - Qiita
BetterというEラーニングの会社をやっていたCarl Baatzさん表題のような記事を書いていて、とても有益だと思ったので訳してみました。 だいたい逐語訳ですがところどころ意訳したり端折ったりしてます。プロの翻訳家ではないので間違いもあるかと思います。ご了承ください。不安なところは原文をご参照頂ければと。自信ないところは括弧に原文を残しているので、よい訳があれば編集リクエストお願いします。あと脚注も Thank you Carl for sharing great experince and knowledge! 原文: A founder's perspective on 4 years with Haskell http://baatz.io/posts/haskell-in-a-startup/ [追記] InfoQでもこの記事が取り上げられていました。 製品開発においてHask
コードレビューを段階的に行ってもらう話 - $shibayu36->blog;
最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found