• ホームページ
  • 記事
  • General
  • アジャイルでのエクストリーム プログラミング – プロジェクト マネージャーと nTaskers のための実践ガイド

アジャイルでのエクストリーム プログラミング – プロジェクト マネージャーと nTaskers のための実践ガイド

公開: 2020-07-08

ウォーターフォールでのエクストリーム プログラミングについて、そしてプロジェクト マネージャーとしてどのように利益を得ることができるかについて、非常に多くのリクエストを受け取りました。 エクストリーム プログラミングとは、PM がソフトウェア開発環境で利用可能なリソースを最大限に活用するアジャイル フレームワークの一種です。

アジャイル SDLC 環境でのエクストリーム プログラミング (XP)

ソース: Udacity.com

アジャイル ソフトウェア開発フレームワークであるエクストリーム プログラミング (XP) は、ソフトウェアの品質、開発チームの作業プロセス、および顧客満足度の向上を目的として設計されています。

これは、プロジェクトのソフトウェア開発ライフ サイクル (SDLC) をよりスムーズかつ効率的にするために考案された方法であり、1996 年 3 月 6 日にプロジェクトで最初に実装されました。

なぜエクストリーム プログラミング (XP) なのか?

エクストリーム プログラミングは、プロジェクト全体で反復的かつ反復的なソフトウェア リリースを提供するように取り組んでいます。 単一の長いプロジェクト開発ライフサイクルの後にすべてをまとめるのではなく。

これらの短い反復サイクルは、チーム メンバーと顧客の両方が、開発全体を通してプロジェクトの進捗状況を評価およびレビューするのに役立ちます。

エクストリーム プログラミング (XP) は何でできていますか?

その価値

XP には、次の 5 つの値が組み込まれています。

  • コミュニケーション: ソフトウェア開発プロジェクトやあらゆる業界のプロジェクトは、コミュニケーションに大きく依存しています。 XP は、チームと顧客の間の効果的なコミュニケーションに重点を置いています。
  • シンプルさ : XP は、物事を成し遂げる最も簡単な方法を探します。 これは、本質的なことを行うことで無駄を減らし、既知の問題のみに対処し、効果的な作成と保守のために設計をシンプルに保つことを意味します。
  • フィードバック: フィードバックは、プロジェクトの改善において重要な役割を果たします。 XP は即時のフィードバックを奨励します。 これは、チームが改善の余地を特定し、プラクティスを修正するのに役立ちます。
  • 尊重: チームは、目標を達成するために、個人的にも職業的にもお互いを尊重しなければなりません。
  • 勇気: XP はあらゆるレベルで勇気を支持します。 これには、うまくいかないことやプロジェクトの有効性に影響を与えるものに反対すること、またはフィードバックを受け入れて方法論を改善することが含まれます。

プラクティス

極端なプログラミング

XP の核となるのは、相互接続された一連のソフトウェア開発手法です。 これらのプラクティスを単独で実装することは可能ですが、多くのチームは、一部のプラクティスは他のプラクティスを強化するものであり、組み合わせて実行する必要があることに気付きました。 これにより、ソフトウェア開発でよく直面するリスクを完全に排除できます。

XP の元の 12 のプラクティスは次のとおりです。

  • 企画ゲーム
  • 小規模リリース
  • 比喩
  • シンプルなデザイン
  • テスト
  • リファクタリング
  • ペアプログラミング
  • 集団所有権
  • 継続的インテグレーション
  • 週40時間
  • オンサイトの顧客、および
  • コーディング標準。

何年にもわたって、チームは、いくつかのプラクティスが他のプラクティスを強化することを発見しました. リスクを排除するには、これらを統合する必要があります。 以下の説明には、さまざまなチームの経験に基づいた改良の一部が含まれています。

チーム全体: チームは、さまざまなスキルを持つ部門横断的なグループで構成する必要があります。 このようにして、それらは互いに補完し合い、特定の結果を達成することができます。

一緒に座る:ほとんどの人は、対面での会話が最良のコミュニケーション方法であることに同意します。 チームは、キュービクルの壁など、コミュニケーションを妨げるものなしに一緒に座る必要があります。

有益なワークスペース: チームは、チームの作業が相互に、またチーム外の関係者に対して透過的になるように配置する必要があります。

Energized Work : 仕事に集中できるよう、心身ともに健康であることを意味します。 これはまた、精神的および肉体的な健康をサポートするために、過労や尊敬のチームが存在するべきではないことを意味します.

