6

現在、私たちのチームは、掲示板と Excel スプレッドシートを組み合わせて使用​​して、タスクを追跡し、バーンダウン チャートを作成しています。バックログは、封筒に入ったインデックス カードに保管されます。

これは、利害関係者が同じ場所にいる場合にうまく機能します。ただし、近いうちに地理的に離れた 2 つの場所にスクラム チームを配置する予定です。Sharepoint を活用して、スクラムの成果物 (バックログ、バーンダウン チャート、ベロシティなど) に関するコミュニケーションを支援する方法のベスト プラクティスを探しています。

その目的のためにSharepointをどのように活用しましたか?ベストプラクティスと潜在的な落とし穴は何ですか?

4

6 に答える 6

7

私たちは実際にアジャイル開発にSharepointを使用しており、プロジェクト管理/コラボレーションに非常にうまく機能することがわかりました.
私たちが特に役立つと思ったことが 2 つあります。それは、メトリクスの追跡と自動化されたテストです。ドキュメント ライブラリと infopath を使用して、プロジェクトのすべてのストーリーをサイトに追加します。InfoPath フォームには、ストーリーに必要なすべての情報 (ポイント、推定時間、開発者、テスター、ストーリー タスク、テスト ケース) が含まれている必要があります。

メトリクスについては、バーンダウン チャート、ベロシティ、イテレーションごとのポイントなどの Web パーツを作成します。これは、マネージャーや顧客がプロジェクトの進捗状況を確認するのに特に役立ち、機能とリリース時間に関する決定を下すのに役立ちます。 .


テストのために、自動化されたテストのために XML をスクレイピングすることによって毎晩テストを実行する単純な SEND-RECV-ASSERT 言語があります。メインページには、テストの統計を示す小さな緑/赤の Web パーツがあります。
ドキュメント ライブラリのバックエンドは XML であるため、これは XML 解析を使用して非常に簡単に行うことができます。(現在、いくつかの単純な ActiveX と JavaScript を使用しています)

メトリックの設定は非常に簡単です (xml の解析と html のグラフ作成のみ)。自動化されたテストでは、テスト ランナーをセットアップするのに時間がかかりますが、それが十分に簡単に実行できるようになると、顧客/マネージャーに受け入れテストを作成させることさえできます! アジャイル!:)

于 2009-02-16T15:25:47.617 に答える
4

社内に既に SharePoint があり、快適に使用できるユーザー ベースがあれば、SCRUM で SharePoint を使い始めるのはかなり簡単だと思います。私は次のことから始めます:

プロジェクトごとに 1 つのスクラム サイトを保持するサイト コレクション

スクラム サイトには、次のものが含まれている必要があります。

  • 電子ファイルのドキュメント ライブラリ (必要に応じて分類のための列を追加します)

  • チームメンバー一覧

  • ディスカッションボード

必要に応じて、Wiki サイト テンプレートからサイトを構築できます。

スクラム サイトが「いい感じ」になったら、それをテンプレートとして保存して、新しいサイトを簡単に作成できるようにします。

このソリューションは、SCRUM 向けに設計されていない可能性がありますが、開始するには十分なはずです。チーム全体が新しいツールを習得するよりも、他のかなり急進的な変更が行われているように思われる場合は、はるかに簡単に思えます。

私の $0.02

jt

于 2009-02-12T16:35:39.787 に答える
4

これには、 TrelloVersionOneRally、さらにはBasecampなどを検討する必要があります。それらはすべてホストされたソリューションを持ち、開始するために試すことができる無料のコミュニティ バージョンを提供します. SharePoint に関する私の経験では、維持するのに多くのリソースが必要です。Team System を使用していて、事前に構築されたものがたくさんある場合は、状況が異なる可能性があります。ただし、私は Team System を使用しており、プロジェクト管理タスクに Wiki を使用することを選択しています。イントラネットおよびすべてのサポート スタッフとして SharePoint に既に投資している場合は、その場合にも実行可能なソリューションになる可能性があります。

SharePoint は、アジャイル開発で最初に思いつくツールではありません。YMMV。

于 2009-02-12T05:19:09.447 に答える
2

ツールが作業の邪魔にならないようにする必要があります。理想的な世界では、チーム全員が大きなホワイト ボードを備えた 1 つの部屋に座っていますが、多くの場合、そうではなく、チームが分散しているか、ポストイットの何らかの形でのバックアップが求められています。

私は SharePoint の大ファンであり、既に社内にこれがあり、プラットフォーム上で既にコラボレーションとチーム作業を行っています。一意のログインを使用して別のツールを追加することはできますが、チームは本当にそれらを使用する必要があります。

SharePoint をすぐに使用できるようにしようとしましたが、うまくいきませんでした。私はバージョン 1 を使用してみました (何年にもわたって何度も、多くのチームで) が、ツールが多すぎて、オプションや実行する必要があるものが多すぎて邪魔になることがわかりました。ホワイトボードから遠く離れています。

そこで、自分のプロジェクトに必要なものを開発することにしました。シンプルなツールが必要で、37signals (basecamp の作成者) のアプローチを使用して、競合他社よりも機能が少ないものが必要でした。

21Scrumは、SharePoint 上に構築されたシンプルなスクラム ツールであり、プラットフォームを使用し、必要なもの (ホワイト ボード、バーンダウン チャート) を追加して、プロジェクトを進めることができます。

おそらく、これは既に SharePoint を持っていて使用しているユーザーにとっては最良の選択肢かもしれません - 少なくともそれが目標です。

于 2010-05-06T18:47:02.210 に答える
0

リリース/スプリント計画、製品バックログ、スプリント バックログのリストを備えた SharePoint ワークスペースをセットアップしました。

中心的な要素は、この SharePoint のタスク ボードです。同じ場所にいなくても、ストーリーとタスクをドラッグ アンド ドロップできます。 http://www.youtube.com/watch?v=XW89M0C3N7Q

バーンダウン レポートは、進行状況を自動的に視覚化します。

よく働く!

于 2013-01-23T10:51:39.620 に答える
-3

私の知る限り、Sharepoint は ASP.net であり、無料の特典があります。アジャイルなプロジェクト管理用に設計されていないため、独自のサイトを展開する必要があります。
私見は、仕事をあなたが持っているツールに曲げようとするのではなく..仕事のためのより良いツールに切り替えることは、より良い選択肢になるでしょう。このスレッドをチェックして、あなたの法案に合ったより軽量なものがあるかどうかを確認してください.

また、個人的には、開発活動をデジタル化しないことの大ファンです。そのため、バックログにスプレッドシートを使用し、そのチャートと Big Visible チャートを投稿します。デジカメを使用して、ダイアグラム/設計ディスカッションのスナップショット (ツール用の Google ホワイトボードの写真) またはレポートを保持します。「プロジェクト管理」ツールのほとんどは、即時のステータス更新を生成するための言い訳に過ぎないことがわかりました..ソフトウェア開発 (これが主な目標です) の邪魔になり、社会的相互作用をあまりにも頻繁に阻害します.

免責事項:sharepointの経験はまったくありません..過去2日間に読んだことを除いて、完全に軌道から外れている可能性があります

于 2009-02-12T05:50:37.700 に答える