WordPress が成長した今、プロのワークフローを導入する
初めて WordPress ブログを立ち上げたときのことを覚えています。オンラインのガイドに従って WordPress をダウンロードし、再度アップロードして、データベースのセットアップ方法を理解するのに何時間も費やしました。
すべての変更をライブサーバーに直接 FTP 送信し、疑問符を打ち間違えてもブログが暗転しないことを祈りました。
その間、WordPress は成長してきました。大手メディア企業は、世界とのコミュニケーションの主な手段として WordPress を使用しています。 Tech Crunch または The New Yorker にアクセスして、ソース HTML を表示します。このウェブサイトは WordPress を使用して構築されていることがわかります。ビヨンセ?うん。彼女はWordPressに興味があります。
同時に、WordPress は開発者の間でひどい評判になっています。ステレオタイプは、スクリプトキディが FTP 経由でファイルをアップロードし、バージョン管理を使用せず、人類に知られているソフトウェア開発の健全な原則をすべて放棄するというものです。
明らかに、それは公正な非難ではありません。 WordPressは成長しました。今年は本格的な REST API が導入されます。 WP-CLI を使用してコマンドラインから WordPress と依存関係をインストールできるようになりました。
WordPress 開発者とテーマデザイナーは成長しています。 Roots.io は、WordPress プロジェクトを本格的なソフトウェア開発プロジェクトと同様に扱う例です。ドラッグアンドドロップによる FTP アップロードをいじることはありません。代わりに、バージョン管理には git を使用し、デプロイメントには capistrano を使用します。
Fog Creek Software の Joel は、ソフトウェアをより良くするための 12 のステップについて書いたことで有名ですが、そのうちの 1 つは問題またはバグ トラッカーでした。彼は正しい。さまざまな機能リクエストやバグをすべて頭の中で思い出すのは困難です。バグを再現するためのすべての手順、ユーザーが何を期待し、実際に何を得たのかを覚えておくことはさらに困難です。
机の上にあるポストイットも限られています。 WordPress 自体は、問題追跡ツールとして Trac を使用しています。私はホスト型 Redmine と git ホスティングを提供する Planio に所属しているため、別のオープンソースの問題追跡ツールおよびプロジェクト管理ツールである Redmine を使用してきました。
問題追跡ツールの一般的な使用例
そこで、WordPress 用の新しいプラグインを構築していると想像してください。あなたは、開発者 1 人か 2 人、デザイナーとビジネス担当者という小さなチームで仕事をしています。
あなたはもはや 1 人だけのチームではありません。リモートワークは最高ですが、北半球の冬はあまり楽しくないので、全員が同じ場所で仕事をするわけではありません。
ユーザーは、プラグインが「機能しない」という内容の電子メールを送信します。本当に運が良ければ、「機能しません」というエラー メッセージを示すスクリーンショットが表示されるでしょう。
あなたはメールを転送します。誰かが使用していたブラウザについて質問するメールを返してくると、突然 12 件のメールで構成される Gmail スレッドができてしまいます。ここにはいくつかの問題がまとめられており、問題トラッカーはこれらの問題の解決に役立ちます。
修正可能なバグの 3 つの重要な要素
1 つ目は、実際にはすべてのバグ レポートに次の 3 つのものが必要であるということです。
- ユーザーが実行した手順によってバグが発生しましたか?
- ユーザーは何を期待していましたか?
- ユーザーは実際に何を見たのでしょうか?
実際に動作が確認できないバグを修正するのは非常に難しいため、バグを再現できる必要があります。次に、そのバグが実際にバグなのか、それともソフトウェアが提供していないものをユーザーが期待していたかどうかを確認する必要があります。
別の言い方をすると次のようになります。
バグ報告に関する親のルール:
– プログラムに何を与えてほしかったのですか?
– プログラムに何をしましたか?
– それはあなたにとってどのような意味がありましたか?— スティーブ・パーセル (@sanityinc) 2015 年 10 月 29 日
そして、古典的なセリフでバグを報告する人を騙すことはできません。「それはバグではありません。それは機能です!」と言うのではなく、その人が何を期待しているのかがわからない場合に使用します。
Redmine などの問題追跡ツールを使用すると、この情報を受け取る標準化された方法が得られることになります。
タスクが決して完了しないようにする方法が 1 つあります。それは、チームにそれについて何かをすべきだと漠然と提案することです。 1 人の「所有者」に割り当てられない限り、それは完了しません。
課題トラッカーを使用すると、課題を常に 1 人に割り当てることができるため、現在誰がバグやタスクを所有しているかを常に把握できます。同時に、問題は「進行中」、「QA/テスト中」、「導入準備完了」などのさまざまなステータスのワークフローを通過します。
ほとんどのトラッカーは、問題の現在のステータスに基づいてレポートを提供するため、現在の進行中の作業量と、どれだけの作業が残っているかを確認できます。アジャイル手法で普及しているバーンダウン チャートを作成することもできます。
Git をプロジェクト管理ワークフローに緊密に統合
上で述べたように、WordPress 開発プロセスで git を使用すると、問題が発生したときの作業が非常に楽になります。 Git ではコードに巻き戻しボタンがあり、サイトの複数の並列バージョンを作成できます。
新しいコードを git リポジトリに「コミット」するたびに、コードベースの変更について議論する自然なポイントが作成されます。さらに、漠然としたアイデアよりも、実際にコミットされたコードに基づいて問題を議論する方が簡単だと思います。
たとえば、Redmine は git または svn と緊密に統合されているため、ここで問題トラッカーが威力を発揮します。問題に対して誰が何をコミットしたかをすぐに確認し、それらの問題について話し合うことができます。
WordPress 開発用のシステムを作成する
課題トラッカーは、自分自身を超えてスケールアップするのに役立ちます。問題が漏れていないことを確認できます。
Planio では、ほとんどのお客様が、WordPress プロジェクトを含むソフトウェア開発プロジェクトを追跡する目的で、ホスト型 Redmine を使用しています。バージョン管理に関連してバグ、新機能、スプリントを追跡します。
Redmine は WordPress と同様にオープンソースであるため、独自のソフトウェアにロックされないという利点があります。また、WordPress と同様に、ホスティングを Planio のような人にアウトソーシングすることも、必要に応じて Redmine.org から自分でインストールすることもできます。
オーバー・トゥ・ユー
では、ワークフローをどのように管理すればよいでしょうか? Redmineを試してみましたか?以下からご意見やご感想をお聞かせください。