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

これが一般的な質問ではないことを願っています。経験豊富なアドバイスを本当に活用できました。 私は、過去10〜20年にわたって広大なコードベースを一緒に使用してきたかなり小さな科学者の店で、唯一の「SWエンジニア」として新たに採用されました。（実質的に廃止された言語で書かれました：G2 -Pascal with graphicsを考えてください）。プログラム自体は、複雑な化学処理プラントの物理モデルです。それを書いたチームは信じられないほど深いドメイン知識を持っていますが、プログラミングの基礎に関する正式なトレーニングはほとんど、またはまったくありません。彼らは最近、存在しない構成管理の結果についていくつかの難しい教訓を学びました。また、コード自体に文書化されていない「スラッジ」が大量に蓄積されているため、メンテナンス作業が大幅に妨げられています。私はあなたに状況の「政治」をspareしまない（常にある 政治！）、しかし言うことで十分ですが、先の道に必要なものについて意見のコンセンサスはありません。 彼らは、現代のソフトウェア開発の原則のいくつかをチームに提示し始めるように私に頼みました。彼らは、コーディング規約、ライフサイクル管理、高レベルの設計パターン、およびソース管理に関する業界標準の実践と戦略のいくつかを紹介してほしいと思っています。率直に言って、それはかなり困難な作業であり、どこから始めればよいのかわかりません。 最初は、The Pragmatic Programmer、またはFowler's Refactoring（ "Code Smells"など）の中心概念のいくつかでそれらを指導したいと思っています。また、多くのアジャイル手法を紹介したいと思っています。しかし、最終的には、効果的にするために、5〜7の基本的な基礎に磨きをかける必要があると思います。言い換えれば、彼らが現実的に実装を開始できる最も重要な原則または慣行は何であり、それは彼らに最も「大金」を与えるでしょう。 それが私の質問です：スパゲッティをまっすぐにするのに役立つ（そして将来的にそれを防ぐために）最も効果的な戦略のリストに何を含めますか？

470 project-management  agile  development-process  maintenance  sdlc 

ソロ開発者としてアジャイルプロセスの概念をどのように実装しますか？アジャイルは、アプリケーションをより速いペースで開発するのに便利なようですが、非常にチーム指向でもあります...

133 agile  solo-development 

アジャイル手法（SCRUMなど）では、ユーザーストーリーに必要な複雑さ/労力はストーリーポイントで測定されます。ストーリーポイントは、チームが反復で取得できるユーザーストーリーの数を計算するために使用されます。 推定工数のように、具体的な測定値を使用できる抽象的な概念（ストーリーポイント）を導入する利点は何ですか？推定工数を使用して、速度を計算したり、反復のカバレッジを推定したりすることもできます。 対照的に、ストーリーポイントは使用するのが難しく（概念が抽象的であるため）、関係者に説明するのも困難です。どのような利点がありますか？

132 agile  scrum  estimation  user-story 

まだアジャイルに慣れていない人として、ユーザーのストーリー、機能、叙事詩の関係や違いを完全に理解しているとは思いません。 この質問によると、機能はストーリーのコレクションです。答えの1つは、機能が実際には叙事詩であることを示唆しています。機能とエピックは同じものと見なされますか？それは基本的には関連するユーザーストーリーのコレクションですか？ プロジェクトマネージャーは、階層構造があると主張しています。 Epic->機能->ユーザーストーリー 基本的に、すべてのユーザーストーリーはこの構造内に含まれている必要があります。したがって、すべてのユーザーストーリーはアンブレラ機能に該当し、すべての機能はエピックに該当する必要があります。 私には、それは厄介に聞こえます。ユーザーストーリー、機能、および叙事詩がどのように関連しているかを誰かが明確にできますか？または、違いを明確に概説する記事はありますか？

111 agile  terminology 

