1,099 測定値

生産性を高め、苦痛を軽減してスクラムを使用する方法

に Mario Casari14m2023/07/22

長すぎる; 読むには

ソフトウェア開発は、1 人の開発者が担当する最小限のプロジェクトであっても複雑な問題です。プロジェクトを開発するためのチームが必要な場合、多くの組織上の問題が発生します。アジャイル手法はこれらの問題を解決する試みですが、実際に役立つのは、割り引いて、無意味な拡大を回避する場合に限られます。

featured image - 生産性を高め、苦痛を軽減してスクラムを使用する方法

ソフトウェア開発に取り組むことは、最もクリーンで簡単なことではありません。これには、技術的および非技術的な問題を含む無数の問題が含まれます。技術的な側面は確かにはるかに複雑で、難しいスキルが必要ですが、同時に、適切な戦術とツールを使用することで、何らかの方法で管理できます。一方、非技術的な世界にははるかに自由度があります。それは人間の性質と同じ変動性と予測不可能性を持っています。

他の製品製造プロセスと同様に、ソフトウェア開発の初期の頃から、数多くのベストプラクティスが導入され、テストされてきました。アジャイル手法は、主に要件の極端な変動や、最終製品を提供するための最も重要な目標への焦点の欠如に対処するための一連のさまざまな方法です。

場合によっては、そのような方法論が本来の目的を超えてしまい、最終的な結果が理想とは程遠いものになることがあります。スクラムはこれらの方法論の 1 つです。これはフレームワークとして詳しく説明されています。それは、原則、ルール、イベント、役割の基本セットに基づいています。この記事では、このフレームワークを判断力と柔軟性を持って使用し、理想から程遠い可能性のある厳密な解釈を回避する方法について説明します。

スクラムの簡単な紹介

アジャイル方法論は、いわゆる「アジャイルマニフェスト」で定義されている次の一般原則に基づいています。

「プロセスやツールを超えた個人と相互作用」
「包括的なドキュメントよりも実際に動作するソフトウェア」
「契約交渉をめぐる顧客の協力」
「計画に従って変化に対応する」

(出典:アジャイルマニフェスト)

アジャイル宣言によると、上記の記述では、右側の項目は重要ですが、左側の項目はそれ以上です。

開発プロセスの観点から見ると、アジャイル手法はすべて、古典的なウォーターフォールモデルではなく、反復的で増分的なプロセスを意味します。開発全体は多数の増分ステップで構成され、各ステップは、ウォーターフォールプロジェクト全体を特徴付ける同じフェーズ、つまり要件の収集、分析、設計、コーディングで構成されます。つまり、各ステップは開発全体の増分を表しており、それ自体をプロジェクト全体として見ることができます。

スクラム方法論は、上記の原則の特殊な偏向として見ることができます。スクラムは、チームが独自のプロセスを使用して特定のソフトウェア製品を開発できるフレームワークです。基本的には、ロール、イベント、アーティファクトによって特徴付けられます。

役割は次のとおりです。

チーム: アナリスト、開発者、テスター、そして一般にプロジェクトに関わるあらゆる種類の専門家が含まれます。これは、スクラム計画セッションの範囲内で自己組織化された方法で機能することになっています。
スクラムマスター: すべてのスクラムプロセスを調整し、会議を主催します。
製品所有者: 製品に対して責任を負います。彼/彼女は、いわゆるプロダクトバックログを管理します。これには、明確な方法で表現された必要な機能がすべて含まれています。彼/彼女はチームと話し合ったり、チームから支援を受けることはできますが、責任は彼/彼女が単独で負います。

イベントは次のとおりです。

