SCRUMメソドロジーは重要な締め切りプロジェクトで使用するのに適したテクニックですか？
私はちょうど会社に加わり、彼らは（彼らの呼ばれる）スクラム方法論で働いています、彼らは非常に厳しい締め切りがあり、プロジェクト開発は方向性がないか、どちらもそうではないようです（これは私たちが望むものです）データベースを持たないモジュールを開発している、このモジュールにリンクする必要のある情報も、モジュールにリンクされて自分の仕事を台無しにした人々も、私は彼らのサポートを得ることができません。
これが、開発モジュール用のDBテーブルを含まないこの方法論を進めるための良い方法であると誰かが私に提案できますか？
何か提案してください。
ありがとう
あなたの会社が実際にSCRUMを使用している場合、プロジェクトにはSCRUMマスターがいます。その主な仕事は、チームメンバーが進行中に目にする障害を取り除くことです。データベースの欠如が作業の妨げになると思われる場合は、スクラムマスターと話し合ってください。
私は3つの可能性を見ます：
- 新しいチームメンバーとして、あなたはこの会社でのやり方に慣れていません。おそらくスクラムマスターはあなたにいくつかの説明を与えることができ、その後あなたはよりよく理解するでしょう
- 作業はまとまりがなく、スクラムマスターは適切に仕事をしていません。たぶん彼は他の任務のために時間がありません。これについては経営陣と話し合う必要がありますが、（特に新入社員として）非常に礼儀正しく、責任を負わせるのではなく、解決する必要のある問題があるという事実に焦点を合わせてください。
- プロジェクトにはスクラムマスターがありません。実際、同社は、彼らが何を主張しても、SCRUMを使用していません。
スクラムはすべて反復リリースに関するものであり、ユーザーが取得する前に取得しているものを示し、目標に優先順位を付けることができます。これは、締め切りが厳しく、プロジェクトに方向性がないように見える場合に最適です。これは、顧客が（締め切り直前に役に立たない製品を大量生産するブラックボックスではなく）絶え間ない開発を確認し、その締め切りが成功と見なされるために最も重要な部分を指示できることを意味します。
モジュールにデータベースがあるかどうかに関しては、それは質問とはあまり関係がありません。しかし、うまくコーディングすれば、それは問題ではないはずです。ファイルベースのストレージを使用するか、ユーザーにデモを行う際にデータをハードコーディングしますが、そのコードは実際のロジックから十分に抽象化してください。データベースの準備ができたら、コードのその部分を簡単に切り替えることができるはずです。
ちょっとしたアドバイス：モジュールのボーンの単体テストを書いてください。これにより、ロジックからデータレイヤーを抽象化する方法がすぐにわかります。
正直なところ、これは私にはスクラムの問題のようには聞こえませんが、適切なエンジニアリングの欠如です。スクラムプロセスはおそらく物事を「修正」するために導入されましたが、彼らはそれを適切に行うことさえできません。悪いニュースは、どの方法論も職人技なしでは機能しないということです。
あなたは適切なスクラムではない環境にいるように私には見えます。
プロジェクト開発には方向性がないか、見た目も同じではないようです（これが私たちが望んでいることです）。
スクラムでは、製品の機能を定義する「製品所有者」がいるはずであり、製品がどのように機能するかについての詳細な質問に答えることができます。指示がない場合は、プロダクトオーナーが行方不明であるか、仕事をしていないかのどちらかです。
私はデータベースを持たないモジュールを開発しています。また、このモジュールにリンクする必要のある情報もありません。モジュールにリンクされていて、自分の仕事を台無しにしている人々もいます。その中での彼らのサポート。
データベースの欠如はそれ自体は問題ではありませんが、あなたの質問はあなたの会社のスクラム実装におけるいくつかの深刻な問題を明らかにしています。スクラムでは、ストーリーは機能に関するものである必要があり、機能を有効にするために必要なインフラストラクチャを追加して、「垂直スライス」で開発する必要があります。データベースがなく、リンクすることになっている他のモジュールのサポートがない場合、プロジェクトは「水平に」スライスされているように思えます。スクラムを使用して開発されたアプリは、非常に薄く起動し、機能が豊富になるはずです。