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

疑似コードに基づく方法でソフトウェアを設計する（つまり、書き留める）良い方法を知っていますか？ 私はソフトウェア設計に不慣れで、UMLに関する情報を読んでいます。私の控えめなクラス階層はこれまでのところ良好ですが、複雑になったら、「全体を見る」ことで、将来の拡張性のために別の構造を使用できることに気付きました。Pythonはプロトタイピングに適しているので、書き始めたばかりで大丈夫ですが、まったくそうではありません。 そこで、UMLクラス図を試しましたが、あまり役に立たないようです。そこで解決する問題は、頭の中でささいなことです。しかし、実際のメソッドの疑似コード化を開始すると、追加の設計要件に気づきます。 では、疑似コードで設計したい場合、どうすればよいでしょうか？私にとっては、コードとほぼ1対1の方法が最も効果的だと思います。しかし、ほとんどのUMLソフトウェアはメソッドのコードさえ表示しません（たとえば、GoFの画像とは対照的です）。 誰かがUMLはドキュメンテーションとプレゼンテーションのためだけのものであり、デザインのためにはそれほど優れていないと主張しましたか？私もその感覚を得ます。Envision APDTが見つかるまで、純粋なUMLといくつかの単純化したホワイトボードスケッチがソフトウェアを設計する方法であると思いました。 それで、アジャイル開発は私が注意すべきものですか、それともランダムにそのアジャイルと呼びますか-アジャイルはスケジュールのみに関するものだと思いましたか？または、私は（UMLを使用して）間違って設計していますか-誰かが疑似コードで設計していますか？どうすればそのための優れたツールを見つけることができますか？

9 agile  uml  design 

ユーザーストーリーを採用して、重いSRS（ソフトウェア要件の仕様）ではなく、軽量な方法で利害関係者の「意図」を捉えることを計画しています。ただし、彼らはストーリーの価値を理解していますが、すべての属性、優先度、入力、出力、ソース、宛先などを備えたSRSのような言語にストーリーを「変換」したいという要望がまだあるようです。 ユーザーストーリーは、アーティファクトのような正式なSRSの必要性を "排除"するため、SRSを持つことのポイントは何ですか？システムの機能要件を取得するためにユーザーストーリーを採用した場合、SRSは「排除」されることを私のチーム（ちなみに、教育と実践の両方で非常に有能なCSスタッフ）にどのように説得する必要がありますか？（NFRなどもキャプチャできますが、それは質問の意図ではありません）。 だからここに私の「ワークフロー」の引数があります：ユーザーストーリーとして初期要件をキャプチャし、後でユースケースにそれらを詳しく説明します（これは低レベルでドキュメント化する必要がある、つまりUIプロトタイプ/モックアップとの相互作用を説明し、成果物です）展開）。したがって、ユーザーストーリーからユースケースへと移行するのではなく、ユーザーストーリーからSRSへと移行します。 現在、職場でユーザーストーリーをキャプチャしている場合（ある場合）、ユーザーストーリーが存在する場合にSRSが存在しないことを「主張する」ことをどのように提案しますか？

9 agile  requirements  user-story  requirements-management 

