タグ

ブックマーク / www.atlassian.com (5)

  • 2022年4月に発生したアトラシアンのサービス停止に関するインシデント事後レビュー | Atlassian Japan 公式ブログ | アトラシアン株式会社

    ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。また、PDF版をダウンロードいただけます。 はじめに – 共同創業者兼共同最高経営責任者より 2022年4月上旬に発生した障害により、お客様へのサービス提供が中断されたことをお詫び申し上げます。私たちは、当社の製品がお客様のビジネスにとってミッションクリティカルであることを理解しており、その責任を重く受け止めています。今回の全責任は私たちにあり、影響を受けたお客様の信頼を回復するために尽力しています。 アトラシアンのコア バリューの 1 つに「オープンな企業文化、デタラメは無し (Open company, no bullshit)」というものがあります。この価値を実現する取り組みの一環として、インシデントについてオープンに議論し、学びにつなげています。そして、このインデント事後レビュ

    2022年4月に発生したアトラシアンのサービス停止に関するインシデント事後レビュー | Atlassian Japan 公式ブログ | アトラシアン株式会社
  • アジャイル要件ドキュメント: 製品ブループリント | Atlassian

    要約: 製品要件ドキュメント (PRD) とは、製品の目的、機能とその実用性、動作を含む特定の製品の要件を定義付ける文書です。ビジネスチームおよび技術チームが製品の開発、立ち上げ、マーケティングを行う場合のガイドとして利用可能です。 優れた製品を開発するためには、研究の積み重ねと包括的な計画が必要です。ただ、どこから始めたら良いでしょうか?プロダクト・マネージャーは PRD(製品要件ドキュメント)から始めることが多いようです。

    terkel
    terkel 2020/12/20
  • Improve Transparency with Statuspage | Atlassian

    Eliminate duplicate support tickets & clunky email lists Halt the flood of support requests during an incident with proactive customer communication. Manage subscribers directly in Statuspage and send consistent messages through the channels of your choice (email, text message, in-app message, etc.) Display the status of each part of your service Control which components of your service you show o

    Improve Transparency with Statuspage | Atlassian
    terkel
    terkel 2020/12/17
  • 製品ロードマップ ガイド: その概要とその作成方法 | Atlassian

    要約: 製品ロードマップとは、製品やソリューションを時間の経過とともにどのように進化させるかを決める活動計画のことです。製品所有者はロードマップを使って今後の製品機能や新機能のリリース時期を計画します。アジャイル開発の場合は、製品計画ロードマップを使ってチームにおける日々の作業の意味を伝えます。また、競合他社の状況の変化にも素早く対応できるようにしておきます。 プロダクトロードマップは、短期的な取り組みが長期的なビジネスの目標と一致しているかどうかを確認するうえで重要になります。チームの全員が同じ方向に進むためには、ロードマップの役割や優れたロードマップを作成する方法を理解することが大切です。

  • Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社

    質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか?これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか?それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか?( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vimEmacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git

    Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
    terkel
    terkel 2013/11/26
  • 1