また読む：

今日の作業環境でプロのようにプロジェクトを管理するには?

ペア プログラミング: このプラクティスの背後にある考え方は、2 つの頭脳は 1 つよりも優れているということです。 ペアプログラミングとは、2 人が同じマシンに座ってソフトウェアを作成することを指します。 これにより、継続的な作業レビューが行われ、問題がより迅速に対応されます。 この方法は、品質を向上させ、より集中力を維持することが示されています。

ストーリー: ストーリーは、顧客やユーザーにとって意味のある、製品が持つべき機能を定義します。 これらのストーリーは計画に使用され、さらなる会話のリマインダーとしても機能します。

毎週のサイクル: 毎週の最初の日に、チームが集まり、これまでの進捗状況を振り返ります。 その週に配信するストーリーは、顧客によって選択されます。 チームは、それらのストーリーにアプローチする方法を決定します。 この背後にある目標は、実行中の検証可能な機能を週末までに実現することです。 固定期間により、フィードバックのために顧客に表示できる機能の作成が可能になります。

四半期サイクル: 四半期サイクルの目的は、プロジェクト全体のコンテキストで各週サイクルの詳細な作業を確認することです。 顧客は、特定の四半期内のチームの全体的な計画を提供します。 これは、チームにプロジェクトのビューを提供するだけでなく、顧客が関係する他の利害関係者と協力するのにも役立ちます。

Slack : これは、毎週および四半期ごとのサイクルで、優先度の低いいくつかのタスクまたはストーリーを追加することを意味します。 チームがより重要なタスクに遅れをとっている場合、これらは削除できます。 それ以外の場合は、これらも完了し、予定されたスケジュールを満たす可能性が高くなります。

Ten-Minute Build : システム全体とすべてのテストを 10 分以内に実行する必要があります。 時間がこの制限を超えると、複数回の再実行により、エラー間の時間が長くなります。 このプラクティスにより、ビルド プロセスの自動化が促進され、すべてのテストを定期的に実行できるようになります。

継続的インテグレーション:このプラクティスは、既存のより大きなコードベースに対する新しいコードの即時テストを促進します。 これにより、統合の問題をより早く見つけて修正できます。 このプラクティスには規律が必要であり、Ten Minute Build および Test First Development のプラクティスに依存します。

Test-First Programming : 通常の方法に従う代わりに、

コードの開発 -> テストの作成 -> テストの実行

テスト ファースト プログラミングの実践は、次のような道をたどります。

失敗する自動テストを書く -> 失敗するテストを実行する -> テストに合格するコードを開発する -> テストを実行する -> 繰り返す

このプラクティスも、問題の特定と解決のためのフィードバック サイクルを短縮します。 これにより、本番環境に持ち込まれるバグの数が減少します。

インクリメンタル デザイン: このプラクティスでは、システム デザインの幅広い観点を理解するために、事前にある程度の作業を行うことを示します。 その後、特定の機能が提供されたときに、設計の特定の側面の詳細にさらに取り組みます。 このアプローチにより、変更のコストが削減され、必要に応じて最新の情報に基づいて設計上の決定を下すことができます。

役割

XP には、チームが従うべき特定のプラクティスが組み込まれており、チーム メンバーの特定の役割は確立されていません。 ただし、要件によると、最も一般的な 4 つの役割は次のとおりです。

顧客: XP の顧客は、プロジェクトに積極的に参加することが期待されています。 お客様は、プロジェクトに関する次のようなすべてのビジネス上の決定を行います。

  • システムは何をすべきか? これは、含まれている機能とそれらが達成することを指します
  • システムはいつ完成しますか？ これは、受け入れ基準を意味します
  • どのくらい費やすべきですか？ これは、プロジェクトの予算を意味し、
  • 次に何をすべきか？ 機能が配信される順序。

開発者: 開発者は、顧客が特定したストーリーを実現します。これは、決定された機能を備えたプロジェクトを提供することを意味します。

トラッカー: トラッカーはオプションの役割であり、チームが必要とするかどうかによって異なります。 これは、関連するアジャイル メトリクスを追跡するために開発者の 1 人によって実行され、進捗状況の評価と改善のための重要な領域の特定に不可欠です。 これは、進捗状況を追跡し、改善が必要な主要領域を特定するために重要です。 これらのメトリックには、作業時間、残業時間、テストの合格と不合格、速度、および速度の変動の理由が含まれる場合があります。

