Marc と Laura Sewell による「The Software Architect's Profession」という本 ( Amazon リンク) を読んでいて、ソフトウェア アーキテクトが古い非アジャイル BDUF アプローチの一部であるかどうか疑問に思いました。
アジャイルアプローチにおいて、ソフトウェアアーキテクトの居場所はありますか? 特にスクラムに興味があります。
ところで、私は現在、大手企業の Unix アプリケーション アーキテクトです。
乾杯、
ロブ
13133 次
15 に答える
50
スクラムにおけるアーキテクトとしての私の役割には、以下が含まれます。
テクニカル スパイク -- 概念実証 -- どうやってそれを行うか。(「単純に SMTP ライブラリを直接使用する方が簡単です。既存の SMTP ライブラリは既にラップされています。ラッパーの周りに独自のラッパーを記述してもあまり役に立ちません。必要なメソッドを追加できます。」)
意図したアーキテクチャに適合するための開発者間の調整。(「うーん...なぜ独自のプロパティ ファイルを使用しているのですか?」
ユーザーと協力して、バックログに適切な優先順位を付ける。(「これら 3 つは関連しており、1 つを実行すると、残りの 2 つをほぼゼロの追加コストで取得できます。」)
マネージャーと協力して、バックログのコストを計算します。(いいえ、プロジェクト マネージャーはこれを行うことができません。彼らには技術的な深みがありません。いいえ、プログラマーはこれを行うことができません。彼らには概要がありません。)
パッケージ名がそのようになっている理由と、データ モデルにそれらの機能がある理由を明確にします。
欠けているものを見つけ、技術的な理由でバックログの優先順位を付け直す (「[X] を統合し、[Y] をアップグレードし、[Z] を置き換えるために、この追加のスプリントが必要になるでしょう。さもなければ、それらのスプリントは決して完了しません。 "）
于 2008-10-07T10:02:41.400 に答える
11
もちろん。
覚えておいてください - アジャイルは 'bring me a rock' アプローチではありません。依然として要件、設計、および堅実なアーキテクチャの必要性があります。
製品または製品ラインを構築し、プロジェクトを管理するためにスクラムまたはその他のアジャイル アプローチを採用している場合、主要なアイデアの 1 つは、短い反復サイクルを開発し、達成するタスクのバックログに優先順位を付け、反復で何を行うかを決定することです。 A、B、C など。建築家が本当に価値のあるところがあります。X、Y、Z がどのように組み合わされるかについて明確なアイデアを持っている人がいれば、スクラムの反復をより生産的にすることができます。
于 2008-10-07T09:52:03.623 に答える
7
アジャイル開発とは無政府主義的な開発を意味するものではなく、長期にわたって保守可能であり続けるために調整する必要があります。
しかし...おそらく、ウォーターフォールの方法論とアジャイルの方法論の最大の違いは、ウォーターフォールではソフトウェア アーキテクトの PERSON を見つけ、アジャイル開発ではおそらくソフトウェア アーキテクトの SKILL を見つけることです。つまり、人々がより緊密に連携して作業するようになるにつれて、時間の経過とともにスキルがホールチーム全体でより共有される可能性が高くなります。これは良いことです.
もちろん、ソフトウェア アーキテクトの「リーダー」は、全体像を維持し、すべてのビルディング ブロックが一貫していることを確認する人ですが、彼の知識が教えてくれるので、時間をかけて参照するのは彼だけではありません。他の人に。
于 2008-10-07T09:55:09.310 に答える
6
もちろん、特に中規模から大規模のプロジェクトではそうです。アーキテクトは、プロジェクトを俯瞰することで技術的な方向性を示し、技術的なリスクの評価と軽減を担当します。開発者は、より狭い範囲に焦点を当てる傾向があり、高レベルの問題にあまりさらされません。
于 2008-10-07T09:50:58.057 に答える
4
絶対に - アーキテクトはスクラム チームに望まれ、必要とされます。おそらく、スクラム/アジャイル エバンジェリストやトレーナーなどからは聞いたことがないかもしれませんが、経験豊富なプロダクト オーナーなら誰でもそう言うでしょう。スクラムにおけるアーキテクトの役割は非常に重要です。
于 2012-02-01T18:41:37.700 に答える
3
完全に。
あなたが言及した開発/プロジェクト プロセスは、アーキテクトが設計したものを構築するためのものです。
よく使われる例えですが、建築家は都市、道路、建物を設計し、計画します。
開発者は都市、道路、建物を建設します。
開発者は、建物を建設し、道路を走行し、都市を機能させるために必要なプロジェクト管理システムを使用できます。
ビル アーキテクトがエンジニアと共にビルを監督するのと同じように、ソフトウェア アーキテクトも開発プロセスを監督する必要があります。
アーキテクトと開発者の両方の役割は関連していますが、独自の作業プログラムを達成するために異なるプロセスに従うことができます。
于 2008-10-07T09:49:59.103 に答える
2
確かにあると言えます。アジャイルでは、開発者が独自のコードを自由に設計できるようにすることに重点が置かれていますが、個々の開発者が作業するレベルよりも高いレベルでの全体的なプログラム設計が依然として必要です。
于 2008-10-07T09:41:33.567 に答える
2
ただし... アジャイルは小規模なプロジェクトに最適であり、専門のアーキテクトは通常、大規模なプロジェクトでより役立ちます。
私が考えるうまくいく方法は、アーキテクトが全体的なロードマップを作成し、必要なモジュールをチーム リーダーと共にスクラム方式で定義する場合です。ただし、チームリーダーとそのスクラムチームが実際の開発を行います。
二段階スクラムの一種。
于 2008-10-07T10:00:22.687 に答える
1
私たちは 1 年間スクラムをうまく実践してきましたが、私たちが経験したことは、バランスを取る必要がある 2 つのことがあるということです。技術レベルでの戦略的および中期的な計画は、プロダクト オーナーが実装したい次の機能に集中するため、明示的に行う必要があります (もちろん、プロダクト オーナーにとってはこれで問題ありません)。 (以前のいくつかの投稿で述べたように) 象牙の塔に座って、理論的にのみ機能するものを設計するべきではありません - すべてのチームが十分なアーキテクチャ スキルを持てるように知識を分配する必要があります
私たちの解決策は次のとおりです (私たちはマルチチーム環境で作業しています): リード アーキテクト (スクラム チームのメンバーではない) が率いる仮想チームを作成しました。各チームは、議論する必要がある各問題について、どのメンバーが議論に参加したいかを決定します。チームは共通の決定を下します。追加の作業が必要な場合は、新しいユーザー ストーリーを介して行うか、スクラム外で小規模な場合に行います。決定にコミットしたチーム メンバーは、チーム内で決定を伝達し、その実行を管理する責任があります。
于 2008-10-24T07:39:22.073 に答える
1
これはアプローチの問題というよりはスキルの問題だと思います。ですから、彼がその役職を持っていても、彼には役割があるかもしれません。
于 2008-10-07T09:39:52.400 に答える
1
厳密なヒエラルキーがないかもしれないアジャイル方法論でさえ、プログラマーは平等にはなりません。ベテランのキャンペーン担当者、初心者、コードベースと問題のドメインを逆に知っている人、および上記の組み合わせが含まれます。
真にアジャイルなプロジェクトには「正式な」アーキテクチャは存在しないかもしれませんが、対処する必要のあるアーキテクチャの問題は常に存在し、一般的に、これらの問題のいくつかに対処する知識を持っているのは、より経験豊富なチーム メンバーであると思います。
また、内部プロジェクトの方法は給与等級とは別のものである可能性があることにも注意してください。
于 2008-10-07T10:04:01.087 に答える
0
絶対。とにかく、アーキテクチャをすべて前もって行う必要がある理由はありません。
于 2008-10-07T15:46:34.280 に答える
0
はい、とてもそうです
「アーキテクト」は、ソフトウェアが建設業界から盗んだ用語で、プロジェクト全体を監督した人物を表すことを意図していました。建設業界の建築家は、プロジェクトの外観と「ヒューマン インターフェイス」について構造エンジニアに相談する人です。ソフトウェア プロジェクトの構築「アーキテクト」と「UX デザイナー」の間には、より密接な類似点があります。ソフトウェア アーキテクトが何をするかをより正確に表していると私が信じている用語は、システム エンジニアです。
では、アジャイル開発におけるソフトウェア アーキテクチャの役割は何でしょうか? これを理解するには、アジャイル ソフトウェア開発の原則を理解することが重要です。これらの原則は、アジャイル ソフトウェア開発のマニフェスト ( http://agilemanifesto.org ) に記載されています。
プロセスとツールを介した個人と相互作用
包括的なドキュメントよりも動作するソフトウェア
契約交渉におけるお客様の協力
計画よりも変化への対応
詳細はこちら: http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
于 2016-10-09T15:30:31.240 に答える
0
まず第一に、スクラムチームは自己組織化されています。つまり、技術管理の役割はあまり表現されていません。はい、チームはメンバーを役割に選出/招待できます。しかし、この雇用の役割では、チームに委任する必要もあります。ええ..そうではありません.チームの活動は、主に会議とスプリントの部分で最も強力です.技術アーキテクチャは、叙事詩のレベルのソリューションを提供し、少なくとも、ロードマップの構築、技術の承認、利害関係者へのフィードバック、およびその他の特定の事項を必要とします.操作はトピックの範囲です。その上、テクニカル アーキテクトは、特に DRY およびソリューションの再利用、品質などの他の原則を維持するために、会社の企業開発の利益のために行動します。大雑把なスプリントは、複数チームの会社で相互に関連付けることができ、また相互に関連付ける必要があります。これには、リーダーシップ レベルでの調整も必要です。これらの面では、アーキテクトは利害関係者を代表し、さらに実装の対象となる技術要素、制約、パターン、テクノロジーは、ユーザー ストーリーの正しいセクションです。基本的に、アーキテクトは、必要に応じて、ビジネス上の利益であれば、スプリント フレームにコードを書くことができます (これは、具体的な企業のリーダーシップ コードに大きく依存します。ここでは、範囲外のものは何もないと思います)。ただし、アーキテクトの定義された役割は、利害関係者に代わってビジネスから技術的な定義への変換と技術的なガイドラインの管理を行うための技術的なソリューションです。アーキテクトは、ビジネスに関心がある場合、スプリント フレームにコードを書くことができます (これは、具体的な企業のリーダーシップ コードに大きく依存します。ここでは、範囲外になるものは何もないと思います)。ただし、アーキテクトの定義された役割は、利害関係者に代わってビジネスから技術的な定義への変換と技術的なガイドラインの管理を行うための技術的なソリューションです。アーキテクトは、ビジネスに関心がある場合、スプリント フレームにコードを書くことができます (これは、具体的な企業のリーダーシップ コードに大きく依存します。ここでは、範囲外になるものは何もないと思います)。ただし、アーキテクトの定義された役割は、利害関係者に代わってビジネスから技術的な定義への変換と技術的なガイドラインの管理を行うための技術的なソリューションです。
于 2017-02-21T11:46:39.810 に答える
-3
SCRUM の元のフォルマント Dr Jeff Sutherland と Ken Schwaber によって書かれた SCRUM ガイドには、その必要性について言及されていないため、必要性があるとは思いません。
于 2013-01-11T10:29:16.443 に答える