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

私の最後の仕事の評価には、ただ一つの弱点が含まれていました：適時性。私はこれを改善するためにできることをすでに知っていますが、私が探しているのはさらにいくつかです。 品質を犠牲にすることなく出力の速度を上げるために何をするかについてのヒントやアドバイスはありますか？ タイムラインをどのように推定し、それに固執しますか？より短い期間でより多くのことを成し遂げるために何をしますか？ フィードバックは大歓迎です、ありがとう、

142 performance  methodology 

私は最近、コンピューターサイエンスの修士号を取得することを目指している大学院生です。私は本当に興味をそそられ、それらに貢献することを勧める複数のオープンソースプロジェクトに出会いました（CloudStack、OpenStack、moby、Kubernetesなど）。それらの大部分に共通していることの1つは、複数のプログラミング言語（Java + Python + GoまたはPython + C ++ + Rubyなど）を使用していることです。複数のプログラミング言語が互いに通信するためにどのように作られているかを扱っているこの他の質問をすでに見てきました：2つの異なる言語を持つ2つの異なるプログラミングを相互作用させる方法は？ 企業に複数のプログラミング言語の使用を促す要件を理解したいと思います。ソフトウェアアーキテクトまたはプロジェクトリーダーが「タスク1に言語Xを使用し、タスク2に言語Yを使用することを提案しています」と言う要件または要件のタイプは何ですか？同じ製品またはソフトウェアで複数のプログラミング言語が使用されている理由を理解できないようです。

114 programming-practices  programming-languages  methodology 

プログラミングの方法を学ぶための最良の方法は何かと尋ねられると、人々は通常、さまざまな著者によって書かれた大量のテキストへの参照を提供します。 しかし、私は多くの人が本からプログラムを学ぶことをまったく信じていません。彼らは通常、課題に直面しており、それを克服するためのツールとしてプログラミングを使用していることがわかります。 たとえば、私がプレイしていたゲームのサーバーを起動したかったため、プログラミングに「入りました」。そのため、特定のサーバーのサポートをグーグルで調べて読み、現在は開発したスキルのみを使用して雇用されたソフトウェアエンジニアです（そして、さらに開発されました）、あまり人気のないサーバーパッケージ用のC＃スクリプトをコーディングします。 だから私の質問は、人々は一般的にこれらの本から学ぶ方が簡単だと思いますか？私はそれらのいくつかを見て、それらを終了するように私を励ますにはあまりにも「ドライ」であることがわかりました。

94 books  methodology 

この質問はしばらく私の頭の中で調理されてきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に尋ねたいと思いました。 私の会社はついにアジャイルプラクティスを取り入れることに挑戦し、トライアルベースでアジャイルグループの4人の開発者のチームから始めました。3回の反復で4か月が経過しましたが、他の人にとっては完全にアジャイルになることなく、それを続けています。これは、経営者がビジネス要件を満たすための信頼が、上記の非常に多くのアドホックタイプの要求であるという事実によるものです。 最近、私はこのイニシアチブの一部である開発者と話をしました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、作業エリアで電話を取ることも許可されていません（ある程度は問題ないかもしれません）。たとえば、アジャイルチームに所属するキックについて友人と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っています。 このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断が生じないように完全な真空を提供し、6時間以上の生産時間を確保することです。まあ、私はアジャイルの第一人者ではありませんが、ヤフーのアジャイルロールアウトドキュメントや他の組織の同様の記事を読んだことから、アジャイルは安くないという印象を与えます。チームにアジャイルを浸透させ、到着した問題を修正して軌道に戻すには、リソースと予算が必要です。 まず、開発者向けのトレーニングとマネージャーなどのコーチングが必要です。現在のスクラムマスターは、管理者が支払うアジャイルトレーニングクラスを数日間受けたマネージャーで、現在このアジャイルチームを率いています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、会社ごとにカスタマイズされていることを指示しないと会議で聞いたことがあります。まあ、それはすべて良いと理にかなっています。 結論として、私はアジャイルが開発チームに調和をもたらすはずだと常に思っていました。ただし、アジャイルチームの開発者と話をするとき、私は非常に反対の気持ちになります。彼らは仕事以外は何も話せないのに不満であり、一日中静かに座って仕事をしているだけであり、経営者が仕事をより良くするための別の方法だと感じています。 これがより多くのドルのために利己的な優位性の目的のために使用される良い習慣の例であるならば、私に教えてください？あるいは、私のような開発者だけがこのアジャイルチームであり、仕事をしているために仕事をするだけの環境で働くのは好きではないと感じています。 これは、全米にオフィスを持つヘルスケア分野の会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じられるので、現在の会社では特に、アジャイルをまったく望んでいません。 それはすべて、管理が完全に安価であることと関係しています。安価なバージョンのために高価なコーヒーを切り取り、可能な限り無駄を省きながら、節約と生産性を重視します。 私は、ドアの後ろの経営陣がこのアイデアを捨て、アジャイルにより生産性が向上し、同じ人員でより多く生産している上司に見せることができると感じています。または、もしそうであれば、人員を減らすことができます。 彼らは毎日5分間の会議を開いています。ただし、チーム外の人とチャットや会話をすることはできません。すべての焦点は仕事にあります。

