タグ付けされた質問 「development-process」

ソフトウェア開発のプロセスに関する質問。

1
スクラムのデザイン要素を含むユーザーストーリー
私たちはスクラムワークフローを実装しており、ユーザーストーリー、つまり完了したとき、イテレーションなどに頭を回そうとしています。私たちがよく行うことの1つは、初期のイテレーション中にストーリーに取り組み、それを完全に機能させることですが、 "醜い"。プレーンなボタンを使用し、画像は使用せず、テキストのみを使用して、ボタンが適切に機能していることを示します。私たちはお客様を紹介し、その動作に満足していることを確認してから、通常は提供された画像を使用して、機能の設計を完成させ、完成させます。 この例では、機能的に完成したときにユーザーストーリーを完成させ、「ユーザーとしてxyzを視覚的に魅力的にしたい」という効果を示す2番目のユーザーストーリーを作成して、設計フェーズを処理しますか?または、設計要素を取得して完了できたら、ユーザーストーリーをプロジェクトの最初の反復から後の方に移動するだけでしょうか。その場合、最初の数回の反復で1つか2つのストーリーしか完了せず、最後の数回の反復でTONのストーリーを完了していることがわかります。 このシナリオをどのように処理しますか?

1
ウォーターフォールのほかに、他の計画主導のソフトウェア開発方法論は何ですか?
私はただバランスの敏捷性と規律を読みました。悪いタイトルはさておき、PSP / TSPを採用していた計画主導のプロジェクトチームと、Extreme Programmingを使用したアジャイルチームとは対照的でした。 著者が計画主導の方法論の例を提供したとき、彼らはパーソナルソフトウェアプロセス/チームソフトウェアプロセスを使用しました。すぐに使用できるこれらは計画主導の方法論ですが、これらはプロセスフレームワークとして使用するようにも設計されており、最終的には実行する処理の種類ではなく、実行する処理の種類のみを指定します。アジャイル環境でも。俊敏でありながらPSPの原則を順守することは可能であり、私はTSPについて十分に理解していません。 本のある時点で、彼らはいくつかの方法論を列挙し、敏捷性の観点からそれらをランク付けしています。スクラム、リーン、クリスタル、XPなどのメソッドが上位にあります。下部(アジャイルの大部分から最小)は、Rational Unified Process、チームソフトウェアプロセス、機能主導開発、CMMI、ソフトウェアCMM、パーソナルソフトウェアプロセス、およびクリーンルームで構成されています。 PSP:ソフトウェアエンジニア向けの自己改善プロセスのワッツハンフリーは、プロセスの定義、特にパーソナルソフトウェアプロセスの変更に関する章を設けています。共通のテーマは、プロセスは規範的(彼らは何をすべきかを言う)であり、記述的(どのようにそれを行うのか)ではないということです。TSPもほとんど同じだと思います。CMMIもアジャイルメソッドと組み合わせて使用​​されており、SEIにはその本(まだ読んでいない)があります。 機能駆動型開発は、プロジェクト管理へのアジャイルアプローチとしてよく宣伝されていますが、著者はそれをアジャイル性の低い方法論としてランク付けすることを選択しています。 RUPは反復フレームワークです。信じられないほど詳しくはありませんが、フレームワークであることから、SW-CMM、CMMI、PSP / TSPとグループ化して、アジャイルまたはプラン主導の方法論として実装できるようになりました。 この本で私が同意する唯一の他の例は、クリーンルームソフトウェアエンジニアリングです。クリーンルームの主要なコンポーネントは、正式な方法の使用、統計的な品質管理、および統計的に適切なテストです。時間とコストのオーバーヘッドが加わったため、これらをアジャイル(反復/増分)メソッドで使用できなかった理由はわかりません。 私が何を求めているかを明確にするために、アジャイルメソッドのファミリーには、スクラムとエクストリームプログラミングの形で抽象的なアイデアの特定の実装が含まれています。これらは、反復的かつ段階的な開発、変化への対応、人(個人とチーム)、頻繁に機能するソフトウェアの提供、顧客との共同作業などの概念を実現します。彼らは、役割、成果物、会議、タイムボックス、およびその他のプラクティスを明確に指定し、「スクラムを実行する」または「エクストリームプログラミングを実行する」とは、パッケージを取ることを意味します。たとえそうであっても、それらは調整可能性と新しいプロセスの作成を可能にします(しかし、あなたは「スクラムをしている」または「XPをしている」ではありません)。しかし、「do X」は見つかりませんでした だから、私の質問:より計画主導のソフトウェア開発方法論の例は何ですか?多くのプロセスフレームワーク(PSP / TSP、SW-CMM、CMMI、RUP)では、計画主導またはアジャイル開発も可能ですが、説明的なものはありません。しかし、たとえばスクラムやエクストリームプログラミングに直接対応するような、真に計画主導の方法論はありますか?