コーチ: この役割は、特にチームが立ち上げたばかりの場合に役立ちます。 コーチは、以前に XP を使用したことがある外部のコンサルタントである場合があり、XP プラクティスと自己規律についてチームを指導するのに役立ちます。 コーチを採用することで、新しいチームが犯す可能性のある潜在的なミスを回避し、プロジェクトを迅速に進めることができます。

エクストリームプログラミングの利点

  • 極端なプログラミングにより、ソフトウェア開発者はコーディングに集中でき、プロジェクトに関連する非生産的な活動について心配する必要がなくなります
  • エクストリーム プログラミングの最も重要な利点は、ソフトウェア会社が、プロジェクトの実現やその他のブレインストーミング セッションなどの活動に費やすことができるときに、無駄な活動に費やされるお金や時間などのリソースの支出を削減できることです。
  • 極端なプログラミングは、プロジェクトの失敗やコーディングの誤動作のリスクも軽減し、クライアントが最終的に目的の製品を確実に入手できるようにします。
  • エクストリーム プログラミングは、コードを複雑にする必要がなく、誰もが理解するのが難しいという驚くべき方法論であり、この方法論を使用する開発者のコ​​ードに示されています。簡単に
  • XP の最も優れた点の 1 つは、すべてが透過的であり、全員の前に立つことで、全員とすべてに説明責任を持たせるのに役立つことです。
  • 絶え間ないフィードバックはエクストリーム プログラミングの素晴らしい機能でもあり、開発者は恐れることなく、判断を恐れずにコードを書くことができます。
  • ソフトウェアのすべての要素の定期的なテスト、すべてのコードのバグ検出、および顧客検証テストの使用により、クライアントは通常よりも短い時間で動作するプロトタイプまたは実際に動作するソフトウェアを取得できます。
  • エクストリーム プログラミングは、企業が顧客を満足させ、ビジネスをより長く維持するのにも役立ちます。
  • 極端なプログラミング方法論では、誰もが群れの平等なメンバーであり、誰もが仲間として負担を分かち合う必要があります。つまり、要件からコードまで、開発者は並んで作業するので、誰も評価されていないと感じたり、忘れられたりすることはありません。

エクストリーム プログラミング (XP) のライフサイクル

XP のライフサイクルは、週ごとのサイクルと四半期ごとのサイクルで説明できます。

まず、顧客が一連のストーリーを定義します。 チームは、各ストーリーのサイズを見積もります。これは、顧客が見積もった相対的なメリットとともに、ストーリーの優先順位付けに使用される相対的な価値を示します。

技術的な考慮事項が不明確なためにチームが一部のストーリーを見積もることができない場合、チームはスパイクを導入することができます。 スパイクは研究のための短い時間枠と呼ばれ、通常の反復が開始される前、または進行中の反復とともに発生する可能性があります。

次はリリース計画です。リリース計画には、特定の四半期またはリリースで配信されるストーリーが含まれます。

この時点で、毎週のサイクルが始まります。 各週サイクルの開始時に、チームと顧客が集まり、その週に実現する一連のストーリーを決定します。 これらのストーリーは、その週に完了するタスクに分割されます。

チームと顧客の間で現在までの進捗状況を確認する週末。 これにより、プロジェクトを継続するか、十分な価値が提供されたかが決定されます。

エクストリーム プログラミング プラクティスのケース スタディ (XP)

XP for Kurizp システム

問題

Krizp Solution は、インドのスタートアップの Web ベースの開発会社でした。 彼らの事業計画には、他の小規模企業や教育機関向けの Web ポータルの作成が含まれていました。 同社はパートタイムのビジネスとして始まり、他の主要な IT 組織で既に働いていた人々を雇用しました。 計画は、スタートアップが成功を収めた場合にのみ、フルタイムで継続することでした。 プロジェクト数も従業員数も少ない新興企業であったため、ソフトウェア開発プロセスのフレームワークがありませんでした。

同社には、ソフトウェア開発に対する構造化されたアプローチがありませんでした。 最初の要件を紙に書き留めた後、顧客から電話で詳細な情報と説明を受け取りました。 通常、要件の大きな変更は、ソリューションが開発された後のカスタマー レビューまで発生しませんでした。

バグ修正以外では、開発者同士のコミュニケーションはほとんど、またはまったくありませんでした。 彼らは、さまざまな機能について別々に取り組みました。 これが、働き方改善の議論の障壁となっていました。

