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

現在、大学で提供されているソフトウェアエンジニアリングおよびキャップストーンデザインコースの新しいカリキュラムを開発するために、大学の教授と協力しています。 最近まで、両方のコースでウォーターフォールモデルを排他的に使用していたため、学生は長い時間をかけてレポートを作成していました。私からの多くのプレッシャーの後、私の教授は、この学期にスクラムをソフトウェアエンジニアリングカリキュラムに含めることにしました。 学期の前半はまだ滝のようで、学生は40ページの設計レポートとソフトウェア仕様書を書きました。学期中期には、すべてのチームがアプリケーションのデモをリリースする必要がありました。その時点で、コースはスクラムに切り替わり、3週間のスプリントが2回行われました。現在、ウォーターフォールを完全に排除し、スクラムベースのカリキュラムのみを作成する方法を考えています。 残念ながら、スクラムと学生の間でいくつかの非互換性が発生しました。 毎日のスクラム会議は、学生にとってほぼ不可能です。授業中であっても、教授が通常講義しているため、学生がスクラム会議を開催するのは不便です。 学生は経験が浅いため、何か時間がかかるのを正確に予測できないため、ポイント/時間の推定は困難です。 スクラムは、常勤の同じ場所にいる開発者に最適ですが、学生もそうではありません。せいぜい、学生はコースに週15〜20時間を捧げ、仕事の会議を開催することは非常に困難です。チームには最大10人の生徒を含めることができます（常に1人または2人の怠け者がいます）。 教授はドキュメントを切望しています！スクラムレポートは聞いていません。バックログとバーンダウンチャートだけです（アカデミックをなだめるのに十分かどうかはわかりません）。 学生はしばしば、アジャイルは「すぐにジャンプして、振り返らずにコーディングを開始する」ことを意味すると思います。これは、想像できる最も恐ろしいコードの一部につながります。したがって、50ページのドキュメントやUMLダイアグラムの山を必要とせずに適切な設計を実施する方法を探しています。 これらの問題を考えると、教授と私はスクラムをアカデミックな環境で機能するようにどのように適応させることができると思いますか（そもそもスクラムを気にする必要がありますか）。また、ウォーターフォールモデルを教えることにはまだ価値がありますか？ フィードバックを事前にありがとう！

15 agile  scrum  documentation 

雇用主に進捗を報告するのに問題があります。私はパートタイムプログラマで、学校の（非技術）部門のソフトウェアプロジェクトを担当しています。 担当者： 1.実際にソフトウェアを使用し、機能要求を提起するスタッフ 。2.私の上司（プログラマーではない）。彼女はソフトウェアのユーザーではありません。 プロジェクトの性質： サードパーティから購入した既製のソフトウェアです。部門のニーズに応えるために、このソフトウェアの機能を変更または追加する必要があります。これは学期を通して使用する必要があるソフトウェアです。すべての機能を最初に使用する必要があるわけではありません。 そのため、アジャイルモデルを使用しています。スタッフが特定の機能を必要とするとき、リクエストを出し、変更を加えます。学期の終わりまでに、必要なすべての機能が引き上げられ、実装されると思います。 問題： 上司が進捗状況を尋ねるたびに、答える方法がわからないので、答えられません。すべての必要な機能の完全なリストがありません。先週提起された機能を完了しましたが、上司に「完了」したことを伝えることはできません。新しい機能も追加されており、その程度はわかりません。「％の完了率があります」や「xxxで完了します」とは言えません。3つのリクエストのうち、2を完了することができたので、上司に「2を完了しましたが、まだ完了していない機能が1つあります」と伝えます。長い時間を経て、「長い間、いつも終わらない何かがあります」と聞こえます。 進捗状況を報告できないことは、私にとって本当に悪いように見えます。それは私がどれだけやったかではなく、人々に知らせる方法です。私がマネージャーであり、私のスタッフが何ヶ月も進捗を報告し続けない場合、この男も能力がないと感じます。 「ソフトウェア変更のステータス/進捗状況」と同じくらい簡単に報告する方法、または質問に答える方法がありますか？ 更新 私の上司は開発タスクに直接関与していないため、私が何をしているか、またはプログラムがどのように機能するかについて、手がかりがありません。彼女は忙しいので、定期的に会うことはありません。彼女はメインユーザーではなく、プログラムの詳細を知らないので時間の無駄になると思います。 私はソフトウェアを使用し、ソフトウェアについてよりよく知っているスタッフと定期的に会います。 上司に進捗を説明するのは難しいと感じています。

