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

私は2人の開発者で構成される小さな会社を経営しています。私たちは、クライアントの1人に対して非常に大きなアプリケーションを構築しています。このプロジェクトの開発は1.5年間続いています。 現在、このクライアントは重要なスポンサーを獲得しており、このプロジェクトに関連するイベントを開催しています。だから今、私たちは2ヶ月で期限があり、私たちはそれを見逃すことはできません。 チームに新しい開発者を追加することを考えていますが、彼の統合を支援するために何ができるのかと思います。 これが状況です： ブルックスの法則の限界に近づいています-新しい開発者を追加するときのポイントは非生産的です。 アプリケーションは比較的適切に設計されていますが、実装はいくつかの点で混isとしています（特に古いコード）。 ユニットテストは、より新しいコードに対してのみ行われます。このプロジェクトが始まったとき、私たちは定期的にテストを行いませんでした。 ドキュメントとコメントは不完全です。 アプリケーションは大規模で複雑です。 クライアントは、プロジェクトに関するほとんどすべての詳細を、非常に明確で「プログラマーに優しい」方法で書き留めています。 今すぐ人を追加することをお勧めしますか？もしそうなら、新しい開発者がチームに統合するのを助けるために何ができますか？ 編集： スポンサーは来春にインターネットベースのスポーツイベントを開催しています。年の特定の日に開始する必要があります。変更することはできません。 開発者（私は2人のうちの1人）がする必要があるのは： 既存のアプリケーションを完了します（実行する作業の約25％）。 このイベントの組織に不可欠な新しいモジュールの作成（行う作業の約75％）。この新しいモジュールは、メインプログラムのAPIを理解しないと開発できません。 正確な時間の見積もりはできませんが、私たちは危険な状況にあります。

24 project-management  agile  teamwork  estimation  knowledge-transfer 

私はアジャイルマニフェスト原則を読んでいました。1点を除いて、すべてが明確で合理的なようです。 シンプルさ-完了していない作業量を最大化する技術-は不可欠です。 これはわかりません。これは、行われなかった作業が何らかの形で誇張されるべきであることを意味しますか？もしそうなら、それは本当に意味をなさない。

24 agile  management 

前回のアジャイルの議論ここでは何であるかを指定良い答えを持っていた重要なソフトウェア開発におけるアジャイルの方法論を実装の成功に。ポイントのほとんどは典型的な組織および管理の課題でしたが、1つのポイントは私を心配し、クライアントはプロセス全体に関与しなければならないということです。 クライアントは現実的に制御できないものの1つです。おそらく、ビジネスモデルは政府の請負業務に向いています。たとえば、厳しく厳しい契約が会社に次の義務を負わせている場合などです。 要求どおりにX機能を提供する 機能のリクエストは壁を越えて投げられますが、私たちはそれを聞きたくありません。 顧客の頭の中には機能の優先順位という概念はありません。それらはすべて重要であるか、私たちがそれらを要求しなかったでしょう。 このプロジェクトは、オーバーランや締め切りに関係なく、Y以上の費用がかかりません。 すべての作業を完全に実施するための、絶対的、厳格、最終的、交渉不能の期限。 私たちは以前にそのようなクライアントと仕事をしたことはありませんでしたが、プロジェクトのお金は過ぎ去るにはあまりにも良いです。この作業が必要です。 私はここに来て、HARDでプロセスを変更してアジャイル開発に移行しました。ここで、このプロジェクトが新しいプロセスに適合する場所を調整する方法がわかりません。私はこれまでに開発チームとプロセスをこの道に導くと信じていたオープンマインドなハンドオフ管理の贅沢を持っていませんでしたが、私たちはここにいるので、このプロジェクトが本当にアジャイルな方法。経営陣はこの道をリードしてくれると私を信じており、私たちが今いるこの状況はウォーターフォールを明確に要求しているので、彼らを失望させたと感じています。今バックトラックすると、彼らの信頼を失うかもしれないと思う。 ここにあるような他の答えは、この種のクライアントではアジャイルが不可能だと言っていますが、同意しますか？似たような状況にあり、それを機能させた人はいますか？アジャイルを成功させるためにどのような戦略を実装しましたか？

24 agile  requirements  government 

私の会社の誰かが最近、コア製品の変更を提案しました。マネージャーは、私の会社が完全なQAサイクルと考えるものをトリガーする必要があると感じています（つまり、製品スイート全体を一からテストする）。QAが製品のQAサイクル全体を実行するには、12週間かかります。これに関する私の問題は、アジャイル（ほとんどの意見では半分ですが）開発をしようとしていることです。スプリント全体を実行した後、リリースを実行します。QAはこれを完了するまでに時間がかかります。問題は、QAが仕事をするのに12週間かかる場合、アジャイルをやろうとするのをあきらめてはいけないということです。このような状況でアジャイルをやろうとすることの意味は一体何でしょうか？

24 agile  qa 

