👟 👨🏽‍🔬 🕷️ アジャイルとスクラムの出会い方 👩‍🚀 📙 🎟️

はじめに

いずれにしても、これはスクラムの導入方法に関するガイドであるとは言いたくありません。これは、スクラムを1つの会社のニーズに合わせて導入し、適応させた経験にすぎません。この経験は、基本的なヒント、ステージ、サイクルなどの初心者にとっても、専門家にとっても、何がうまくいかなかったのか、やる価値がなかったのかなどを議論するための、興味深い/有用です私たちに起こったことは、スクラムを連想させるものに過ぎないことを強調します。

背景、それがどのように始まったのか、どのようにしてスクラムが必要になったのか

私は、中小規模のTomsk社でITマネージャー（プロジェクトマネージャー）として働いています。活動開始時のIT部門の従業員数：5人、現時点では24人。

初期段階では、私はゲームデザイナーでしたが、プロジェクトマネージャーは徐々にキャンプに移りました。およそ、これは2014年の夏に発生しました。今回は出発点と見なされます。

ほとんどの初心者マネージャーと同じように、私は急いで資料を勉強しました：インターネットを検索し、会議の記録を見て、本を読んで、他の会社の兄とコミュニケーションを取り、当時考えていたように多くの知識を得ました（これは当然間違いでした）。そして、野心的で、新しい目標と目標に触発された私は、戦いに突入しました。

私は、初心者マネージャーの主な問題である従業員との不在または不正確なコミュニケーションについて考えます。この問題には多くの理由があります：経験不足、従業員の不信、主要な技術/ビジネスプロセスの知識の不足など。しかし、私はこの件で幸運でした。最初は、ゲームデザイナーとして開発者と緊密に連携していましたが、それ以前は管理が完全に欠如しているプログラマーとして働いていたため、何が欠けているかについて一定のビジョンがありました。

スクラム前の様子

当初、プラグインと設定なしで古いRedmineをデプロイしましたが、ほとんどクリーンで、TeamCity（無料）と見なすことができます。一般に、すべてが機能しました。

タスクは完了し、数時間、時にはパーセンテージが設定されるため、redmineで設定されましたが、締め切りや計画がなかった場合が多く、締め切り交渉さえあれば幸運でした。

そして、私の時が来ました。リーダーシップは、私の心が望むものを何でも使用することを約束しました（より多くの利益をもたらします）。上で書いたように、これは2014年の夏です。

当時、私たちはまだ大学のコースであるアジャイルやいくつかの記事にあまり精通していませんでした。そのため、私たちにはまだ柔軟性についての考えがなく、昔ながらの方法で行動し始めました（おそらく考えが生じましたが、経験の不足や他の何かが彼らをさらに突破させることはできませんでした）。最初に、ほとんどすべてのオフィスにあるボード上のメインタスクを修正しました。このように見えた：

当然、すべてが電子形式に転送されました：一部のタスクでは、機能または叙事詩の形でredmineで修正されました。古き良きExcelの一部では、タスクを完了するための重要性とおおよその期限を設定しました。その後、タスクを実行する各従業員とのタスクの分解と評価を開始しました。その結果、サブタスクを備えた機能セットと、タスクを完了するための期限の推定値が得られました。ある種のバックログが判明しましたが、何らかの方法でさらに作業する必要があります。それだけでは結果が得られません。

ガントチャート

しばらく前に、プログラマーとして働いていた会社でガントチャート（テープチャート）に出会いました。私たちのプロジェクトでいくつかの図を作成し、管理者にスケッチを見せましたが、彼らはこのテクニックを気に入っていました。そして、私はこれらの図表を可能な限り最良の方法で作成できるツールを研究し始めました。

私はテストされました：