Sprint : は、反復開発における 1 つの増分を表します。期間は通常 2 週間から 1 か月です。
スプリント計画: 2 週間のスプリントの場合は最大 4 時間、1 か月のスプリントの場合は最大 8 時間の会議です。これはスクラムマスターによって組織およびスケジュールされ、チームとプロダクトオーナーが含まれます。このミーティングでは、プロダクトバックログのいくつかの機能が選択、評価され、現在のスプリントで開発されるように議論されます。機能は優先度に基づいて選択されます。
毎日のスクラムミーティング: 15 分以内の毎日のミーティングです。それらはスクラムマスターによってスケジュールされます。これらのミーティングでは、チームの各メンバーが、現在のタスクを実行するために何をしたか、発生した問題、および起こり得る困難を克服する方法について説明します。スクラムマスターは、これらの会議のスケジュール設定と調整、および会議の適切な実行を担当します。
スプリントレビュー: 現在の春の終わりに行われるミーティングです。 2 週間のスプリントの場合は 2 時間、1 か月のスプリントの場合は 4 時間かかります。これはスクラムマスターによって組織され、参加者はスクラムチーム、スクラムマスター、プロダクトオーナー、およびプロダクトオーナーの決定に従って必要なすべての関係者です。現在の増分について説明します。何がうまくいき、何がうまくいかなかったのかが概説され、最後に必要に応じてプロダクトバックログが更新されます。
スプリントレトロスペクティブ: 2 週間のスプリントの場合は 1 時間、1 か月のスプリントの場合は 2 時間のミーティングです。これは、スプリントレビューの直後と次のスプリント計画の前に行われます。このミーティングでは、前回のイテレーションの経験に基づいて、最終製品の品質を改善および追加するためのすべてのアクションが議論され、次のスプリントに向けて計画されます。

アーティファクトは次のとおりです。

製品バックログ: 製品のすべての要件を含む進化するドキュメントです。各項目はユーザーストーリーと呼ばれ、説明、順序、見積もり、値などの属性があります。高次の項目ほど明確かつ詳細になります。
スプリントバックログ: 次のスプリント用に選択されたプロダクトバックログ項目と、必要な計画が組み合わされたものが含まれます。
ユーザーストーリー: 上で述べたように、ユーザーストーリーはプロダクトバックログの項目です。ユーザーストーリーは、一般的なテキスト構造に従います。「<親切な OS ユーザー>として、私は<何らかのタスクを実行> し、<何らかの目標を達成できる>ようにしたいと考えています。また、それぞれに次のスキーマを持つ多数の受け入れ基準も必要です。<何らかの前提条件>が与えられたとき、<ユーザーが何らかのタスクを実行したとき>その後、 <何らかのシステムステータスの変化が発生した>。
バーンダウンチャート: 横軸が時間を表し、縦軸が時間の各ステップで実行すべき残りの作業量を表すチャートです。作業量は、いわゆるストーリーポイントによって測定できます。ストーリーポイントは、スキル、複雑さ、ツールなど、開発作業に影響を与える可能性のあるすべての変数を考慮した作業の測定単位です。
増分: これまでの合計増分、つまり、これまでに完了したプロダクトバックログ項目と、過去の反復ですでに完了した他のすべての項目の合計です。

スクラムを何らかの教義と混同しないでください

上記の項目は、専門家が業務を遂行するためのベースとして考えることができます。これらは便利なツールのように見えますが、プロジェクトに結束力、相互コミュニケーション、効率性を本当にもたらすのは人々自身です。実際のところ、これらすべての処方箋が厳密に守られ、スクラムマスターがすべての取り組みを行っていたとしても、プロジェクトは混乱に陥り、惨めに失敗する可能性があります。

これは、人々がルール、方法論、フレームワークを、人間を正しい道に導くはずの何らかの神聖なエンジンと混同することが多いためです。それはよくある心理的欠陥です。非常に重要な考慮事項は、現実は理論とは異なり、非常に複雑で野生の動物であるということです。ルールとパターンのリストを使ってそれを制御できると考えているなら、あなたは失敗する運命にあります。

スクラムの本当の目的は、開発プロセスにおける「バックグラウンドノイズ」の量を最小限に抑え、最も重要なことに集中できるようにすることです。適切な柔軟性と謙虚さを持って使用すれば、効果的な効果が得られます。