7
開発アプローチ文書に何を含めるべきですか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 2年前休業。 私は、オフショアリソースが私たちのプロジェクトに移行するときに、オフショアリソースの「開発アプローチ」ドキュメントを共同制作している最中です。 私たちの会社が使用した最新の(類似した)ドキュメントは80ページを超えており、これにはコーディング標準/規約のドキュメントは含まれていません。 私の懸念は、このドキュメントが消費可能ではないために失敗することです。 開発アプローチ文書には何を含めるべきですか?このトピックに関して適切なガイドラインはありますか? 編集:開発アプローチ文書には、ソフトウェアの設計、構築、およびテスト中にソフトウェア開発者が使用するプラクティスとテクニックの詳細を記載する必要があります。

8
アルゴリズムを開発するとき、ペンと紙のフェーズをスキップするのは悪い習慣ですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 アルゴリズムを開発するときは、最初にペンと紙、フローチャートなどを使用して、アルゴリズム自体に集中でき、そのアルゴリズムの実装について心配する必要がない(つまり、時間)。 ただし、ほとんどの場合、実際にアルゴリズムをオンザフライで開発する方が簡単です。つまり、一般的な方向性がわかるまで問題について少し考えてから、アルゴリズムが現れて機能するようになるまで、コードの記述と変更を開始します。 これは私が変えようとするべき悪い習慣ですか?

6
ソフトウェアを開発するとき、いつ並行セクションを考えたり設計したりしますか?
最適化が早すぎないという原則に従って、ソフトウェアの設計/開発のどの時点で、同時実行の機会について考え始めますか? シングルスレッドのアプリケーションを作成し、プロファイリングを通じて、並列実行の候補となるセクションを特定することが1つの戦略となることはよく想像できます。私が少し見てきたもう1つの戦略は、タスクのグループごとにソフトウェアを検討し、独立したタスクを並列化することです。 もちろん、尋ねる理由の1つは、最後まで待ってソフトウェアをリファクタリングするだけで同時に動作する場合、可能な限り最悪の方法で構造化し、大きなタスクを抱えることになるということです。 設計で並列化を検討するときに、どのような経験が役立ちましたか?