さらに、プロジェクトは文書化されていませんでした。 プロジェクトを追跡したり、顧客が提示した要件が満たされていることを確認したりするプロジェクト マネージャーはいませんでした。 開発者は、求められたことだけに取り組みました。

旅

エクストリームプログラミングPERT認定

Krisp System のチームは、さまざまなアジャイル フレームワークの背後にある概念を紹介されました。 XP 法は 1 か月にわたって採用され、結果が評価されました。

同社の CEO は、顧客担当者とトラッカーの 2 つの役割を担いました。 彼の最初の役割では、ユーザー ストーリーに優先順位を付けて開発チームに委任し、顧客と定期的にコミュニケーションを取りました。 トラッカーとして、彼は特定のタスクを完了する時間を追跡しました。 また、CEO は毎週 (または少なくとも 4 日に 1 回) プランニング ゲームを開始しました。これは、プロジェクトが小規模であり、開発者が 1 つのユーザー ストーリーでより早くタスクを完了できるためです。 しかし、この顧客は月に 2 回しか直接連絡を取ることができず、残りの時間は電話や電子メールで連絡を取り合っていました。

両方の開発者が協力して作業するペア プログラミング手法が採用されました。 タスクの完了後、両方の開発者が CEO と一緒にコードをレビューしました。

顧客テストが導入され、チームは月に約 12 ～ 15 の継続的な設計改善に取り組みました。

概要

XP のアプローチは、同社のソフトウェア開発サイクルに良い影響を与えたようです。 プラスの変化には次のようなものがあります。

  1. チームのコラボレーション、コミュニケーション、フィードバックの改善
  2. より良いタスクと時間管理、および
  3. 技術的な貢献なしに CEO の関与を増やす。

IBM と Sabre Airlines のエクストリーム プログラミング プラクティス

問題

ウォーターフォールとエクストリーム プログラミングの実際のアプリケーションを評価するために、調査研究が 2 つのケース スタディを通じて実施されました。1 つは IBM で、もう 1 つはセイバー航空で行われました。 各ケース スタディでは、ウォーターフォール アプローチと XP アプローチを比較しました。

旅

最初のケース スタディである IBM では、研究者は XP アプローチの採用が生産性、品質、および顧客満足度に及ぼす影響を調査したいと考えていました。 XP プラクティスの採用に関して、7 ～ 11 人のメンバーからなるチームで 1 年間にわたる調査が実施されました。 このチームは、他の IBM チームが外部顧客向けの製品を作成するために使用するツールキット用のサーブレット/XML アプリケーションの開発を担当していました。 ケーススタディでは、同じ製品の連続リリースに関する 2 つのアプローチを分析しました。 1 つ目は従来のウォーターフォール アプローチで、2 つ目は XP です。

2 番目のケース スタディでは、Sabre Airline Solutions で同じ方法が使用されました。つまり、同じ製品の異なるリリースによる 2 つのアプローチを比較しました。 チームは、外部の顧客がカスタマイズされたエンド ユーザーおよびビジネス アプリケーションを開発するためのスクリプト可能な GUI 環境の開発に取り組みました。 チームは6〜10人のメンバーで構成されていました。 古いリリースは、ウォーターフォール方式を使用して 3 年前 (18 か月間) に終了しましたが、新しいリリースは、XP を使用して最近 (3.5 か月間) 完了しました。

最初のステップは、XP Context Factors (XP-cf)、XP Adherence Metrics (XP-am)、XP Outcome Measures (XP-om) の 3 つの部分で構成されるエクストリーム プログラミング評価フレームワーク (XP-EF) を確立することでした。

  • XP Context Factors (XP-cf) : XP-cf は、プロジェクトに関連する重要な情報を記録するために使用されました。 これらの要因には、チームの規模、プロジェクトの規模、重要度、およびスタッフの経験が含まれます。
  • XP Adherence Metrics (XP-am) : XP-am を通じて、チームが XP プラクティスを使用する程度が表現されました。 XP-am は、XP プラクティス間の相互作用と依存関係、およびプラクティスを分離または削除できる程度の調査にも役立ちました。
  • XP Outcome Measures (XP-om) : XP-cm は、ビジネス関連の結果 (生産性、品質など) の評価を可能にします。

フレームワークに加えて、チーム メンバーと顧客にインタビューを行い、顧客の満足のためにチームが XP を組み込むことを理解するのに役立ちました。

概要

