ما هو جدول إصدار تجريبي واقعي (ولكن سريع)؟ [مغلق

Question

فريقي قريب من نشر طلبنا، ونحن على وشك الدخول في بيتا مغلقة مع بعض العملاء المحتارين. أتساءل عما يتمكن الإطار الزمني الواقعي لإنتاج إصدارات بيتا جديدة، وعدد هذه الدورات التي يمكن أن نتوقعها بشكل واقعي أن نحتاجها قبل أن نتمكن من الاتصال بالنسخة الأولى مستقرة بما يكفي للإصدار.

التطبيق نفسه هو تطبيق التصوير الطبي، لذلك لا يمكن أن تعطل البيانات أو تالف أو تالف. سوف يستخدم العديد من المستخدمين أيضا البرنامج لمدة أربع إلى ثماني ساعات على الأقل يوميا بشكل مستمر، لذلك أتوقع مواجهة أخطاء المستخدم العادية بسرعة إلى حد ما. يرتبط التطبيق بقطعة معينة من الأجهزة، وإذا كان لديهم الأجهزة، فسوف يحتاجون إلى هذا التطبيق أو الإصدار السابق من التطبيق لتشغيل أجهزةهم.

بالطبع، هناك أيضا ضغط من الأعلى لإطلاقها الآن، الآن، الآن! وبما أنهم يدفعون شيكاتي، فأنا أضطر إلى اتباع تعليماتهم، على الرغم من أي مخاوف قد يكون لدي إصدارات سريعة.

أعتقد أن السيناريوهات التالية يمكن أن تلعب:

1. وقت دورة أسبوعين. لدينا مجموعة مختارة من المستخدمين، قل ثلاثة إلى خمسة مواقع، وكما يواجهون الأخطاء، نصلحها. أعتقد أن وقت الدورات هذه سريع سخيف، لكن يمكنني أن أشعر بالفعل أنه سيكون كيف ستكون القوى التي سترغب في النشر. بالنسبة لهذا النهج، نحن قفل المنتج إلى بناء معين، وأي أخطاء تتراكم نحن نصلح في الإصدار التالي (والتي يمكن أن يكون خمسين مباني لاحقا).
2. دورة لمدة ستة أسابيع. لدينا نفس مجموعة من المستخدمين المختارين، ولكن يمكن أن تنمو هذه المجموعة، وكما ينمو، نحن نتصرف كما في الخطوة 1. ليس بأسرع 1، ولكن بالتأكيد أكثر حذرا. المشكلة هي أن المستخدمين قد يحصلون على الانطباع بأن المنتج هو عربات التي تجرها الدواب بشكل مفرط (إذا واجهوا الأخطاء)، ولن يكون هذا الانطباع واجه حتى نطلق إصدار إصدار آخر، في أي نقطة قد لا يهتمون. نظرا لوجود هذا الإغلاق إلى الأجهزة التي ذكرتها في وقت سابق، قد يترجم هذا الانطباع عن Bugginess فقط إلى تطوم خفيف بدلا من المبيعات المفقودة. ومع ذلك، فإن كل نسخة تجريبية أحدث ستكون أكثر بكثير بكثير من الأخير.
3. بأسرع ما يتم إصلاح الأخطاء، احصل على إصدارات ثابتة في أيدي المستخدمين. لدينا خادم بناء، لدينا العديد من المختبرين، ونحن سريعون جدا للرد (قد نقول حتى "رشيقة"). هل هناك عيوب فقط لإعطاء إصلاحات الأخطاء بأسرع ما لدينا خطأ، طالما أن الإصلاح لا يكسر بعض السلوك الآخر الذي يحتاجه البرنامج؟ إذا أخذنا هذا النهج، هل سنفعل دورات، أو مجرد فترة بيتا "؟

أدرك أن هذه الأسئلة تختلف اختلافا كبيرا من المستخدم إلى المستخدم، وأن شيء مثل فترة عاصفة ثلجية أو جوجل بيتا هي قليلا على الجانب الطويل. ما زلت أحب الحصول على شعور عام حول كيفية الرد على أسئلة الإدارة المستمرة حول المدة التي يجب أن تكون فيها في بيتا.

Answer 1

في حالتنا، نسمح لملاحظات العملاء تملي دوراتنا. بعد الافراج عن بيتا الأولي، نستمع إلى ردود الفعل. في بعض الأحيان هناك خطأ كارثي ونحن نتوقف عن الإصدار التجريبي، وإصلاحه ثم استئناف. في كثير من الأحيان، نقوم بجمع الأخطاء بناء على أهمية العملاء ثم ROLLOUD تحديثا بمجرد وفاة الشكوى. في نهاية المطاف، فإن تصور العميل هو ما يهم أكثر هنا (بالإشارة إلى السرعة)، وبالتالي توازن بين شكاوىهم ضد ما يريده الإدارة هو الجانب الصعب. في حالتنا، نذهب عموما مع مكان ما في حدود 2-4 أسابيع بناء على عدد وكيف عاجل الأخطاء.

Answer 2

يبدو ذلك وكأنه سؤال أجاب بشكل أفضل بعد فترة وجيزة من الموجة الأولى من الملاحظات تأتي من الإصدار الأولي الإصدار التجريبي. إذا كان العملاء سعداء عموما، وقضايا أكثر مستحضرات التجميل من الهيكلية والخطة لدورة بيتا أقصر. إذا وجدت عكس ذلك، فأعد إدارة الإعدادية للتحضير لفترة أطول في فترة تجريبية متعمقة.

لا أعرف التفاصيل الدقيقة للتطبيق الخاص بك، لكنني أعتقد أن جدول إصدار محدد سيكون أسهل لعملائك مواكبة. عندما يجد العميل مشكلة ذات أولوية عالية، فمن الرائع أن نسمع أن القرار قيد التشغيل وسوف يكون في الإصدار التالي خلال أسبوعين، أو حتى 6 أسابيع، طالما لم يكن بعد شهورا. "التصحيح" ما لم يكن الإقلاع الشديد يمكن أن يسبب المزيد من المشكلات أكثر مما يحل، مع وجود عملاء لديهم قواعد شفرة شفرة مختلفة ومختلف بشكل كبير، والتي ستقوم بإنشاء مشكلات بجدية.

Answer 3

الذهاب مع الرقم 1. بلا شك، ربما تكون أفضل طريقة للذهاب. من الواضح أن # 2 غير مثالي، بسبب وقت الدورات الطويلة. # 3 مغرية، وسيؤديك إلى حد كبير كمية لا تصدق من المتاعب. إليك السبب في: إذا قمت بنشر الإصلاحات على كل من يحتاج إليها لأنهم يحتاجون إليهم، فأنت تفقد تماما أي مخطط إصدار عقلاني، وتتبع العميل الذي يعمل عليه وأي إصدارات صعبة في أحسن الأحوال.

Answer 4

لقد رأيت جداول إصدار واحدة وواحدة. يتم التخطيط للإصدار الأول، أكبر، يتضمن ميزات، AYBE 6-8 أسابيع أو في بعض الأحيان أكثر. والثاني هو إصلاح مخطط، فاصل أسبوعين. لذلك كل 10-12 أسابيع لديك 2 إصدارات.