私の友人と私は、統合テストとは何かを正確に分類するのに苦労してきました。 今、家に帰る途中で、統合テストの実世界の例を挙げようとするたびに、それが受け入れテストであることがわかりました。事業者が大声で言うことで、システムが何を提供すべきかを特定します。 これらのテストタイプの分類についてRuby on Railsのドキュメントを確認しましたが、今では完全にスローされています。 統合テストの簡単なアカデミックな説明を実際の例で教えてもらえますか？

110 testing  agile  tdd 

バックストーリー： 私は過去3年間このチームの一員として働いていましたが、今回は3つの異なるスクラムマスターがいます。 スクラムマスターの変更とショーの運営方法のため、原則が一貫して実施されておらず、スクラムマスターの1人がアジャイルを信じない人だったため、私のチームはスクラムのアイデアに無感覚になりました。開発と企業の決定に従うための初心者としてのイベントとアーティファクトの保持。 私のチームメンバーは、スクラムイベントを行うときにイライラして退屈し、特に一人はこのことについて非常に口頭で話します。 現在： 2か月前、会社はアジャイルとその原則に専念するために、私のチームのスクラムマスターを任命しました。 私は、チームメンバーがスクラムを実行したくないという大気圧の下で非常に苦しんでいます。 前述したように、彼らは全体のプロセスに悩まされており、プランニング、レトロスペクティブ、およびデイリースクラムを効果的にするために必要な会話に参加していないため、私にとって非常に困難です。 彼らにとって、計画は時間の浪費です。なぜなら、私たちはオーバーフローを新しいスプリントに移し、とにかく作業を完了しないからです。 振り返ってみると、彼らは「スクラムをやめる」と言いたいと思うだけです。一人はそうしますが、他の人は黙っており、私は毎回これに対処しなければなりません。 デイリースクラムもまた、彼らにとっては時間の無駄です。彼らは「昨日はタスクXに取り組みましたが、今日もまたタスクXに取り組みます」と述べています。そしてほとんどの場合、彼らは冗談を言って冗談を言った。 これらのイベント中に彼らがどのように時間を過ごしたかということになると、私は非常に大きくなりました。しかし、私はこれに情熱を傾けており、彼らはもう気にしないので、内側で死にかけています。 今日、私に常に反対している人は、「彼らはこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言った。次のスプリントでクォータを埋めます。実際にKanBanを実行します。 なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。障害を処理するのではなく、単に機能します。彼らは障害について文句を言いますが、それらについては何もしません。そして、私が彼らを助けようとするとき、彼らはそれをすくい取るだけです。 かつて彼らは気にかけていましたが、過去2年間で彼らの意欲は多少なりとも底に落ちました。 これらの会議中に冗談を言ったり時間を無駄にしたりすると、会社に多額の費用がかかることを彼らに見せることができますか？

109 agile  scrum  scrum-master 

私は比較的新しいデベロッパーで、大学の新人です。大学在学中およびその後の求職中に、ユニットテスト、ロギング、データベースの正規化、アジャイル開発（一般的なアジャイルコンセプト）、コーディングスタイルに欠けている多くの「最新の」ソフトウェア開発方法があることに気付きました。ガイド、リファクタリング、コードレビュー、標準化されたドキュメント化方法（または要件）などもありません。 全体として、これが問題だとは思いませんでした。私は私の最初の仕事がこれらすべてのアイデアを受け入れ、仕事で私にそれらを教えることを期待していました。それから私は大企業で私の最初の仕事（フルスタックWeb開発）を得ました、そして、私は我々がこれらのことのどれもしないことに気付きました。実際、チームで最も経験の浅い私は、「最新の」プログラミング技術でチームをスピードアップさせようと試みている先駆者です。 最初にロギングソフトウェア（log4J）から始めましたが、すぐに独自のスタイルガイドの作成に移り、それをGoogleスタイルガイドのために放棄しました。 Springの採用-しかし、ユニットテストもなかったことに気付きましたが、私はすでにSpringを学習していました...そしてご覧のように、特に通常の開発作業と組み合わせると、圧倒的に速くなります。さらに、これらの方法論の中で「専門家」になって、他の誰かに教えるのに十分な「専門家」になるのは難しいです。 今日のソフトウェア開発の世界では「期待される」と思われるこれらのテクニックのうち、自分とチームの両方を圧倒することなく、それらを新しいプレーヤーとしてチームに統合するにはどうすればよいですか。 どうすればチームに影響力を与えてアジャイルになれますか？関連していますが、私はここの質問者のようなアジャイル開発者ではなく、アジャイルよりもはるかに広範な方法論のセットを探しています。

