ポール CCによる写真
IaaSプロバイダーの開発中、
1cloudのチームは、チーム全体のワークフローを正しく整理することがいかに重要であるかを直接知っています。 最近、開発者とテスターが言ってはいけない13のことを議論した
資料を発行し、別の投稿で組織の企業文化に
触れました。
今日は、会社のプロセスの組織をさらに深く掘り下げ、サービスの開発を最適化する方法についてお話したいと思います。
LucasArtsのプロジェクトマネージャーであるジェフモリスは、かつて日常業務がアプリケーション開発の成功の主要な基準である
と述べました。 成功したアスリートはすぐにオリンピックで金メダルを獲得し始めませんでした、彼らは定期的に練習し、コーチの指導の下で適切に食べました。
サービスを開発する場合-すべてが同じです。 リーダーとして、あなたはあなたのチームを成功に導くコーチになるべきです。 プロジェクトの成果を改善するために、サービス開発プロセスを適切に編成する必要があります。 また、開発チームを燃え尽きないようにし、スタッフの離職率を減らし、チームの精神を強化します。
エグゼクティブがアプリケーションとサービスを開発するプロセスを整理するためのヒントを次に示します。
スプリントのみ、ハードコアのみ
開発は徐々に繰り返し実行される必要があるため、厳密なスケジュールを作成する必要があります。 次の図は、2週間のスプリントのそのようなスケジュールの例を示しています。
実際、予定された就業日は、全員が現在のタスクに取り組む標準的な日です。
リーダーとして、チームを良好な状態に保つために、従業員間で負荷を正しく分散する必要があります。 大きなタスクを小さなタスクに分割し、プログラマーが「重み」の下で苦労しないようにします。 マーケティング担当者のCheryl Andrus（Cheryl Andrus）による
と 、「小さな成功でもチームをすぐに元気づけることができます」。 開発者が別の小さなタスクを完了するたびに、開発者は通電され、2番目の風が開きます。
タスクを配布するときは、各チームメンバーの個々の特性を考慮してください。 すべての人が同じ速度で働くわけではなく、それぞれに長所と短所があります。 また、2週目の終わりに、残りのタスクを完了し、予期しない問題を解決するために数日を予約する必要があります。
さらに、各タスクの病棟の進捗状況を評価し、次のスプリントの作業段階をスケジュールする必要がある場合は、計画会議に1日割り当てる必要があります。
もっと頑張る
スプリントに予定されているすべてのタスクが時間通りに完了するように、作業がどのように動いているかを定期的に確認する必要があります。 スクラム方法論では、毎朝15分を開発チームと話し合うことをお勧めします。 この間、各チームメンバーは、昨日どのタスクを完了したか、残りのタスクを完了するのにどれだけの時間を必要かについて簡単に話します。 トレーナーとして、チームに耳を傾け、貴重なガイダンスを提供する必要があります。
そのような会議が遅れることを恐れている場合は、常設会議を開催してください。 この方法により、3分の1の時間が短縮されることが証明されています。 さらに、会議が早く終了すればするほど、開発チームはより強力になります。
良いテクニックは、色とりどりのカードにタスクを書き、ボードにそれらを掛けることです。 各色には、たとえば次のような独自のステータスがあります。
- ロック済み-タスクを開始できません（技術的な問題が発生したか、関連するタスクが完了していません）。
- 開始されていません-タスクを開始できます。
- 作業中-タスクの作業が進行中です。
- 検証-開発者はタスクを完了し、検証のためにシニアに転送しました。
- 完了-問題は解決しました。
これにより、チームメンバは、移動している方向を確認し、負荷を個別に評価できます。
優先順位を設定する
優先順位付けは、プロジェクトがレース終了時に「落ちない」ことを保証します。 Drupalプロジェクトでは、タスクの興味深い分類が
提案されました。
- 重要なタスク：おそらく誰かが仕事を続けられなくなるので、できるだけ早く完了する必要があります。 このようなタスクを延期すると、生産性が急激に低下し、ユーザーエクスペリエンスとドキュメントの品質が大幅に低下する可能性があります。
- 重要なタスク：完了するまで、製品の新しいバージョンを起動することは望ましくありません。 重要なタスクの典型的な例の1つは、コードのリファクタリングです。 リファクタリングは、コードの読みやすさだけでなく、パフォーマンスも向上させることができます。これは、顧客の態度にプラスの影響を与えます。これについては、以前の投稿のいずれかで言及しました 。
- 中程度に重要なタスク：リリースは完了せずに実行できますが、プログラムの品質が影響を受ける可能性があります。 このようなタスクの例は、小さな作業コードのテストです。
- 重要なタスクではありません：アプリケーションの機能に影響を与えないため、「美しさのために」実行されました。 たとえば、コードコメントのタイプミスを修正します。
タスクの優先順位付けには多くの方法があります。 上記はそのうちの1つです。 リンクの詳細については、
こちら （
こちら 、
こちら 、
こちら ）を
ご覧ください 。
呼吸を続ける
ソフトウェアエラーを識別するには、優先順位付けが重要です。 すべてのバグを完全に追跡および「クリーニング」することは難しく、このため、最も「致命的な」バグに焦点を当てることは合理的です。
- 重大なバグは定期的にシステムを破壊し、チーム全体の作業を弱体化させます。すぐに対処する必要があります。
- 2番目は、チームメンバーが作業を継続できなかったり、生産性が低下したり、特定のサービス機能を適切に評価しなかったりする重大なバグです。
- 3つ目-明らかな問題やプログラムの不正確さを示すが、ワークフローには影響しない、それほど深刻ではないバグ。
- ユーザーが重大なバグに気付くことはほとんどありませんが、それらを見つけた場合は、必要に応じて修正できます。 美しさをもたらすことは常に喜びです。
バグを追跡するために、検出されたエラーに関するすべての情報を保存する独自のデータベースを作成できます。 重要度の高い順に列を配置し、フィルターの作成に注意してください。 これにより、ナビゲートしやすくなります。
特別に設計されたバグ追跡システムに関しては、いくつかの推奨事項があります。 多くの場合、大規模なチームで使用されるバグトラッカー
Jiraがあります。 複数の人で構成されるチームには、
Pivotal Tracker 、
Trello 、および
Githubトラッカーが適しています。 Mozilla Foundation、
Mantis BT 、
Redmine 、およびミニマルな
Tracから無料の
Bugzilla 。
マーカーで書くのが好きな人は、すべてのバグをホワイトボードにマークするか、2番目の段落のカードのようなステッカーを貼り付けることができます。
多くの場合、マネージャーは情報でチームを過負荷にせず、一度に見つかったすべてのバグに「機能しない」ことを試みます。 ただし、できるだけ早く報告する方が賢明です。 そのため、各開発者は、修正しなければならないエラーの数を明確に把握し、作業日をより正確に計画できるようになります。 したがって、これらのデータをチームと共有しないということは、少なくともそのメンバーに対して無礼を示すことを意味します。
技術重視
高品質のソフトウェアを作成するためにチームを設定します。 ただし、この品質を確認するには、定期的にサービスをテストする必要があります。 このトピックに関するいくつかの提案は、Quoraのディスカッション
の参加者
によって提供されました 。
さらに、開発チーム全体が参加してテストを実施する必要がある場合があることに注意してください。 少なくとも週に1回は、誰もが自分のアプリケーションで「遊んで」、それを感じてください。 ただし、開発者
はテストを完全にあきらめ
ないでください 。
したがって、リーダーとしてチームを勝利に導くには、チームメンバー間で負荷を正しく分散し、バグを修正する場合を含めて優先順位を付け、各開発者がプロジェクトの段階を理解できるようにタスクの透明性を確保する必要があります。
PS週末にIaaSプロバイダー
1cloudに精通し 、その機能をテストする時間がある場合に備えて、実用的なガイドラインへのリンクを用意しました。