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

そのため、名前に3文字が含まれる大企業で働き始めました。彼らはアジャイルになろうとしていますが、プロセスがたくさんありますが、アジャイルだとは感じません。 私が一番苦労しているのはコードレビューです。私の最後の仕事は、私が見た、今まで聞いた、そして/または聞いたことがある中で最もアジャイルな開発チームだと言うスタートアップの仕事でした。 とにかく、私の意見では、コードレビューは、UX / UIが極端/強烈な反復開発またはアジャイル開発では時間の無駄であるということです（Apple / Steve Jobsの完璧さを考えてください）。たぶん、ここの誰かが私を解雇する前に理解するのを助けることができますか？ これが私の開発プロセスであり、最後のスタートアップのプロセスです...非常にアジャイルです。 開発作業/仕事を分類するために、初期の機能作業を行います。フィードバックを得るために、いくつかのバージョンをモックアップし、ユーザー、チーム、マーケティングに提示します。次に、上記と同じ利害関係者から1つのラウンドを取得するために、別のモックアップの反復を行います。次に、作業を分割して開始します。達成すべきマイルストーンと日付はありますが、プラグインは続けます。この間、コードレビューはありません。開発の数週間に何度か、利害関係者とのセッションを開催し、機能/機能/ UX / UIがまだ適切で目標に合っているかどうかを確認します。 8週間の反復サイクルの終わりに近づくと、QAがテストを開始し、アルファユーザー、そして最終的にベータユーザーに進みます。しかし、アルファ版およびベータ版の開発者は、UXを改善するために、UIを毎日または1時間ごとに繰り返し変更して、新しい機能と古い機能を検討しています。したがって、このリリースで開発されていた機能は、最後の4週間でさらに3回変更されて、改善および完成されるか、いくつかの小さな機能が追加されます（たとえば、コンポーネントを少しスマートまたはスマートにします）。時々、変更は表面的なものであり、CRUD操作は変更または変更されず、すべてのUIが変更されるだけです。 このタイプの開発プロセス、極端なアジャイルでは、コードレビューは時間の無駄ではないでしょうか？別の開発者または2人がコードをレビューしたが、そのコードがさらに3回変更されると、UI / UXのすべての改善により、最初の3回のレビューに時間を無駄にしないという意味です。そのコード/コンポーネント/ UIが廃棄されたコード このプロセスで品質の問題はあまりありませんでした。開発者がすべての知識を手放した場合、そうです。 はい、テスターは3〜4回再テストする必要があるため、多くのテスターがいます。また、すべてのUI / UXが変更される理由を尋ねるのに夢中にならないでください...それがまさにその方法です...それが、アプリがUI / UXに対して多数の賞を受賞し、ユーザーがアプリ。思考プロセスは、1時間余分に時間をとってから何かを2％改善できるかどうかです。ユーザーはより幸せになり、より多くの$またはユーザーを意味します。はい、私たちのユーザーは、アプリが絶えず変化していることで大丈夫です。なぜなら、それが初日から行われている方法であり、悪いまたはネガティブとは思わないからです。 この投稿が華々しいものにならないことを願っていますが、コードレビューが無駄にならないことはわかりません。おそらく、レビューしたコードのすべてのコードの2％にバグがあります。各リリースでは、コードレビューで3つのバグが見つかる可能性があります。それで、リリースごとに開発者ごとに40時間のコードレビュー（4 x 40 = 160時間）になって3〜5個のバグを見つけることになりますか？とにかく3〜5個のバグがQAによって検出される可能性が50％です。開発者が新しい機能を追加したり、既存の機能を改善したりするのに、開発者ごとに40時間を費やす方が良いと思いませんか？

13 agile  code-reviews 

まあ、質問はそれ自身を言いました。私の職場ではそのようなケースが起こりますが、多くのアジャイルの本は同じ職場で働き、仕事のペースを速くするために現在のプロジェクトに集中することを促進しています。 たぶん、私はそのトピックについて知らされていないかもしれませんが、それほど厳密ではないかもしれませんが、そのような場合にアジャイルが提案することを知りたいと思ったのはそのためです。 誰か？

