Clever Geek Handbook

スクラム設計の神話と誤解







今日、柔軟な方法論を持つ人を驚かせるのは困難です。アジャイルマニフェストが採用されてから15年が経過しました。世界がスクラムについて学ぶ前です。 これは多くのソフトウェア開発会社にとってすでに一般的であり、追加することは何もないようです。



しかし、私の仕事やさまざまな種類のセミナーや会議でスクラムが人気を博しているため、その基本原則に対する理解が不足していることがあります。 また、Habréのコメントには頻繁に否定的なレビューがあります。反復開発への移行について顧客が同意できない場合や、チームを適応させることができない場合があります。 おそらく、スクラムに関する最も人気のあるレビューは次のように聞こえます。「私たちはゼロメリットの集会に30分を費やし、それから以前と同じように作業します。デモ、レトロ、プランニングの頭痛だけが追加されました。」



2011年にスクラムの実装を開始しました。 私たちのプロジェクトは単純ではありません：6チーム（スクラムのスクラム）、40人以上の参加者、長年の仕事のための機能。 当然、最初のfirst折の後、通常のウォーターフォールモデルに戻ることを真剣に考えた後、最初はすべてが順調に進んでいませんでしたが、最終的にはスクラムを自分自身に適応させることができました。 その結果、安定した予測可能な開発プロセスが実現し、高品質で高品質なものが得られません。 この間ずっと、私はチームの1つのチームリーダーであり、チームリーダーであり続け、実際に私たちが遭遇した問題は1つでもありませんでした。



個々の企業でスクラムが失敗した理由については長い間話すことができますが、今日は開発の重要な部分の1つであるデザインに注目したいと思います。 さらなる検討は個人的な経験に基づいて行われ、すべてのキャラクターは架空のものであり、偶然の一致はランダムです。 それでは始めましょう。



神話1.私はプログラマーであり、設計したくない









そして、おそらくここで多くの人が自分自身を認めました。 簡単な実験：自分自身と「デザイン」したい同僚に尋ねます。 私の観察によれば、70-80％はノーと答えます。 なんで？



まず、「デザイン」とは何かを理解する必要がありますか？ 数年かけて、きれいなウォーターフォールプロセスと仕様への強い愛情と大量の設計ソリューションを備えた「カスタムメイド」プロジェクトに取り組みました。 そして、ご存知のように、デザインもしたくないとも言えます。 2か月だけでも、数百ページのドキュメントを生成するのは不幸であり、すべてのプログラマーがコードを書くことを好むとは思えません。



しかし、スクラム設計について話しましょう。 設計目標はわずかです。開発中のリスクを軽減し、製品の所有者、利害関係者/顧客、チームにチームが何をどのように行うかを理解させ、その結果、製品の価値を高めます。 その結果、制約、リソース、および能力を考慮した現実的な「ハウツー」モデルが作成されます。 一般的なケースでは、大量の包括的なドキュメントは必要ありません。何をする必要があるかを理解し、作業を詳細に分解するだけで十分です。



あなたはまったく設計することはできません、最終的にはバグ駆動型の開発があります。 ふるいに水を注ぎ、指で底をすばやく塞ぐと、水が漏れないという感覚が得られます。 同様に、多くのソフトウェア製品の品質が保証されています。



しかし、結局のところ、バックログからタスクを作成する方法を考えることも設計です。 スプリント計画も設計です。 反復的なチームワークでは、「デザイン」で開発者を苦しめずに、目的を達成するための優れたトリックがあります。





一般的に、「私はプログラマーであり、デザイナーではありません」は言い訳ではありません。スクラムは主にチームであり、各チームは設計時に行うことがあります。



神話2.「ガラスの塔の賢者」









この表現は私によって発明されたものではありませんが、デザインに関する別の神話を正確に反映しているように思われます-あなたはすべてのデザインの決定を担当し、時間通りに、適切な品質ですべてをチョコレートに入れるスーパーデザイナーを見つけることができます。 彼にはすべての能力、知識、すべての責任があります。



