問題タブ [agile]

アジャイル開発に関して、リリースごとにセキュリティをテストするためのベスト プラクティスは何ですか?

月刊の場合、毎月ペンテストをしているショップはありますか？

There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?

私の会社は、スクラムの方法論を採用しようとしましたが、成功はまちまちでした。論文は、私たちが問題を抱えているいくつかの分野です。これらをどのように処理しますか？

1. 製品マーケティングから製品までの要件の追跡。すべての要件を個別に追跡するために JIRA を試しており、実装のために選択されたときにそれぞれにリリースを割り当てています。
2. ストーリーを作成するのは誰ですか? 効果的な小さなストーリーを作成するのに十分な知識がない製品管理者、ドメインの知識を持たない可能性のある開発者、その中間のアナリスト?
3. 機能仕様
   1. それらを書きますか、それとも単にストーリーの定義に取り入れようとしますか?
   2. ストーリーごとに機能仕様を書いていますか? 機能ごと？
   3. 機能仕様とストーリーの関係をどう捉えていますか？
4. 役職に VP が付いている人からの質問に答える: 「[今から 8 か月後] までに何が得られるでしょうか?」

私は 2 番目の開発者で、PHP/MySQL ショップで最近採用されました。私が雇われたのは、混沌とした混乱からある種のプロセスを論争した経験が主な理由です。少なくとも、前の会社ではそうでした。;)

私がここに来てから (ここ数か月)、上司、プロダクト マネージャー、その他数人の主要人物 (ただし、スクラム ベースの固定観念をお許しいただければ、ほとんどがニワトリです) を迎え入れました。また、1 年以上遅れている主要製品の開発サイクルを可視化するのにも役立ちました。人々はそれを愛しています！

しかし、私の同僚 (今ここにいる唯一の他の開発者) はそれに興味がありません。彼女はドアを閉めて仕事に集中し、一人にされることを好みます。自分？私は、コラボレーション、協力、オープン性のアジャイル アプローチ全体に興味があります。彼女の意見がなければ、私はスクラムの実践を始めました (毎日のスクラム、バーンダウン チャート、および私と私の以前のチーム (H. Kniberg のクールなウォール チャート) でうまくいったことがわかったその他のもの)。私たちは実際に彼女のドアのすぐ外に立っていなかったかのように私たちを. (私たちは実際に. それはかなり驚くべきです. 私はそのような抵抗を見たことがありません.

質問... どうすれば彼女を乗船させることができますか? 同調圧力は機能していません。

仲間のスクラムボーグからの感謝

美しい

エクストリームプログラミング、スクラム、テスト駆動開発は、現時点で間違いなく最も人気のあるアジャイル手法のようです。しかし、最近誰かが私に機能駆動開発を見てみようと提案しました。

この方法を使用して成功したことはありますか？それを使用する利点は何ですか？

スプリントのチーム ベロシティを計算するためのアドバイスが必要です。

私たちのチームは通常、約 4 人の開発者と 2 人のテスターで構成されています。スクラム マスターは、すべてのチーム メンバーがベロシティの計算に平等に貢献する必要があると主張しています。つまり、スプリントでどれだけのことができるかを計算するときに、開発者とテスターを区別してはなりません。スクラムによると正しいですが、ここに問題があります。

反対の提案にもかかわらず、テスターはテスト以外のタスクを手伝うことはなく、開発者は開発以外のタスクを手伝うことは決してありません。また、さまざまな提案にもかかわらず、テスターは通常、各スプリントの最初の数日間、何かをテストするのを待っています。

その結果、通常、スプリントで実際に処理できる能力よりもはるかに多くの開発作業を引き受けることになります。たとえば、開発者はベロシティの計算に 20 日間、テスターは 10 日間貢献する場合があります。ただし、スプリント計画の後にタスクを合計すると、開発タスクは最大 25 日、テスト タスクは最大 5 日になります。

皆さんは、このような状況にどのように対処していますか？

アジャイル開発に対する私の理解は、本来あるべきほど良くないかもしれませんが、最終的なシステムがどうあるべきかについての要件と知識が十分にある場合、アジャイル開発者が既製 (OTS) ソフトウェアをどのように使用する可能性があるのか​​興味があります。私が理解している限り急速に変化します（多くの場合、開発の各反復の後）。

私にとって特に興味深い 2 つの状況があります。

(1) OTS システムは、既存のシステムへの潜在的な統合を除いて、ほとんどまたはまったく変更を加えずに、最初の一連の要件を満たします。しかし、開発を数回繰り返すうちに、このシステムはコア コードを書き直さなければニーズを満たせなくなりました。開発者は、この OTS ソフトウェアの背後にあるコア コードの学習にさらに時間を費やすか、それを捨ててゼロから構築するかを選択する必要があります。どちらも、開発時間とプロジェクト コストに大きな影響を与えます。

(2) 最初のニーズは、利用可能な既存の OTS システムとは異なりますが、最終的に顧客が製品を受け入れると、要件の追加と削除により、既存のソリューションに非常によく似たものになります。開発者がより多くの要件を抱えていて、事前にそれらの作業により多くの時間を費やしていた場合、このソリューションを再構築する代わりに使用できたはずです。プロジェクトは実現しましたが、遅れて必要以上のコストがかかりました。

ソフトウェア エンジニアとしての私の責任の 1 つは (教えられてきたように)、可能な限り低コストで高品質のソフトウェアを予定どおりに顧客に提供することです。アジャイル開発は高品質のソフトウェアを可能にしますが、場合によっては、手遅れになり、多額の費用が費やされるまで、より良い代替手段があることが明らかにならないことがあります。

私の質問は次のとおりです。

1. 市販のソフトウェアはアジャイル開発にどのように適合しますか?
2. アジャイルマネージャーとアジャイル開発者は、これらのケースにどのように対処しますか?
3. これらのケースについて、アジャイル パラダイムは何と言っていますか?

FogBugz の「エビデンスに基づくスケジューリング」は興味深いですが、アジャイル手法でどのように使用すればよいですか?

Martin Fowler による技術的負債、Steve McConnellによる

YAGNI (You Ain't Gonna Need It)ウィキペディアより

ウィキペディアによるBDUF (Big Design Up Front)

更新：質問を明確にするために、このように述べて、私の意味を維持することもできると思います：

「あなたは、アジャイルの実践者として、各イテレーション内で、「クイック アンド ダーティ」(YAGNI に準拠しようとして意図せずに技術的負債を負う危険を冒すこと) とオーバーエンジニアリング (BDUF) の間の適切なバランスをどのように見つけますか?

開発者およびプロのエンジニアとして、Kent Beck によって「バージョン 1」で定義されているように、Extreme Programming のテナントに触れてきました。これらの 12 の基本原則のうち、現在の仕事や他の仕事で実践することを許可されているか、少なくともその一部になることが許可されていると感じているのはどれですか?

エンジニアの観点からは、XP の主なエンジニアリング原則は、私が関わってきた他のどの原則よりもはるかに優れていると感じています。あなたの意見は?