タグ付けされた質問 「agile」

残念なことに、誰かが私たちの経営陣に「アジャイル」という言葉を教えてくれました。私は（原則として）アジャイルの周辺的な理解を持っていますが、実際にアジャイルを使ったことはありません。私が知っていることから、それは私たちの組織によく合いません。今のところ、物事はかなり不潔です。その方法は次のとおりです。 私たちは非常に小さなチームです。2人の開発者、1人のDBA、1人のデザイナーです。私が働いている会社は、その規模に比べて不釣合いに多額のお金を稼ぎ、その95％近くが純粋なオンライン販売です。 開発の観点から、私たちは通常の日に多くのデスクの侵入を受けます（私たちは技術サポートであり、開発者でもあります）。営業チームのメンバーが誰かに何かを約束した場合、すぐに定期的に仕事が空から落ちます。私たちはより大きなプロジェクトにも着手していますが、それらは絶え間ない中断を伴う悪夢です。私たちの何人かは私たちの髪を引き裂き始めています！プロジェクト計画は、技術担当でない管理者がExcelスプレッドシートで作成します。そこでは、タスクを一口サイズの文に分解して、理解し、それぞれの横に日付を入れます。これらの日付は常にひどく非現実的で見逃されることが多く、私たちのミーティング（毎週開催）には、「なぜこれがまだ行われていないのか」と人々が尋ねる厄介な瞬間が定期的にあります。 アジャイルは私たちにとっては間違いないと思います。今、（そして私が試した）この会社はその方法を変えないことを考えると、開発チームだけが喜んで変更しますが、採用することができる開発方法論はありますか？

11 project-management  agile 

一部の組織ではアジャイルの採用が失敗する場合があります。ウォーターフォールが唯一の（真の）方法である会社で働いていましたが、それは彼らがプロジェクトでアジャイルを試みて失敗したためです。 まだ覚えている人たちに聞いたとき（私は後輩でした）、本当に起こった悪い悪夢を思い出させたように、私は激しくシャットダウンされました。 プロジェクトが失敗した理由はわかりません。一部の企業ではアジャイルが失敗する理由がウェブ上に記載されていますが、その理由は主に経済的です。そこで、私はここでいくつかのフィードバックをお願いすると思った。 一部の組織でアジャイルの採用が失敗する理由は何ですか？または、別の言い方をすれば..アジャイルで成功するには何が必要ですか？

11 agile  methodology  waterfall  technique 

アジャイルの原則の1つは、動作中のソフトウェアを測定することです。 動作するソフトウェアは進歩の主要な尺度です-アジャイルの12の原則 問題は、出来上がったストーリー、つぶれたバグ、欠陥レポートの減少などの観点からソフトウェアを測定できる一方で、ソフトウェアの価値を測定する方法に固執しています。 Mike Cohnを例として使用し、SalesForce.comが支援することで、SalesForce.comが前年に比べて500％高い価値を顧客に提供している場合、その増加をどのように測定すればよいですか？私が今いる場所をどのように測定しますか？ 彼が使用する他のメトリックは、機能の数と開発者ごとの機能の数です。これは私のバックログが順調で、ストーリーが「機能」によって分割されていた場合に解決できるものですが、アジャイルから始めたばかりなので、私たちが今どのような価値を提供しているかを解決する何らかの方法が必要です、たとえば6か月間で同様のメトリックを使用して、出力が増加したかどうかを確認します。 収益の増加、または顧客満足度の向上によってソフトウェアの価値を測定することを聞いたことがあります（しかし、どのようにそれを測定しますか？）私の部門が行っている仕事に直接。 それでは、ソフトウェアの価値をどのように測定し、どのように始めましたか？ * アジャイルで成功する -マイク・コーン

11 agile  scrum 