たとえば、このコンテキストでは、デザイナーギルドのメンバーは 「アナリストデザイナー」という用語を使用します。 彼は個人的にそのような役割を果たしていた男性と仕事をし、おそらく他の状況では、彼自身がそのような「ガラスの塔の賢者」になるでしょう。 一般に、これはかなり一般的なアプローチです。



なぜこれが機能しないのですか？



実際には機能しますが、いくつかの欠点があります。





その結果、スーパーデザイナーは実用的なソリューションですが、チームがそれを使用して設計することはさらに優れており、より高速で優れたものになります。



神話3.論文を提出し、気分が良い









柔軟な方法論における文書化の問題は、しばしば苦痛なものです。 とにかく大量のドキュメントを読む人はいませんし、コードの最初の行を書いた後は時代遅れになります。 そしてプログラマーは、これを見て、「破裂のために」紙片を書きたくありません。 おそらく文書化をまったく拒否するでしょうか？



それは素晴らしいことですが、完全にはうまくいきません。

「徹底的なドキュメント」（ アジャイルマニフェスト 、パラグラフ2）を最小化した結果、プロジェクトドキュメントを作成しなくなったと判断するのは簡単です。 私たちは口頭で問題を解決し、チームは私たちが何をしているのかをまだ認識しており、お客様に指で説明します。



残念ながら、それを生きていくと、人類は知識を修正する方法として何千年もの間文章を発明して開発し、2016年にソフトウェア開発者は口頭伝説に戻ったように見えます。 顧客と何かを話し合ったとき、それを書き留めておらず、それを忘れてしまったので、彼は質問について何を思いついたのかを尋ねます。



個人的な習慣から、いくつかの推奨事項があります。





最終的には、設計決定を自発的にではなく意識的に文書化し、自分用にフォーマットを調整します。



神話4.さて、デモを見せます









チームとして働くとき、十分なコミュニケーションがあり、一般的なコンセンサスが得られるため、顧客、ユーザーがいることを忘れがちです。 もちろん、デモでは、製品の有効な増分を表示する必要がありますが、スプリント中、チームは自給自足のように見えます。

しかし、ここで簡単な質問をします。デモの後、あなたがすべてをやり直したということはあなたに起こりましたか？



もしそうなら、スプリント中にコミュニケーションが取れていない可能性があります。 これは開発にも当てはまり、設計には製品所有者または顧客との定期的なコミュニケーションが絶対に必要です。



顧客/利害関係者は、製品に関する独自のビジョンを持っている場合がありますが、製品の所有者は異なります。 理想的には、毎日直接会って、研究の設計結果と問題について話し合う必要があります。 これらのディスカッションでプロトタイプを提示すれば、ほぼ間違いなく、デモに驚きはありません。



神話5.スレッドとプロダクションの世界









正直に言って、私たちが行うほとんどすべてのことは、私たちの前に誰かによって発明されており、おそらく実装されており、おそらくうまくやっていることさえあります。 ロシアのIT市場は当初、欧米の製品とアイデアをコピーすることによって開発されました。 デザインにユニークなものは何もないことがわかりました。競合他社のソリューションを選択して、最高のものを強調してそれを行うことができますか？



はい、いいえ。



既製のソリューションの分析は、設計にとってほぼ不可欠な部分ですが、製品を可能な限り価値あるものにするためには、私たちが何を、誰のために、どのように行うのかを理解する必要があります。 設計は有意義で制御されている必要があります。 これに関して、既製のトリックがたくさんあります：





結局、怠duringである必要はなく、設計中に既製のソリューションに限定されます。 時間をかけてユーザーとそのニーズを研究してください。そうすれば、製品は競合他社よりも際立ったものになります。



仕事のやり方について簡単に



これはベストプラクティスではありませんが、具体的には私たちにとってプラスの効果がありました。







結論の代わりに



スクラムでの設計は特効薬ではなく、なじみのない領域でチームワークを編成する方法にすぎません。 それはあなたにfakapに対する保証を与えるものではなく、作業プロセスを構築すると時間と神経がかかります。



彼らもそれをする必要がありますか？ 誰もが自分でこの質問に答えるでしょう、私は彼が犯した間違いに対してあなたに警告したいだけです。 他の神話に出くわした場合、このリストは私の練習に限定されます-コメントに追加していただければうれしいです。


More articles:


All Articles