IBM では、以下の点で、ウォーターフォール方式よりも XP 方式の方が生産性が高いように見えました。

  • テストの欠陥: XP アプローチによるリリースでは、プレリリースでは欠陥が 50% 減少し、ポストリリースでは欠陥が約 40% 減少しました。
  • 生産性: XP アプローチを使用すると、ウォーターフォール方式よりもスタッフの生産性が大幅に向上しました。
  • 顧客満足度: 顧客満足度は XP で高く、ウォーターフォールでは N/A と記載されています。
  • 士気: 関係者の士気は XP で高く記録され、ウォーターフォールでは N/A として文書化されました。

Sabre Airlines でも​​同様の結果が得られました。

  • 欠陥収集期間: 最初のリリースが 18 か月にわたって作成されたため、ウォーターフォール ベースのアプローチでは欠陥収集期間も長くなりました。 XP ベースのリリースでは大幅に短くなっています。
  • テストの欠陥: XP アプローチによるリリースでは、プレリリースでは欠陥が 65% 減少し、ポストリリースでは欠陥が約 46% 減少しました。
  • 生産性: XP アプローチを使用したスタッフの生産性は、ウォーターフォール方式よりも約 46% 高くなりました。
  • 顧客満足度: 顧客満足度は XP で高く、ウォーターフォールでは N/A と記載されています。
  • 士気: 利害関係者の士気は約 68% の XP であり、ウォーターフォールでは N/A として文書化されています。

ユースケースとアプリケーション

ユース ケース 1: Web 開発

問題の説明:会社の Web サイトを再設計する必要があります。

アクター: 顧客、開発者、トラッカー

  1. イベントの通常の流れ:
  2. 顧客は初期要件を通知します。
  3. 開発チームがプログラミングを開始します。
  4. QA チームがバグをテストし、プログラミング チームに通知します。
  5. 顧客はより多くの要件を持っています
  6. サイクルが繰り返されます。

XP の使用:

  1. 顧客と開発者が参加する対面会議と呼ばれます。
  2. 顧客は、要件、予算、タイムラインをストーリーの形で定義します。
  3. プロジェクト マネージャーはトラッカーとなり、プロジェクトの進捗状況を追跡します。
  4. 開発チームはペアで作業を開始します。 コードの作成とデバッグが同時に行われます。
  5. 毎週、進捗状況について話し合う会議が開催されます。 顧客は新しい要件を定義できます。
  6. ストーリーの状況について話し合うために、四半期ごとに会議が開催されます。
  7. 古いストーリーが完成した後、新しいストーリーのセットが形成されます (次の四半期の要件)。

ユースケース 2:ゲーム開発

問題の説明: クライアントは、ゲームをゼロから開発する必要があります。

アクター: 顧客、開発者、トラッカー

イベントの通常の流れ:

  1. 顧客は、要件、時間、および予算を提供します。
  2. 開発者はプログラミングを開始します。
  3. QA チームがゲーム モジュールをテストします。
  4. 顧客にはさらに多くの要件があります。
  5. サイクルが繰り返されます。

XP の使用:

  1. 顧客と開発者が参加する対面会議と呼ばれます。
  2. お客様は、要件、予算、タイムラインをストーリー (ゲーム モジュール) の形で定義します。
  3. プロジェクト マネージャーはトラッカーとなり、ゲーム開発の進行状況を追跡します。
  4. 開発チームはペアで作業を開始します。 異なるモジュールのコードは、同時に作成およびデバッグされます。
  5. 毎週、進捗状況について話し合う会議が開催されます。 顧客は新しい要件を定義できます。
  6. ストーリーの状況について話し合うために、四半期ごとに会議が開催されます。
  7. 古いストーリーが完成した後、つまり優先度の高いモジュールが完成すると、新しいストーリーのセットが形成されます (次の四半期の要件)。

エクストリーム プログラミング プラクティス用の nTask (XP)

nTask は、エクストリーム プログラミング フレームワークのアジャイル メソッドをサポートするタスク管理システムです。 これは、チームワークとプロジェクトの配信のために特別に設計されたオンライン タスク管理アプリケーションです。 業界に関係なく、nTask は XP の方法論を促進し、効果的なプロジェクト計画とプロセスの調整に貢献します。

以下は、すべて XP フレームワーク内で、nTask がプロジェクトの目標をより適切に計画および達成するのに役立つ方法の一部です。

会議のスケジューリング

座り込み、毎週の会議、四半期ごとの会議を事前にスケジュールできます。 会議の議題とタイミングを指定できます。 会議の固定時間を定義するか、提案された時間をチームに送信して、チームの応答後に確定することができます。

