「スクラムの偉大な力」と「滝の方法論の劣等性」に関するさまざまな入門資料でこの記事を開始するには、テクノロジーを作成するための前提条件の歴史から、現在の実装。 ことわざにあるように：「求める人は常に見つけます...」（c）:-)。
私はいくつかの経験を共有したいと思います。そしておそらく、いくつかのIT企業の「既存のソフトウェア動物園」、つまりアプローチと実装に関する私の意見を共有したいと思います。
それでは始めましょう...
当然、新しい製品を作成するか、既存の製品を改善するには、まず市場を調査し、顧客のニーズを分析し、いくつかのとんでもない概念とTKを作成する必要があります。「システムのより大きな恐怖とパワー」のために、可能な限り次のような表現を使用する必要があります：既存のアーティファクトに基づいて、開発されたメタモデルは実際のユーザーに役立ちます...」、用語と略語のみを使用することは必須であり、もちろん前提条件は「vacの球状の馬」の説明です 心。」 次に、これらのすべての概念を詳細に分析し、数百万のモデルを成長させる必要があります。単純なIDEFダイアグラムから、あらゆる種類の関連付け、集約、およびその他の「属性」を持つ巨大なUMLモデルまで。 その結果、新しい「スパイダー」がますます増えています。 エンドユーザーは、これらのモデル、図などについて気にしません。作業ボタンが必要です...
この後、開発が直接開始され、プログラマーは、ToRで書かれたように、意図したものを「リベット」し始めます。 ドキュメントとテストを省略します...市場での製品の発売にすぐに進みます。 マーケティング担当者は、SuperMegaSistemaPro製品のリリースに関する一連の紙を開発しました。これにより、「あれこれを自動化するシステム」になるだけでなく、（過度の謙虚さなしに）...それ...それは、一般に「全世界を自動化」することができます:-)。 システムはすべてパワフルで現代的であるように見えますが、何らかの理由で顧客は不満を抱いています。システムはすべてに関するものですが、実際には何もありません。 その結果、既存の製品は全員をscり始め、SDK（もしあれば）の助けを借りて田舎の実装者は、顧客だけが満足すれば、より多くの新しいプラグインを「リベット」します。 その結果、動物園は成長しています...
既存のソフトウェアの問題は直接「表面に」あり、それらを探す必要はなく、はるかに少ない深さから引き出されます。 それにもかかわらず、新しい議論が始まり、新しい概念が...最終的には「誰が森の中に、誰が火のそばにいるのか」...しかし、最も重要なことは、既存の欠点が広い意味で隠されているため、新しいシステムはさらに複雑になり、理解されていないことです。 プログラマーのせいではないので、費やされた時間（2〜5年）は残念ですが、「コードのトン」が投げられることはさらに残念です。
デマゴジーの後、「ウォーターフォールアプローチ」について離婚しました:-)実際に機能するSCRUMテクノロジーに切り替えるのは理にかなっています。 この技術は、製品の活性化を本当に助け、新しい高品質の製品の開発に貢献します。
イニシアチブ開発チームは、既存の状況を修正しようとして、SCRUMに取り組むことを決定しました。 プログラマー、アナリスト、テスターで構成されるチームが形成されました。チームは、ProductBacklogとSCRUMマスターを備えたProductOwnerでした。
プロセス
SCRUMプラクティスといくつかのXPプラクティス（eXtreme Programming）を組み合わせました。 SCRUMは管理と組織の問題を解決し、XPはエンジニアリングの実践を専門としています。 XPから借りたもの：ペアプログラミング、リファクタリング、CodeReview、およびコードの文体的な説明。 また、振り返ってみると、私たちは私たちが順守している多くのルールを自分自身のために特定しました。 質の高いGUIを設計するために、文字を使用する方法を使用します。
軽量のドキュメントのみを使用します。データベースダイアグラムとUMLモデルは、それぞれ開発時にのみ成長します。これらは、上記のようなひどいクモではありません。
計画中
私たちのチームのスプリント計画はほぼ終日続きますが、スプリントの計画が不十分な場合は、反復を単純に「埋める」ことができます。 したがって、計画はSCRUMプロジェクトの最も重要な部分です。
理想的な時間を計算するには、0.4のフォーカスファクターを使用します。 原則として、このような指標はすべての反復の平均であり、通常は予定されたタスクを時間通りに完了することができるため、最適です。
計画は通常、「デザインウォール」（マーカー付きのホワイトボード）の近く、または以前の機能とGUIをはっきりと見ることができるコンピューターのあるテーブルで行われます。 いくつかのダイアログがボード上にすぐに描画されて撮影され、これらの写真はタスクの実際の実行に関与します。 PlanningPokerを使用して複雑さを評価するために、ほとんどすべてのタスクをテストできます。これにより、すべてのエラーをすぐに識別できます。
スクラム-ラリー
毎日の会議は、SCRUMボードの近くで1日に2回開催されます。 会議の後、燃焼スケジュールにマークが付けられます。 タスクは完了した、つまり テスト後にのみ「完了」に転送されます。 プログラマーは、アナリストが実行のために前のタスクを承認した後にのみ、InProgressで次のタスクを実行できます。 スクラムマスターは燃焼ダイアグラムを「ノックアウト」します。 15分の制限時間を超えないように、会議は立った状態で開催されます。 会議では、何をしたか、次に何をするか、どのような問題があるかを判断します。 技術的な詳細については議論しませんが、常にうまくいくとは限りません。 通常、会議は10分以内です。 ラリーでいくつかの技術的な問題が特定された場合は、「デザインウォール」（マーカーのあるボード）の近くでスクラムラリーが行われた後、議論が行われます。
スクラム-ボード
スクラムボードとして、通常のコルクボードを使用します。 ボード領域を、ToDo（実行する必要があるもの）、InProgress（作業中）、Done（完了）の3つの部分に分割しました。
ただし、プログラム内の電子版のボード（UserStory、タスク、関与するチームメンバーの参加率など）も維持します。 これは、「ストーリーのために」行われます。作業では、ボードのみを使用します。
燃焼スケジュール
燃焼グラフは、進行状況の明確な指標です。 X軸は時間軸です。 Y軸-未処理のタスクの複雑さ。 テスターによって検証された場合、タスクは完了したと見なされます。それ以外の場合、タスクは完了していません。
完了したタスクは、スクラムボードの「完了」セクションに転送されます。 したがって、グラフには「ToDo」および「InProgress」セクションのタスクの複雑さの合計が表示されます。 毎日の集会の後、その日の完了したタスクを考慮して燃焼図が「ノックアウト」されます。 また、実装に関する情報がプログラムに記録され、タスクの完了日である「進行中」にタスクの日付が明確に表示されます。 製品は、チームの平均速度、フォーカスファクターを自動的に計算します。 この情報は、タスクの複雑さとチームのフォーカス要因を再評価するのに役立つ場合があります。
デモンストレーション
デモは通常午後に行われます。 私たちは、できるだけ多くの興味のある人を招待し、彼らの願いを考慮に入れようとします。
回顧
多くのスクラムの達人はバーやパブなどで回顧展を行うことを提案していますが、通常はデモの直後に何かおいしいものを回顧展します。 どういうわけかこのアイデアを検討できると思います。
振り返ってみると、各チームメンバーは、自分が好きまたは嫌いだった瞬間について話し、チーム内のプロセスを改善するためのアイデアを提供します。 いくつかの組織的な問題、チームワークについても説明します。
レトロスペクティブを実施するには、マーカー付きのボードを使用します。このボードは、条件付きで4つのブロック（マイナス、プラス、アイデア、計画）に分割されています。 すべての参加者が発言し、すべてのアイデアが書き留められた後、磁気チップを配置して投票します。 事実上、「計画」ブロックに記録されたすべてのものは、その後に従うことを試みます。
SCRUMに取り組んだ結果、私たちのチームはこれらの問題の多くを「表面的に」迅速かつ効率的に解決することができました（システムは復活しませんでしたが、それらはゼロから作成されました）。
「スクラムの大きな力」が私たちと共にあり、ユーザーにボタンを機能させてくれますように！
動物園を回避する方法、またはユーザーにボタンを機能させる方法...
All Articles