15 project-management  agile  reporting 

組み込みシステムのスクラムには2つの問題があります。第一に、特に初期段階では多くのタスクを実行する必要がありますが、それは実証できません。開発ボード、OS、ディスプレイ、シリアル通信などから始めました。6つのスプリント用のディスプレイはありませんでした。 最初の4つのスプリントは次のとおりです。 取得RTOSを起動して実行 ネットワークおよびシリアルドライバーを作成するタスクの作成 ボタン、通信などの割り込みルーチンの作成 プライマリデータベースのクラスとメソッドの作成 シリアルデバッグメニューの作成 これらのタスクのほとんどは、ユーザーストーリーにはあまり適していません。実際、システム全体への唯一のインターフェースは、スプリント3に組み込まれたシリアルデバッグメニューであったため、スプリントの最後にデモンストレーションするものはありませんでした。シリアルメニューでさえ、エンドユーザーではなく内部使用を目的としていました。それにもかかわらず、私はまだスクラムを介してこれらの開発活動を追跡および管理したいと考えています。 「開発者として...」などの「ユーザーストーリー」というフレーズを書くことになりましたが、これは満足できませんが、ターゲットプロセス（www.targetprocess.com）を使用する場合、バックログアイテムという概念はありません。タスクまたは雑用。 次に、リリースとテストをどのように処理しますか？テスターに​​はハードウェアデバッガーがないため、非常に苦痛です。したがって、コードのフラッシュバージョンをビルドし、テストするために開発ボードに書き込む必要があります。テスターは技術的には開発者ほど鋭くなく、多くの場合、初期段階（ボードのリセット、シリアル通信の接続など）で作業を行ったり、出力を理解したりするのに多くのサポートを必要とします。 最後に、完了の定義に関して、スプリントはすべてのストーリーが完了するまで完了できません。すべてのストーリーは、テスターに​​よって検証されるまで完了しません。開発者がテスターに​​与える時間を「奪う」ことを避ける方法はありません。つまり、スプリント内の最後の3つのユーザーストーリーのテストに5日間かかる場合、スプリント終了の5日前にコーディングしてユニットテストを行う必要があります。開発者は何をすることになっていますか？仕事をやめる？ 私は面白く思っていますが、ルールに準拠しようとするのは本当の問題です。今、私はルールを曲げることに問題はありませんが、私が抱えている問題は、テストされるまで物事をマークできない場合、すべてのバーンダウンメトリックを台無しにします。 他の人がこれらの状況をどのように処理したか聞いてみたい。

15 agile  scrum  embedded-systems 

ほとんどのアジャイル / XP理論家が支持している一般的な考え方は、ペアは定期的に交換する必要があるようです。たとえば、各プログラマは1日に1回ペアを交換する必要があります。一日の始めに人の半分、昼食後に人の半分が入れ替わります：会議、休日などの外部要因により、ほとんどの人は週に1、2回スワップ時間を反転させ、ペア構成が分散する傾向がありますチーム全体でほぼ均等に。 頻繁にスワッピングを行う理由の1つは、特定のスキルや知識が特定の個人に集中するのではなく、知識がチーム間で迅速かつ均等に分散することです。ペアプログラミング自体を取り巻くドグマの一種の帰結である別の理論的根拠は、誰かがあなたを交換するたびに、新しいペアの目で新しいコードレビューを取得しているため、コードの品質を向上させることです。 どちらの主張も理にかなっています。管理の観点から見ると、安定性と品質の両方が向上したように聞こえます。このような頻繁な交換は、私が見たほとんどのアジャイル / XPの本でかなり標準的な理論です。 だから、実際に実行するとき、人々は実際にペアスワッピングについて何を考えますか プログラマーの視点？ マネージャーの視点？ そして 誰かがペアから/にスワップするとき、何を決定する必要がありますか？

15 agile  pair-programming 