106 agile  teamwork 

私は3人の開発者と1人のデザイナーのチームで働くWeb開発者です。アジャイルスクラムソフトウェア開発方法論を実装したのは、約5か月です。しかし、私はこのサイトで共有したかっただけの奇妙な気持ちを持っています。 人間の生活における重要な要素の1つは、意思決定プロセスです。ただし、意思決定には大きな違いがあります。一部の決定は内部または外部の力の結果にすぎませんが、他の決定は完全にあなたの自由意志に基づいており、一部の決定は単なる中間的なものです。意思決定の自由度が高いほど、仕事はより自己主導的になります。これがルールのようです。私たちは自分自身の人生を形作る傾向があるからです。 あなたが何をするかを決めるか、何をするかを言われるかには大きな違いがあります。 スクラムの前に、開発、分析、実装の優先順位付けなどに関連する決定をより自由に行えるようになりました。自分がやっていることを決定しているように感じました。 ただし、スクラム方法論により、多くの決定は製品所有者から単純に下されます。彼はPBIを優先し、ソフトウェアがどのように動作するか、時にはUIと機能をどのように実装するかを分析します。これはスクラム方法論の一部であることを知っています。また、これにより将来的に製品の売り上げが向上する可能性があることも知っています。しかし、私は今、何かをすることを決心するのではなく、常に何かをするように言われているように感じています。この症候群により、私は仕事に対してより受動的になりました。 より良いソリューション、アプローチ、またはテクニックを見つけるために、検索回数を減らす傾向がある 楽しい仕事ができると期待して朝目が覚めない。むしろ、生きるために働くことを余儀なくされるような気がします 仕事の後、自分の趣味のプロジェクトに取り組みたいと思っています より高い技術レベルに到達するためにチームをプッシュすることはもうありません 夕食やお茶の時間に今より多くの時間を費やしているので、仕事に戻る意欲があまりない 私は家に帰ることができるように、仕事をもっと早く終わらせたいと思っています 大きな問題は、同僚でもこの動作を確認して診断することです。それはスクラムの結果ですか？スクラムは、開発チームに、ソフトウェア全体の形成に関与していないように感じさせ、プロジェクトを受動的にさせますか？どうすればこの気持ちを克服できますか？

103 agile  self-improvement  scrum 

明確にするため、締め切りは次のとおりです。 制限時間または期限は、目標またはタスクを達成する必要がある狭い時間フィールドまたは特定の時点です。 ウィキペディアから 私のソフトウェア開発のキャリア全体で「アジャイル」を行ってきましたが、これはどこでも、少なくとも次のプラクティスが順守されていることを意味しているように見えます。 毎週または隔週のスプリント 回顧スプリント計画 製品の所有者 スクラム ユーザーストーリー しかし、私がこれまでに行ったすべてのプロジェクトは、期限を設定することを主張しています。アジャイルが適応計画、柔軟性、変化に焦点を合わせようとしていることを考えると、締め切りはアジャイルですか？ 私の意見では、納期が柔軟性の欠如と品質の欠如につながるため、そうではありません。代わりに、スプリントと早期納品に集中するほうが価値があると思います。しかし、私が参加したすべてのサークルで、そうではなく、締め切りはアジャイル開発と連動すると見られています。

100 agile 

私のマネージャーは最近、生産性の目標と尺度として速度を使用することを本当に推し進めています。現在、平均速度50ストーリーポイントで作業しています。私のマネージャーは、ストーリーポイントを40％増やして70ストーリーポイントにすることを望んでいます（チームメンバーの増加はありません）。この増加が達成されない場合、彼はその理由を説明する完全な内訳を提供することを望んでいます。 チームのパフォーマンスを速度で測定し、それをターゲットとして使用するという考え全体は間違っているように思えますが、その理由を説明するのは難しいと感じています。助けがありますか？なぜ生産性を測定し、インセンティブを与えるのにこれが適切な方法ではないのですか？