私のチームへの導入の可能性について、アジャイルスタイルの方法論を評価しています。スクラムでは、同じ人に複数の役割を任せることはできますか？4人の開発者とWebデザイナーの小さなチームがいます。私たちは実際にはリードを持っていません（私はこの役割を果たします）、QAテスターまたはビジネスアナリストであり、すべての開発タスクはCIOから行われます。自動テストは時間の無駄とみなされ、すべてが品質ではなく速度に焦点を合わせています。 何が起こるかは、CIOが開発タスク（機能かバグかに関係なく）を考え出し、それを開発者（チーム全体ではなく、個人、多くの場合は非公開または突然）に渡します。完成する予定です。CIOは当初のアイデアを超えて要件を収集しません（そして、これについて以前に私たちを悩ませてきました。なぜなら、エンドユーザーが相談または通知されていないため、機能を使用できないことを確認するためだけに実装するからです。開発する前に、そしてパニックの場合は変更を元に戻すように指示されます）が、私たちが行うすべてのことについて、/承認する必要があります。 まず最初に、いくつかの基準と実践を導入するためにスクラムスタイルを検討する必要がありますか？読書から、スクラムは少し信頼とコミュニケーションに依存しているようで、開発よりもプロジェクト管理に重点を置いています。これは、現在プロジェクト管理の類似点がないため、完全に欠けているものです。 第二に、それが機能する場合、誰かがスクラムマスターと開発者の両方として行動するのは無理でしょうか？または、開発者がプロ​​ダクトオーナーになることもできます（ただし、これは開発者ではないCIOになる可能性があります）。スクラムマスターとプロダクトオーナーは異なる人物であるべきだと思いますが、同時にプロダクトオーナーの資質を持っている人はいないと思います（たぶん、「これらすべてのストーリーが必要です。どうでもいいが、それを成し遂げる」というタイプの取引やフリーズは、気まぐれでフリーズ解除されます）。 メンタリティを変更できる可能性は非常に低いため、現在行われている方法を補正するために、スクラム/ XP /リーンの一部を選択する必要があるように思えます。たとえば、ペアプログラミングが飛ぶことは決してなく（無駄と見なされ、2人ですべてを行う必要がある場合、半分のタスクが完了します）、TDDは困難ですが、短いサイクルは歓迎されます。

9 agile  scrum 

私は、タスクまたは「ストーリーポイント」を完了するために必要な労力に基づいてそれらを呼び出すときにチームがタスクまたは「ストーリーポイント」を推定するケーススタディについて読んでいます。 これらの「ストーリーポイント」はどの単位で推定されますか？この「ストーリーポイント」の概念は、「アジャイル開発」と呼ばれるプロセスに由来すると思います。

9 agile 

チームは最初の資本であるアジャイルプロジェクトを開始しています。このプロジェクトは、方法論とうまく調和しているように見えます（つまり、アジャイルブックを入手して、レシピのようにそれに従うことができます）。 プロジェクトには、チームの誰も経験のない3つのことが含まれています。FooPayroll Systemと統合し、ファイルタイプXYZ​​89（「XYZ89」=聞いたことのないファイルタイプ）を処理し、いくつかを変換できるようにします。 Frobnobdicatorで処理できるように他のファイル。 私が理解しているように、標準的なアジャイルのプラクティスは、これらのそれぞれにスパイクをスケジュールすることです。その後、スパイクにかかる時間を決定できます（クライアントが実行しないことを決定する可能性が高いかどうかはわかりません）それらはプロジェクトのかなり確かな要件であるため） だから私の質問は： 最初の反復ですべてのスパイクを最初に実行して、それらを実行するのにかかる時間、および/または「ウォーキングスケルトン」を起動して実行するのにかかる時間のより良い見積もりを取得しますか？ そうでない場合、プロジェクト全体のスケジュールは、これらの急上昇の1つに翻弄され、この特定のストーリーは、私たちが球場をとるよりも長い時間がかかるというデータが戻ってくるのではないでしょうか。 プロジェクトの基本的に交渉できない要件である複数のスパイクを処理するためのベストプラクティスの方法は何ですか？

9 agile 