最近、スクラムプロセスに移行し、スプリント内のタスクとユーザーストーリーに取り組んでいます。コードを頻繁にレビューして、手間を軽減したいと考えています。ユーザーストーリーレベルでそれらを行うことを考えていますが、これを説明するためにどのようにコードを分岐させるのかわかりません。 VSとTFS 2010を使用しており、6人のチームです。 現在、機能の分岐を行っていますが、スクラムの分岐への変更に取り組んでいます。 現在、シェルフセットを使用しておらず、他に利用可能な技術がある場合は実際に実装したくありません。 ユーザーストーリーごとにコードレビューを実装することをどのようにお勧めしますか？

15 agile  code-reviews  scrum 

私は過去9年間に多数の小さなチームで働いてきました。それぞれには、短い会議、改訂管理、継続的統合ソフトウェア、問題追跡などの明らかな優良事例がありました。 この9年間、開発方法論についてあまり聞いたことはありません。たとえば、「私たちはスクラムをやっている」、「アジャイルをする」、または参照を超えるものはありませんでした。すべてのチームはうまく機能しているように見えましたが、多くのプロセスを踏まなくても、ただのフリーフローで、自然にうまく機能していました。 スクラム/アジャイル/その他に遭遇することなく、他の誰かが長期間進歩しましたか？ 私がこれらにさらされた唯一の露出は、このようなサイトを通してです。私はスプリント会議のような質問を読みます-何を話すべきか ...そしてすべての話は方法論の有限状態機械に従う人々のようなほとんどロボットのことを説明しているようです。それは本当に（誇張されていますが）そのようなものですか？インターネットに投稿している人々は、「ベストプラクティス」を大声で支持しているだけで、教科書の見方も同じで、実際に人々がどのように働いているのかを反映していないのでしょうか？ さらに（私は英国にいるので、関連があるかもしれません）...私が取り組んでいるチームのいずれかに方法論が導入された場合、彼らはそれを愚かで不必要であるとして拒否するでしょう...オン。同意する傾向がありますが、次のプロセスは少し不自然に思えます。これは典型的ですか、それとも一般的ですか？

15 development-process  agile  scrum 

私は大学で（唯一の）Webアプリケーション開発者として新しい仕事に就きました。 大学には多くの異種のシステムがありますが、どれもかなりひどくコーディングされたレガシーシステムです。ほとんどがPHPで構築されており、出席、試験結果、採点などを処理します。 私の最初の仕事は、このデータを大量に組み込むシステムを構築することです。現在、さまざまなデータベースに格納されており、それを引き出すためのフレンドリーなAPIはありません（既存のシステムは、データとビューを分離せずにPHPでコーディングされています）学生に関する牧歌的な情報を記録し、教師や上級スタッフに有用な方法で提示するための新しいプラットフォームを使用して、学生に関する問題に迅速に対応できるようにします。 最初の会議では18人が参加しました！多数派を代表する明確なリーダーや声はありませんでした。識別可能なクライアントはありません。会議は、学部長からのマイナーな機能に関する詳細な実装のアイデアから、Excelスプレッドシートをデータ入力に使用すべきかどうかについての議論へと変わりました。 想像できるように、私の頭は最後に回転していました。私は実際にはたくさんの良いアイデアを持っていましたが、それらを聞くことはできませんでした。マーケティング代理店の開発チームの一員になる前、これは私にとって非常に新しい役割です。プロジェクトマネージャー、クライアント、デザイナー、開発者という非常に明確な役割がありました。 経験豊富な開発者やマネージャーが、プロジェクトチームに似たものに同僚を誘い込む方法についての指針を教えてくれるかどうかを知りたいです。アジャイルは進むべき道ですか？すべての異なる声を処理する方法はありますか？いくつかのプロセスを非常に迅速に導入する必要があることは明らかですが、それが何であるかはわかりません。

15 web-development  project-management  agile  development-process  management 

理想的なアジャイルの世界では、目的のエンドシステムの小さいながらも有用なサブセットをすばやく構築し、ユーザーに提供します。彼らは興奮している、なぜならそれは便利だからだ。彼らはそれを使い始め、フィードバックを与える。次に、何を追加するのかを考え出し、それを構築し、時間がなくなるまで繰り返します。 私は最近、いくつかの種類の作業システムの交換を伴うプロジェクトをいくつか行ってきました。上記のモデルはまったく機能しませんでした。既存のシステムのほぼすべての機能を含むシステムを構築するまで、ユーザーはまったく興味を持ちませんでした。彼らはそれを使用しません。 「最小の有用なサブセット」が「すべて」の場合、どのようにアジャイルを適用しますか？

