問題タブ [agile]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
8 に答える
737 参照

agile - アジャイル開発方法論に移行する最良のケースは?

アジャイル開発方法論 (SCRUM や XP など) の採用または移行についてビジネスに主張する必要がある場合、どのような主張をしますか (コンセプトをどのように売り込むか)?

例えば

  • 技術者ではない人に、概念と利点をどのように説明しますか?
  • 成功した場合、勝者となった議論/ケース/理論的根拠は何でしたか?
  • 編集:私が尋ねる理由は、私の友人(彼は会社のソリューションアーキテクトです)が現在、まさにこのトピックについて彼の経営陣にどのようにアプローチするかを決定しようとしており、提案に関して私ができることを彼に与えたからです。 . 特に、アジャイルに沿った方法論への移行を成功させた人々の話を聞くのは興味深いことです。

    0 投票する
    6 に答える
    364 参照

    architecture - アジャイルプロジェクトでアーキテクチャをどのように制御しますか?

    柔軟なソフトウェアアーキテクチャを可能にする「適切な」設計上の決定を使用してプロジェクトが構築されることをどのように保証しますか?

    アーキテクチャを一方のチームに完全に任せることと、すべてのアーキテクチャをもう一方の少数の個人に制御させることのバランスをどのように取っていますか?

    「建築グループ」や「建築レーベル」などはありますか?

    0 投票する
    2 に答える
    701 参照

    agile - クラスプロジェクトに最適なアジャイル手法は何ですか?

    プロジェクトの定義は不十分です。CS111コンピュータプログラミングIの学生向けに、機能に焦点を当てた教育用ソフトウェアを作成する予定です。Flexで働いているさまざまなバックグラウンドを持つ6人の学生開発者がいます。プロジェクトの期間は約7週間です。面接時間は非常に限られており(週30分)、作業時間は非常に限られています(開発者1人あたり週8時間未満)。お客様(コースの教授、CS 111の教授、CS 111の学生)へのアクセスは制限されています。

    当社のツールセットには、Flex Builder、Subversion、およびTRACが含まれています。

    このプロジェクトに最適な方法とその理由は何ですか?あるいは、この状況により適したものにするために、さまざまな方法論からどのような機能を収集する必要がありますか?

    0 投票する
    11 に答える
    3056 参照

    agile - カードウォール+オンラインカードウォール=重複?

    私は努力を複製するのが好きではありません。ただし、物理的なカード ウォールとオンラインの「電卓」 (Excel、いくつかのスクラム ツール) またはオンラインのカード ウォール (Mingle など) の両方でアジャイル イテレーションの進行状況を追跡することには利点があることがわかりました。

    チーム スペースの物理的なカード ウォールは、カードの状態と本能的なつながりを提供することを発見しました...そして何かを終えたときにカードを物理的に動かすことは、オンラインでは真似できないレベルの満足感を提供します。私はカードを感じることができます...そして人々は私が何かを動かすために壁まで歩いているのを見ることができます.

    オンライン ツールは、リモートで共有し、進行状況を計算するための優れた機能を提供します (たとえば、Mingle では、組み込みツールを使用して、実際のデータからバーンアップまたはバーンダウンを自動的に計算し、それらを手動で行うための多くの管理時間を節約できます)。 )。

    アジャイルの実践者が私のように 2 つのトラッキング メディアを維持している場合、物理的な壁の利点を「オンラインでできる... なぜカード ウォールでやりたいのか?代わりは?"。

    0 投票する
    5 に答える
    1324 参照

    unit-testing - 単体テストの保守負担の管理

    コーディングテスト-最初に、私のコードのおそらく3/4が単体テストであることがわかりました。私が本当に極端で、失敗した単体テストを修正する以外にコード行を記述しなかった場合、この比率はさらに高くなります。これらすべての単体テストを維持すると、コードの変更に大きな慣性が加わります。早い段階で、私はそれを吸い上げて修正します。プレッシャーがあるとすぐに、私はbroken_unit_tests「時間があるときに」再訪するためのディレクトリに行き着きます。デザインが結晶化する前に、TDDが高カバレッジを開始するのが早すぎるように感じます。

    このジレンマから抜け出し、私が想定しているように変化する要件を歓迎し始めるにはどうすればよいですか?

    0 投票する
    13 に答える
    29510 参照

    project-management - 方法論としてのスクラムの主な利点は何ですか?

    私はデザイン会社の技術部門で働いています。XP を使用して、部門のソフトウェア開発を管理しています。私は、スクラムについて説明し、クライアントのプロジェクト作業を管理するためのより広い文脈でスクラムが適切かどうかについて簡単なプレゼンテーションを行うよう求められました。

    スクラムは、グラフィック デザイナー、情報アーキテクト、コンテンツ エディター、ユーザー エクスペリエンス エンジニア、Web デザイナー、およびソフトウェア開発者を含む部門横断的なチームに適用されます。

    スクラムはこの種のチームにどのような利点をもたらすでしょうか?

    0 投票する
    4 に答える
    1116 参照

    agile - 実用的なアジャイルですか?

    私はPragmaticProgrammerを読み直しました(3回目はそれを読んでいます...私も毎回何か新しいものを手に入れます)。彼らが言及しているヒントは、さまざまなアジャイル手法の多くに関連しているようです。実用的なプログラミングは、アジャイル開発の単なる別の形式ですか?

    0 投票する
    5 に答える
    32535 参照

    agile - スクラムとエクストリームプログラミングの違いは何ですか?

    数年前、私はエクストリーム プログラミングを行うグリーン フィールド プロジェクトに取り組みました。また、多くの人がスクラムの方法論について言及しているのも目にします。

    誰かスクラムと XP の主な違いを教えてもらえますか?

    0 投票する
    8 に答える
    1348 参照

    tdd - 重要なアプリケーションでTDDをどのように実行しますか?

    私はTDDをテーマにした本やウェブサイトをたくさん読んだことがありますが、それらはすべて、特にケントベックの本で非常に理にかなっています。しかし、自分でTDDをやろうとすると、どうやって始めたらいいのかとキーボードを見つめています。使用しているプロセスはありますか?あなたの思考プロセスは何ですか?最初のテストをどのように特定しますか?

    この主題に関する本の大部分は、TDDとは何かを説明するのに優れた仕事をしていますが、実際の重要なアプリケーションでTDDを実践する方法については説明していません。TDDはどのように行いますか?

    0 投票する
    7 に答える
    2163 参照

    continuous-integration - スクラム/アジャイル:内部改善をどのように計画しますか?

    私は過去2年間、アジャイル/スクラムアプローチを使用する2つの異なるチームで作業してきましたが、どちらのチームもソフトウェア開発へのアプローチ方法を改善することに熱心でした。最初のチームでは、ビルドシステムの改善、より良い統合テストの設定、より良いリリース戦略の設定など、社内の作業に時間を割くようにプロダクトオーナーを簡単に説得できました。現在、POも喜んで時間を与えてくれますが、彼はもっと押し返しています、それは彼も彼のことを成し遂げなければならないので合理的です。

    とにかく私の質問は今です、他のチームはこれをどのように処理しますか?改善ストーリーを作成し、計画中にそれをテーブルに置きますか、それともそのようなことのために時間の「バケツ」を保持しますか?改善のための時間を確保するように製品所有者を説得することは、あなたの経験ではどれほど難しいですか?結局のところ、これらの種類の改善はチームに利益をもたらしますが、直接またはすぐに製品の所有者/ビジネスに利益をもたらすことはありません。