私は最近、ソフトウェア開発のアジャイルプラクティスに興味を持ちました。それ以来、多くの記事で、これらのプラクティスにより全体的なコストを削減できることを指摘しました。 その背後にあるロジックは通常、次のようになります。要件が変更された場合、この変更を次のスプリントバックログに反映できます。これにより、新機能の設計と実装が時間的に近いため、コストの削減につながります。後で要件を変更する必要があるほど、その要件を満たすためにコストがかかるという有名なルールに従って、コストは下がります。 しかし、中規模から大規模のソフトウェアプロジェクトは複雑です。要件が突然変更されても、その要件を満たすためにシステムの他の部分に触れる必要がないわけではありません。多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。したがって、コスト削減の全体的な要点はここではなくなります。もちろん、新しい要件がシステムの新しい独立した部分を必要とする場合、それは問題ではなく、古いアーキテクチャが成長するだけなので、再考して再実装する必要はありません。 そしてその逆。ウォーターフォールを使用していて、新しい要件を導入する必要があることに突然気付いた場合は、デザインを変更できます。既存のアーキテクチャを変更する必要がある場合は、再設計します。それが本当にそれを台無しにせず、システムの新しい部分を導入するだけなら、あなたは行ってすべての仕事をします、ここでは問題ありません。 そうは言っても、アジャイル開発の唯一の利点は、スプリント間で機能を完全にビルドできることだけであるように思えます。多くの人やプロジェクトにとって、これは重要ではありません。さらに、アジャイルはソフトウェアアーキテクチャ全体で悪い結果を招くように見えます。機能が相互に平手打ちされるため、アジャイルチームは機能が機能するかどうかではなく機能が機能することのみを気にします。これは、システムが時間とともに複雑になると、アジャイル開発の実践により、製品アーキテクチャ全体の混乱が実際に増大し、最終的にコストが高くなります。なぜなら、ウォーターフォールにより、アーキテクチャを完成させることができるからです。あなたが何かを解放する前に。 明らかに、多くの人が実稼働環境でアジャイルを使用しているので、どこかで間違っているに違いありません。

9 project-management  architecture  agile 

最初に、アジャイルプロセスは、以下の基本原理のために機能すると思います。 それは焦点をもたらします 本当にフォーカスをもたらすノイズを制限します 次に、アジャイルプロセスを成功させるために必要な初期条件は何ですか。たとえば、次のものが必要ですか。 既存のバグはありません 完全に自動化されたテストプロセス、または少なくとも高度に自動化されたテストプロセス プロジェクトに専念する人々 より明確に定義された新しい開発 速くも安定もしない開発 ？ それを成功させるには何が必要ですか？これらの初期条件のいくつかがないことをより適切に処理するさまざまなアジャイル実装はありますか？

9 agile 

約一年半前、私はアジャイル開発をしていると主張する職場に入りました。私が学んだことは、この場所はいくつかのアジャイルプラクティス（毎日のスタンドアップ、スプリントの計画、スプリントのレビューなど）を採用しているが、原則（ジャストインタイム/十分に良いメンタリティ、失敗を早期に公開する、リッチなコミュニケーション）を採用していないことです。 私は今、チームをより機敏にすることを任されており、開発者とビジネスチームから完全に賛同できることを確信しています。パイロットプログラムとして、15か月の要件収集を完了し、110ページの分析と設計ドキュメント（「石で書かれた」と見なされる）があり、最後にアクセスできないプロジェクトが与えられました。ユーザー（実際に製品を使用しないユーザーのマネージャーで構成される委員会のみ）。 私は小さく始めて、最初の5つのスプリントに期待される成果物のリスト（将来のスプリントは未定義のまま）、最初のスプリントの目標のリストを与え、最初のスプリントの目標を満たすのに十分なユーザーストーリーを取得するためにA＆Dドキュメントを分析しました。 それ以来、彼らはなぜすべてのスプリントのすべての要件がないのか、なぜ私が3番目のスプリント（もっと重要だと考えているが最初のスプリントの成果物に基づいている）の作業に着手していないのかと尋ねてきました。 2つのスプリント）そして、私のITチーム全体が忙しい作業または私たちとは無関係であると考えるさらに多くのドキュメントを求めています（ユーザーマニュアルを前に書く、すべてのスプリントのすべてのデータフィールドを前にドキュメント化するなど） 「前払い」作業）。 これは私にとって新しいプロジェクトマネージャーとしてはかなり大雑把でしたが、ストーリー管理のスクラムバン、ペアプログラミング、顧客に受け入れテストを（要件ドキュメントの一部として）提供してくれるなど、効果的に実装した改善点があります。 。 だから私の質問は： 抵抗力のあるビジネスに変更をより効果的に導入するにはどうすればよいですか？ ビジネスにアジャイルの利点を示すためにIT側に導入できる他のプラクティスはありますか？ 文書化の負担は私たちを苦しめています-ビジネスはそれをリスクとしてではなくリスク管理戦略としてまだ見ています。文書化の懸念と要求を緩和するために何ができるか（具体的には、文書化の量とそのすべてに対する事前のニーズ）。 私たちは私たちのビジネスとは別の建物にあり、約3ブロック離れています。彼らは、プロジェクトに参加している人に、同じ場所に他のプロジェクトに取り組むことはできません。建物。" 彼らは私たちがいつもそこに行って質問をまとめることを期待しています。そうすればすべてを一度に尋ねることができ、その人の時間を「絶え間ない中断」で無駄にしないでください。彼らからより豊かなコミュニケーションを得るために私たちは何ができるでしょうか？ 追加のアドバイスもいただければ幸いです。 ありがとう！

