しかし、行われたすべての決定は、何らかの形で「同期」する必要があります。 Hacker Newsの居住者の1人は、1つの大企業の500人の開発者がチームから独立していくつかの決定を独立して行うことを許可されていることに注意しなければならないと述べました。 彼によると、それは混乱だった。 そして、チームはより速く働き始めましたが、ソフトウェアサポートの段階で後の問題が発生したため、どこにも動きませんでした。
このような状況を回避するために、アジャイル開発プロセスのファミリーが使用されます。 それらの実装により、企業経営者は従業員の関心とモチベーションを高め 、顧客への製品の配達を加速することができます。 最近、このトピックはますます一般的になっています。なぜなら、大企業のトップは、いくつかのアジャイル手法に国民の注目を集めているからです。
そのため、機能を再度検討し、オプションを比較し、企業のプロセスの合理化を支援するために、「柔軟な」方法論に関する一連の投稿を開始することにしました。 今日は、スクラム、カンバン、および極端なプログラミングについて話しています。
/ Flickr / セバスチャン・シコラ / cc
スクラム
スクラムは、デフォルトの方法論と見なされる柔軟なソフトウェア開発フレームワークです。 多くの人にとって、それはアジャイルと同義です。 VersionOneが提供する 2016年の統計によると、柔軟な企業の58％がスクラムを使用しています。 同時に、多くのSaaSプラットフォームでサポートされています。 たとえば、アジャイル開発ツールが含まれる ServiceNowソリューション。
方法論は80年代後半から90年代前半に開発されました。 管理プロセスは、固定の短い反復（スプリント）で構成されています。
スクラム方法論を使用して、顧客担当者は開発チームと密接に連携し、製品バックログを優先します。 このリストは、バグ修正、機能要件および非機能要件-動作中のアプリケーションを実装するために必要なすべてで構成されています。
バックログに追加される機能要素はストーリーと呼ばれます。 各タスクは、特定のポイント数で評価されます。 メガネは抽象的なメトリックであり、さまざまなスケールを使用して評価できます（ たとえば 、フィボナッチ数列または2度）。
顧客の要件のリストに基づいて、チームは実装する機能を決定し、スプリントを開始します。 通常は30日間続きます。 最後に、チームがスプリント（速度）に対して得点した合計ポイント数が計算されます。 これにより、次のスプリントをより明確に計画できます。
過去10年間、プログラマーのケンシュヴァーバー、マイクビードル、ジェフサザーランドはスクラムの開発に懸命に取り組んできました。 Ken Schwaberはフレームワークの最も積極的なサポーターであり、彼のサイトは方法論に精通するのに適した場所です。 彼も本をリリースしました。
スクラムはその存在自体が非常に人気があり、大企業でも開発チームが使用しています。 ただし、この期間中にコミュニティはいくつかの欠点を明らかにしました。
たとえば、それらの中で、一連のポイントに過度に焦点を合わせていることに注意してください。 計画する際、チームは、前のステージの速度に基づいて、スプリントの終わりまでに完了するストーリーを選択します。 これらのポイントの主な目標は、計画の信頼性を高め、明確な視点を提供することです。
ただし、ここには問題が潜んでいます。開発者の作業はポイントごとに評価されるため、開発者はより多くの収益を上げ、そのためにアクティビティを最適化しようとします。 コードベースの改善にはつながりませんが、簡単にはなりません。
もう1つの問題は、長期にわたるmitapです。 さらに、会議は開発のすべての参加者と同期して開催されるため、リモートで作業する専門家にとっては問題になります。 別の方法で伝達できる情報を交換するには、何時間もの会議をスケジュールに組み込む必要があります。
スプリント中のストーリーの不変性に関して、大規模ではこれも問題につながります。 プログラマには、新しい機能が発見されたときに作業を再配布する方法がありません。 スクラムでは、航行中に船をすぐに再構築することはできないため、セッションの終了を待って変更を加える必要があります。
極端なプログラミング
スクラムの特徴は、このフレームワークが開発プラクティスにほとんど注意を払っていないことです。 したがって、一部のアジャイル企業（約10％）は、それをエクストリームプログラミング（XP）と組み合わせています。
90年代後半に極端なプログラミングが注目を集めました。 コンセプトはSmalltalkコミュニティに由来し、その作者はKent BeckとWard Cunninghamであり、人々のために作られたソフトウェア開発の新しいプラクティスを作成したかったのです。
エクストリームプログラミングの方法論を使用して作成された最初のプロジェクトは 、90年代半ばのクライスラー総合補償（C3）支払い管理システムでした。 「極端なプログラミング」という用語自体は1997年に登場しました。
コンセプトは12のトリックに基づいています：
- テストによる開発（テスト駆動開発）
- 計画ゲーム
- 顧客は常にそこにいます（オンサイト顧客）
- ペアプログラミング
- 継続的インテグレーション
- リファクタリング （設計改善）
- 頻繁な小規模リリース
- シンプルなデザイン
- システムのメタファー
- 集団コードの所有権
- コーディング標準
- 週40時間の労働時間（持続可能なペース）
XPはスクラムに非常によく似ており、顧客が開発チームと密接に対話し、優先順位付け（ストーリー）を行うことを前提としています。 プログラマは、短い反復でタスクを評価、計画、および実装します。
ただし、エクストリームプログラミングはテストに重点を置いており、スクラムとは一線を画しています。 方法論によれば、開発者は、すべての単体テストに合格するまでコードが正しく記述されているとは言えません。 したがって、多くの場合、テストが最初に記述され、次にそれを渡すためのロジックが記述されると、XPはテスト駆動開発（TDD）開発手法と連携します。
しかし、このような「テスト指向」もアプローチの欠点です 。 XPを適応させるには、自動化されたテストインフラストラクチャと継続的なソフトウェア展開の構築に投資する必要があります。
同時に、スクラムの場合、会社がプロジェクトマネージャーを2日間のコースに送ることができる場合、極端なプログラミングの場合、開発チーム全体をトレーニングする必要があります。 それははるかに高価です。 組織の文化を変更し、複数の部門を統合する必要があります。XPでは、テスター、UIデザイナー、プログラマー、アーキテクト、ユーザーが協力して作業する必要があります。
/ Flickr /アメリカ軍 / cc
かんばん
スクラムは依然として人気のある効果的な方法論です。 特に極端なプログラミングと組み合わせて。 合わせて、アジャイルチーム間の使用率は 68％に達します。
しかし、今日、多くのチームが他のオプションを検討しており、他の方法論に注意を払っています。 それらの1つはかんばんでした。 CTO ConvertKit Grant Ammonsによれば、企業はまずスクラムを採用し、ソフトウェア開発に必要な規律を教えてから、より便利な代替手段を探してかんばんに切り替えます。
かんばんは開発管理のための技術であり、開発プロセスは機能の実装を要求するパイプラインと見なされ、そこから高度なソフトウェアが生まれます。
かんばんはトヨタの生産システムの一部として「ジャストインタイム」で生まれたため、この方法論は不要なタスクの蓄積を排除します。 たとえば、テスターが1週間に5つの機能をテストし、開発者とアナリストが10を実装している場合、「総パイプラインスループット」は5つの機能に制限されます。 これは、QAチームによる作業の蓄積を回避するために必要です。そうしないと、彼らは「コーナーをカット」し始め、市場で品質の悪い製品を誤って見逃してしまう可能性があります。
この場合、リソースを再割り当てすることもできます。プログラマーとアナリストが標準を満たしていれば、自動テストのテストと作成を支援できます。 将来的には、これによりパイプラインのスループットが向上します。
そして、かんばんはそのようなボトルネックを簡単に明らかにします。 最も単純な実装では、ステッカーカードが配置される列が描かれた大きな黒板です。 列は開発プロセスの段階であり、ステッカーは作業タスクです。 各列の上部にある数字は、「保存」できるカードの数を示しています。
ただし、HNコミュニティで指摘されているように、このアプローチにはいくつかの欠点もあります。 同じスクラムでは、短いスプリントは開発者のモチベーションにプラスの効果をもたらします。 プログラマは、30日間の要件のリスト全体が完了すると、製品の作業が終了することを知っています。 かんばんの場合、これは絶え間ないタスクの流れです。 ただし、解決策があります-1週間（または2週間）のタスクリストの簡単な議論です。
また、その特異性により、かんばんは長期計画にはあまり適さず 、大規模な開発チーム（5人以上）には不便です。
結論として、アジャイル手法を使用すると、チームメンバーの経験とチームメンバーが互いに効果的に対話する能力に重大な要件が課されることに注意してください。 さらに、多かれ少なかれ一般的な方法論には、それぞれ独自の長所と短所、および適用分野があります。 このため、新しいフレームワークが登場し、「古い」フレームワークが完成しています。
PS私たちの企業ブログからのいくつかの記事：