そのため、テストの価値を本当に理解していない人から何度も聞いています。物事を始めるために、私はアジャイルとテストのフォロワーです... 私は最近、製品の書き換えでTDDを実行することについて議論しました。現在のチームはどのレベルでも単体テストを練習しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがないでしょうコードをきれいにするために）。 現在、私はこの製品の書き換えについて完全に責任を負っており、TDDのように試してみると、単にメンテナンスが悪夢になり、チームがメンテナンスすることが不可能になると言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。ビジネスドライブが変化すると（当然、改善を意味します）、テストは時代遅れになります。将来のプロジェクトはそれらを維持せず、彼らが修正するなどの負担になるでしょう。 現在、テスト経験のないチームのTDDは良く聞こえないことは理解できますが、この場合の私の主張は、周囲に練習を教えることができるということですが、さらに、TDDがより良い結果をもたらすことを知っていますソフトウェア。TDDを使用してソフトウェアを作成し、メンテナンスチームに引き渡す際にすべてのテストを破棄する場合でも、TDDを最初から使用しないよりも確実に良い方法でしょうか。 TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うことについて言及したので、私は撃downされました。「インターフェイス」と奇妙な外観のDIコンストラクターの考えは、それらを怖がらせます... 通常、TDDを販売しようとするという非常に短い会話や、人々への私のアプローチについて、誰か助けてください。会社/チームにひざまずく前に、私は通常非常に短い議論の窓を持っています。

24 testing  agile  tdd  bdd 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ユーザーのメールにownれているので、取得したすべてのリクエストを管理し、チームのユーザーとユーザーがそれらにアクセスして共有できるキューに入れるより良い方法を実装したいと思いますノート。電子メール、コメント、アイデアなどをドロップ/入力して簡単にアクセスできるプロジェクトの下で、複数のタスクを作成できるようなタスク管理ツールを考えています。 ユーザー、マネージャー、チームリーダー、開発者など、すべての関係者が関与できるものが必要です。私ができるツールを探しています： ユーザーは、電子メールをドラッグアンドドロップするだけで、メンテナンスまたは機能強化のリクエストを送信できます。 開発者は、各タスク/プロジェクトのキューと重み付けされた優先度を確認するだけです。 開発者のチームは、誰もがリアルタイムで作業していることを確認します。 各タスクに費やされた時間のログを保持する管理。 IIは、この問題を解決するために、よりアジャイル/スクラムの方向に目を向け始めています。私はスクラムアジャイルソフトウェアプロジェクト管理のオープンソースツールのリストを見つけました。私は時間に制限があるので、誰かがこれらを使用しましたか？私のニーズを満たすかどうかを確認するには、どれをテストする必要がありますか？TeamPulseは良い方向ですが、少し肥大化しすぎていると思います。すべての関係者にとってシンプルなものが必要です。

24 project-management  agile  scrum  issue-tracking 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私は最近私たちが参加しているいくつかの新しい人のためにアジャイルのコースを書いています、そして私はアジャイルがすべてのプロジェクトを意味するものではないことを彼らが理解するように注意書きを加えたいです。 私の問題は、私がアジャイルで取り組んでいるプロジェクトの性質のため、これまでかなりうまく機能していたため、間違った種類のプロジェクトで何が間違っているのか、なぜそれを使用するのかを正直に指摘することはできません。 アジャイルプロジェクトがうまくいかないときに注意すべきことは何ですか？

23 agile 

プロジェクトでは、次のようなタスクに時間を費やす必要がある場合があります。 代替のフレームワークとツールの調査 プロジェクト用に選択されたフレームワークとツールの学習 サーバーとプロジェクトインフラストラクチャ（バージョン管理、ビルド環境、データベースなど）のセットアップ ユーザーストーリーを使用している場合、この作業はどこに行けばいいですか？ 1つのオプションは、それらすべてを最初のユーザーストーリーの一部にすることです（たとえば、アプリケーションのホームページを作成します）。別のオプションは、これらのタスクを急増させることです。3番目のオプションは、タスクをユーザーストーリーではなく問題 / 障害（たとえば、まだ選択されていない開発環境）の一部にすることです。

23 project-management  agile  scrum  user-story 

ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は過去4年半にわたってエンタープライズの分野で働いてきましたが、一般的に言って、エンタープライズはテストファーストスタイルの開発を促進する環境ではないことに気付きました。プロジェクトは通常、固定コスト、固定タイムライン、およびウォーターフォールスタイルです。ユニットテストが行​​われたとしても、通常はQAフェーズでの開発後に別のチームによって行われます。 企業で働く前に、私は多くの中小企業に相談しましたが、テストファーストスタイルの開発プロジェクトにお金を払うつもりはありませんでした。彼らは通常、開発をすぐに開始するか、短い設計期間の後、つまりアジャイルに似たものを望んでいましたが、一部のクライアントはすべてがウォーターフォールのようにマッピングされることを望みました。 テスト駆動開発は、どのタイプのショップ、企業、クライアントで最も効果的ですか？どのタイプのプロジェクトがTDDを助長する傾向がありますか？

23 testing  agile  unit-testing  tdd 

