今日、柔軟な方法論を持つ人を驚かせるのは困難です。アジャイルマニフェストが採用されてから15年が経過しました。世界がスクラムについて学ぶ前です。 これは多くのソフトウェア開発会社にとってすでに一般的であり、追加することは何もないようです。
しかし、私の仕事やさまざまな種類のセミナーや会議でスクラムが人気を博しているため、その基本原則に対する理解が不足していることがあります。 また、Habréのコメントには頻繁に否定的なレビューがあります。反復開発への移行について顧客が同意できない場合や、チームを適応させることができない場合があります。 おそらく、スクラムに関する最も人気のあるレビューは次のように聞こえます。「私たちはゼロメリットの集会に30分を費やし、それから以前と同じように作業します。デモ、レトロ、プランニングの頭痛だけが追加されました。」
2011年にスクラムの実装を開始しました。 私たちのプロジェクトは単純ではありません：6チーム（スクラムのスクラム）、40人以上の参加者、長年の仕事のための機能。 当然、最初のfirst折の後、通常のウォーターフォールモデルに戻ることを真剣に考えた後、最初はすべてが順調に進んでいませんでしたが、最終的にはスクラムを自分自身に適応させることができました。 その結果、安定した予測可能な開発プロセスが実現し、高品質で高品質なものが得られません。 この間ずっと、私はチームの1つのチームリーダーであり、チームリーダーであり続け、実際に私たちが遭遇した問題は1つでもありませんでした。
個々の企業でスクラムが失敗した理由については長い間話すことができますが、今日は開発の重要な部分の1つであるデザインに注目したいと思います。 さらなる検討は個人的な経験に基づいて行われ、すべてのキャラクターは架空のものであり、偶然の一致はランダムです。 それでは始めましょう。
神話1.私はプログラマーであり、設計したくない
そして、おそらくここで多くの人が自分自身を認めました。 簡単な実験：自分自身と「デザイン」したい同僚に尋ねます。 私の観察によれば、70-80％はノーと答えます。 なんで？
まず、「デザイン」とは何かを理解する必要がありますか？ 数年かけて、きれいなウォーターフォールプロセスと仕様への強い愛情と大量の設計ソリューションを備えた「カスタムメイド」プロジェクトに取り組みました。 そして、ご存知のように、デザインもしたくないとも言えます。 2か月だけでも、数百ページのドキュメントを生成するのは不幸であり、すべてのプログラマーがコードを書くことを好むとは思えません。
しかし、スクラム設計について話しましょう。 設計目標はわずかです。開発中のリスクを軽減し、製品の所有者、利害関係者/顧客、チームにチームが何をどのように行うかを理解させ、その結果、製品の価値を高めます。 その結果、制約、リソース、および能力を考慮した現実的な「ハウツー」モデルが作成されます。 一般的なケースでは、大量の包括的なドキュメントは必要ありません。何をする必要があるかを理解し、作業を詳細に分解するだけで十分です。
あなたはまったく設計することはできません、最終的にはバグ駆動型の開発があります。 ふるいに水を注ぎ、指で底をすばやく塞ぐと、水が漏れないという感覚が得られます。 同様に、多くのソフトウェア製品の品質が保証されています。
しかし、結局のところ、バックログからタスクを作成する方法を考えることも設計です。 スプリント計画も設計です。 反復的なチームワークでは、「デザイン」で開発者を苦しめずに、目的を達成するための優れたトリックがあります。
- あなたがなじみのない複雑な主題分野で働いているなら-アナリストをチームとして連れて行き、彼と友達を作ってください-彼は噛み付きません。 彼は、ユーザーの役割とその仕事の事例の説明（要件ではありません、要件ではありません）を作成し、競合他社の概要をまとめ、法律と対象分野全体をまとめます。
同時に、彼はスプリント全体でチームに所属しているため、開発のチームと協議を支援することができます。 そして、これは開発者の頭痛の種を取り除きます。なぜなら、アナリストの仕事は、プログラマー自身が設計するときにやりたくないことだからです。
- 不要なドキュメントを書かないでください-コードを書きます。 過去数年にわたって、私は明確なルールを開発しました。多かれ少なかれ複雑なプロジェクトでは、プロトタイプを作成する必要があります。 これは何もしませんが、実際には、その実装中に、プロトタイプがなければ気付かなかったさまざまな小さなものが絶えずポップアップします。 紙ではなくプロトタイプを使用している顧客に見せます。これは、プロジェクトの評価と個人的な信頼にプラスになります。 そして最も重要なことは、チーム全体がプロトタイプを開発できることです！
- 迅速な設計。 プロジェクトの遅延は、スプリントの目標の達成と開発者の士気に悪影響を及ぼします。 チーム全体を「崩壊」させ、設計を完成させ、実装に移る方が良いでしょう。
一般的に、「私はプログラマーであり、デザイナーではありません」は言い訳ではありません。スクラムは主にチームであり、各チームは設計時に行うことがあります。
神話2.「ガラスの塔の賢者」
この表現は私によって発明されたものではありませんが、デザインに関する別の神話を正確に反映しているように思われます-あなたはすべてのデザインの決定を担当し、時間通りに、適切な品質ですべてをチョコレートに入れるスーパーデザイナーを見つけることができます。 彼にはすべての能力、知識、すべての責任があります。
たとえば、このコンテキストでは
、デザイナーギルドのメンバーは 「アナリストデザイナー」という用語を使用します。 彼は個人的にそのような役割を果たしていた男性と仕事をし、おそらく他の状況では、彼自身がそのような「ガラスの塔の賢者」になるでしょう。 一般に、これはかなり一般的なアプローチです。
なぜこれが機能しないのですか？
実際には機能しますが、いくつかの欠点があります。
- 互換性の欠如や一人の気分、健康、忠誠心への依存などの明らかなことを描く必要はありません。これは理解できます。
- 「Sage」は、チームスタイルのみでチームとのコミュニケーションに切り替えるのが非常に簡単です。 彼は要件を「塔から」下げ、残りはそれを実現します。 ここで、「要件」が好きではない理由を説明する必要があります。 ユーザーストーリーは、ユーザーに必要なものとその理由を示し、要件は、「賢者」にとって重要と思われるもののみを示しています。 さらに、すべての参加者が彼らから何を望んでいるかを理解できるように、チームに「賢人」のアイデアをもたらすために多くの時間を費やす必要があります。
- 「賢者」がそれを設計するという事実のために、彼は非常に長い間これをします。 それでさえない：ああ、本当に長い。 1回のスプリント中に、機能を完全に終了することは不可能であることが判明し、その結果、「デザインスプリント」が表示され、次に「実装スプリント」および「サポートスプリント」が表示されます。 スクラムとあまり似ていませんよね？
- それとは別に、このような設計ではチームがまったく発展しないことを強調します。 一方、スクラムで重要なのはチーム、その作業と開発です。
その結果、スーパーデザイナーは実用的なソリューションですが、チームがそれを使用して設計することはさらに優れており、より高速で優れたものになります。
神話3.論文を提出し、気分が良い
柔軟な方法論における文書化の問題は、しばしば苦痛なものです。 とにかく大量のドキュメントを読む人はいませんし、コードの最初の行を書いた後は時代遅れになります。 そしてプログラマーは、これを見て、「破裂のために」紙片を書きたくありません。 おそらく文書化をまったく拒否するでしょうか？
それは素晴らしいことですが、完全にはうまくいきません。
「徹底的なドキュメント」（
アジャイルマニフェスト 、パラグラフ2）を最小化した結果、プロジェクトドキュメントを作成しなくなったと判断するのは簡単です。 私たちは口頭で問題を解決し、チームは私たちが何をしているのかをまだ認識しており、お客様に指で説明します。
残念ながら、それを生きていくと、人類は知識を修正する方法として何千年もの間文章を発明して開発し、2016年にソフトウェア開発者は口頭伝説に戻ったように見えます。 顧客と何かを話し合ったとき、それを書き留めておらず、それを忘れてしまったので、彼は質問について何を思いついたのかを尋ねます。
個人的な習慣から、いくつかの推奨事項があります。
- プログラマーに紙を書くのは本当に難しくて退屈です-あなたが個人的に好きなことを文書化する方法を見つけてください。 あなたはモカパを描く-素晴らしい。 マインドマップが大好き-約 ボード上に描画-素晴らしい、これが設計決定のフォーマットになります。 主なものは、あなたが今この形式を持っていることを皆に同意することです。 それ以外の場合、スクラムは禁止されておらず、大きなテキストを書くよりも95％おもしろいことがわかります。
- チームのほかに、設計の決定に関心を持つ人を決定します。 営業マネージャー、マーケティング担当者、顧客と連携するコンサルタントなどです。 多くの場合、同じことを何度も繰り返し語るよりも、時間を費やして書く方が簡単です。
- ディスカッション、デモ、または廊下で尋ねられた質問のリストを保管してください。 選択性は柔軟性とは何の関係もありませんし、同僚には無礼のように見えます。
最終的には、設計決定を自発的にではなく意識的に文書化し、自分用にフォーマットを調整します。
神話4.さて、デモを見せます
チームとして働くとき、十分なコミュニケーションがあり、一般的なコンセンサスが得られるため、顧客、ユーザーがいることを忘れがちです。 もちろん、デモでは、製品の有効な増分を表示する必要がありますが、スプリント中、チームは自給自足のように見えます。
しかし、ここで簡単な質問をします。デモの後、あなたがすべてをやり直したということはあなたに起こりましたか？
もしそうなら、スプリント中にコミュニケーションが取れていない可能性があります。 これは開発にも当てはまり、設計には製品所有者または顧客との定期的なコミュニケーションが絶対に必要です。
顧客/利害関係者は、製品に関する独自のビジョンを持っている場合がありますが、製品の所有者は異なります。 理想的には、毎日直接会って、研究の設計結果と問題について話し合う必要があります。 これらのディスカッションでプロトタイプを提示すれば、ほぼ間違いなく、デモに驚きはありません。
神話5.スレッドとプロダクションの世界
正直に言って、私たちが行うほとんどすべてのことは、私たちの前に誰かによって発明されており、おそらく実装されており、おそらくうまくやっていることさえあります。 ロシアのIT市場は当初、欧米の製品とアイデアをコピーすることによって開発されました。 デザインにユニークなものは何もないことがわかりました。競合他社のソリューションを選択して、最高のものを強調してそれを行うことができますか？
はい、いいえ。
既製のソリューションの分析は、設計にとってほぼ不可欠な部分ですが、製品を可能な限り価値あるものにするためには、私たちが何を、誰のために、どのように行うのかを理解する必要があります。 設計は有意義で制御されている必要があります。 これに関して、既製のトリックがたくさんあります：
- キャラクター/ロールからデザインします。 キャラクター/役割は将来のユーザーであり、あなたの仕事は頭痛を軽減し、生活を少し楽にすることです。
- カスタムストーリーを使用します。 製品に価値を与えるのは機能のセットではなく、実際の状況を閉じる機能です。 アジャイルソフトウェア開発に適用されるユーザーストーリーを読むことをお勧めします。 M.コーン。
- ユーザーケースに基づいた設計アーキテクチャ。 最終的に、この製品は生きている人々によって使用され、その開発はおそらく彼らのケースから来ます。 適切に構築されたサブジェクトモデルを使用すると、一から書き直すのではなく、時間をかけて補完することができます。 そして、実際のサブジェクトエリアのコンセプトで運営する開発者は、ビルダー、ビジター、ヘルパーのみで運営する人々の前で有利なスタートを切りました。 説明してください。パターンは抽象化の設計に役立ちますが、よく考え抜かれたオブジェクトモデルの欠如を隠すことはできません。 Eric EvansによるOriented Design（DDD）を読むことをお勧めします。
結局、怠duringである必要はなく、設計中に既製のソリューションに限定されます。 時間をかけてユーザーとそのニーズを研究してください。そうすれば、製品は競合他社よりも際立ったものになります。
仕事のやり方について簡単に
これはベストプラクティスではありませんが、具体的には私たちにとってプラスの効果がありました。
- リリースサイクルは6つの開発スプリントで構成されており、リリースを正しく計画するために、基本的に短い「ゼロ」スプリント（予備調査と設計）を実行します。 その結果、誰もがスプリント中に私たちが何をするかを明確に知っており、計画の背後にいる場合、私たちは常に最小価値製品（MVP）と何が捨てられるかを理解しています。
- 反復期間-12営業日。 理想的には、1つのスプリントですべてを調査、設計、および実行すると、迅速なフィードバック（テスト、受け入れテスト、廊下テスト、デモ）が得られ、次のスプリントでは改善のための準備を整える必要があります。 同時に、1回のスプリントでこれらすべてが行われたときに、より長い反復を試みましたが、実際には、 PDCAから「チェック」を行う頻度が高いほど、何か間違ったことをする可能性は低くなります。
- ペアデザインを使用しています。 これは、チームの少なくとも2人が研究、オプションの生成、プロトタイピングに参加することを意味します。 単独で設計するよりも速くて簡単です。 また、彼らは通常、プロトタイピングに関してビジネスアナリストと多くの場合チームの他のメンバーを結び付けます。
結論の代わりに
スクラムでの設計は特効薬ではなく、なじみのない領域でチームワークを編成する方法にすぎません。 それはあなたにfakapに対する保証を与えるものではなく、作業プロセスを構築すると時間と神経がかかります。
彼らもそれをする必要がありますか？ 誰もが自分でこの質問に答えるでしょう、私は彼が犯した間違いに対してあなたに警告したいだけです。 他の神話に出くわした場合、このリストは私の練習に限定されます-コメントに追加していただければうれしいです。