プログラミングチーム

プログラミングチームとは、コンピュータソフトウェアの開発や保守を行うチームです。[ 1 ]プログラミングチーム の構成は様々ですが、自我のないプログラミングチームとチーフプログラマーチームが一般的な構成となっています。[ 2 ]

説明

プログラミングチームは、コンピュータソフトウェアを開発または保守する 人々で構成されています。[ 3 ]

プログラミングチームの構造

プログラミングチームは様々な方法で編成されますが、エゴレスプログラミングチームとチーフプログラマーチームは、一般的に使用される2つの一般的な構造です。[ 2 ]プログラミングチームの構造を選択する際の主な決定要因には、通常、難易度、規模、期間、モジュール性、信頼性、時間、社交性などがあります。[ 2 ]

エゴレスプログラミング

マリリン・マンテイによると、分散型プログラミングチームに所属する個人は、より高い職務満足度を報告している。[ 2 ]一方、エゴのないプログラミングチームは、10人以下のプログラマーで構成されるグループで構成される。コードはグループメンバー間で交換され、目標が設定される。リーダーシップは、特定の期間に求められるニーズと能力に応じてグループ内で交代する。エゴのないチームにおける構造の欠如は、大規模プロジェクトにおいて効率性、有効性、そしてエラー検出の弱点につながる可能性がある。エゴのないプログラミングチームは、非常に複雑なタスクで最も効果を発揮する。

チーフプログラマーチーム

チーフプログラマーチームは通常、チーフプログラマー、シニアレベルプログラマー、プログラムライブラリアンの3人で構成される。必要に応じて、プログラマーとアナリストがチームに加わる。この構造の弱点は、チームメンバー間のコミュニケーション不足、タスクの協力、複雑なタスクの完了などである。チーフプログラマーチームは、チーム内の情報の流れが限られているため、より単純で分かりやすいタスクで最も効果的に機能する。このチーム構造で働く人は、一般的に仕事への意欲が低いと報告している。[ 2 ]

共有ワークステーションチーム

ペアプログラミング

2 人のプログラマーが 1 つのワークステーションで共同作業する開発手法。

モブプログラミング

チーム全体が同じものを、同じ時間に、同じ場所で、同じコンピューターで作業するソフトウェア開発アプローチ。[ 4 ]

プログラミングモデル

プログラミング モデルを使用すると、ソフトウェア開発チームはさまざまな方法論を使用してプロジェクトを開発、展開、テストできます。

どちらのプログラミングモデルにおいても、チームメンバーは通常、毎日5～15分のスタンドアップミーティングに参加します。伝統的に、各チームメンバーは立ち上がり、前回のスタンドアップ以降に取り組んだ内容、次回のスタンドアップまでに取り組む予定の内容、そして進捗を妨げているもの（いわゆる「ブロッカー」）があるかどうかを表明します。[ 5 ]

ウォーターフォールモデル

ウォーターフォールモデルは、より伝統的なアプローチとして[ 6 ]知られており 、生産の線形モデルです。この方法論における一連の流れは以下のとおりです。

  1. 要件を収集して文書化する
  2. デザイン
  3. コードとユニットテスト
  4. システムテストを実行する
  5. ユーザー受け入れテスト（UAT）を実行する
  6. 問題を修正する
  7. 完成品を納品する

ソフトウェア開発プロセスの各段階は明確に区別されており、通常、各段階は次の段階が始まる前に終了します。

このモデルを採用するプログラミングチームは、開発プロセスの早い段階でプロジェクトを設計できるため、チームは開発の大部分において、設計を何度も繰り返すことなくコーディングとテストに集中できます。また、チームはより綿密かつ綿密に設計できるため、すべてのソフトウェア成果物を完全に理解することができます。

アジャイルモデル

アジャイル開発モデルは、従来のウォーターフォールモデルよりもチームベースの開発アプローチです[ 6 ]。チームは迅速なデリバリー／デプロイメントを行い、作業を「スプリント」と呼ばれるフェーズに分割します。スプリントは通常、各チーム／チームメンバーに2週間分の計画されたソフトウェア成果物として与えられます。

各スプリントの終了後、作業の優先順位が再設定され、前回のスプリントで得られた情報が今後のスプリント計画に活用されます。スプリントの作業が完了すると、プログラミングチームによるレビューと評価が行われ、次のイテレーション（つまり次のスプリント）に送り返されるか、完了している場合はクローズされます。

アジャイル宣言[ 8 ]の一般原則[ 7 ]は次のとおりです。

  • 顧客を満足させ、継続的にソフトウェアを開発します。
  • 変化する要件は、顧客の競争上の優位性のために受け入れられます。
  • 動作するソフトウェアを頻繁に提供することに集中します。提供期間は可能な限り短くすることを優先します。
  • 開発者とビジネス担当者はプロジェクト全体を通じて協力する必要があります。
  • プロジェクトは、やる気のある人材を基盤としなければなりません。彼らに適切な環境と必要なサポートを与え、仕事をやり遂げられるよう信頼されるべきです。
  • チーム間で情報を伝達するには、対面でのコミュニケーションが最善の方法です。
  • 動作するソフトウェアは進捗状況を測る主な指標です。
  • アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、そしてユーザーは、一定したペースを維持できる必要があります。
  • 技術的な卓越性と優れたデザインに常に注意を払うことで、敏捷性が向上します。
  • シンプルさは、行われていない作業を最大限に活用する芸術であると考えられており、不可欠です。
  • 自己組織化されたチームは通常、最高のデザインを生み出します。
  • チームは定期的に、より効果的になる方法を振り返り、それに応じて行動を調整します。

参照

参考文献

  1. ^ジャック・ベルツァー、アルバート・ジョージ・ホルツマン、アレン・ケント（1979年10月1日）、コンピュータサイエンスとテクノロジー百科事典、第13巻、CRCプレス、ISBN 9780824722630{{citation}}: CS1 maint: multiple names: authors list (link)
  2. ^ a b c d e Marilyn Mantei (1981年3月). 「プログラミングチーム構造がプログラミングタスクに与える影響」(PDF) . Communications of the ACM . 第24巻第3号. pp.  106– 113. 2019年3月26日閲覧。
  3. ^ジャック・ベルツァー、アルバート・ジョージ・ホルツマン、アレン・ケント（1979年10月）、コンピュータサイエンスとテクノロジー百科事典、第13巻、CRCプレス、ISBN 9780824722630{{citation}}: CS1 maint: multiple names: authors list (link)
  4. ^ジャック・ベルツァー、アルバート・ジョージ・ホルツマン、アレン・ケント（1979年10月）、チェンジマネジメントプロセス、第13巻、ISBN 9780824722630{{citation}}: CS1 maint: multiple names: authors list (link)
  5. ^クリスティーナ・グリフィン、マーガレット・ロルダン（2013年10月29日）「ウォーターフォールを泳ぎきる：ウォーターフォールの世界におけるアジャイルプロセス」プロジェクトマネジメント協会。 2023年10月10日閲覧。
  6. ^ a b Mary Lotz (2018 年 7 月 5 日)、「ウォーターフォール vs. アジャイル: プロジェクトに適した開発手法はどちらですか?」
  7. ^ Linchpin SEO チーム (2019 年 3 月 26 日)、アジャイル手法とスクラムの初心者向けガイド
  8. ^ 「アジャイル宣言の背後にある原則」 2019年6月11日。
「 https://en.wikipedia.org/w/index.php?title=Programming_team&oldid=1233875600」から取得