次のセクションでは、スクラムの世界への旅をした実際の使用例について説明します。これは、私を含めた経験の浅い人々が初めて一貫した方法でアジャイルの原則を受け入れようとする旅でした。私が以前働いていた多くのプロジェクトは反復的な方法で作成されましたが、実際のアジャイルフレームワークの儀式全体は行われませんでした。

実際の使用例

ここでは、スクラムフレームワークの厳密な採用とは程遠い実際の使用例について説明します。このプロジェクトは、組織標本の収集からさまざまなステップでの処理、最終的な組織スライドの配布まで、解剖病理学研究室に関わるすべての活動を追跡することを目的としたソフトウェアシステムに関するものでした。このシステムは、特定のソフトウェアドライバーによって、特定の段階で外部の自動化機械と統合されることも想定されていました。

私はソフトウェアアーキテクトとしてこのプロジェクトに参加しました。主要な問題の概要を説明し、基本的なアーキテクチャの青写真を考案するには、プロジェクトマネージャーと協力する必要がありました。アジャイルの原則に徹底的に従う場合、事前にアーキテクチャを考えることは最善の策ではありません。アーキテクチャ設計も反復シナリオで見られます。ただし、ほとんどの状況では、開始するための基礎が必要であり、それについて関係者全員と話し合う必要があります。

私は、ビュー、視点、パースペクティブに基づいた構造化されたアプローチで、コンテキストを明確に分離することを目指して、この予備的な建築研究に取り組みました。このようなアプローチに従うことは、問題を明確に分離し、特定の種類の利害関係者に基づいて議論をカスタマイズするために重要です。

実際、議論されたアーキテクチャの一部は、開発フェーズとその組織でした。同社自体はまだアジャイル手法を採用していませんでした。それにも関わらず、マネージャーやその他の関係者の同意を得て、私たちはこのギャップを埋めたいと考え、スクラム方法論のフレームワークからインスピレーションを得ることを選択しました。

私たちはスクラムについてまったく訓練を受けていませんでしたが、全員がスクラムの基本を意識していました。このプロジェクトに関して私たちが念頭に置いていた主な指示は、方法論と技術の両方で次のとおりです。

反復的なアプローチ (最終決定ではスクラム) で部分的および全体的な目標に集中するために従うべき基本的な一連のプラクティス。
自動化ツールによるアクティビティ/ソースの追跡。
単体テストと統合テストを組み合わせた動作駆動開発アプローチ。

スクラムの実践

確固たる方法論フレームワークを強制する必要性から動機づけられましたが、深いスキルが不足しているため、私たちは行き過ぎずにスクラムの主要なルールのいくつかを採用することにしました。まず第一に、反復的なアプローチが私たちの考えでは非常に重要でした。スクラムは、いわゆるスプリントを通じてこれをカバーしており、これは反復的な作業単位と考えることができます。各スプリントは、バックログから選択された数の機能をカバーすることになっており、特定の期間が設定されています。

スプリントの期間として 2 週間を選択しました。実際の取引を開始する前に、予備作業と組織的なタスクを実行するために、従来の 1 週間のスプリント番号 0 を設定しました。この予備スプリントでは、すべての機能を優先度別にリストしたバックログの初期バージョンも作成しました。私たちはタスクの取り組みを評価するための特定の方法を採用せず、チームメンバー間の通常のディスカッションのみを採用しました。

スクラムルールに関しては、各スプリントの開始時に、すでに行われた作業について話し合い、発生したすべての問題を評価し、次のスプリントに実装する機能を選択します。

プロジェクトマネージャーはプロダクトオーナーの役割を果たし、ドメインの専門家がサポートしました。これは、実際のプロダクトマネージャーが関与しておらず、プロジェクトマネージャー自身がクライアントの要件についてすべての知識を持っていたため、特定の状況では理にかなっていました。スクラムマスターに関しては、私がしばらくその役割を担当し、その後、たとえ私たち二人とも十分なトレーニングを受けていなかったとしても、その役割を別の同僚に引き継ぎました。

