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

私たちは、上級管理職による新しいプロジェクトに機敏に取り組んでいくと言われ続けています。彼らはスタンドアップ、スプリント計画、回顧などをセットアップしました。しかし、彼らは今、私たちが各要素に対して日付を提供し、それぞれでデモされるもので再び日付を見せたいすべての仕事を詳述する計画を思いつきました。 1。この計画は、2017年第2四半期に予定されています。 私にとってこれは最悪の意味でのウォーターフォールのように思えます。技術チームからの情報がない計画が作成されており、計画に関する特定のストーリーが非常に不明確であり、開発チームによって推定されていません。 しかし、私は彼らの議論が「シニアの利害関係者は日付を持たなければならず、計画が必要であり、単にバックログから作業することはできない」ことを知っています。私には、これは上級の利害関係者がアジャイルに買収していないようであり、したがって、私たちはそれをより低いレベルで実装することに失敗する運命にあります。 これは公平な判断ですか、それともこの計画に過剰に反応していますか？

47 agile  project-management 

2つの主要なソフトウェア開発方法論は、ウォーターフォールとアジャイルです。これら2つを議論するとき、それらを区別する特定のプラクティス（ペアプログラミング、TDDなどと機能仕様、大きな先行設計など）に多くの焦点が置かれることがよくあります。 しかし、実際の違いははるかに深く、これらの慣行は哲学に基づいているという点です。 Waterfall氏は次の ように述べています。 アジャイルは言う： 変化は避けられないので、変化を安くする。 私の質問は、TDDや機能仕様についてどう考えているかにかかわらず、ウォーターフォール開発の方法論は本当に実行可能かということです。 ソフトウェアの変更を最小限に抑えることは、貴重なソフトウェアを提供することを望む人々にとって実行可能なオプションであると本当に考えている人はいますか？それとも、避けられない変化を管理するために、私たちの状況でどのような実践が最も効果的に機能するのかという質問ですか？

47 agile  development-methodologies  waterfall 

ソロ開発者として、私はアジャイルのようなプロセスを使用していると思いますが、私がやっていることを実際のアジャイルと比較し、自分のプロセスを改善できるかどうかを確認したいと思います。 アジャイルに関するベストプラクティス、方法論、およびその他の役立つ情報を説明するための事実上の標準である本はありますか？その本は特別なものですか？

45 agile  books 

TDD（テスト駆動開発）を行わない場合、自分自身（またはチーム）を「アジャイル」と正しく呼ぶことは可能ですか？

45 agile  tdd 

スクラムマスターは、バグを技術的負債と呼んでいます。彼は正しい、バグはアジャイルの世界で技術的な負債と考えられていますか？

44 agile  technical-debt 

一部のソフトウェア開発者はこれに非常に熟達しており、抽象的な要件を備えた実用的なコンセプトを提供できることで称賛されることがよくあります。率直に言って、これは私を夢中にさせ、私は行くにつれて「作り上げる」のが好きではありません。以前はこれが問題だと思っていましたが、変化を感じ始めました。そして、方向性がほとんど与えられていないときに思考（およびプログラミング）プロセスを調整する必要があるかどうか疑問に思っています。この能力をスキルとして習得し始める必要がありますか、それとも要件の収集とビジネスルールが最優先事項であるという考えに固執する必要がありますか？

44 agile  programming-practices  waterfall 

公的機関から、スクラム、かんばんなどの用語と概念を説明するアジャイル開発の101に関する非公式ワークショップを行うように依頼されました。私は約5年間アジャイル環境で働いてきましたが、私はスクラム伝道者とは思いません。 ワークショップの後、彼らはそのアイデアを気に入りました。しかし、彼らは外部のソフトウェア会社に彼らのためにソフトウェアを開発するよう依頼する必要があるので、彼らにはアプローチがおそらく適用されないだろうと説明した（彼らは少数の開発者しかいない）。この活動は、結果、価格、および期間を説明する公開入札プロセスで行う必要があります。これは、この組織（公的研究機関）の予算を申請するための法的要件です。 これらの制約は、アジャイル開発の基本原則とは幾分矛盾しています。 スクラムはそのような環境では互換性がありませんか？ この組織に何をお勧めしますか？

43 agile  project-management  scrum  government 

開発者は、各スプリントのマスターブランチへのストーリーの統合について懸念を表明するレトロコールを終了しました。開発者はすべて自分のブランチ内のコードを作成し、スプリントの終わりに向かってすべて1つのマスターブランチにマージします。 次に、ある開発者（通常は同じ開発者）に、すべてが他の開発者のコ​​ードとうまく統合されていることを確認するタスクを残します（ほとんどの変更は同じページにあります。たとえば、データ表示ストーリー、データフィルターストーリー、 SLAインジケータ）。 この負担を軽減し、コードをより簡単にマージするにはどうすればよいですか？私の観点からすると、POまたはSMがストーリーをより効率的な方法で優先順位付けすることで、同じスプリントでこれらの種類の依存関係がなくなるため、いくつかの問題が解決する可能性があります。他のみんなはどのようにこれに取り組んでいますか？または、これはプロセスの一部ですか？

42 agile  scrum  branching  stories 

リード開発者以外のアジャイル開発チームでは、一般的に： 標準を設定します（コーディングなど） チームの新技術を研究する チームの技術的な方向性を設定します 問題について最終決定権を持っています システムのアーキテクチャを設計します ただし、アジャイルチームの動作は異なります。 アジャイルチームは、前もってではなく、新しいデザインに依存します アジャイルチームは、1人が設計を指示するのではなく、一緒に設計します アジャイルチームは、プロジェクトを提供するのに最適な独自の技術的方向を決定します これにより、アジャイルチームの主任開発者はどこに残りますか？アジャイルチームにリード開発者を置くことは可能ですか？アジャイルチームはリードに異なる責任を要求しますか？