80 agile  scrum  methodology 

ここまで読んで研究してきたすべてのことは、アジャイル/スクラムが約4〜6人、さらにそれ以上のチームでどのようにうまく機能するかを説明しています。 私の現在のショップには、約8人の開発者がいますが、プロジェクトの量とサポートする部門の数を考えると、特定のプロジェクトに1人または2人以上の人が割り当てられることはありません。 1人または2人の開発者のチームでアジャイル/スクラムを使用できますか？私はこの方法論で作業を開始するためにマネージャーにピッチを作成しようとしていますが、小さな開発者クルーのために物事を縮小する方法を説明するか、特定のメンバーを増やすように説得する必要があります事業。

63 scrum  methodology  agile 

DRYのようなものは、デザインパターン、方法論、またはそれらの間にあるものですか？それらには、必要に応じて実証できる特定の実装はありません（KISSのようなものを使用しないケースを簡単に実証できる場合でも... 多数の例については、The Daily WTFを参照してください）。一般的には。これらのタイプの「経験則」はどこにあるのでしょうか？

58 design-patterns  terminology  methodology 

あなたの経験（逸話的またはその他）で、アジャイルを非アジャイル組織または会社に導入するための効果的な方法は何ですか？ 更新：アジャイルを導入しようとしたが「撃ち落とされた」ケースについてだれでも話せますか？また、なぜあなたが「撃down」されたのかを振り返って理解していますか？

55 agile  scrum  methodology  culture 

たとえば、{現在は比較的小さいが、将来的には大きくなる可能性がある}プロジェクトで、非常に小さなチームで作業を始めたばかりだとしましょう。これは、実際の世界の他の開発者が使用することを目的とした実際のプロジェクトであり、学期の終わりに廃棄されることを意図した学術プロジェクトではないことに注意してください。 ただし、コードはまだ他の人にリリースされていないため、まだ決定が確定していません。 方法論 コーディングを開始して、すべてのコンポーネントがどのように正確に相互作用するかを明確に理解する前に、ピースを一緒に合わせることが好きです（ボトムアップ設計）。もう1人は、最初に設計全体を行い、ソリューションをコーディングする前にすべてのコンポーネントと通信の詳細を特定することを好みます。 既存のシステムを模倣するのではなく、新しいシステムで作業しているため、適切な最終設計がどのように見えるかが必ずしも明らかではないと想定します。そのため、チームでは、チームメンバーごとに、最終製品にどのような要件が必要であるかについてのアイデアが異なることがあります。 ボトムアップ開発者がいくつかのコードを書くとき、トップダウン開発者は、コードが手元の問題を解決するかもしれないという事実にもかかわらず、設計で想定される潜在的な将来の問題のためにそれを拒否します。問題の解決策をコーディングする前に。 トップダウン開発者がコードを書き始める前に完全な設計と想定される問題を解決しようとすると、ボトムアップ開発者は実際に問題の一部が実際に発生するとは思わないため、ボトムアップ開発者はそれを拒否します、および要件と制約がより明確になったときに、設計を将来変更する必要があるかもしれないと考えています。 問題 これにより、ボトムアップ開発者は設計上の欠陥のためにボトムアップ開発者が書いたソリューションを廃棄すべきであると頻繁に判断するため、ボトムアップ開発者が時間を無駄にしてしまうという問題があります。 -コードを記述します。 トップダウン開発者は、作業を並列化する代わりに、ボトムアップ開発者と正しい設計を行うために頻繁に座って、2つをより速くなる可能性があるまで直列化するため、時間が無駄になります1人が2人よりも仕事をする。 両方の開発者は協力を続けたいと考えていますが、実際にこの組み合わせが実際にどちらかを支援しているようには見えません。 目標 共通の目標は、明らかにコーディングの効果を最大化する（つまり、時間の浪費を最小化する）ことと、有用なソフトウェアを書くことです。 質問 簡単に言えば、どのようにこの問題を解決し、この状況に対処しますか？ 時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者が自分のデザインのスタイルに従うようにすることです。しかし、これは、コードをレビューして、お互いの変更を実際に承認する必要があるとき、および他の人が使用するための一貫したフレームワークを設計しようとしているときに聞こえるよりも困難です。 もっと良い方法はありますか？