私たちのチームは、さまざまな都市から働いている人々からなる異質なチームでした。そこで私たちは、Skype 通話を毎日同じ時間にスケジュールして、スタンドアップミーティングの仮想バージョンを開催することを余儀なくされました。会議の長さは約 15 分でした。チームメンバーの中にはこれを何らかの形で抵抗している人もいますが、それはおそらく彼らがこれを制御の一形態として解釈したからかもしれませんが、そうではありません。

私たちは時間をかけて、毎日のミーティングの本当の意味、つまり主要な問題に焦点を当て、コミュニケーションを強化し、改善方法を見つけて全員が仕事をやりやすくするためのチームメイト間の短いディスカッションであることを認識してもらいました。しばらくの間、彼らはそれは時間の無駄で、本来の仕事の邪魔になると言い続けましたが、最終的にはなんとか彼らを説得することができました。

自動化ツールによるアクティビティ/ソースの追跡

方法論の実践に加えて、次の主な懸念事項を解決するためのツールも必要でした。

コードをバージョン管理し、その変更を追跡し、チーム全体で共有します。
アクティビティとバグ解決の追跡: 何をしなければならないか、誰が何に割り当てられているか、そのステータス。
ソースコードの変更をアクティビティに一致させます。

プロジェクト内の情報の流れは非常に複雑なので、それを制御する方法論の実践だけに頼ることはできません。作業を容易にするためには、しっかりとしたツールが必要です。多くのタスクを自動化すればするほど、より重要なことに集中でき、より良い製品を生み出すことができます。

コードのバージョン管理には、最も自然な選択である Git を使用しました。 Git はさまざまな方法で使用できますが、私たちはワークフローパターンとしてGitflow を個人的に採用しました。

アクティビティを追跡するために、プロジェクト管理を目的とした汎用プラットフォームであるRedmineを使用しました。

3 番目の懸念に対処するために、コミットコメント内の問題識別コードを使用して、Git コミットを特定の Redmine チケットに関連付けることができるように、Git リポジトリを Redmine と統合しました。このようにして、アクティビティと Git の作業単位の間の完全なマッピングが得られました。

単体テストと統合テストを組み合わせた動作駆動開発アプローチ

私たちは、開発プロセスを行動駆動型のアプローチに基づいて行うことに強い意欲を持っていました。 BDD はスクラム、そして一般にアジャイルの原則、特にコミュニケーションに関する部分に非常によく適合します。これにより、技術者以外の人でも理解できる形式でテストシナリオを作成でき、適切なツールを使用すると、現在のステータスの視覚的なレポートが得られます。製品の論理的な境界を引き、その境界内で開発作業を強制します。

BDD 機能テストは、テスト機器全体の外部層にすぎません。単体テストと統合テストも使用しました。このような開発環境の複雑さに圧倒されないようにするには、適切なツールと自動化機能を使用する必要がありました。

関連する主なテクノロジーは次のとおりです。

Cucumber : REST サービスを使用して Spring Boot アプリケーションに統合
その他のテストツール: 統合テストをサポートするためのJUnit 、 Mockito 、および Spring Boot ライブラリ。

次のメンタルマップは、上で説明したことの概要を示しています。

考慮事項

たとえそれが軽量かつ柔軟な方法であっても、スクラムを採用する価値はあったでしょうか?答えは「はい」です。ただし、はっきりさせておきたいのは、これがすべての問題の解決策であるとは考えられず、その精神そのものを理解せずに採用されると、有害ですらになる可能性があります。方法論の本質は、情報を最大限に共有し、コミットメントを持って人々が協力できるようにするための集合的な精神スキーマを提供することですが、人々が実際の仕事ではなく、風変わりな儀式のルールに従うことに集中してしまうと、本来の目的は消えてしまいます。

スポーツのたとえ