15 agile  scrum  users  iterative-development 

現在、作業中のバグプロセスがあります。 バグには3つのレベルがあります。 P1バグ：ユーザーの作業を妨げるバグ。それらはその場で解決されなければなりません。 P2バグ：影響はあるが、ユーザーは作業できるバグ P3バグ：影響がなく、ユーザーが作業できるバグ。 P1は必須であり、その場で対処する必要があります。しかし、P2とP3については、ケースバイケースで判断します。 3つのレベルがあるため、チームはP2とP3を扱うのではなく、顧客から求められたより緊急の新しい開発に取り組む傾向があります。 質問は次のとおりです。 P4を持つなど、別のレベルの優先度を追加する必要がありますか？ 今週のように、緊急ではないチケットを処理するためのターゲットも割り当てる必要があります。コーディングタスクを割り当てない場合は、少なくとも1 P2を処理する必要がありますか。 現在、私が上で挙げたような目標はありませんが、私の懸念は、そのような目標を与えることは残忍なことです。確かなことは、目標について話し合う必要があることです。チームは、特に目標を設定するときに議論に関与するのが好きです。 更新： この質問は、類似性の観点から提案されました。しかし、まったく似ていません。 私の質問は、厳密なアジェンダを課すことなくバグを処理し、それを解決する方法です。だから、暗示された質問は私を助けない。それでも、ありがとう。

14 agile  debugging  issue-tracking 

1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。 ほとんどのチームメンバーはシニアではないため、スプリント計画で詳細を議論します。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。 これにどう対処しますか？ 1週間のスプリントあたりわずか2時間の長さに合わせるために、計画中にどの程度詳細に議論する必要がありますか？

14 agile  scrum  planning  sprint 

アジャイルプロセスには2週間のスプリントがあります。タスクは毎日配信され（毎日ビルド）、テストチームは翌日または同じ日にテストを完了します。 Devコードレビューもありますが、これには時間がかかります（1〜2時間）ため、週3回、月曜日から水曜日にスケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。 問題は、コードレビュー後にアクションアイテムが登場するまでに、ほとんどのタスクが既にテストされていることです。テスターは、既にテストに合格したものを再テストしたくない。内部の開発者の変更を気にしません。 アジャイルプロセスを誤解していますか？コードレビューは毎日のリリース/テストサイクルと互換性がありませんか？毎日コードレビューを行うことはできません。すべての人の時間がかかるからです。

14 project-management  agile  teamwork  code-reviews  sdlc 

極端なプログラミングプロジェクトでは、プログラマはほとんどの場合ペアプログラミングを行います。 これらのペアも回転するため、つまり、プログラムをさまざまな人とペアにし、集団所有権の感覚があるため、ソースコードは頻繁にレビューおよび更新されています。 そうであれば、コードレビューが必要ですか？つまり、プログラミングを停止し、実際にコードレビューを行うだけです。

14 agile  code-reviews  pair-programming  extreme-programming 