37 design  development-methodologies  methodology 

プログラミングの場合、完璧主義は良い面と悪い面があります。 問題を解決するとき、いつどこで線を引きますか？ ソリューションが過剰すぎる、一般的すぎる、または単に未来的すぎると判断するのはいつですか？ 質問が不明な場合はコメントしてください。

37 methodology  time-management  problem-solving  decisions 

私は、インラインドキュメントも技術ドキュメントも持たない既存のアプリケーションのチームの一員として働いています。アプリケーションのさまざまなバグレポートに取り組んでいるので、さまざまな場所にあるバグ番号-バグ番号を書いて、次の開発者がそのバグ番号を参照して何が起こっているのかを確認できるようにしました。 したがって、私の質問は次のとおりです。 このコードを文書化する最も効率的な方法は何ですか？領域に触れたときに文書化する必要がありますか（ウイルスの場合はウイルス手法）、またはアプリケーションの他の領域に分岐するパスをたどらないで、各セクションから単独で文書化する必要がありますか？以前に存在しなかった場所にインラインコメントを挿入する必要があります（コードが何をするかを誤って特定する恐れがあるため）。 既存のインラインドキュメントも、外部ドキュメントへのインライン参照もない、かなり大きなアプリケーションを正確かつ迅速にドキュメント化するには、どの方法を使用しますか？

35 documentation  language-agnostic  methodology 

Gunther Verheyenのスクラム-ポケットガイドを読んでいます。 Standish Groupによる2011年のChaosレポートは転換点を示しています。従来のプロジェクトとアジャイル手法を使用したプロジェクトを比較するために、広範な研究が行われました。このレポートは、ソフトウェアを期限内に、予算内で、すべての約束された範囲で提供しなければならないという古い期待に反して、ソフトウェア開発へのアジャイルアプローチがはるかに高い歩留まりをもたらすことを示しています。このレポートは、アジャイルプロジェクトが3倍成功し、従来のプロジェクトと比較して失敗したアジャイルプロジェクトが3倍少ないことを示しています。 ですから、一部のプロジェクト（要件が変わらない医療/軍事など）では、アジャイル（および特にスクラム）がすべての会議などでオーバーヘッドであり、より論理的であると言う同僚との議論がありますたとえば、ウォーターフォールを使用します。 私の見方では、このようなプロジェクトにスクラムを採用する必要があります。これにより、プロセスがより透明になり、チームの生産性が向上するからです。また、1か月間のスプリントのために8時間をスプリントプランニングに費やす必要がないため、スクラムイベントが必要なければ、それほど時間はかからないと思います。全員が同じページにいることを確認して作業を開始するためだけに、5分間を節約できます。 では、スクラムは、要件が変わらないプロジェクトに追加のオーバーヘッドを作成しますか？

29 agile  project-management  scrum  methodology 

私はソフトウェア開発と単体テストの作成について考えていました。私は次のアイデアを得ました： 開発者のペアがあるとしましょう。各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目は機能の単体テストを記述します。テストはコードの後に​​記述されます。私の考えでは、彼らはお互いを助けますが、かなり別々に働きます。理想的には、2つの同様のサイズの機能で動作し、テスト準備のために交換します。 このアイデアにはいくつかの利点があると思います。 テストは、実装の詳細を確認できる誰かが作成します。 ペアプログラミング（2つの機能を同時に使用）よりも作業を少し速くする必要があります。 テストとコードの両方に責任者がいます。 コードは少なくとも2人でテストされ、 コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。 また、コード開発とテスト開発の間にコードレビューのために別の開発者を追加することも良い考えです。 このアイデアの欠点は何ですか？それはすでに私にとって未知の方法論として説明されており、ソフトウェア開発で使用されていますか？ PS。私はプロのプロジェクトマネージャーではありませんが、プロジェクト開発プロセスについては何かを知っており、いくつかの最も一般的な方法論を知っています。

