問題タブ [methodology]

Web アプリケーションをゼロから開始する場合、どの手順とどの概念に従うかを知りたいです。

新しい Web アプリケーションの開発を依頼され、どの機能が必要かだけを言われた場合、どのようにしますか?

バックエンドを忘れずに、データベース設計から UI 設計まで、アプリケーションのさまざまなレイヤーをどのように、どのような順序で考えますか。

どのツールを使用しますか? あなたはどのルールに従いますか？

前もって感謝します。

書かれたコードの最初のラウンドは、使用したいものではない可能性が高いという概念を考慮したプログラミング方法論はありますか? プロジェクトの最後に開発者からよく耳にする言葉は、「もう一度やり直せるなら、違う方法でやりたい」というものです。これは、最初のドラフトを書いた後に作家がたどるプロセスをほぼ正確に反映しています。違いは、ライターは編集段階に移行する準備が整うまで何度も書き直しますが、開発者は最初のドラフトを書いてからテストとリファクタリングを行って改良するようです。

私は確かに、開発プロセスを定義するために別のアナロジーを使用しようとするのが好きではありませんが、最初のドラフトは単にアイデアを書き留めるためのものであり、何か価値のあるものを作成するにはさらに書き直す必要があることを認識することには価値があると思います. それを認識できるプログラミング プロセスやプロジェクトの方法論に出会ったことがないと思うので、Stackoverflow の膨大な集合意識が、この可能性の探求をどこから始めればよいかについてのアイデアを持っていることを期待していました。

私は現在プログラミングを学んでいて、CS のクラスを受講していないので、基本的には下から始めています。私は何年にもわたってコードをまとめてきましたが、より大きなプロジェクトに取り組むために必要な基本的な概念を十分に理解していませんでした。オブジェクト指向は明白なものであり、その概念のいくつかを理解し始めていると感じています。次に、MVC、UML、SCRUM、SOLID など、話題や方法論がたくさんあります。私はこれらの多くを見てきましたが、ほとんどの説明にはある程度の理解が必要なようで、いつも困惑しています。他の概念。

このことを「正しい」方法で学びたいのですが、どこから始めればよいですか?

ソフトウェア アーキテクチャ/設計/開発のすべての基盤を理解するために理解する必要がある包括的な構造は何ですか?

私は何が欠けていますか？

基礎をクリアするまで待つことができ、また待つべき構成要素や概念はありますか?

アーティスト兼ミュージシャンとして、私は座って自由形式の詩のようにコードを回転させたいと思うことがよくありますが、目標を設定した場合と同様に、それはうまくいかないことがわかりました。私は最近、アーティストが簡単な静物をスケッチする方法とは異なり、自分自身のために小さな楽しい目標を設定することを試みていますが、私は疑問に思います...

すでにコミットされたプロジェクトの束縛なしに、楽しみのためにコーディングしたいとき、他の人は何をしますか？

私のチームは、スクラムからリーン/かんばんに移行し、ますます正式なプロセスが少なくなる軽量な方法論を徐々に採用しています。ある時点で、Cowboy Coding に戻ります。確かに、私たちはすでに境界線にいるのではないかと心配しています。

非常に軽量なリーンおよびアジャイル プロセスとアナーキーの境界線はどこにあるのでしょうか? 一線を越えたことをどうやって知ることができるでしょうか。どうすれば一線を越えないようにできるでしょうか。

この質問は、「ムダを排除しようとするリーンの意欲の中で、安全に排除できないプロセスはどれか」と言い換えることもできます。

たとえば、この論文[PDF] を見てみましょう。天気の劣化を鮮明な写真に追加したい場合は、その紙を見て逆さまにしてみる価値はありますか? また、可能な場合、アルゴリズムを逆にする特定のアプローチはありますか?

「継続的実装」はソフトウェア開発方法論の名前ですか? もしそうなら、それは正確には何ですか？

使用経験はありますか？

継続的インテグレーションとは何かは知っていますが、継続的実装は知りません。

背景: 今日、私は、ソフトウェア開発のコンテキストで「継続的実装」を使用している会社について (間接的に) 知りました。それは正式に定義されていますか、それともアジャイル ソフトウェア開発方法論の一部ですか?

私が見つけた最良のものは、European Journal of Information Systems の次の論文でした。

シナリオ開発と継続的実装による俊敏性

「... Volvo におけるビジネスと IS/IT のイニシアチブ ... アジャイルなアフターマーケット サプライ チェーンの開発と実装. ... プラットフォーム、Web サービス、およびインターネット経由でスペア パーツを販売するための Web ポータルを作成すること。」

私はリーン/かんばんにまったく慣れていませんが、過去数週間にわたってオンラインリソースを使い果たしており、適切な答えが見つからない質問を思いついています。リーン/かんばんは、それ以外の点では、すでにスクラムを使用している当社には非常に適しているようですが、その方法論の中でいくつかの制限に達しています。ここの誰かが私に良いアイデアをくれたらいいのにと思います。

私が見ているように、ウォーターフォールに対するスクラムの最大の利点の1つは、スプリントの使用です。14日ごとにすべてを準備することで、短いフィードバックサイクルが得られ、頻繁にリリースできます。ただし、リーンについて読んだことから理解したように、これにはいくつかのコストがかかります（たとえば、スプリント計画会議、チームコミットメント会議、およびスプリントの最後にすべての人に役立つものを見つけるための問題）。

リーン/かんばんはこれらの廃棄物を取り除きますが、14日ごとに放出できないという犠牲を払うだけです。それとも私は重要なポイントを逃しましたか？かんばんでは、どのようにして新しい開発タスクに取り組み、同時にリリースすることができますか？途中でしか出荷されていないものを出荷しないようにするにはどうすればよいですか？そして、どうすればそれを適切にテストできますか？

これまでの私の最高の「解決策/アイデア」は次のとおりです。

• 頻繁にリリースせず、新しい開発タスクの不足に関連する無駄を許容します。しかし、実際には、尋ねられた質問に対する解決策ではありません。
• ブランチで開発してから、メイントランクにマージします。内部で少なくとも2つのブランチを継続的にサポートする必要があります。
• 一部のスマート自動ラベル付けシステムを使用して、特定の完了したタスクのみを自動的に作成し、他のタスクは作成しません。

要約すると、私の質問は次のとおりです。リーン/かんばんを使用する場合、無駄を導入せずに頻繁にリリースできますか？または、リリースはリーン/かんばんの一部ではないことがよくありますか？

私の会社に固有の追加情報：Team Foundation System＆Source Controlを使用しており、以前は分岐とマージに関していくつかの悪い経験がありました。この分野の専門知識を取り入れることで、これを解決できるでしょうか。