プロジェクトを開始するだけでは、UI、データレイヤー、中間に何もありません。したがって、「ユーザーは自分のfooを表示できるはずです」のような単一のストーリーには多くの作業が必要になります。そのストーリーが得られたら、「ユーザーはfooを編集できるはずです」のようなものがより現実的ですが、最初のストーリーにはUIレイヤー、プレゼンテーションロジックレイヤー、ドメインロジックレイヤー、データアクセスレイヤーの設定が含まれます。 これは、私の「タスク」の概念には合いません。私にとっては、次のような「タスク」のようなものが欲しいです。 JavaScriptオブジェクトから派生したHTMLでユーザーのfooのダミーデータを表示します。 プレゼンテーションロジックレイヤーを設定し、JavaScriptオブジェクトをそれに接続します。 ドメインロジックレイヤーをセットアップし、プレゼンテーションロジックレイヤーをそれに接続します。 データアクセスレイヤーを設定し、ドメインロジックレイヤーをそれに接続します。 これらはすべて上記の単一の「ストーリー」に該当しますか？もしそうなら、ストーリーはプロジェクトの初期段階で非常に有用なフレームワークではないと感じます。もしそうなら、それは大丈夫です---私はこのアジャイルな方法論をできる限り最善の方法で学ぼうとしているので、何かを逃さないようにしたいだけです。

11 project-management  agile 

DRY Principle（Do n't Repeat Yourself）は、「すべての知識は、システム内で単一の明確な権威ある表現を持たなければならない」と述べています。ほとんどの場合、これはコードを指しますが、多くの場合、ドキュメントにも拡張されます。 すべてのソフトウェアシステムには、選択したかどうかに関係なくアーキテクチャがあると言われています。つまり、構築するソフトウェアには構造があり、その「構築された」構造がソフトウェアのアーキテクチャです。 構築されたソフトウェアシステムにはアーキテクチャが付属しているため、そのシステムのアーキテクチャ記述を作成することはDRY原則に違反していますか？ 結局のところ、アーキテクチャを知る必要がある場合は、常にコードを見ることができます...

11 agile  documentation  architecture  dry 

「Promiscuous Pairing and Beginner's Mind」（PDF）の記事では、コードベースの特定の領域についてほとんど知らない人をペアに入れることをお勧めしています。また、90分ごとにペアのシニアメンバーを交換することをお勧めします。初心者はコードのその領域について学習するだけでなく、すでにその領域を知っている人とは違う考え方をします。 誰もこの戦略の経験がありますか？それは現実と何か関係がありますか？ ペアプログラミングをいつ使用するか、ペアプログラミングが必要な仕事を受け入れるかどうかに関する他の質問を見つけましたが、特に無差別なペアリングとこの「初心者の心」戦略に関するものは見つかりませんでした。 ペアプログラミングに慣れていない場合は、Wikipediaとc2.comに興味深い記事があります。

11 agile  pair-programming 

マスターへのプルリクエストのすべてのコードは、本番環境で使用できるようにする必要があるという概念があります。これは理にかなっており、私の意見では公正な声明です。 ここでの考え方は、PRを作成したら、これをマスターにしたと述べているが、一部のレビュアーがあなたと単に「同意」して、見逃したことを見つけて欲しいということです。 私たちは人間なので、間違いを犯し、他のレビュアーがユニットテストでは見つけられなかった項目を見つけることを期待しています-スペルミス、誤ったjavadocなど。 しかし、プルリクエストは、開発者に何らかのレベルの支援/トレーニングを提供する必要がある場所ですか、そうであれば、どのレベルまでですか？ 新しい変更をプッシュするたびに、レビュー担当者は変更を再レビューする必要があります。これは、開発時間からかかり、変更の再レビューを引き起こします。 それでは、プルリクエストではどのくらいのトレーニングが予想され、許可されるべきですか？私の一部は、それがジュニアからシニアまで変化すると感じます。しかし、それはジュニアにとってさえ、膨大な量の問題を見つけるための場所ではないはずだとも感じています。 開発者に「私のプルリクエストは本番環境で使用できるようにする」という目標を達成させるために苦労している人はいますか？

11 agile  pull-requests 

スクラムマスターの職務に対する私の理解は次のとおりです。 プロセスを実施する 障害を取り除く（開発者が自分で取り除くことができない） 外部からの中断を防ぐ スクラム会議を促進します（スタンドアップ、回顧など） チームの開発者が統制されている場合、彼らは誰かが指導することなくプロセスに従います。また、回顧会議やその他のスクラムミーティングの開催にも問題はありません。組織の他のメンバーがスプリントの境界を理解していれば、スクラムマスターを必要とする外部の中断や障害はすでに最小限に抑えられています。 チームのパフォーマンスが向上し、組織がスプリントの境界を理解するようになると、スクラムマスターの必要性が減少するように見えます。チームが最終的にスクラムマスターが不要になるポイントに到達することは可能ですか？

