Web 開発者向けに効果的なワークフローを組織します: Confluence、Airtable、その他のツール

私は約 XNUMX 年間フロントエンド開発者として働いており、さまざまなプロジェクトの作成に参加してきました。 私が学んだ教訓の XNUMX つは、同じ目標を共有しながらも異なるタスクと責任を負う異なる開発者チーム間のコラボレーションは簡単ではないということです。

他のチームメンバー、デザイナー、開発者と相談して、小規模チーム (5 ～ 15 人) 向けに設計された Web サイト作成サイクルを作成しました。 これには、Confluence、Jira、Airtable、Abstract などのツールが含まれます。 この記事では、ワークフローを整理するための機能を共有します。

スキルボックスは次のことを推奨します。 XNUMX年間の実践コース 「私はプロのウェブ開発者です」.

リマインダー： 「Habr」のすべての読者が対象 - 「Habr」プロモーション コードを使用してスキルボックス コースに登録すると 10 ルーブルの割引。

なぜこれだけが必要なのでしょうか?

Web サイトをゼロから作成するために必要な最小限のチームは、デザイナー、プログラマー、プロジェクト マネージャーです。 私の場合はチームが結成されました。 しかし、いくつかのサイトをリリースした後、何かが間違っていると感じました。 場合によっては、私たちが自分たちの責任を十分に理解していなかったり、クライアントとのコミュニケーションに不十分な点が多く残っていたりすることもありました。 これらすべてがプロセスを遅らせ、全員に迷惑をかけました。

私は問題の解決に取り組み始めました。

Google 検索すると、私たちの問題に関して良い結果が得られます。

作業をより視覚的にするために、ここでの作業がどのように行われるかを理解できるワークフロー図を作成しました。

画像をクリックするとフル解像度で開きます。

目標と目標

私がテストしようと決めた最初のテクニックの XNUMX つは、「カスケード モデル」 (ウォーターフォール) でした。 問題を強調し、その解決方法を理解するために使用しました。

問題: ほとんどの場合、クライアントは開発者とは異なり、Web サイト作成プロセスをモジュール形式で評価しません。 彼はそれを通常のサイトとして認識しており、つまり、個々のページの観点から考えています。 彼の意見では、デザイナーとプログラマーは個別のページを次々と作成します。 その結果、顧客は実際のプロセスで何が続くのかを理解できません。

タスク: そうでなければクライアントを説得しても意味がありません。最良の選択肢は、ページごとのモデルに基づいて社内で Web サイトを作成するためのモジュール式プロセスを開発することです。

ユニバーサル デザインのトークンとコンポーネントは、開発者とデザイナーの両方によって管理されます。

問題: これは、多くの戦略が対処する一般的な状況です。 興味深い解決策は数​​多くありますが、ほとんどの場合、スタイル ガイド/ライブラリ ジェネレーターによって制御されるデザイン システムを作成することが提案されています。 しかし、私たちの状況では、設計者のアクセス レベルを管理できるようにする別のコンポーネントを開発プロセスに追加することはまったく不可能でした。

タスク: デザイナー、開発者、マネージャーが互いに干渉することなく同期して作業できるユニバーサル システムを構築する。

正確な開発追跡

問題: 問題を追跡し、全体的な進捗状況を測定するために利用できる便利なツールは数多くありますが、そのほとんどは柔軟性がなく、最適ではありません。 このツールは、通常は特定のタスクに関する質問や説明に費やされるチームの時間を節約することで役立ちます。 また、プロジェクト全体をより正確に理解できるようになるため、マネージャーの作業も楽になります。

タスク: ダッシュボードを作成して、さまざまなチームメンバーが実行するタスクの進行状況を追跡します。

ツールのセット

さまざまなツールを試した結果、Confluence、Jira、Airtable、Abstract のセットに落ち着きました。 以下にそれぞれのメリットを紹介します。

合流

ツールの役割: 情報およびリソース センター。

Confluence のワークスペースはセットアップが比較的簡単で、多くの機能があり、さまざまなアプリと統合されており、個別にカスタマイズ可能なテンプレートがあります。 これは万能のソリューションではありませんが、情報およびリソース センターとしては理想的です。 これは、プロジェクトに関連する参照または技術的な詳細をデータベースに入力する必要があることを意味します。

このツールを使用すると、各コンポーネントとプロジェクトに関するその他の詳細を適切に文書化できます。

Confluence の主な利点は、ドキュメント テンプレートのカスタマイズです。 さらに、仕様およびさまざまなプロジェクト文書の単一リポジトリを実装するために使用でき、参加者のアクセス レベルを分離できます。 電子メールでドキュメントを送信するときに発生するような、古いバージョンの仕様書が手元にあることを心配する必要はなくなりました。