たとえば、ガントプランニングなど、 多くのデスクトッププログラムは、インターネットで簡単に見つけることができます。それらのいくつかは不快な品質のもので、一部は有料でした。私が言及できる唯一のものは、ガントプロジェクトです。非常に便利で、必要な図を簡単かつ迅速に作成できます。短所：私は無料版を持っているという事実のために、それは正しい形式でアップロードすることを許可しませんでした、そして1つのプロジェクトでチーム作業の可能性の欠如。
1C Bitrix CRM 。当時、私たちはこのプログラムを企業に積極的に導入しました。彼女は、いくつかの機能が制限されたダイアグラムを作成することを許可しました。短所：インターフェースの混雑、チャートの色を変更する機能の欠如（私は本当に好きではありませんでした）、再び、その時点で正しい形式でアンロードする可能性はありませんでした（現在はそうです）。大きなプラスはチームワークの可能性ですが、IT部門の私たちはこのプログラムの仕事が特に好きではありませんでした。
レッドマイン ここではすべてが簡単です-期限を設定してタスクを設定すると、ダイアグラム自体が表示されます。短所：多くの開発者が関与して仮想の計画を作成し、計画に従って何が起こっているのかを確認したい場合、開発者はそれをすべて確認し、全員がワークスペースを散らかし始め、再び美しい色を作る方法はありません。
MSプロジェクト 。ある理由でそれを逃しましたが、後で積極的に使用し、チームワークのセットアップの難しさを除いてすべてが好きでした。
メガプラン 古い会社のCRMシステム。すぐに却下され、それはすべて便利ではありませんでした。
MS Excel 古き良き、いくつかの計画のために私はまだ時々それを使用します。

計画は次のとおりです。

その結果 、いくつかのプログラムに出くわし、それらを時々変更して、数か月間、ガントチャートを積極的に使用してプロジェクトを実施しました。経営陣はそれをすべて気に入っており、明確で承認された計画を見ており、小さなBUT（大）を除いてすべてが順調でした。

このBUT 、管理だけでなく、マーケティング担当者、販売など。最も適切でない瞬間に、開発を常に計画に押し込む。これにより、計画を完全に再構築し、開発者のタスクをシフトする必要があり、ダウンタイムがある場合は新しいタスクが発明されました。チームに人がほとんどいなかったとき、特別な問題はありませんでした。数人を移すことはそれほど悪くはありませんでしたが、2人以上が1つのタスクの完了に依存し始め、時にはタスクが完全になくなるポイントまでそれらを押し進めると、計画を立て直すことが問題になりました。

これは、他の何かの必要性が生じた場所です。

ニーズは何でしたか

経営陣と会社の主人公からのフィードバックを集めて、私が見たかったもののリストが作成されました。

開発の透明性。各部門（特に管理者）は、現時点で、そして次の結果がいつになるかについて、開発中のものを見ておくべきでした。
いつでも開発に変更を加えます。ディレクターは、開発プロセスにすばやく影響を与えたいと考えていました。
結果の報告。経営陣は、報告活動を見たいと考えていました。
ランタイムと優先度を持つタスクプール

開発者からのフィードバックも収集されました。

タスクを完了するための期限のより詳細な評価。
外部開発への干渉の影響を最小限に抑える。
着信タスクに関する開発者の意識を事前に高めます。
進行中のプロジェクトの全体像を提供します。

まだ考慮されたもの

プロセスを中断できないように、厳密に規制された「ウォーターフォール」の導入。しかし、そのような中断の機会はすべて、リーダーシップを圧倒しました。
かんばんですが、どういうわけかそれ以上先に進めませんでした。正確な理由を示すことはできません。
オプション：「まあ、神と」、しかし彼はすでにみんなを手に入れた！

スクラムがニーズを満たす理由

柔軟性。 ほとんどいつでも、優先順位を確認して新しい機能を導入できます。
透明性 誰もが（主人公とともに）メールにスプリントリストを持っているので、最初はすべてのオフィスでそれを掛けました。また、スクラムデスクでオフィスに移動して、現在誰が何をしているのかを確認することもできます。
報告スプリント終了時のデモンストレーション。結果として何が起こったかを（ある程度）理解できるようにするかなり良い手順です。
プロジェクトの詳細図（バックログの分解の程度に依存）。 常に更新されることにより、プログラマーとマネージャーの両方がプロジェクトの特定のビジョンを得ることができます。
開発者の安全性 開発者は、少なくともスプリントの間、外部の干渉から安全です。
より詳細な設計/計画。 開発者が完全に理解するまで、またはミニスプリント-分析/設計が配置されるまで、タスクはスプリントに取り込まれません。
継続的かつ周期的なプロセス改善。 デモの後、フィードバックはキャンセルされていません。毎日の会議（会議）もプロセスの改善に積極的に貢献しています。そして回顧：悪い点はすべて改善してください！

すべてに伝えられるように

開発者は記事から基本概念を理解していたので、実質的に問題はありませんでした。全員が熱意をもってそれを受け入れました。主な問題はリーダーシップでしたが、実際にはプロセスに関与していないため、私たちはカードの管理下にあります。