アジャイルに関する本を書くことができませんでした。私は彼らのプロセスをアジャイルと呼ぶいくつかの店で働いてきました。アジャイル開発の主なポイントの1つは、定期的なクライアントの関与です。スプリントの後、フィードバックを得るためにクライアントに作業をデモすることができます。すすぎ、繰り返します。 私が出くわす問題は、多くのクライアントがそのようになりたくないということです。彼らは、ウォーターフォールアプローチを好むでしょう。要件を事前に収集し、完了したら戻ってください。私の経験では、滝は機能しません。クライアントは、それを見るまで何が欲しいかを知りません。ウォーターフォールのジレンマは、すべての要件を事前に取得したい開発者の大規模なコミュニティによってさらに広まります。このようにして、彼らは自分が何を構築しているのかを知り、それに応じて設計することができます。そして、クライアントは、前述の要件に「サインオフ」したので責任があります。 私は間違っていますか？クライアントの関与なしにアジャイルは機能しますか？もしそうなら、私が議論した問題をどのように、どのように克服しますか？

23 agile  waterfall 

私はアジャイルチームの開発者であり、スクラムを使用しようとしています。 そこで、状況を説明するために仮想問題をここに入れます。 面倒で保守性の悪いJQueryコードを使用した非常に古いアプリがあります。また、Reactを使用したアプリの一部もあり、それらの部分は更新/保守がはるかに簡単です。それに加えて、会社の目標は、Reactでクライアントシングルページアプリを作成することです。そのため、JQueryを使用すると、さらに離れることができます。 計画を立てるときは、常に開発時間の観点から簡単な解決策を探します。たとえば、新しいダイアログなどを作成する場合は、以前のJQueryを使用します。後で整理してReactに変換しますが、それはめったに起こりません。 ユーザーストーリーから、必要なことの要件を取得します（IMOはよくできていますが、スリムですが、何をしているのか、なぜそれをしているのかを説明しています）。 新しい機能の要件は非常にスリムな場合があるため、たとえば、要件が「大量のコンテンツをロードするダイアログを作成する」と言っているが、ロード機能を実装するように言っていない場合、ほとんどの場合、実装しません、それは私たちがスプリントの目標を妥協する可能性があるという理由で、私たち全員がそれが顧客にとってより良いことを知っているにもかかわらずです（私は個人的にはそうはしないと信じていますが）。 その結果、私たちのコードベースは非常に保守性の悪い大きな混乱であり、新しい機能は非常に小さく、フルスプリントを費やすことがあります（良いコードベースで1日で達成できるもの）主にこの開発のため戦略、ただ速く行き、最小限のことをしてください。 この場合、何が間違っていますか？先週書いたばかりの悪いコードを書いたりコードを書き直したりしないように、より完全な方法で解決策に取り組むべきでしょうか？それとも、すべてのコードが書き直されていることを確認するだけでそれを続けるべきでしょうか？この問題に対するアジャイルなアプローチは何でしょうか？

22 agile  scrum 

最近、私の会社では、1人の開発者が1つの機能に集中する（そして1人だけ）ことが推奨されています。それは、開発者を通常のチームルーチンとは別に設定し、他の責任（会議など）から解放するようなものを意味します。この人は、テクノロジに関して「唯一の」責任を負います。 記録のために、SAFe内でSCRUMを使用し、チームごとにフルタイムの開発者がいて、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。 これは短期的に生産性を高めることに同意しますが、多くの理由でこれは悪い習慣であると感じています（そして大学で学んだと思います）。 コードレビューは価値を失います。 最小限の知識共有。 リスクの増加。 チームの柔軟性の喪失。 私は正しいですか、それとも悪い習慣ではありませんか？

22 agile  team  code-ownership 

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。） 私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。 私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。 ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。 私はこのジレンマを持っている最初の人ではないと確信しています。 過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

22 agile  testing  unit-testing  scrum  qa 

私が理解しているように、アジャイル方法論のアイデアは、機能的なものを提供し、頻繁にそれを提供することです。アプリケーションは、増分後に最終的な形状の増分になります。 しかし、初期のイテレーションでは、アプリケーションが基盤となるフレームワークまたは基盤を構築する可能性があります。これは重要なことですが、ユーザーには見えません。 これらの最初の反復でクライアントに配信されるものは何ですか？足場コードをビルドするとき、正しい方向にどのように進行状況を表示しますか？

22 agile  development-process  frameworks  development-methodologies  iterative-development 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行 。 私はこの課題に何度か出くわしました。製品バックログアイテムとTFSのタスクの違いを説明する方法について、誰かが参照、トレーニング、またはアドバイスを提供できることを望んでいます。 製品バックログ項目は「何」であり、タスクは「方法」であると理解し、説明しました。また、PBIが要件であり、タスクが要件を満たす方法であることも説明しました。 私がこれを説明するとき、私は繰り返し空白の視線と頭の傷に会います。これを説明するソフトウェアエンジニアは区別できないようです。それらはすべて同じです。 私のもう一つの課題は、区別することが重要である理由を効果的に説明できないことだと思います。

22 team-foundation-server  scrum  agile