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

まず、これがこの質問を投稿するネットワークの間違ったセクションである場合、私は謝罪します。もしそうなら、より適切な場所に移動してください... 質問：オープンソースプロジェクトの開始と実行の方法に関するあなたのアイデアを聞きたいです。オープンソースのコンテンツ管理システムプロジェクトがありますが、ここでいくつかの疑問が生じます。最初にフロントエンドとバックエンドが機能する実行可能なプレアルファ版を作成してから、プロジェクトを公開しますか？それとも、すぐにそれを発表しますか？開発者として、GitやSVNなどのバージョン管理システムを使用する必要があることを知っています。そして、ユニットテストのメリットも覚えておく必要があります。率直に言って、私はまったく興味がありません…プロジェクト管理-私はせいぜい初心者です。アジャイル開発などのコーディング技術と経験は、私が探求したいものです... 要するに、オープンソースの世界に慣れていない開発者向けのアイデアは大歓迎です。

29 open-source  cms  agile  project 

無駄のないソフトウェア開発とISO 9001の対象となる慣行との関係を扱った学術論文はほとんどありません。ほとんどの記事は、これらのアプローチの相違は大きいと述べていますが、アプローチします。 学問的にはとても美しいですが、実際にはとにかくですか？ 質問は次のとおりです。ISO9001としてアジャイルの両方を適用している会社で働いていますか、または働いていましたか？あなたの認識は何ですか？本当に良いものと不適切なものは何ですか？

28 agile  lean  iso 

当店では、アジャイルであるよう努めています。そして、私たちは大きな進歩を遂げていると思います。そうは言っても、私たちの何人かは、「障害駆動型開発」と呼んでいるパターンを発見しました。 障害駆動型開発は基本的に、バグ/機能が受け入れ基準を備えたタスクやストーリーではなく、欠陥追跡ソフトウェアに入力された欠陥によって導かれるアジャイルなリリース/反復サイクルとして記述できます。 私たちのチームには、顧客からの受け入れ基準の取得に努める優れたプロジェクトマネージャーがいますが、常に可能であるとは限りません。私の開発委員長から、これは顧客が自分が望むものを正確に知らないか、顧客の本社の2つの異なる「キャンプ」がストーリーの実装方法と対立するためです。キャンプAは、機能Xがこのように機能することを大まかに指示し、キャンプBはそのように機能しないために失敗します。したがって、「FDD」という用語。プロセスは「失敗」によって駆動されます。 これは私の質問につながります：他の誰かがこれに遭遇しましたか？もしそうなら、それを扱うためのヒント/提案はありますか？ もちろん、キャンプAとBが事前に同意するように試みましたが、これは必ずしもそうではないことを誰もが知っています。 ありがとう

28 agile  anti-patterns 

私は興味深い仕事を提供されましたが、私にとって大きな警告があります：彼らはペアプログラミングを使用します。 私はペアプログラミングのアイデアが嫌いで、おそらくそれには向いていません：私は頻繁にポーズをとるのが好きです、誰かのプログラミングを見ることは嫌いです（自分でコーディングするために絶えずペアを突っ込んでしまいます）私が取り組んでいるマシンのコントロール、音楽を聴くのが好きで、基本的に他の誰かに縛られるのは好きではありません。私は社交的な人間でもありません。 しかし、実際にペアプログラミングを行ったことはありません（他の人を支援したり、複雑なタスクを一緒に解決したりするために、短い時間を数回使用します）。そして、私の態度を考えると、仕事を拒否すべきですか、それとも現在の仕事を辞めて試してみるべきですか？ それについて尋ねた人々のために：私は、私たちが「荒野でコーディング」している私の現在の仕事が嫌いなので、正式な設計と開発が使用される仕事を探しています。会社は私の技術的なプロファイルに非常に興味を持っているので、ペアプログラミングで仕事をしたことはないと指定したとしても、彼らはそれを好まないだろうと主張しました（社交的でない孤独なプログラマーであるだけでなく、ペアプログラミング）。