89 agile  scrum 

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。 これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。 Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案しています 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように頼みます スクラム中毒マネージャーはスクラムチームに相談し、チームはすべての機能を完了するには3週間のスプリントが必要だと言っています Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約を結びます 4回のスプリント（出荷期限）後、スクラムチームは機能の80％しか提供できません（新しいシステムでの経験不足、本番環境の以前の機能の重大なバグを修正する必要性など）。 スクラムが示唆しているように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsは契約で述べられているように機能の100％を必要とします。だから彼らは契約を破って何も支払わない。 スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。 明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。要約すると、2つの質問があります。 誰が悪いのか？ 適切な計画を立てることが彼らの仕事だからです チーム。彼らができる以上の仕事をすることにコミットしたから 他の誰か 何を終わらせるべきなのですか？ マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。 チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより） 会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります 私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです ???

80 agile  scrum  sprint 

この質問はしばらく私の頭の中で調理されてきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に尋ねたいと思いました。 私の会社はついにアジャイルプラクティスを取り入れることに挑戦し、トライアルベースでアジャイルグループの4人の開発者のチームから始めました。3回の反復で4か月が経過しましたが、他の人にとっては完全にアジャイルになることなく、それを続けています。これは、経営者がビジネス要件を満たすための信頼が、上記の非常に多くのアドホックタイプの要求であるという事実によるものです。 最近、私はこのイニシアチブの一部である開発者と話をしました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、作業エリアで電話を取ることも許可されていません（ある程度は問題ないかもしれません）。たとえば、アジャイルチームに所属するキックについて友人と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っています。 このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断が生じないように完全な真空を提供し、6時間以上の生産時間を確保することです。まあ、私はアジャイルの第一人者ではありませんが、ヤフーのアジャイルロールアウトドキュメントや他の組織の同様の記事を読んだことから、アジャイルは安くないという印象を与えます。チームにアジャイルを浸透させ、到着した問題を修正して軌道に戻すには、リソースと予算が必要です。 まず、開発者向けのトレーニングとマネージャーなどのコーチングが必要です。現在のスクラムマスターは、管理者が支払うアジャイルトレーニングクラスを数日間受けたマネージャーで、現在このアジャイルチームを率いています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、会社ごとにカスタマイズされていることを指示しないと会議で聞いたことがあります。まあ、それはすべて良いと理にかなっています。 結論として、私はアジャイルが開発チームに調和をもたらすはずだと常に思っていました。ただし、アジャイルチームの開発者と話をするとき、私は非常に反対の気持ちになります。彼らは仕事以外は何も話せないのに不満であり、一日中静かに座って仕事をしているだけであり、経営者が仕事をより良くするための別の方法だと感じています。 これがより多くのドルのために利己的な優位性の目的のために使用される良い習慣の例であるならば、私に教えてください？あるいは、私のような開発者だけがこのアジャイルチームであり、仕事をしているために仕事をするだけの環境で働くのは好きではないと感じています。 これは、全米にオフィスを持つヘルスケア分野の会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じられるので、現在の会社では特に、アジャイルをまったく望んでいません。 それはすべて、管理が完全に安価であることと関係しています。安価なバージョンのために高価なコーヒーを切り取り、可能な限り無駄を省きながら、節約と生産性を重視します。 私は、ドアの後ろの経営陣がこのアイデアを捨て、アジャイルにより生産性が向上し、同じ人員でより多く生産している上司に見せることができると感じています。または、もしそうであれば、人員を減らすことができます。 彼らは毎日5分間の会議を開いています。ただし、チーム外の人とチャットや会話をすることはできません。すべての焦点は仕事にあります。

80 agile  scrum  methodology 