どうやって学びましたか？何を見ましたか？どのリソースですか？どんな本？

専門家とのコミュニケーション

他の会社のマネージャーと話をして、彼らが何をどのように持っているかを学びました。私たちは、彼らが標準からどのような逸脱をしたか、どのように、そして何を適用できるかを見ました。正直に言うと、彼らはそこから多くを得ることはありませんでした。 主な結論：誰もが好きなように行動します（アジャイルは彼らにとって便利です）。

記事を読む

正確に表示された記事を修正しましたが、誰も覚えていません。しかし、たくさんありました。これには十分な時間がありました。当然、すべてはアジャイルマニフェストに基づいており、ほとんどの記事とサイトはそれにリンクしているので、私たちも例外ではなく、それをソースとして採用しました。 （リンクはソースとリンクにあります）

本を読む

多くの本はレビューされていません。一瞬アドバイスした人の中には一見したが、何も違いは見られず、読み上げを止めた。メイン（私にとって）は、「アジャイルとXPの上級者向けノート」だと思います。3回読みました。いつも質問があれば、「スクラムについて知るにはどうすればいいですか？」と呼びます。 （リンクはソースとリンクにあります）

実装開始

キーイベント文書

メインイベントをペイントし、アクションの説明を含む小さなリストを作成し、レビューのためにすべての従業員に配布しました。当時、彼はもちろん完璧からは程遠いものでした。 （リンクはソースとリンクにあります）

カード

当然、どこかでポーカーのプランニング用のカードを入手する必要がありました。インターネット上の多くの店舗をレビューしたところ、4人のデッキのコストは1,000ルーブルから2,000ルーブルの範囲でした。特に経営陣にお金を要求したくなかったので、自分で作りました。普通のA4用紙、白黒プリンター、はさみ-これは何が起こったかです：

多くの場合、カラープリンタ、厚紙など、それらを作り直そうとしましたが、これらの古き良きカード（完全な力ではありません）はまだ機能します。

興味深い事実。 何も混ぜていないことを願っています。当時私が気に入っていたカード販売店は、planningpoker.ruでした。それから、なんてクールなカードだと思いました。その後、会議で数年経った後、この店を組織した会社のディレクターが、偶然にもこれらのデッキの1つを見せてくれました。 （リンクはソースとリンクにあります）

ボード

次の重要なステップは、スクラムデスクの準備で、通常のWhatmanペーパー、A3とA4のペア、マーカー、スコッチテープなどを使用しました。

準備の結果として起こったこと

メインステージに精通したチーム。
Redmineによって準備されたタスクリストがコンパイルされました。
ポーカープランニングにより作成。
スクラムデスクにより作成。
そして、多くの熱意。

最初の経験、最初のスプリント

バックログ

MS Excelで最初に作成したバックログでは、必要に応じてすべてを列に分割しました。

当然、図には含まれていない列がいくつかありますが、これは別の話です。アジャイルの慣習であるユーザーの要望（ユーザーストーリー）ではなく、タスク（機能）を正確に取得したことを強調します。最初のスプリントは、2週間にすることにしました。優先順位を設定し、ソートし、緑色でマークし、スプリントでやりたいことを、ストーリーポイントを配置します。うーん、ストーリーポイントとは何ですか？！

開発者の注意を引くように。ストーリーポイント-日

ストーリーポイントレーティングシステム-理想的な人の日々は、開発者が切り替えるのはかなり難しく、理解しにくいものです。ストーリーポイントについて説明したように、これは開発者の理想的な8時間の就業日であり、彼がすべてを手元に置いて、仕事から気を散らすものは何もありません（問題はすでに顕著であり、すべてがそこにあり、うーんと干渉しません...）、彼は他の人から隔離されています新鮮な空気、食べ物、お茶/コーヒー、トイレがあり、彼は生産的に仕事を果たし、その解決策は彼にとって完全に明確な部屋です。新人に説明するときにいくつかのことを追加しましたが、それらは実際には重要ではありません。

役割分担

当社にはクロス開発者はほとんどいませんか？別のテスターがあり、さまざまなプラットフォーム向けに開発しています。したがって、労働者の統一として、スクラムの概念の1つに弱く依存しています。私たちはそれを無視し、最初のスプリントでは同じチームに異なる開発者がいました。

計画中