28 agile  pair-programming 

作業しているコードベースのユニットテストカバレッジが0％である場合、「アジャイル開発」または「アジャイル手法」を適用していると主張することは理にかなっていますか？（そして、チームとして、あなたはそれについて何もしていません）。 それを明確にするために：私にとって、それは意味がありません。私の個人的な経験では、ユニットテストが実際に「アジャイル」（つまり、変更への対応、設計の改善、知識の共有など）を可能にする唯一のツールであり、TDDが唯一の手段であることがわかりました。 。 他の方法もあるかもしれませんが、どのように機能するかはまだわかりません。

27 unit-testing  agile  tdd 

アジャイル手法について簡単な文章で説明できる人はいますか？

27 development-process  agile 

私は2つの物語を持っています（私は彼らが利益部分を欠いていることを知っています） 与信管理ユーザーとして、Officeの現在と以前の給与の差異を表示できます。 与信管理ユーザーとして、Officeの現在と以前の給与の差異のPDFを含む電子メールを受信できます。 2つは、同じクエリ/フィルター基準を持つという点で関連しています。唯一の違いは、「表示」ストーリーでは結果がユーザーに表示され、「メール」ストーリーでは結果がPDFに書き込まれ、ユーザーにメールで送信されることです。 これらの2つのストーリーの共通の側面の分離に苦労しています。 たとえば、どちらも同じクエリを使用しますが、結果に対する処理は異なります。 クエリを純粋に技術的な別のストーリーに分離する必要がありますか？ PDFの作成と電子メールの送信はオフラインで行う必要がありますが、それは技術的な話になりますか？ これらの2つのストーリーを2つの機能的なストーリーと2つの技術的なストーリーに分けることができました。 システムとして、Officeの現在の給与と以前の給与の差を計算できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いを確認できます。 システムとして、Officeの現在の給与と以前の給与の違いのPDFドキュメントを作成できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いのPDFを含む電子メールの受信をリクエストできます。 私が戻ってくる問題は、4つのストーリーが独立しておらず、「ケーキをスライス」しないことです。 したがって、これら2つをどのように扱うかはよくわかりません。

27 agile  requirements  user-story 

アジャイルは、ヘルスケアITのような分野で採用できますか？そこでは、患者のケアの多くがシステムの品質とタイムリーな配信に依存していますか？

26 agile  healthcare 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 以前にアジャイルと効果的に仕事をしたことがある人として、私は現在の雇用者にアジャイルの利点を納得させようとしています。ただし、経営陣は、プロジェクトのビジネス価値を評価するために、事前に見積もる能力を保持することを強く求めています。 私の顧客のほとんどは社内にいるので、最近、チームを回って、自動化するビジネスプロセスのアイデアを彼らに尋ねることを任されました。次に、これにどれだけの時間がかかっていたかを調べ、ソリューションがどれだけの時間を節約できるかを調べ、総開発時間を見積もりました。そうすれば、管理者は、時間の節約という点でソリューションがどれほど効果的であるかを測定することができます。 しかし、この要件に「アジャイル」でアプローチする方法はないように思えます。柔軟な要件とは、所要時間の推定が間違っているだけでなく、潜在的な時間の推定も節約されることを意味します。私は多くのことを説明し、なぜそれが問題になる可能性が高いのかを説明しましたが、それは交渉不可能であると言われました。 （ウォーターフォール）クライアントにアジャイル開発を販売する方法の質問には、外部顧客にアジャイルを「販売」する方法に関する有用なアドバイスがあります。私はそれを外部のクライアントに販売しようとはしていません。うまくいくと信じている方法論を保持しながら、内部管理の要求をどのように調整できるかを考えています。 少なくともいくつかのアジャイルの利点を保持できる柔軟な方法でこのタスクにアプローチする方法はありますか？