11 project-management  agile  scrum  team 

プロジェクトにはPivotal Trackerを使用しており、次の3つのポイントスケールから選択できます。 0,1,2,3 0,2,4,8 0,1,3,5,8 そして、私たちの決定を導くのに役立つリソースを探しています。（2回の反復で0,1,2,3を使用した後、他の1つがはるかに有用または意味のある場所を確認できます。）

10 agile  scrum 

私はCraig Larman著の 『Applying UML and Patterns』を読み始めたところです。それは私が仕事で言われたことの多くに挑戦するのでそれは非常に興味深いと思います。要件はアジャイルで一度に完全に収集されるわけではなく、要件の収集を完了するには多くの反復が必要であると私は読んだ。その場合、明日、新しい画期的な要件（または要件としてマスカレードする変更要求）が存在する可能性があることを考えると、ハードセットの締め切りを設定することになります。

10 agile  requirements  release  iterative-development 

スクラムガイドは 5と11のメンバー間のどこかのために製品の所有者、3-9員の開発チーム、および1スクラムマスターで構成され、単一のユニットを定義します。プロダクトオーナーがサポートスタッフを持っている場合や、チームがその数をわずかに変更するための専用のスクラムマスターを持っていない場合がありますが、約12人で制限されているようです。 ネクサスガイドは、単一の製品に取り組んで3-9スクラムチームを処理するためにスクラムをスケーリングする1つの方法を説明します。専用のメンバーになるか、さまざまなスクラムチームのメンバーで構成される新しいNexus統合チームが追加されます。そのガイドに基づいて、それは約20〜120人にスケーリングされます。 統制のとれたアジャイルは、1チームからNチームにスケールアップできます。標準的な個々のチームのサイズは、スクラムとほぼ同じです。3〜9人のメンバーと、さまざまなスペシャリスト、独立したテストチーム、ドメインエキスパートなどからのサポートの役割です。このフレームワークでの考慮事項は、単純なスケーリングではなく、アジャイルメソッドの適用です。大規模な組織では、コンプライアンス、アウトソーシング、グローバルに分散されたチームを必要とする規制環境。制限は、製品または製品ラインごとにDAのインスタンスを1つ持つことです。 程度の差はありますが、私はスクラム、ネクサス、DADを使用したプロセスの作業または実装に携わってきたので、それらについてしっかりと理解しています。私は、他の人が言っていることを読んでいる以上に、LeSSとSAFeの実用的な知識を持っていません。 LeSSは簡単なようです。これは、Nexusに代わるものであり、はるかに大きな拡張機能を備えています。LeSSのルールでは、LeSSは2〜8チーム向けに設計され、LeSS Hugeは8チーム以上向けに設計されています。開発組織のサイズは、LeSSの場合は15〜80、LeSS Hugeの場合は80以上と推定されます。組織によっては、LeSSの製品組織で20〜110人、LeSS Hugeで100人以上が見られ、管理、独立したQA、運用などがカウントされます。どちらの形式のLeSSも、単一の製品、またはおそらく密接に関連する一連の製品（製品ラインやマイクロサービスのセットなど）を対象としています。すべての製品には、LeSS（またはLeSS Huge）の独自のインスタンスがあります。 SAFeには、組織全体（操作、ユーザーエクスペリエンス、エンタープライズアーキテクトおよびシステムエンジニア、製品マネージャー、QA、開発者など）が含まれているようです。3つのレベルの組織と4つのレベルの組織という2つのモデルがあります。3レベルの組織は、チーム、プログラム、およびポートフォリオを識別します。4レベルの組織は、プログラムとポートフォリオの間にバリューストリームレベルを追加します。識別された役割の数に基づいて、これは複数の製品と並行プログラムを持つ大企業組織をターゲットにしているようです。実装のためのガイダンスを読む、彼らは実装組織が幹部と管理を訓練し、それから少なくとも50人の開発チームのメンバーを訓練することを期待しているようです。最小の組織サイズは、特定されたすべてのグループおよび実装を意味のある複数の製品にわたって数百人と思われます。 LeSSはターゲットオーディエンスに関してNexusの「競争相手」であり、SAFeは他のスケーリングされたアジャイルフレームワークよりもはるかに多くの製品または製品ラインを持つ非常に大規模な組織をターゲットにしているという私の想定では正しいですか？