スプリントに行くことになっているバックログのすべての機能が印刷され、評価を開始しました。

スプリント計画で行ったアクション：

ボード上のすべての葉を貼り付けます。
私たちは目標をスプリントで達成することを宣言しますが、残念ながら（幸いなことに）いくつかの目標があり、さまざまなプロジェクトの開発者が計画に参加したため、単一の目標はありませんでした。
主任開発者は、各機能について個別に全員に伝えます。
質問が発生した場合、それらはすぐに解決されます。
各機能をサブタスクに分解し始め、再び、なぜそうでないかを正確に説明します。
すべてのタスクが分解されて理解できる場合、ポーカープランニングを使用して評価を開始します。
1つのサブタスクが呼び出され、誰かが理解できない場合は再度説明されます。
このタスクを実行する能力のあるすべての開発者（多くの場合、ほとんどすべて）は、このタスクのストーリーポイントに等しい数字で表を下に向けます。
全員がカードを配置したら、カードを裏返します。
強い矛盾がある場合、評価を他の人と対立させて投稿した開発者は、この評価が発生した理由を他の人に説明します。彼が何かを理解していなければ、彼らは再びすべてを彼に説明します。次に、再評価。
強い違いがない場合、評価されたサブタスクには、開発者が割り当てた値が割り当てられます。
このようにして、すべてのサブタスクが評価され、サブタスクの合計から機能スコアが追加されます。
機能の評価が予備的な評価と大きく異なる場合は、後で対処する必要があります。
スプリントにフィーチャを入力します。最初のスプリントでは、開発者が2週間のスプリントで約7つのストーリーポイントを完了することができることがわかりました。したがって、それらが5つある場合、35ストーリーポイントでタスクを実行できます。後で間違いになったことが判明したため、私たちはさらに39を取りました。
撮影した機能をスクラムデスクに投稿します。
毎日の会議（会議）の時間、デモンストレーションの日時を割り当てます。
始めましょう。

最初の会議は成功し、5〜6人の参加で約4時間かかりました。当然のことながら（私たちにとって判明したように）、当初計画されていたすべてのものからはほど遠いものがスプリントされました。ディレクターは計画会議の一部に出席していました。彼とチームはこのイベントを本当に気に入り、チームは熱心に機能の実装を開始しました。

コンパイルされたスクラムリスト（MS Word）：

（リンクはソースとリンクにあります）

スプリントとチームに名前を付けてください。
目標を達成するために指定された目標、チームの主なタスク。
スプリントバックログ-目標を達成するために完了する必要がある機能。括弧内のスコアはストーリーポイントです。同じタスクがスクラムデスクにかかっています。
指定されたスプリントの日付、および毎日の会議（集会）とデモの時間と場所。
チームメンバーの列挙（括弧内）、このスプリントでの雇用率（何もない場合は100％）。

最初に、このシートを印刷して各オフィスに吊るし、また主要な俳優に郵送しました。しかし後になって、これは単なる紙の無駄であり、誰も本当にそれを必要としていないことが判明しました。開発者のオフィスでは1枚のシートで十分でした（後でオフィスが増えたとき）。

なぜシートが必要なのですか？

プロジェクトに関係する他のチームや人々が、このチームまたはそのチームが現在実行しているタスクを想像するために。また、一定期間後に結果がどうなるかを確認するためにも。

デイリープレーナー

時計仕掛けのように、誰もが最初の会議に来ましたが、これは幸せではありません（将来はそれほどバラ色ではありませんでした）。彼らは集まり、だれと物事が起こっているのかを交互に話し始めました。誰も質問や問題を抱えていませんでした。スクラムデスクに切り替えました。

ペーパータスクボード

ステッカーは動き始め、すでに問題がありました。ステッカーがテープ上の紙に接着されていたため、引き剥がして再貼り付けが問題でした。彼らはこの悲しみに半分で対処しました（後に彼らはコツを獲得しましたが、これは問題にはなりませんでした）。彼らは燃え尽きたストーリーポイントを書き始めた後、特定の質問が生じました。開発者は誰も問題や質問を持っていなかったし、燃えたストーリーポイントだけでは十分ではありません。いつものように、理由は平凡です：誰かがスイングするのに少し時間がかかり、彼は常に自分のタスクを実行しませんでした、誰かが準備作業を実行しましたが、それはスプリントではまったく同じ精神で敷かれていませんでした。その結果、次のようなものが得られました。