7
最初に行われる受け入れテスト…これはどのように達成できますか?
ほとんどのアジャイルメソッドの基本的な要点は、機能が開発され、テストされ、多くの場合リリースされるまで、「完了」しないことです。これは、スクラムプロセスの「スプリント」など、時間の短いターンアラウンドで発生するはずです。 アジャイルの共通部分はTDDでもあり、テストが最初に行われると述べています。 私のチームは、多くの特定の描画などを行うGUIプログラムに取り組んでいます。テストを提供するために、テストチームは、少なくともテストしようとしていることを実行しようとする何かを処理できる必要があります。この問題を回避する方法は見つかりませんでした。 基本的に不可解なインターフェースをターゲットにしたソフトウェアを書こうとした場合、非常に苦労することになるので、それらがどこから来ているのか非常によくわかります。動作はかなり明確に規定されていますが、自動化に関してさまざまなUI要素を操作する正確なプロセスは、機能に固有すぎて、テスターが自動化スクリプトを記述して、存在しないものを駆動することはできません。たとえできたとしても、多くのことが後で仕様から欠落していると判明します。 私たちが行うことを検討したことの1つは、人間が「自動化」できるように、ユースケースの観点から説明した、実行する必要のある一連のステップのようなテスト「スクリプト」をテスターに​​記述させることでした。これは、開発者が機能を作成したり、他の誰かが検証したりすることで実行できます。テスターは後で機会を得たときに、主に回帰の目的で「スクリプト」を自動化します。しかし、これはチームに追いつくことにはなりませんでした。 チームのテスト部分は、実際にはかなりの差で遅れています。これが、人間が実行する「スクリプト」を開発するための明らかに余分な時間が発生しなかった理由の1つです。開発者に追いつくために危機に瀕しています。それらを待っていた場合、何も実行されません。それは本当に彼らのせいではありません、彼らはボトルネックですが、彼らは本来あるべきことをしていて、できるだけ速く働いています。プロセス自体はそれらに対して設定されているようです。 非常に多くの場合、テスターが最終的に確認したバグを修正するために行った作業を1か月以上前に戻す必要があります。私が何かをしたいのは醜い真実です。 では、この失敗のカスケードを解決するために他のチームは何をするのでしょうか?テスターを私たちの前に置いて、どのようにしてスプリントで実行する機能のテストを書いて、その間に親指をいじる必要がないようにすることができますか?現在のところ、アジャイル定義を使用して機能を「完了」させるには、開発者を1週間作業させ、次にテスターを2週間作業させ、開発者が思いついたすべてのバグを修正できるようにする必要があります。過去数日間。それが妥当な解決策であると私が同意したとしても、それは起こりません。より良いアイデアが必要です...

2
Ruby on Rails開発プロセス
私たちはRoRを使用して韓国で成功した米国のWebアプリのローカライズ版の開発を開始しようとしている小さなチームです。 私たちの質問は次のとおりです。アプリの開発に取り掛かるために、どのプロセスを使用することをお勧めしますか? データモデルから始めるべきですか?ビューをHTMLにしてから、コード化しますか?単一の機能を採用して開発し、必要に応じて機能を追加しますか? プロジェクトの詳細: 中小企業経営者向けのウェブアプリです これには、ほとんどの小さなビジネスアプリが持つ傾向がある通常のcrm-reporting-dashboard-user admin-document mgmtfeaturesが含まれています チームのサイズは最初は2人です:プログラマーとデザイナー/ CSSの第一人者(ただ1つのコーダー) 経験レベルは中です。Git、Ruby、Rails、およびXHTML / CSSについての十分な知識があり、デプロイメントの問題に関する経験が少ない。これは私たちがチームとして一緒にやっているその種の最初のプロジェクトです


4
(巨大な)プロジェクトで複雑なコードを処理する方法
「なぜ(一部の)ITプロジェクトが複雑になりすぎるのか、それを回避する方法は?」についての回想録を準備しています。 複雑なコードを含むプロジェクトに遭遇したり、維持するのが困難だったりした場合、どうやってそれをやり遂げましたか? プロジェクトで使用する複数のアプリケーションから選択する必要がある場合、それらの機能で何が最優先事項であり、その理由は何ですか?

1
商用品質の8ビットゲームの構築に使用されたハードウェア/ソフトウェアツールは何ですか?
つまり、私はまだZ80プロセッサを搭載したMSX2を持っています。そのコンピューター(約'84年から'90年)向けに作成されたコナミのゲームを見ると、これらのゲームの高品質コードは驚くべきものです。私は当時子供で、コンピューターのプログラミング方法を学ぼうとしていましたが、実際には非常に複雑な動作にもかかわらず、バグやグリッチがほとんどなく、どれだけうまく機能しているかに魅了されました。その品質を達成するためにどのハードウェア/ソフトウェアツールを使用できましたか、どの方法論ですか?今日、コンピューターは本当にもっと複雑ですが、当時、Basicで作成した在庫管理プログラムでさえ、多くのバグに悩まされており、デバッグするのは面倒でした。あなたが放つことができるどんな光でも深く感謝されます。