10 agile  large-scale-scrum  scaled-agile-framework 

今日、誰もが機敏になりたいと思っています。私が一緒に働いたすべてのチームで、アジャイルの形は異なっていました。いくつかのことは一般的です-毎日のスタンドアップや計画などですが、他の部分は大幅に異なります。 私の現在のチームには、気になることが1つあります。それは機能要件の欠如です。書面による期待が存在しないだけでなく、タスクでは、何を実行する必要があるかが漠然と定義されています。 プロジェクトの目標は、新しいテクノロジーを使用して古いシステムを書き換えることです。古いシステムにも適切なドキュメントはありません。確かに最新のものは存在しません。事業主の要件の説明は、以前と同じように新しい実装で実行しましょう。それは合理的に思えますが、そうではありません。古いシステムは一種のスパゲッティコードであり、そこからビジネス要件を抽出するにはコストがかかります。状況は計画に悪影響を及ぼしているようです。確かに、新しい実装では間違いやバグが発生しやすい（詳細は省略）。 したがって、私は考えています-古いシステムを書き換える場合にビジネス要件がないことは本当に俊敏ですか？

10 agile  legacy-code  rewrite 

アジャイルの質問：アジャイルは物事を立ち上げて「迅速かつ汚い方法」で実行することを信じますか、それともアジャイルは根本からしっかりと構築することを好みますか？または、これは方法論の質問ではなく、ケースバイケースで評価する質問ですか？ 構造自体の多くをすでに構築した後、私は技術的にシステムの基礎を「再構築」しています...莫大な量の作業ではありません...アジャイルでは、最初にフロー全体を仕様化して分析する必要がありました。微調整してからビルドしますか？この方法の方が良いように感じます...乱雑なシステムを配置すると、それがどのように行われる必要があるかがよくわかります...一方、それはあまり体系化されていません...何が最良の開発であるかに興味があります実践はこれに関してです。 私はプロトタイピングと使い捨てコードについて質問していないので、この質問はアジャイルとプロトタイプとは少し異なると思います。プロダクショングレードのコードのアジャイルに興味があります。

10 agile 

私は、毎日のスタンドアップでのスクラムルールは、チームは昨日何をしたか、今日何をしているか、そしてそれらを妨げるものについてのみ話すべきだと言っていることを知っています。他には何もありません。しかし問題は、開発者が1日を自分のタスクに関係のない作業に費やし、それについてスタンドアップで話し合うことです。彼らが昨日やったことです！ 私の経験では、ボード上のタスクについて話し、スタンドアップに焦点を合わせ、全員のタスクに焦点を合わせ続け、見積もりを確認してレコードを毎日追跡する方がより効果的であることがわかりました。 ディスカッションをボード上のタスクに限定することは有効ですか？

10 agile  scrum  meetings 

開発方法論の別の新しい用語に出くわしましたが、その定義を見つけることができませんでした。具体的には、「電車ベースの開発」と呼ばれています。 ここに私がこの用語を見た場所のいくつかの例があります。 今週の初めに、私はエンジニアリングリーダーとリリースマネージャーにWindows MetroバージョンのFirefoxを廃止するよう依頼しました。（ジョナサン・ナイチンゲール） https://blog.mozilla.org/futurereleases/2014/03/14/metro/ MozillaのキャリアWebサイトから： アジャイル開発方法論とトレーニングベースの開発/ QAチームの両方での作業経験。 Mozillaのコンテキストだけでなく、以前に「トレーニング」について聞いたことがあります。しかし、ネット上でそれに関する良い情報を見つけることができませんでした。 「電車ベースのソフトウェア開発」をググると、検索結果にほとんど情報が見つかりませんでした。列車をワゴンから分離するために私が掘り出すことができる最も近いのは、「列車」はスケジュールに従って定期的にリリースすることです。しかし、「電車」は一種の具体的なQA設定のようでもあります。 では、「電車ベースの開発」とは何でしょうか？

10 agile  development-process  terminology  development-methodologies