9 project-management  agile  waterfall 

私たちはスクラムではかなりグリーンな4人の開発者の小さなチームです。全国から来て、私たちは家に帰るためにしばしば奇数日休みまたは丸一週間休みます。したがって、私たちのチームのキャパシティは、年次休暇のために、反復ごとに劇的に変化します。これにより、反復ごとに速度が大きく異なります。計画会議で速度を推定するとき、チームのキャパシティをどのように説明しますか？過去のデータは非常に異なる容量を反映するため、推定速度の平均を導き出すのに1年待つことはできません。

9 agile  scrum  estimation 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 次の理由で、問題追跡システムは好きではありません。 その中で問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。 バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるようにするためにバグをそこに置くことができます。 時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間を費やしています。 ホワイトボードでポストイットを使用して問題を処理したり、顔を見ながら会話したり、重要なバグが現れたらすぐに殺したりすることを好みます。オーバーヘッドに見合うだけの価値はないと思うので、バグの履歴を追跡することはあまり気にしません。 私はここに一人ですか？問題追跡システムを使用することの欠点（または大きな利点）に関する研究（本/記事/何でも）はありますか？

9 project-management  agile  issue-tracking 

私は中規模の会社の小さなチームで働いています。そのほとんどはソフトウェア開発に関与していません。私は最新かつ最も経験の浅い開発者であり、開始する前にソフトウェアの専門的または学問的なバックグラウンドを持っていませんでしたが、私の入力がどれほど尊重されたかに非常に満足しており、私のキャリアの早い段階で真剣に受け止められたことに感謝しています。 それでも、私はこの寛大な量の放送時間でもっと多くのことをすべきだと感じています。チームとして、物事を成し遂げるのに苦労しているようです。状況を改善するために何か提案できるようになりたいと思います。それが良いアイデアだったら聞いてもらえると思いますが、何を提案すべきか途方に暮れています。 問題として特定できるものは次のとおりです。 手元のタスクの仕様はまばらです。これは、管理がボトルネックであり、私たちが望むほど詳細な要件を解決するために費やすお金や人がいないためです。また、開発中のソフトウェアは調査対象であり、その有効性を判断するために実証および使用されるまで正確な方法が明確ではないためです。 Lead Devは、彼が最近すべてを「プロトタイピング」していると主張し始めたところまで彼が「プロトタイピング」と呼んでいるものを非常に気に入っています。多くの場合、彼がこの演習から何を期待しているのかは明確ではありません。「実際の」実装は、プロトタイピングに時間がかかりすぎるという彼の主張のために、苦しみます。私はこのねじれた論理を解くことができるようになり始めていないので、試してみたいと思いませんか。 モデラーは望ましい方法論についてすべてを正確に詳細に教えてくれることが期待されており、彼らが生み出すものは理論的に完璧であるという絶対的な信頼に基づいています。これはほとんど真実ではありませんが、この状況を修正するためのアクションは取られません。モデリングの側の誰も、行動を起こそうな構造化された方法で懸念を提起したり、ベストプラクティスを適用する際のガイダンスを求めたりすることはありません。彼らの受動性についても何も行われません。 私は以前にチームでTDDをプッシュしようとしましたが、それは私にとって新しいものであり、私の仕事を監督している人はそれを許容する用意がある一方で難しいと感じましたが、他の誰からも熱意はありませんでした。機能を詰め込んで仕上げるのではなく費やす時間を正当化することはできないため、このアイデアは（現時点では）放棄されています。私はそれが再び取り上げられないのではないかと心配しています。 現在、継続的インテグレーションサーバーがありますが、ほとんどの場合、数時間の回帰テストを実行するためにのみ使用されています。フルカバレッジの単体テストと統合テストも実行する必要があることはオープンなままですが、現時点では誰も作成していません。 リード開発者と一緒に品質の問題を提起するたびに、「機能Aのテストは簡単です。機能Bはユーザーにとって非常に重要ですが、テストが難しいため、機能をテストするべきではありません。 A '。もう一度、私はこの論理を解き明かそうとして進んでいません。 ....ふw。そんなふうに言うと、思っていたよりもずっと悪く見えます。結局のところ、これは助けを求める叫びだと思います。