13 project-management  agile  team  scrum 

最近、プロジェクトがあり、クライアントはツアーで忙しかった。通常のスクラムチームが結成されたため、経営陣はクライアントが積極的に参加できないため、アナリストをプロダクトオーナーとして任命することにしました。アナリストは、要件分析と仕様の草案作成のためにクライアントと密接に協力した人でした。 クライアントには、最初の2つのリリースをレビューする時間がありません。クライアントが3番目のリリースを見るまで、すべてが順調に進みました。彼はいくつかの機能に満足していませんでしたが、それらはmake shiftプロダクトオーナー（私たちのアナリスト）によって導入されました。 設計チームがすべてのページのモックアップを完了し、クライアントが各ページをチェックし、作業を継続することを承認するまで待つように言われました。スクラムチームは存在しますが、スプリントはありません。従来のウォーターフォール方式とほぼ同じように作業を終了しました。 スクラムチームメンバーまたはマスターをプロダクトオーナーとして任命するのは良い考えですか？クライアント/製品所有者の参加がない場合、スクラムに従う必要がありますか？

13 agile  scrum  waterfall 

私のチームは、日々の進行状況を追跡するためにかんばんシステムを使用しており、機能（ユーザーストーリーとしてキャプチャ）の進行状況を理解するために非常にうまく機能しています。最近までうまく機能していた機能を開発するにつれて、システム設計の出現をほぼ許可しました。過去2週間で、パフォーマンスと変更可能性の品質属性に特に関連するアーキテクチャのトレードオフについていくつかの議論がありました。 私が思うに、機能を実装してシステムを設計するときに、アーキテクチャについて暗黙的に決定を下しますが、既知の品質属性要件に関してはそれらの決定を考慮していません。これらの重要な設計上の決定がどのように行われているのかを追跡/キャプチャ/視覚的に表現できれば、チームメンバーが実装中にシステムのアーキテクチャにさらなる緊張を生じさせないようになります。そしてもちろん、より複雑なものに、私たちのボード上の機能はありません、排他的、機能的で、時には建築の複雑さを隠します！ チームのかんばんの品質属性（またはその他のアーキテクチャに関連する決定）の進捗を視覚的に追跡するにはどうすればよいですか？

13 agile  tracking  architecture  kanban  quality-attributes 

私の経営陣は、私の組織の（確かに簡潔な）歴史の中で、前例のない質問をしました。 同時に、私たちはかなり新しいクライアントのためにいくつかの大きなプロジェクトに取り組んでいます。彼らはプロジェクトの途中で要件をプッシュする能力が伝説です。これらの人のために開発することは、流砂の上でタップダンスするようなものです。 より機敏なアプローチへのシフトを提案する絶好の機会のようです。私が尋ねられることを知っているのは、そのようなプロジェクトの見積もり/入札/請求方法です。1時間ごとに行きますか？さまざまな価格で入札しますか？スプリントで請求しますか？ より一般的には、「契約交渉よりも顧客とのコラボレーションを大切にしている」というアジャイル宣言の側面は、私の経営を怖がらせようとしています。少しでも多くのことを望む顧客の現実の世界で、それをどのように評価しますか？

13 agile  billing  customer-relations 

スクラムテストの1つには、複数の開発チームが同じ製品で作業を行うときの「完了」を最もよく説明する定義に関する質問が含まれています。 適切な答えは、それらの開発チームが、結合された作業を潜在的にリリース可能にする「完了」の定義を持っている必要があることを示しています。 このクイズの適切な答えから私には明らかではないものは、次のとおりです。 チームは「完了」の異なる定義を持つことができますか？どれくらい？

12 agile  scrum 