ツールに関する詳細情報 公式製品ウェブサイトで入手可能.

JIRA

ツールの役割: 問題の監視とタスク管理。

Jira は、非常に強力なプロジェクトの計画および管理ツールです。 機能の主な部分は、カスタマイズ可能なワークフローの作成です。 問題を効果的に管理するには (これが必要です)、リクエスト タイプと問題タイプ (課題タイプ) の正しい使用に特別な注意を払う価値があります。

したがって、開発者が正しい設計に基づいてコンポーネントを構築していることを確認するには、設計で何かが変更されるたびに開発者に通知する必要があります。 コンポーネントが更新されたらすぐに、設計者は問題をオープンし、責任のある開発者を割り当て、正しい問題タイプを割り当てる必要があります。

Jira を使用すると、プロセスの完全にすべての参加者 (ここでの参加者は 5 ～ 15 人であることを思い出してください) が、迷子にならずに正しいタスクを受け取り、実行者を見つけることができます。

Jira について詳しく知る 公式製品ウェブサイトで入手可能.

Airtable

ツールの役割: コンポーネント管理と進行状況ボード。

Airtable はスプレッドシートとデータベースを組み合わせたものです。 これらすべてにより、上で説明したすべてのツールの操作をカスタマイズすることが可能になります。

例 1: コンポーネント管理

スタイル ガイド ジェネレーターに関しては、必ずしも使いやすいとは限りません。問題は、デザイナーが編集できないことです。 さらに、Sketch コンポーネント ライブラリには多くの制限があるため、それを使用するのは良い決断とは言えません。 おそらく、プログラムの外ではこのライブラリを使用することはできません。

Airtable も完璧ではありませんが、他の多くの同様のソリューションよりも優れています。 以下は、コンポーネント管理テーブル テンプレートのデモです。

開発者は設計コンポーネントを受け入れると、そのコンポーネントを表に記録することによって、結果として得られる ABEM を評価します。 合計 9 つの列があります。

• 名前 - ABEM 原則に従ったコンポーネントの名前。
• プレビュー - 別のソースからダウンロードされたコンポーネントのスクリーンショットまたは画像が配置される場所です。
• リンクされたページは、コンポーネントのページへのリンクです。
• 子コンポーネント - 子コンポーネントへのリンク。
• 修飾子 - スタイル オプションの存在を確認し、それらを定義します (たとえば、アクティブ、赤など)。
• コンポーネント カテゴリは、一般的なカテゴリ (テキスト、プロモーション画像、サイドバー) です。
• 開発ステータス - 実際の開発の進捗状況とその定義 (完了、進行中など)。
• 責任者 - このコンポーネントの責任を負う開発者。
• アトミック レベルは、このコンポーネントのアトミック カテゴリです (アトミック デザインの概念に従って)。
• データは同じテーブル内または異なるテーブル内で参照できます。 点を接続すると、拡大縮小時の混乱を防ぐことができます。 さらに、データは問題なくフィルタリング、並べ替え、変更できます。

例 2: ページ開発の進捗状況

ページ開発の進捗状況を評価するには、この目的のために特別に作成されたテンプレートが必要です。 このテーブルは、チーム自体とクライアントの両方のニーズに応えることができます。

ページに関するあらゆる情報をここでマークできます。 これは期限、InVision プロトタイプへのリンク、宛先、子コンポーネントです。 設計の文書化と更新、およびフロントエンドとバックエンドの開発ステータスの両方に関して、この操作の実行が非常に便利であることがすぐにわかります。 また、これらの動作は同時に行われます。

抽象

ツールの役割: 設計資産のバージョン管理の単一ソース。

Abstract は Sketch のアセットの GitHub と呼ぶことができ、デザイナーはファイルをコピーして貼り付ける必要がなくなります。 このツールの主な利点は、「信頼できる唯一の情報源」として機能する設計リポジトリを提供することです。 デザイナーは、master ブランチを承認されたレイアウトの最新バージョンに更新する必要があります。 その後、開発者に通知する必要があります。 これらは、メイン ブランチのデザイナー アセットでのみ動作する必要があります。

結論として

新しい開発プロセスと上記のすべてのツールを実装した後、作業速度は少なくとも XNUMX 倍向上しました。 完璧な解決策ではありませんが、非常に良い解決策です。 確かに、それが機能するためには、多大な労力を費やす必要があります。すべてを更新し、正常に動作する状態に維持するには、「手動作業」が必要です。

スキルボックスは次のことを推奨します。

• 実践コース 「モバイルデベロッパーPRO」.
• オンラインコース 「C#開発者」.
• 実践一年コース 「0からPROまでのPHP開発者」.

出所： habr.com