上で述べたことをスポーツに例えると、よりよく理解できるでしょう。すべての人がサッカーを好むわけではありませんが、ほとんどの人はサッカーがどのように機能するかについて少なくとも最低限の知識を持っています。まずは集団ゲームです。 2 つのチームが試合のピッチで対峙し、ゴール内にボールを届けようとします。この一見単純なタスクを実行するには、個人の取り組みと集団の戦略や戦術を組み合わせる必要があります。これらの戦略と戦術はコーチによって事前に教えられ、トレーニングセッションに費やす全体時間の大きな割合を占めます。

本当に効果的であるためには、サッカー選手が従う上記の集団ルールは、努力することなく、またその存在を意識することなく実行されなければなりません。たとえば車を運転するときのジェスチャーのように、それらは自動的である必要があります。この目標を達成するための基本的な要件は、チャンピオンシップの準備に必要な限られた時間の中で、すべてのプレーヤーが完全に吸収できるほど単純なものでなければならないということです。

実際の作業ではなく、スクラムの儀式に従うことに集中していると、秩序ではなく混乱をもたらすことになります。一方、より現実的なアプローチに従えば、柔軟であり、私たちの特定の経験ではうまくいかないことをすべて取り除くことさえできれば、それを最大限に活用することができます。従うのが難しいと思われる場合は、一部のスクラムアプローチを延期し、後のフェーズで導入してみることも考えられます。

マネージャーの管理

コンセプトを強調しましょう。アジャイル方法論と特にスクラムは、チームのメンバーがそれを積極的に採用するか、少なくともその利点を認識している場合にのみ機能します。一般的な大騒ぎに倣い、「ほら? 私たちはアジャイルだ!」と社外の世界に伝えることを社内のマネージャーだけが導入した場合、それは機能しません。はっきり言っておきますが、目的がマーケティングだけであれば、それらの方法論に従ったふりをしたほうが良いでしょう。内部プロセスにプロモーション目的のみの負担を導入する必要はありません。

この話の教訓: アジャイル手法は、マネージャーだけが押し付けるのではなく、エンジニアとマネージャーが採用した場合にのみ、何らかのプラスの効果をもたらすことができます。ほとんどのマネージャー、特に技術的な背景のないマネージャーは、方法論がソフトウェアプロジェクトのライフサイクルにどのような影響を与える可能性があるかについて何も知りませんが、エンジニア、特に上級エンジニアは知っています。長年の経験は最高の書籍や最高のコースよりも優れています。

さらに、イタリア企業での私の奇妙な経験に基づくと、組織はある種の中世の遺産から来たと思われる文化によって規定されることがよくあります。この文脈では、スクラムマスターやプロダクトオーナーの役割さえも、実際的な役割ではなく、単にキャリアパスにおける権限の源と見なすことができます。

実を言うと、私は最近この厳しい現実を試してみました。通常、これらの人々は方法論の原理自体が何であるかをまったく理解しておらず、理解さえしていないルールで人々を嫌がらせし続けます。

このような恐ろしい環境では、エクストリームプログラミングやスクラムは意味のないタイトルにすぎません。このような状況では、マネージャーは対処すべきエントロピーの源であり、適切なレベルの生産性を達成するには、チームが自分の仕事を管理し、さらにはマネージャーを管理して、悪影響を軽減する必要があります。これが、このセクションのタイトル「マネージャーの管理」の説明です。

方法論、テストの実践、アクティビティの追跡、および関連ツールのバランス

この記事で説明する使用例では、方法論だけでなく、テスト戦略、アクティビティの追跡、およびそれらをサポートするために使用されるツールについても説明しました。最高の方法論フレームワークだけでは、ソフトウェア開発に関わるすべての複雑な問題を解決することはできません。

実際のところ、機能テストを対象とする BDD は、開発中のソフトウェアシステムのロジックに関する知識を共有する非常に効果的な方法です。これにより、チームメンバー全員とプロダクトオーナーとの間に強い絆が生まれ、プロジェクトのより重要な側面に集中できるようになります。つまり、スクラムがカバーすべき問題の一部をカバーしています。

一方、単体テストと統合テストはソフトウェア開発者の内部プロセスにより深く関与しますが、間接的に変更への対処が容易になり、スクラムの反復アプローチとうまく連携します。