アジャイルに関する文献のほとんどは、ユーザーが舞台裏で何が起こっているかをかなり認識しているCRUDタイプのビジネスアプリケーションに偏っているようです。（書かれているコードのほとんどはおそらくこのクラスに属しているため、それは問題ありません。） このタイプのアプリケーションでは、ユーザーストーリー（要件）と開発タスクの関係はほとんど単純です。ユーザーストーリーをいくつかのタスクに分割するだけです。 しかし、ほとんどのコードがユーザーに直接見えない複雑な処理を処理しなければならない別のタイプのアプリケーションがあります。例は次のとおりです。 コンパイラー 自動運転車の画像解析システム 流体シミュレーションシステム ここでは、タスクとユーザーストーリーを関連付けるのが非常に難しくなる可能性があります。この問題を克服するためのテクニックはありますか、それを受け入れてそれを最大限に活用しなければならないのでしょうか？

12 agile  project-management  user-story  task 

最近、アジャイルが使用される主な理由の1つは、クライアントが要件を頻繁に変更するためだと言っている多くの投稿を見てきました。 ただし、クライアントが要件を頻繁に変更しないとしましょう。実際、クライアントには多少あいまいな要件もありますが（不当にあいまいなものはありません）、要件はしっかりしていますが、とにかくアジャイルを使用しています。 私がアジャイルを採用する理由は、ソフトウェアが非常に複雑であるため、実際にそれらに直面するまで認識できない問題や詳細が存在するためです。ウォーターフォールのような本格的な重度の計画アプローチを行うこともできますが、その後、すべての高レベル設計と低レベルコーディングシグネチャを完成させるのに数か月かかります。ただし、システムには非常に具体的な固定アーキテクチャ設計があります。 私の質問は、これは悪い、カウボーイコーディング、アンチパターンなどと見なされますか？アジャイルでの「やろう」という考え方ではなく、要件が安定しているときにコーディングを開始する前に、ウォーターフォールを使用し、可能な限り詳細に計画する必要がありますか？ 編集：ここでの主要なポイントは、次のとおりです。要件の変更についてクライアントを責めることはできません。クライアントが私たちに非常に具体的な問題を指摘し、非常に合理的な詳細でウィッシュリストを提供し、私たちをそのままにしておくと仮定します最小のプロトタイプが完成したら終了します）。このシナリオでアジャイルを使用するのは間違っていますか？

12 agile  development-process 

私は大企業で働いており、アジャイルプロセスの使用を指示しています。たとえば、プロジェクトでは、アジャイル開発の管理を特に対象としたクラウドベースのサービスを使用しています。 私が働いている特定のエンジニアリンググループは、従来ソフトウェアを開発していませんでした（代わりに、より多くの鳥瞰的な観点からプロジェクトを推進しています）が、それは変化しています。私たちには、主にデータ中心の広範囲の今後/計画中のソフトウェアプロジェクトがあります。たとえば、データの監視、収集、集計、およびいくつかのレポート作成を行います。その他のタスクには、特殊なハードウェアとさまざまなタイプのクライアント/サーバー（多層）アーキテクチャによる自動化が含まれます。私は、複数の人を採用し、前進するための多くの計画を策定するプロセスを支援します。 私の質問は、ラピッドプロトタイピング（スローアウェイコード）を行うことがアジャイル哲学に適合するかどうかです。たとえば、Pythonとその幅広いパッケージが大好きです。Pythonベースのワークフローを使用して、多くのアイデアを非常に迅速に実装できる可能性があると思います。ただし、Pythonは「エンタープライズ品質」ではないという認識が多くあり、この作業の多くはJavaまたはC ++で書き直す必要があると思います。 ただし、Pythonプロトタイプを作成することで、実際の結果を迅速に提供できるようにするための費用を大幅に削減できます。 ラピッドプロトタイピングを（できればPythonで）エンタープライズ環境の堅牢なアジャイルワークフローに組み込むことができましたか？

12 python  agile  design  prototyping  product-management 