当初、ステッカーは単にボードに貼り付いていましたが、時間が経つにつれてスコッチテープでさらに修正されるようになり、すべてが飛び散ったときにいくつかの先例がありました。その後、テスト、コードレビューなどで、このタイプの列がさらに2つ登場しました。

なぜ燃え尽きるのですか？

バーンダウンは、スプリントチームの進捗を追跡できるようにするため、また計画からの逸脱を時間内に視覚的に確認するために必要です。バーンダウンの主な目的は、逸脱が発生した場合に運用上の対策を講じる必要があることをチームに示すことです（自己組織化チームがあるため）。

バーンダウンを作成する方法は？

多くのツールを使用すると、バーンダウン図を電子形式で作成できます。MSExcelを使用し、whatmanを使用して作成しました。

最初（後で追加の列が表示されます）、テーブルには以下が含まれていました。

最初の列は、スプリントの最初の稼働日から最後の稼働日までの日付です。
2列目-ストーリーポイントをどれだけ書き込むか。計画セッション中は毎日、値が表示されます。
3番目の列は、 スプリント中にチームがストーリーポイントを完全に書き込むための標準です。 1日あたりの書き込みに理想的=スプリントあたりの撮影ポイント数/日数。

残念ながら、それは紙の形で保存されていませんでした。最近、世界的な清掃が行われ、すべてのゴミが捨てられました。

電子形式では、MS Excelを使用して行われました。

図からわかるように、最初のスプリントはほぼ成功し、理想的なパフォーマンスからのわずかな逸脱がありました。 しかし 、ルールが言うように：スプリントの終わりに燃えたストーリーポイントがない場合、スプリントは失敗します。このルールに対して、その瞬間、私たちは目を閉じて、スプリントが正常に完了したことを喜びました！

デモンストレーション

スプリントの結果を経営陣に紹介する時が来ました。「チーム」（マネージャー）がプレゼンテーションを準備し、将来、チームの各メンバーが自分の役割を果たしました。当初、プレゼンテーションの標準はありませんでした。多くの観客が集まりました：経営陣、販売およびマーケティング部門の一部。

プレゼンテーションはMS Powerpointで行われました。

最初のプレゼンテーションにはスライドが4つしかありませんでした。そのため、説明するスライドがなかったため、開発者が説明するのは困難でしたが、将来は修正しました。

デモはどこでどのように行われましたか

当時、開発者のオフィスで開催された会議室でのプレゼンテーションは行わなかったため、プロジェクターを取り出して壁に光を当てました。

最初、マネージャー（I）が話し、誰もがここに集まった理由を話し、スプリントの主な目標と目的を話し、開発者が交代し始め、マネージャーはバーンダウンダイアグラムのデモと一般からの質問で終わりました。

デモのマネージャーの主なタスク：

スプリントのタスクと目標を全員に紹介します。
開発者のパフォーマンス中にすべての質問と提案を修正します。
質問に答えて、開発者を支援します。
開発者のプレゼンテーションのすべての欠陥/肯定的な側面を修正します。
バーンダウンデモでスプリントを要約します。
プレゼンテーションの最後にすべての質問を記録して回答してください。
フィードバックを取得します。

最初のデモの開発者

最初のデモンストレーションでは、他に10個のスプリントがあったので、開発者は自分で言った：複雑な用語の使用、主題領域の深化、結果のデモンストレーションは普通の人には向いていない。最初のスプリントでは、時には今でも、興味のある人々が何が起こっているのか理解できるように、開発者のデモを言い換えて要約する必要がありました。

デモ視聴者

大衆の側には多くの抽象的な質問があり、それはデモンストレーションされたスプリントに間接的に関連し、彼らは本当に答えを得たいと思っていました。これは今日まで非常に長引くデモンストレーションです。最初のデモは約1時間半続きました。

回顧

開発者にとっても最初のスプリントは成功しました。レビューは肯定的でした。

最初の回顧展で議論された改善点：

プレゼンテーションでさらにスライドを行う必要があります。
プロジェクトに間接的に関連する人々のデモを求めないでください。
労働者の機器を改善するためのいくつかの技術的な微妙さ;
計画に関する機能を議論するために、スプリント中に考慮されなかったいくつかのニュアンスが発見されました。

経営陣からのフィードバック