42 design  architecture  agile  scrum  team-leader 

アジャイルまたはエクストリームプログラミングの文脈で言及された群れを聞いたことがあります。ペアリングを補完するようです。 正確には何ですか？いつ適用する必要がありますか？どうやってうまくやるの？

42 agile  terminology 

「ユースケース」、「ユーザーストーリー」、「使用シナリオ」の区別について、正確でありながらシンプルで理解しやすい定義はありますか？ 多くの説明がありますが、今のところ、1つか2つの文の違いを説明している人はいません... （例：http : //c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonは非常に長く取得が難しく、議論に満ちています）

42 agile  object-oriented 

アジャイルマニフェストの設立原則の一つは アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。 スクラムチームは、スプリントという用語を使用してワークサイクル（反復とも呼ばれます）を指します。 しかし、これは私には意味がありません。Googleによると、スプリントは次のとおりです。 短距離で全速力で走る。 言い換えれば、それは持続可能ではありません。なぜスクラムチームはスプリントという言葉を使用するのですか？私には、アジャイルの基本原則の1つと対立するように思われます。

41 agile  terminology  scrum 

私はアジャイル開発の大ファンであり、数年前に非常に成功したプロジェクトでXPを使用しました。私はそれについてのすべて、反復開発アプローチ、テストの周りのコードの記述、ペアプログラミング、物事を実行するための顧客を現場に持っていることが大好きでした。それは非常に生産的な職場環境であり、私はプレッシャーにさらされているように感じたことはありませんでした。 しかし、私が働いた最後のいくつかの場所はスクラムを使用/使用しました。最近のアジャイル開発の代表的な子であることは知っていますが、アジャイルであることを100％確信しているわけではありません。以下に、私にとって俊敏性を感じない主な理由を2つ示します。 プロジェクトマネージャーは大好き 本質的にタイムラインに夢中になっているプロジェクトマネージャーは、すべてスクラムを気に入っているようです。私の経験では、彼らは時間要件を追跡し、特定のタスクに費やされた時間の記録を保持する手段としてスプリントバックログを使用しているようです。ホワイトボードを使用する代わりに、全員がExcelシートを使用します。各開発者はそれを宗教的に記入する必要があります。 私の意見では、これはアジャイルプロセスのための非常に多くのドキュメント/時間追跡です。タスク自体に取り掛かることができるのに、タスクがどれだけの時間を要するかを見積もるのに時間を無駄にするのはなぜですか。または、同様に、手近な次のタスクに移動できるときに、タスクにかかった時間を文書化するのに時間を浪費するのはなぜですか。 スタンドアップミーティング 私が以前働いていた場所でのスタンドアップミーティングは悪夢でした。毎日、昨日やったことと、その日に何をしようとしていたかを説明しなければなりませんでした。タスクの「見積もり」に時間を費やした場合、プロジェクトマネージャーは悪臭を放ち、タイムラインを順守していないためにあなたが無能であることを示す手段としてスプリントバックログを参照します。 今、私はコミュニケーションの必要性を理解していますが、確かに毎日の会議の雰囲気は軽やかで、知識の共有に焦点を当てるべきです。私はそれがあなたの宿題スタイルのシャレードの場所になるとは思わない。また、アジャイルの重要なポイントは、タイムラインが変更されることであり、それらを固定するべきではありません。 結論 アジャイルのアイデアは、開発者の生活を楽にすることでソフトウェアを改善することです。したがって、私の意見では、チームが使用するアジャイルプロセスは開発者主導である必要があります。プロジェクトマネージャーが、プロジェクトを追跡するために「アジャイル」とラベル付けしたプロセスを使用することは、アジャイル開発と関係があるとは思わない。 誰でも考えますか？

41 agile  scrum 

私は新しく設立されたチームのスクラムマスターになりました。このチームは、ソフトウェアの作成と、デプロイされた他のアプリケーションの保守を担当しています。したがって、基本的に各チームメンバーには開発および運用タスクがあります。 過去数週間、彼らがどのように機能するかを観察してきましたが、これらのタスクの調整にチームが問題を抱えていることに気付きました。開発者がコーディングに集中していると、本番で発生した問題を修正するために中断され、以前のタスクに再び集中することは困難です。 開発作業時間の％を運用作業に割り当てようとしましたが、明らかにこれは問題を解決していないようです。以前にこの状況に遭遇したスクラムマスターからの連絡に興味があります。どのようにそれを管理し、どのような推奨事項がありますか？

40 agile  scrum  scrum-master 

毎日のスタンドアップミーティングはどれほど価値があると思いますか（またはそうでないと思いますか）？ あなたがそれに慣れていない場合、これはスクラムの支持者の一部である毎日の会議を指します（および他のいくつかのアジャイル方法論）。アイデアは、15分のタイムボックスで毎日会議を開催し、全員が立ち向かわなければならないということです（人々がそのポイントになるように促すため）。 会議では、部屋を歩き回って各自が次のように言います。-昨日あなたがしたこと-本日あなたがすることを計画していること-進行の妨げや障害 この実践には価値があると思いますか？誰かがそれをした場所で働いたことがありますか、あなたはどう思いましたか？

40 agile  scrum  meetings  development-methodologies