25 agile 

私の職場では、「アジャイル」とは「あいまいな要件、受け入れ条件の悪さ、幸運」を意味することが多いという課題に直面しています。私たちは、一般的な改善努力として、それに対処しようとしています。 そのため、その一環として、ユーザーストーリーレベルを超えて、システム内の特定の機能の影響の予備調査の結果を正確に反映し、私たちが持っている質問への回答を含む設計ドキュメントを生成することを提案していますビジネスに尋ねた。 これに効果的な基準はありますか？ 現在、新しい機能が「泥の大玉」システムの複数の領域に影響を与える可能性がある状況に直面しており、この技術的負債により見積もりが上昇し始めています。うまくいけば、より思慮深い設計プロセスが役立つことがあります。

25 design  agile  documentation 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 icescrumで遊んで、ユーザーストーリーとユーザー機能の違いを理解していないことに気付きました。 誰かが違いを説明できますか？

25 agile  scrum  features 

一般的なアジャイルのプラクティスを見ると、彼らは（意図的または意図せずに）開発者にブログ/記事の閲覧、チャット、コーヒーブレイク、単なる先延ばしとは対照的に、実際により多くの時間を費やすように思われます。 特に： 1）ペアプログラミング-最大のワークフォーサー。2人が一緒に座っているときに先延ばしをするのは不便だからです。 2）短編小説-1か月などで行う必要のある大量の作業がある場合、最初の3週間で緩み、最後の1週間はOMG DEADLINEモードに切り替えるのが一般的です。 そして、小さなチャンク（1日以内に行う必要があります）では正反対です-時間はきついと感じ、操縦するスペースがなく、すぐにタスクの責任を負うことになりますので、開始しますすぐに動作します。 3）チームのコミュニケーションと結束-ゆっくり、遠く離れた静かな環境でパフォーマンスを下回っていても大丈夫だと感じるかもしれませんが、スクラムミーティングで一日の終わりに誰もが達成したことを誇り、実際に感じるかもしれないと言うことはありません恥ずかしい。 4）テストとフィードバック-再び、締め切りが突然発生するまで、タスクを「99％準備完了」（実際には20％程度）に保つことを防ぎます。 アジャイルのもとでは、「従来の」方法論よりも仕事をしていると感じますか？この圧力は、より快適な環境と、実際に正しいことを迅速に実行できるという感覚によって補われていますか？

25 agile 

私はアジャイル手法を実践しようとする多くのチームに所属しており、多くの場合、これらのチームはテスト中心です。テストはアジャイル手法を実践するのに必要な部分ですか、それとも長年にわたって定着しているXPの実践ですか？

24 agile  testing  extreme-programming 

オフィスで、視覚障害のある新しい同僚を見つけました。 私はポーカープランニングの企画を担当しており、新しい同僚はチームのメンバーとして参加する必要があります。素晴らしいポーカーカードのセットがあり、そこにポーカーナンバーが計画されていますが、それはもちろん新しい同僚にとっては役に立ちません。 これまでは、見積もりに名前を付けるだけでこの問題を修正し、新しい同僚に残りの人がカードを置いた直後に見積もりを言うようにし、残りの人がカードを裏返し、見積もりに名前を付けました。 私の質問：このような状況を経験し、より良い解決策を持っている人はいますか？点字ポーカーカードのようなものはありますか？ 現在のソリューションは機能しますが、たとえば点字ポーカーカードを使用することで、これは私たち全員にとって改善できると思います。

24 agile  scrum  planning  project-planning 

開発者（またはプログラマー）アナーキーについて読んでいますが、これはアジャイル開発後の方法論として請求されているようです。私は（それにいくつかのリソースを発見した1、2）そこにたくさん出ていないようです。 私はそれについてもっと知ることができる良いリソースがあるかどうか疑問に思っていました-実装方法、賛否両論、他の方法論との比較など

24 agile  development-process  development-methodologies