私はすべてが好きで、プレゼンテーションにはさらにスライドが必要です。経営者は、開発者のRFPのボーナス部分をスプリントデモンストレーションの結果にリンクさせたいと考えていました。利害関係者は各開発者にこの評価の基準で主観的な評価を与え、マネージャーの評価はすべての評価の算術平均です。このシステムは実際には定着していませんが、これはまったく別の話です。

どうだった

最初のスプリントの後、多くの水がすでに漏れていて、プロセスを最適化するために多くの行動が取られました。

どのような対策が講じられていますか

チームワークの理由

当初、開発プロファイルの異なる2つのチームがあり、それぞれにブラックジャックとスクラムデスクを備えた独自のスクラムがありました。しかし、私たちは常に、そして現在、経営陣（私は実際には1人）にドローダウンがあるため、2つのチームの計画、保守、実証のプロセスを整理する時間はありませんでした。このため、チームを1つにまとめることにしました。

はい、それはしばらくの間勝つのを助けました、しかし、いいえ、それはポジティブな結果を生み出しませんでした。これには4つのスプリントが続きましたが、チームの開発プロファイルはまったく異なるため、開発者は協力する必要がまったくありませんでした。

チームの分離

時間が経つにつれて、より多くの労働者とより多くの開発分野があり、携帯電話などが登場しました。チームの関連付けに関する段落で述べたように、プロジェクトの開発においてチーム間の直接的なつながりがない場合、人々は協力することは絶対にありません。したがって、チームを異なる方向に分割しました。はい、個々のチームに生産的な結果をもたらしましたが、各チームはマネージャーの多くの時間を浪費しました。

スプリント時間の変動

さまざまなバリエーションを試しました：

2週間のスプリント。 開発作業と計画作業の最適な比率。しかし、マイナスがあります。2週間にわたって、追加の（管理者からのスマートまたは緊急タスク）タスクがあります。このため、スプリントは常に正常に終了しません。
毎週のスプリント。 この比率は、作業の計画に向いています。しかし、サードパーティのタスクはほとんどなく、すべてのスプリントは正常に終了します。
4週間のスプリント。 結果のスプリントに非常に大きな偏差があることがわかります。私たちにとって最も不幸なスプリント。

その結果、2週間のスプリントに落ち着きました。

マーカー付きのボードに切り替えました

彼らはWhatmanの論文を放棄しました、それはいようで、開発者は壁紙でそれを好きではありませんでした。

そして、紙からテープを引き裂く問題を解決します。しかし、新しい問題が現れました-ボード上の接着剤。開発者のオフィスのテレビに図のイメージを表示し始めたため、紙の形式のバーンダウン図も消えました。

次の段階：彼らはボード上のマーカーで集会の毎日のテーブルを書き始めました：

この表には、番号、計画からではない書き込みタスクの列、計画からの書き込みタスクの列が含まれます。

クラウドソリューションへの切り替え：Googleドキュメント

Googleドキュメントクラウドソリューションに切り替えた、拒否されたMS製品。スクラム/スプリントリストもアップグレードされました。シートの最初のバージョンとの主な違い：タスクは従業員ごとに分割され、分解されます。 （リンクはソースとリンクにあります）

彼らはグーグルの表の図を燃やし始めました。 :

sprint'e : sprint ( , ), — off-plan, .

, : Real, Off-plan (error) Off-plan (extra):

Ideally. — .
Plan. .
Off-plan (error). , , — .
Off-plan (extra). , sprint'a (smart ).
Real. = + + .

google

, :

, , .

Redmine

Redmine, — Backlog's. backlog' sprint' Redmine:

, , . Redmine, — . Sprint «» Redmine. , .

story-points sprint'. , sprint story-ponts. , , , . story-points sprint — .

. .

?

: . . .

?

:

.
sprint', backlog .
, .
( ).
, .
, , .

, , 1 , . , CRM. - : — scrumban.ru. ( )

MS Project .

おわりに

結論として、これは決してガイドではなく、1つの小さな会社の経験にすぎないことを繰り返します。記事を読んだ後、あなたは前向きな考えを持ち、あなたが自分にとって有用な何かを引き出し、おそらくそれを行う方法を経験することを願っています。

ソースとリンク：

» 本：“スクラムとXP：高度なメモ”

» アジャイルマニフェスト

» 主要なイベントを含むドキュメント

» スクラムリスト（最初）

» ポーカープランニングを購入するストアへのリンク

» スクラムリストの経時表示

» ボードビトリクス用

アジャイルとスクラムの出会い方