9 productivity  agile  testing  teamwork 

ここでPOの責任について混乱しています。私はゲーム機能チームの開発者でしたが、POでもありました。開発者の毎日の仕事はほぼフルタイムなので、私は時間をかけてPOの義務に注意しなければならず、POの責任は開発者の考えに反するようです。 POとして、次のスプリントでより多くの機能を選択します。そうでなければ、私はそうしないように自分に言い聞かせます。私はそれらの機能を開発するチームメンバーだからです。この状況は私を混乱させますので、皆さんからいくつかのアイデアを聞きたいです。 私はスクラムとゲーム開発の初心者です（約1年半）。また、ここと英語も初めてです。

9 agile  scrum  game-development 

次のリリースで何を行うかを決定し、各ユーザーストーリー（および特定のストーリーのサブタスク）のタイミングを見積もるとき、グループでこれを行うのですか、それともマネージャーだけですか？ チームサイズが10の場合、これは実用的ですか？ それはどのくらいかかりますか？

9 agile 

私のチームは数日前にスクラムを使い始めました。私たちのプロジェクトには、物理​​デバイス（ロボットやセンサーなど）とのインターフェイスとなるソフトウェアの構築が含まれており、通常の製品バックログは、通常、システム全体に制御デバイスを追加することを表しています。 ここでは、例に近いタスクを分割します。各デバイス統合機能は、コード、テスト、統合テスト、ピアレビューなどに分割されます。明らかに、各製品バックログアイテムに固有のシーケンスがあります。通常、スプリントは2週間続き、チームには4〜6人のメンバーがいます。 スプリントの最後に2つの問題が発生します。 1つは、スプリントの終了時に全員を忙しくしておくことです。 2番目の（関連する）1つはシステムの競合です。私たちはスプリントの最後の数日間でほとんど統合することになります。統合システムは1つしかありません。そのため、システムにアクセスできないため、多くの場合、作業の継続が妨げられます。これはスプリントの終わりなので、スプリントバックログで行う必要のある作業は多くありません。これらの人々は何に取り組むべきですか？現在のアイテムが完了していないため、商品のバックログの一番上からアイテムを受け取ることは、商品の所有者から十分に受け取られていません。取り組む技術的負債は、プロジェクト全体を支援しますが、スプリントを完了助けにはなりません。 これらの問題を回避するためにスプリントを構成するためのベストプラクティスはありますか？製品所有者と交渉するためのヒント？

9 agile  scrum 

現在、JIRAを使用して開発作業を追跡しています。私の経営陣は、ソフトウェア以外の開発関連のタスクを含め、すべてを「ユーザーストーリー」としてフォーマットおよび分類したいと考えています。例えば： 「テストマネージャーとして、自動テストのみを使用し、手動テストを使用せずにアプリケーションのテストを実行して、アプリケーションをできるだけ効率的にテストできますか？ 承認基準：1. 50の既存の手動テストを完全に自動化されたテストに変換します2.テストは1時間未満で実行する必要があります ソフトウェア開発プロセスをサポートする作業に「ユーザーストーリー」を使用することが理にかなっていて、プログラマーによって行われず、成果物コードが直接生成されない場合は、コミュニティから理解を得たいと思います。または、これを別の方法で処理/分類する必要がありますか（たとえば、JIRAで）？ 2011年6月7日更新-「ユーザーストーリー」という用語に焦点を当てた質問に言い換え。

9 agile  stories