このアプリケーションを使用すると、会議で議論されたすべての重要なポイントを書き留めることもできます。 その後、議事録をレビューして、チームの他のメンバーのために公開することができます。

チームの割り当て

チーム割り当てセクションで、チームと彼らが引き受ける役割を手配できます。 開発者、トラッカー、顧客の役割を簡単に定義できます。

プロジェクトの作成

お客様はプロジェクトを作成し、要件を指定できます。 顧客は、予算とタイムラインを定義することもできます。

タスクの作成と割り当て

顧客は、プロジェクト内でタスクを作成することにより、ストーリーを作成できます。 タスクは、1 つのストーリーの下で完了するアクティビティのリストで構成されます。 その後、これらのストーリーをプログラマーに割り当てることができます。

チーム メンバーの一部が時間前にストーリーを完了した場合、顧客は彼らに「スラック」タスク、つまり残りのタイムライン内の優先度の低いタスクを割り当てることができます。 これにより、プロジェクトの完了に向けてより迅速に作業する時間を節約できます。

参照:

nTask 2.0 のご紹介 – これまでで最も待望のアップデート

プロジェクトの流れ

プロジェクト マネージャーまたはトラッカーは、タイムシート モジュールを通じてプロジェクト フローを追跡するのに役立ちます。 このモジュールにより、プロジェクトの進行状況を効果的に監視および評価できます。 さまざまなタスクのタイムラインと、達成または保留中のマイルストーンを個別に評価するのにも役立ちます。

簡単なコラボレーション

特定のチームが別のサイトで作業している場合など、顔を合わせてミーティングを行うことができない場合があります。 このような場合、プロジェクト、タスク、および会議の自動更新により、タイムリーで効果的なチームのコラボレーションとディスカッションが保証されます。 これにより、プロジェクトとタスクのフォローアップの手動調整、議事録の会議の伝達、またはプロジェクトの更新に無駄な時間が費やされることを回避できます。

リアルタイム コメントを使用すると、チームと簡単にコミュニケーションできます。 情報交換であろうと新しいアイデアであろうと、これによりチームは同じページにとどまることが容易になります。

相互に依存するタスクが強調表示され、各チーム メンバーは、他のチーム メンバーによって更新された更新を即座に確認できます。 これにより、チームは状況の変化を常に把握し、それに応じて次のタスクを計画することができます。

さらに、顧客はチームと直接協力して、要件の変更を更新できます。

透明度

nTask は、そのタスクボードを通じて、すべてのプロジェクトと対応するタスクおよびサブタスクの透過的なビューを提供します。 作成または変更されたプロジェクトは、すぐにチームに伝達されます。 進捗状況の更新、会議の招待状、プロジェクト レポートを再確認する必要はありません。

更新、変更、または削除されたタスクにより、チーム全体が完全に認識し、いつ何が達成されているかを正確に知ることができます。

フィルター オプションを使用すると、選択したプロジェクトの更新を優先度または手元のタスクに基づいて表示するように選択できます。 [ステータス] オプションを使用すると、選択したタスクのステータスが開始済みかどうか、完了済みか進行中かを確認できます。

結論

この記事では、アジャイル ワーカーとして XP をどのように活用できるかについて詳しく説明します。 さらに、nTask は、極端なプログラミングとウォーターフォール技術の領域内でそのような要件を実行するために作成されます。 したがって、それを読んで、下のコメントセクションであなたの考えを共有することを忘れないでください. または、 [email protected] までメールでお問い合わせください。

また読む：
  • 2022 年の最高の無料生産性アプリ 21 個
  • 2022年の個人タスク管理に最適な23のTo Doリストアプリ
  • 2022 年のプロジェクト マネージャーに必須の 10 のプロジェクト管理スキル
  • Getting Things Done (GTD) メソッドと 14 の最高の GTD アプリとツール
  • チームの生産性を向上させる上位 19 のタイム トラッキング ソフトウェア
  • 2022年のスタートアップに最適な27のタスク管理ソフトウェア
  • 2022 年の最高の無料生産性アプリ 36 選
  • 2022 年の個人タスク管理に最適な 30 の To-do リスト アプリ
  • 2022 年にアジャイル チームに最適な 22 の無料プロジェクト管理ツール
  • 仮想チームの管理: 課題、ヒント、仮想チーム管理ツール
  • コラボレーションとモチベーションを祝う 47 の最高のチームワークの名言