28 unit-testing  methodology 

私はこの記事をSOに関するいくつかの投稿で見つけました。私は自分が6番目の原型に陥ることに気づきました。「理論家」。 「理論家」を次のように定義します。 理論家は、プログラミングについて知っておくべきことをすべて知っています。あいまいなプログラミング言語の歴史について講義したり、作成したコードが完全に最適ではないことの証明を提供したり、実行するのに3ナノ秒かかることがあります。問題は、理論家はソフトウェア開発に関することを知らないことです。理論家がコードを書くとき、それは非常に「エレガント」であるため、単なる人間はそれを理解できません。彼または彼女のお気に入りの手法は再帰であり、コードのすべてのブロックは、適時性と読みやすさを犠牲にして最大限に調整されます。 理論家も気が散りやすい。理論家は既存のツールでは不十分であり、新しいツールを作成して新しいライブラリを作成し、高い基準を満たすまったく新しいシステムを作成する必要があると判断するため、1時間かかる単純なタスクには3か月かかります。理論家は、プロジェクト自体の境界内でプレイして、究極の並べ替えアルゴリズムの作業に時間を費やすのをやめることができれば、最高のプレイヤーの1人になります。 単純なプロジェクトであるべきものに取り組んでいるときでさえ、私はすべてをゼロからやり直そうとすることで動揺する傾向があります（これはおそらく、私がゼロからオペレーティングシステムを作ろうとして約2年を無駄にした理由です。最終的に無意味だった）。 これを避けるのに何が役立ちますか？そしてKISSの原則に固執しますか？ ありがとう

28 methodology 

プロジェクトに最近参加したプロのスクラムマスターコンサルタント[*]がいます。残念ながら、私たちは彼女の名前を知りません（彼女は私たちに自己紹介したことはありません、彼女は1日で来て、「私たちは毎日立ち上がっている」と言いました）、そして彼女は椅子a毎日のスタンドアップミーティング-私は冗談で彼女にミーティングで毎日フィードバックをするように頼んだとき、彼女は非常にf辱され、「参加せずに促進する」ことがスクラムマスターの仕事だと言った。 これはかなり反アジャイルのようです（他のアジャイルプロジェクトに取り組んでおり、チームは自己指示されていました）。これは平等主義であるはずですが、スクラム方法論でどのように機能するかはわかりません。私は彼女が一日中あまり役に立たないと思います、そしてそれがこの問題に対する彼女の防御の理由です。 スクラムマスターは、スタンドアップミーティング中に「昨日、今日、障害」という演説に参加しますか、それとも、会議の議長を務める（「促進する」）役割がありますか？ [*]彼女は自分の仕事が何であるかを実際に知らされていませんでした。

21 agile  scrum  methodology  meetings 

この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 7年前に移行され ました。 「カスタムソフトウェア会社」とは何ですか？ 「カスタムソフトウェア会社」とは、主にカスタムの1回限りのソフトウェアを構築することで収益を得ている会社を意味します。例は、代理店またはミドルウェア企業、またはRedifyのような請負業者/コンサルタントです。 「カスタムソフトウェア会社」の反対は何ですか？ 上記のビジネスモデルの反対は、展開可能なデスクトップ/モバイルアプリであろうとSaaSソフトウェアであろうと、長期的な製品に焦点を当てている企業です。 技術的負債を積み上げる確実な方法： 私は、一連のSaaS製品に集中しようとする会社で働いています。ただし、特定の制約のために、特定のクライアントの意志に屈することがあり、そのクライアントにのみ使用できるカスタムソフトウェアのビルドを終了します。 これは技術的な負債を負う確実な方法です。これで、コア製品に何も追加しない、維持するソフトウェアが少しあります。 カスタム作業が技術的な負債を増やす確実な方法である場合、代理店はそれをどのように処理しますか？ それで私は考えました。ビジネスモデルの中心としてコア製品を持っていない企業は、常にカスタムソフトウェア作業を行っています。彼らはどのように技術的負債の概念に対処しますか？どうして彼らを技術的な破産に追い込まないのですか？

20 methodology  technical-debt