したがって、アジャイルは初めてですが、テスト駆動開発ではありません。大学の私の教授は、テスト、コード、そしてテストのアイデアについてすべてでした。理由がわかりません。私の観点からは、多くの初期費用であり、おそらくコードが進化するにつれて変更されるでしょう。 これが私がTDDを想像し、それが私を混乱させる理由です。TDDの請負業者として家を建てる場合。 すべての仕様（ストーリー）を教えてください。 仕様の承認を取得します。 すべての仕様を検査に分解します（今後参照してください）。 検査官に電話してそれらの点を見て、今私は検査に失敗していると教えてください（ありがとう）。 家を建て始めます。 インスペクタを毎日コールバックします（2/100を渡します）。 ああ、私の理解に問題があったので、今度は9つの検査を追加して、27を変更する必要があります。 1/109を渡すインスペクターを呼び出します。 畜生。なぜインスペクターはこのようなものではないのでしょうか...ああ、そのメソッド名を更新しました... さらにビルドします。 UGGGGHHHHのその他の変更により、いまいましいインスペクタを更新できます。ああ、私は失敗していません。 もう終わった？ さて、それは奇妙なことかもしれませんが、すべてのメソッドをどのように知るべきか、そしてコードがそこに来るまでどのように機能するかはわかりません。99％の時間、戻ってユニットテストを更新する必要があります。ただ逆に思えます。 より適切と思われるのは、DDTまたは開発主導のテストです。これは、コミュニティが忘れてしまったことのように思えます。 私の理解では、家のDDTは次のようになります。 すべての仕様（ストーリー）を教えてください。 仕様の承認を取得し、それらを分割します。 ユニット（基礎）を開始します。 トリッキーなロジックのメモ（コメント）を取ります。 最後に次のユニットの検査を開始します（テストを作成します）。 見つかった問題を修正し、再度検査します。 このユニットが次のユニットに移動することを承認しました。 私たち全員が正直であるならば、それはより人間的で、開発者とビジネスに集中しているとは思わないでしょうか？変更をより速く行うことができ、オーバーヘッドなしでTDDが作成されるようです。

74 agile  tdd  development-methodologies 

アジャイルアプローチは、要件があいまいで、エンドユーザーのアイデアを形作るのに多くの相互作用が必要なプロジェクトに最適だと思います。 しかし...私の専門的な仕事では、「アジャイル」アプローチが前もってデザインに労力が費やされなかった理由の言い訳として使われている会社に行き着きます。要件が十分に理解されている場合。 アジャイルなアプローチがなかったら、いいハイレベルな仕様でここに座っていて、何か他のものができあがったときでも同じ画面と機能を二度と再訪する必要はないだろうと考えずにはいられませんそんなことは考えていませんでした。 アジャイル手法の利点は、カウボーイの技術的なリードに足りないという言い訳を上回るのに本当に十分なのでしょうか？ 更新：皮肉なことに、私は認定スクラムマスターになりました。スクラムコースで発表された論文の1つは、最適な開発プロセスは、設計上の決定を下す単一の専門家または第一人者がいるが、明らかな弱点があるものであると述べました。スクラムは、品質の高いソフトウェアを作成する責任を「チーム」に移します。つまり、標準以下のチームは、他のアジャイル開発プロセスや非アジャイル開発プロセスと変わらないスパゲッティを排除できます。

73 agile  cowboy-coding 

ここまで読んで研究してきたすべてのことは、アジャイル/スクラムが約4〜6人、さらにそれ以上のチームでどのようにうまく機能するかを説明しています。 私の現在のショップには、約8人の開発者がいますが、プロジェクトの量とサポートする部門の数を考えると、特定のプロジェクトに1人または2人以上の人が割り当てられることはありません。 1人または2人の開発者のチームでアジャイル/スクラムを使用できますか？私はこの方法論で作業を開始するためにマネージャーにピッチを作成しようとしていますが、小さな開発者クルーのために物事を縮小する方法を説明するか、特定のメンバーを増やすように説得する必要があります事業。

63 scrum  methodology  agile