私の会社では、1人のユーザーが1つのタスクを完了することはできません。各タスクをQAおよびコードレビューする担当者が別々になります。これが意味することは、各個人がタスクごとに、完了するまでにかかる時間についての見積もりを提供することです。 問題は、どのようにすれば燃え尽きるのでしょうか？時間を一緒に集計する場合、次の推定を仮定します。 10時間-開発時間 4時間-QA 4時間-コードレビュー。 タスクの見積もり= 18時間 毎日の終わりに、タスクを「完了するまでの残り時間」で更新するようにお願いします。ただし、一般的に各人は自分の部分について考えます。彼らは残りの努力をマークし、それに努力の見積もりを追加する必要がありますか？どうやってこれをやってるの？ 更新 いくつかのことを明確にするために、私の組織では、ストーリー内の各タスクに3人が必要です。 タスクを開発する誰か。（単体テストを行う、など...） タスクをレビューするQAスペシャリスト（主に統合テストと回帰テストを行います） コードレビューを行う技術リーダー。 間違った方法や正しい方法があるとは思いませんが、これは私たちの方法です...そしてそれは変わりません。私たちはチームとして働き、可能な限りストーリーの最小レベルでも完成させます。開発が完了するまで何かが機能するかどうかを実際にテストすることはできません。また、コードの品質を確認することもできません。そのため、できることは、最小限の機能をテストしてプロセスのできるだけ早い段階でレビューしました。 このように働く人々への私の質問は、彼らがこのようにセットアップされたときに「タスク」を焼き払う方法です。タスクにそれ自身のサブタスクがない限り（JIRAは許可しません）...毎日「残っているもの」を追跡するための最良の方法がわかりません。

12 agile  scrum 

私が読んだアジャイル開発から、コードをダイアグラムにリファクタリングまたはリバースエンジニアリングすることがよくあります。もちろんそれ以上のものがありますが、これら2つの方法に依存するプラクティスを考慮すると、動的に型付けされた言語は不利になりますか？ 静的に型付けされた言語は、リファクタリングとリバースエンジニアリングをはるかに容易にするようです。 動的に型付けされた言語では不可能ではないにしても、リファクタリングまたは（自動化された）リバースエンジニアリングは困難ですか？現実のプロジェクトは、アジャイル手法のための動的に型付けされた言語の使用について何を教えていますか？

12 agile  dynamic-typing  static-typing 

重要：ソースコードのドキュメントに問題はありません。これは通常のコード監査に属し、最新の状態に保たれます。私たちの問題は、開発者のドキュメント（または、必要に応じて「外部」）、プログラマーからプログラマーへのブログのような小さなヒントです。 ウィキのようなシステムを使用して、プログラマーのドキュメントを作成します。プログラマーのためにプログラマーが書いた記事は、特定のコードがどのように機能するかをもう少し詳しく説明しています。これらのWikiページには通常、次のものが含まれます。 APIの各部分の設計決定の背後にある動機（たとえば、この特定のサードパーティライブラリがこの方法で何かを行うことを望んでいるため、このotherいことをしました。 特定の一般的なタスクを処理する方法の説明（たとえば、適切なアプリケーションスタイルを参照し、レジストリコンポーネントに自分自身を登録し、他のコンポーネントによって自動的に「スキャン」されるために何らかのインターフェースを実装する必要がある些細なポップアップを表示する） 良い習慣（主観的なもの、実際にこのようなものを書き留めます） 環境設定、必要なツールとそのセットアップ 一般に、主にサイズとブログ投稿/記事のような性質のために通常のコード文書に適合しないコードの記述に関連するもの。 問題 このシステムを導入することは数か月前には良い考えのように思えましたが、最近では解決するよりも多くの問題を引き起こしているように感じます。例えば： 人々は記事を書きます...しかし、コードが変更されると、Wikiの更新はめったに続きません 急いで誰かが書いたスクラッチ記事の多くは、そのように残しました 記事のリクエストは通常​​プロジェクトリーダーからのものですが、正確性や構成についてはほとんど検証されていません。 通常の劣化。コードは変更されましたが、wikiは変わりません。誰かが次に情報を探すとき、彼が通常見つけるのは、時代遅れの低品質のものの束です-そして、何が起こっているのか、彼が見つけたものが正確であるのか、（さらに悪いことに）その一部であるのか疑問に思っています。そして、助けになるはずだったものが、逆になります。 現時点では、プロジェクトリーダーを含め、人々は問題を認識しているようですが、明らかにそれで何かをすることに煩わされる人はいないようです（または、もっと面白いことがあります）。 私の最初の考えは、それをすべて忘却の中に投げ込むことでした（時代遅れの「ヒント」に何回か噛まれた後）。しかし、それは極端すぎるかもしれません。いくつかの情報は注意する価値があり、時々読むことをお勧めしますが、問題は依然として同じです。「最新」にどのように対処しますか？ソースコードに何らかの形でリンクされていますか（したがって、ファイルの更新バージョンがチェックインされると、記事の作成者はコード/記事を修正する必要があるかもしれないと通知されます）？指定された人は、毎日の基本でそれを「見守っていますか」？定期的なクリーンアップを行いますか？