3
いつ、どのように、そしてなぜ1つの(Java)フレームワークをアップグレードする必要がありますか?
概要としての短い要約: 私たちは小さなJava Web開発チームであり、JSF、Hibernate、Seamなどのさまざまなフレームワークとライブラリを使用してアプリケーションを作成し、それらすべてを一緒にJBoss ASにデプロイします。 当初、アプリは組み立てられ、いくつかの機能が追加されて潜在顧客に表示するショーケースが形成されました。研磨が行われ、アプリがリリースされ、承認されて機能し、時間が経つにつれ、追加機能が追加され、バグが修正され、新しいバグが発生しています。 高いバス要因とスタートアップレースのために、開発は手に負えなくなりました。システムのコアアーキテクチャを完全に理解していないのに、ますます多くの機能が追加されました。それはまだ機能していますが、システムが元の場所から別の場所に進化したため、常に落とし穴があり、最初はさまざまなショートカットが開発をスピードアップするために行われました-回避策が使用されているため、これはすべて戻ってきて開発が遅くなりますプロジェクトに新しい開発者を紹介するのはかなり難しい。 今、私は物事の整理と整理を進めています-バグ追跡システムのインストール、テスト/品質の文化の構築、自動テストの実行方法の検討、コードレビュー(私たちが欠けていたすべての豪華な専門的なもの)はじめに)クラスの階層や関数を整理するなどの一般的なリファクタリングを行い、ものを使いやすくします。これですべてが少し良くなりますが、やるべきことはまだたくさんあります。私は最初にシステムを構築した人ではなく(以前のプログラマーは去りました)、それを経験していません(現在2.5年間開発していますが、これが今のところ私の唯一の「オープンワールド」の経験です)。行う。 これが私の問題です: リファクタリングは常に良いものであり、私は物事を簡単にするために常にそれを行っていますが、基本的なアーキテクチャ(つまり、システムが依存するライブラリ、アプリケーションサーバー、データベースなど)をいつ、どのように、なぜアップグレードする必要があるのか​​、というのは私を困惑させます。 例: 現在、JBoss 4.2.2を使用しています。JBoss7.1のどこかをすでに読んでいますが、それでもいいですか?これをどのように評価できますか? 大きなブロッカーのように見えるSeam 2.2を使用します(より高いJBossバージョンでは機能せず、JSF2をサポートしていません)。さらに、Seamの代わりにJEE機能を使用するように指示するソースが表示されます。 基本的に、私は上記の例で述べたものだけでなく、この問題の一般的なアプローチに興味があります-別のシステムの別のライブラリの別の時間にこの問題に遭遇する可能性があります(または他の誰かが同様の問題に直面する可能性があります) 。 だから、ポイントは何ですか?私は最新の状態で最先端のライブラリのみを使用する必要がありますか、それとも私が持っているものを使い続けるべきですか?私が使用している技術は文字通り死んだ馬であり、飛び降りることをどのように認識しますか?このようなテクノロジーのアップグレードはどのくらいの頻度で表示されますか? そして、一般的な「アップグレード方法」の横にある別の質問。私のソフトウェアが「専門家によって作成された」ものと呼ばれる可能性があることをどのように認識しますか?一般的なプログラマーのセンス以外に、よくできたソフトウェアのJoelテストはありますか?