アジャイルプロジェクトの短期的な要件管理は、私にとっては解決された問題のようです。 スクラムアングルから、新しい要件または既存の要件への変更がユーザーストーリーを通じて提供されます。また、EpicまたはFeatureの下にグループ化されたユーザーストーリーにより、より複雑な要件の配信が容易になります。 もちろん、ユーザーストーリーは技術的には要件文書ではありません。これは、機能の垂直スライスと呼ばれることが多いものにマッピングされる、管理可能な作業グループです。また、これらのストーリーの範囲は、承認基準（AC）を使用して明確に定義できます。 そのため、ユーザーストーリーは正式な要件ではありませんが、ユーザーストーリーを参照することで、ユーザーの基本的な要件をかなり明確に把握できます。短期的に。 プロジェクトが進行するにつれて、ユーザーストーリーの数が増加するため、短期間で言います。したがって、増え続けるストーリーのリストを閲覧して要件を見つけることは、時間の経過とともに効率が低下します。 この問題は、以前のストーリーを拡張したり、置き換えたり、さらには無効にするユーザーストーリーを検討するとさらに悪化します。 ここで、プロジェクトでの開発の反復間の2年のギャップを想像してください（本番環境で安定）。元のチームはなくなり、すべての知識も失われました。 元のチームがこれが起こるとわかっていた場合（たとえば、ビジネスの性質）、その後のチームを支援するためにどのような対策を講じることができましたか？ 確かに、バックログはいくつかの情報を提供しますが、簡単に閲覧できる形式ではほとんどありません。 それでは、後続のチームがプロジェクトの状態を理解するために何ができるか、なぜそれがどのようにそこに到達したのかを含めて？ 私の経験では、次のことはうまくいきません。 バックログを要件ドキュメントとして読み取ることができるように、以前のユーザーストーリーを削除または更新するバックロググルーミング。 ドキュメントスプリント。チームメンバーがシステムの現在の状態をド​​キュメント化するタスクを担当します。 動作テストによる文書化。このアプローチは、私が仕事に近づいているのを見た唯一のものです。残念ながら、コード化された動作テストはネーミング問題の犠牲になります。テストはシステムを適切に文書化するかもしれませんが、変動する開発者チームが同じドメイン用語、表現、スタイルに従ってテストを作成することはほとんど不可能です。 繰り返しますが、 長期的にアジャイルプロジェクトの要件をどのように管理しますか？

14 agile  requirements  requirements-management 

実際、私は彼らのスクラムの実装に関する小さなソフトウェアショップを手伝っています。最近、スクラムマスターから、チームがスコープ（コミットバックログ）を達成するために時間をかけて作業しているため、問題があると報告されました。そのため、Unreal Velocityがあります。 私の正式な質問は/です： レトロスペクティブ会議について話すこととは別に、オーバータイムを避けるためにいくつかのハードブロックを実装するのは良い考えだと思いますか？ もしそうなら、どのようなテクニック/ツールを提案しますか？ リビジョン管理システム（SVN、GIT、HGなど）、時間単位（8〜5）のブロック ワークステーションは、時間単位（8〜5）または累積時間（最大8時間/日）でブロックしますか？ その他... または、多分、この種のものをハードブロックしないでください。しかし、不当な余分な時間に「ペナルティシステム」を実装しますか？ 最初：あなたの速い応答のためのすべて。 @Baqueta（および同様の質問を持つ他の人）：いいえ、彼らは余分な時間に対して支払われていません。彼らへの私の最初のアドバイスは、おそらく彼らが過小評価していたので、彼らの見積もりをレビューすることでした。これは私のお気に入りのアドバイスでした： 残業に興味がある場合は削除してください。開発は週に60時間行うことができ、生産性を維持できるものではありません。これを証明する多くの研究があります。残業代が問題になる場合は、それを取り除き、基本給を改善して、彼らが価値のあるものを手に入れるようにします。 また、（このチームの）根本的な問題は、次の組み合わせであると思います。 開発者は、スプリントで何を達成しなければならないかを伝えられている/達成可能なことについて相談されていない/作業が多すぎると言われたときに無視されている。 開発者は、タスクにかかる時間/各タスクに含まれる作業単位の数を常に過小評価しています。 要約：チームと話し合い、見積もりを確認します。POについても、あなたが述べたように、範囲について相談されていないように感じます。

14 agile  scrum 

4人の開発者のチームでアジャイル/スクラムの使用を開始しました。ストーリーの見積もりを行い、ストーリーを注文しました。製品バックログのプライミングストーリー。 まず、通常の1,2,3,5,8,13 ....の代わりに、1から5までの複雑さのポイントベースの推定から始めました。 いくつかのストーリーに取り組んだ後、4ポイントと推定されたストーリーの一部は2のみである必要があると感じましたが、2と推定されたストーリーはもっと複雑で、5と推定されるべきでした。知っている： 繰り返しの途中でストーリーの見積もりを変更しても大丈夫ですか？ 通常の1,2,3,5,8,13 ....の代わりに1から5までの現在の推定ポイントを使用することは問題ありませんか？ 私は個人的には両方のケースでノーであるべきだと感じていますが、自分の理解があまり明確ではないので自分をバックアップする必要があります（良い参考資料は良いでしょう！）

14 project-management  agile  estimation