Documentation
-
UMLUnified Modeling Language #Documentation システムの設計を視覚的に表現するための統一的な記法
-
Atlas
-
Markdown#Documentation
-
SCQAフォーマット#Documentation 文書の冒頭に書く要約に用いるフォーマット (S)シチュエーション (C)コンプリケーション (Q)クエスチョン (A)アンサー の4つを用いる
-
受け入れ条件#Agile #Documentation プロダクトバックログアイテムが完成したと判断できる条件
-
MADRMarkdown Architectural Decision Records #Documentation ADRを記述するテンプレートカテゴリの一つ。マークダウンによって構造化された文書を提供する いくつかのテンプレートは以下から参照可能 https://github.com/adr/madr/tree/develop/template About MADR | MADR
-
C4 model#Documentation 以下の4つのダイアグラム図を表すアプローチ Context Diagram Container Diagram Component Diagram Code Diagram 順に抽象度が下がっていく流れになっている https://c4model.com/
-
開発者とアーキテクトのためのコミュニケーションガイド
-
Kubernetes Icons Set#Documentation Kubernetesの各リソース等のアイコンを公開しているリポジトリ 様々なダイアグラムサービスのデータセットに利用されている https://github.com/kubernetes/community/tree/master/icons
-
DevOps capabilities/Documentation quality#Documentation DevOps capabilitiesの1つ、Climate for Learningに分類される https://dora.dev/capabilities/documentation-quality/
-
ユビキタス言語#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語 以下、原著から抽出 モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する
-
Write the Docs#Documentation ドキュメンテーションに関心を持つ人たちを歓迎するコミュニティ https://www.writethedocs.org/
-
実例マッピングExample Mapping #Documentation Agile Testing、BDDで紹介されるプラクティス。Matt Wynneによって考えられた マッピングする付箋の種類には Story Rule Example Question の4種があり、あるStoryにおけるExample(具体例)を軸に、定められるRuleと残論点としてのQuestionをマッピングする
-
ArchiMate#Documentation エンタープライズ・アーキテクチャーを記述するためのグラフィカルなオープンソース言語 https://www.archimatetool.com/
-
ADRArchitectural Decision Records #Documentation アーキテクチャに関する意思決定とその理由を記録する文書。意思決定に際する文脈、根拠、その決定による成果物等を記述する ADRはなぜそのアーキテクチャを選出したかの意思決定を理解するのを助ける。 ADRはチームメンバーの誰もが作成できる。ただしオーナーシップとしてAuthorは明確にする必要がある。初期ステータスは Proposed とする。 次に他チームメンバーによるレビューを行う。修正すべき点がある場合は Proposed のままアクションのアサインを行う。このときアサインはチームメンバーの誰でもよい。ADR自体はRejectする場合はステータスを Rejected にしADRのライフサイクルは終了する。 レビューを経て全てのアクションが完了した場合、ステータスを Accepted にする。一度AcceptされたADRはイミュータブルに扱い変更はしない。 Architectural Decision Records (ADRs) ADR process - AWS Prescriptive Guidance
-
Devin Wiki#Documentation #LLM Devinと連携されたリポジトリの内容を説明するWikiを生成する機能 自動でインデックスされる
-
要件定義#Documentation 「何を作ればよいのか」を明確にするために行う
-
ユーザーストーリーマッピング#Agile #Documentation ユーザーストーリーを洗い出すためのプラクティス 優先度付けや段階的なリリースのスコープ整理を行う Blog / Agile Studio
-
Open API
-
Docs as Code#Documentation Write the Docsコミュニティが提唱するソフトウェア開発と同じツールとワークフローを使用してドキュメントを作成・管理するアプローチ 以下のような特徴がある Gitを使用したバージョン管理 Markdownなどのマークアップ言語を利用 レビュープロセスを経る ドキュメントの品質をチェックする https://www.writethedocs.org/guide/docs-as-code/
-
Redoc#Documentation Open API仕様を元にドキュメンテーションを行いシンプルなUIで表示される CLIによるドキュメント生成またはHTMLファイルへのscript埋込が可能 Redoc
-
Gherkin#Testing #Documentation 以下のフォーマットでテストシナリオを記述する記法 Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters https://cucumber.io/docs/gherkin/reference
-
BDD/定式化Formulation #Testing #BDD #Documentation システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する
-
DeepWiki#LLM #Documentation Devinの一つの機能であるDevin WikiをPublicなリポジトリに絞って利用できるOSS Devin Searchに相当するAsk機能も備えている https://docs.devin.ai/work-with-devin/deepwiki
-
仮説キャンバス
-
Swagger
-
Claude Code/カスタムスラッシュコマンド#LLM #Documentation Claude Codeにおいて、 .claude/commands ディレクトリ内にMarkdownファイルを用意しプロンプトを記述すると再利用が可能になる機能 https://docs.anthropic.com/ja/docs/claude-code/slash-commands#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89