1
プロジェクトで作業しているのが私だけの場合、どうすれば自分を確認できますか?
私は自分の分野の仕事の合間にあり(ソフトウェア開発とは関係ありません)、最近、会社のいくつかのアプリケーションを作成する一時的な副契約を取得しました。これらの特定のアプリケーションに取り組んでいるのは私だけです。アプリケーションが正常であることを確認するために自分で確認する方法はありますか?私はコードをテストし、エッジケースを考えて、サンプルデータを生成し、ソース管理を使用します。しかし、これらのアプリケーションで作業しているのは私だけなので、簡単に見つけられるバグを見逃してしまうのではないかと心配しています。チーム環境。アプリケーションが完成したら、それでよければ、または締め切りが過ぎると、会社はそれを本番環境で使用する予定です。何かアドバイス?決まり文句を使用するのではなく、今のところ、私は「自分の能力を最大限に発揮するように」働き、それで十分であることを願っています。 ちなみに私は厳格なNDAと機密資料に関する法律の両方に基づいているため、実際にソフトウェア開発に携わった友人とアプリケーションについて話し合うことはありません。(明白でない場合は、私は貿易ではソフトウェア開発者ではありません。情報技術/コンピューターサイエンスの他の側面での私の経験も制限されており、ほとんど手を振るだけです)。

5
完成したユーザーストーリーをどのように処理しますが、妥協して再訪する必要がありますか?
構築したばかりの新しいプロジェクトバックログから2つのユーザーストーリーを達成しました(いい言葉ですか?)。これらはユーザー登録とパスワードのリセットで、どちらもメールが必要です。私が最初に選択したもの、および通常は信頼できるものが機能しなかったため、代替メールコンポーネントを実装する必要があります。メールコンポーネントのデバッグではなく、ユーザーストーリーの配信に重点を置いていたため、スプリントの最後に機能するコードを配信するためにそれを交換しました。メーラーの新しいサポート問題をログに記録しますか、それともこれらのストーリーをバックログに「再挿入」しますか?後者を実行する場合、ユーザーストーリーに技術の詳細をあまり紹介していませんか?

3
ハードウェアチームに大きく依存しているソフトウェアチームに最適なソフトウェア開発モデルはどれですか。
ソフトウェア開発には、競合するベストプラクティスがいくつかあります。私が発見したことから、多くのチームがアジャイルプラクティスの恩恵を受けている場合があります。ただし、他のいくつかのケースでは、統一プロセスの使用はIBMなどの大企業によって支持されています。 私が見つけた共通のテーマは、主にソフトウェアを開発するチームにとってはうまく機能するように見えました。 私は、ソフトウェアが実行されているハードウェアを生産するチームが反対側にいるショップで働いている人々にとって何が最もうまくいったか知りたいです。たとえば、1つのチームが複数のカスタムハードウェアを搭載したクレートを組み立てます。一方、これらのクレートで動作するソフトウェアを開発する必要があります。この場合に最適に機能する開発モデル(アジャイル、スパイラルなど)が見つかりません。 どんな知恵もこの領域は高く評価されます。

4
ピアコードレビュー中に欠陥を分類することの利点/欠点は何ですか
約3か月前に、私たちのエンジニアリンググループはレビューボードを展開し、すべてのピアコードレビューに使用しました。今日、私はそのプロセスに関与している人の1人と話し合ったところ、いくつかの機能が不足しているため、すでに代替品(おそらく何か商業用)を探していることがわかりました。 多くの人から明らかに要求される機能の1つは、各コードレビューコメントを分類/分類する機能です(つまり、スタイルの問題、コーディング規約、リソースリーク、ロジックエラー、クラッシュなど)。 コードレビューを定期的に実践するチームにとって、この分類は一般的な手法ですか?あなたはそれをしますか?過去にそれをしたことがありますか?良い/悪いですか? 一方で、これはチームにいくつかのより多くのメトリックを提供し、おそらく開発者をトレーニングする必要がある可能性があるより具体的な領域を示します(少なくともそれは議論のようです)。他のメリットはありますか?一方で、これは私の懸念ですが、コードレビュープロセスの速度がさらに遅くなるということです。チームリーダーとして、私はかなり多くのレビューを行い、コードのチャンクを強調表示し、コメントをハンマーで叩き、できるだけ早く進む機能が常に好きでした。私は個人的には試していませんが、そのコンボボックスを毎回展開し、適切なカテゴリをスクロール/検索すると、何かがあなたをつまらせているような気がします。また、これに関するメトリックを維持し始めた場合、

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.