12 project-management  agile  documentation 

スプリントに割り当てられたストーリーを完成させるための態度はどうあるべきですか？明らかに、あなたはそれらをスプリントで終わらせることを優先したいのですが、私にとってアジャイルのポイントは動的であるということです。予想外のことが起こり、それらのストーリーが完了せず、次のスプリントにプッシュされるのと同じ時間に、何か間違ったことをしたという感覚は望みません。それは怖い経験やネガティブな経験ではないはずですよね？ 負けた/怖い経験は、逃したスプリントのコミットメントに受け入れられますか？開発者は、対処しなければならない予期しないタスクが発生した場合に、スプリントのコミットメントを逃したことに対して責任を負うべきですか？

12 agile  sprint 

チームには7人の開発者がおり、短期間（約1か月）で開発ペースを2倍にする必要があります。「より多くの開発者を雇えば、最初の数か月間だけ生産性を失う」という常識的なルールがあることを知っています。このプロジェクトはeコマースWebサービスであり、約27万行のコードが含まれています。 現在の私の考えは、プロジェクトを多かれ少なかれ独立した2つのサブプロジェクトに分割し、新しいチームが2つのサブプロジェクトのうち小さい方で作業し、現在のチームがメインプロジェクトで作業することです。つまり、新しいチームはチェックアウト機能に取り組み、最終的にはカップリングを減らすために独立したWebサービスになります。このようにして、新しいチームはコードが10万行だけのプロジェクトに取り組みます。 私の質問は、このアプローチは初心者の開発者が新しいプロジェクトに簡単に適応するのに役立つのでしょうか？初心者がバグよりもソフトウェアの生産を開始するまで2か月待たずに開発チームを迅速に拡大する他の方法は何ですか ======= 更新 この企業は完全に失敗しましたが、皆さんが言及した理由ではありません。まず第一に、私は新しいチームの規模と能力について誤解されていました。自分で評価すべきだった。第二に、そのサイトでの採用は大変な仕事でした。メインオフィスのサイトでは、雇用ははるかに簡単でしたが、2番目のチームの都市では、必要な資格を備えた開発者が明らかに不足していました。その結果、1.5か月を予定していたのではなく、約4.5か月に延長され、その途中でトップマネジメントによってキャンセルされました。 私が犯したもう1つの間違い（およびアレックスDから警告された）は、リファクタリングを経営陣に売り込もうとしていたことです。リファクタリングは決して販売せず、機能のみを販売します。 とにかくスタートアップは成功したことが判明した。決して起こらなかったリファクタリングは技術的な負債に変わりました。システムはよりモノリシックになり、保守性が低下し、開発者の生産性は徐々に低下しました。私は現在チームにいませんが、近い将来に完成することを願っています。そうでなければ、私はプロジェクトの存続に一銭も払わないでしょう。

12 productivity  agile  team 

開発者が「スクラムマスター」になることは有益ですか？ これは公式の認定ですか、それとも専門の人ですか？ 一体になるためのステップは何ですか？

12 agile  scrum  scrum-master