MPS - 4

3:37كيف حالكم ؟ كيف أموركم

3:39؟

3:42>> مرحباً ، مساء الخير .

3:48>> حسناً ، لقد اطلعت على

3:49الواجبات العملية حتى

3:51يوم الجمعة ، على ما

3:53أعتقد . إذا قمت بالرد

3:55على أي منها ، فذلك

3:57لوجود شيء يحتاج إلى

3:58تحسين . أما الذين لم

4:00أرد عليهم ، فهذا يعني

4:02أن عملهم جيد . لذا ، إذا

4:06كنتم ترغبون في

4:07إرسالها بعد يوم

4:08الأربعاء هذا ، فلا

4:10توجد مشكلة . لا يزال

4:13البعض لم يرسل بعد ،

4:15لذا لا توجد أي مشكلة .

4:17استمروا في العمل بشكل

4:18جيد ، لكن بعد هذا

4:20الأربعاء سنتوقف ،

4:21لأننا إذا استمرينا

4:22أكثر من ذلك فسيصبح

4:24الأمر طويلاً جداً .

4:25حسناً . إيه ، جيد . اليوم

4:35سنتناول عملية تطوير

4:37البرمجيات ،

4:39والمنهجيات ، ودورة

4:40حياة النظام . وبعد ذلك

4:43سنتحدث قليلاً عن قصص

4:45المستخدمين . إنها عرض

4:47تقديمي آخر . هل لديكم

4:49أسئلة حول الواجب

4:50العملي ؟

4:56>> لا ، أعني ، أنا أربطه

4:58بالخوارزمية ، ما قمنا

5:00به يشبه الخوارزمية .

5:04إيه

5:05>> تقسيم كل شيء إلى

5:06خطوات ، والانتباه لها .

5:08حسناً ، هذا صحيح ، هذه

5:09مدخلات ومخرجات ، أليس

5:11كذلك ؟ ونرى ما نحتاجه

5:12وما الذي

5:14>> نحصل عليه .

5:15>> لن تكون خوارزمية ، بل

5:17ستكون سيناريوهات

5:19حالات اختبار ، لكن

5:21>> لا ، إنها ليست

5:23خوارزمية

5:25>> لكن لحلها ، فكرت فيها

5:27كخوارزميات .

5:28>> إذا كنت تريد التفكير

5:29فيها بهذه الطريقة ،

5:31فلا توجد مشكلة . لا ، لا

5:32، لا توجد أي مشكلة .

5:34حسناً . حسناً ، هل هناك

5:39أي سؤال آخر حول

5:40الواجب ؟ الأمر واضح

5:42جداً يا شباب . لا توجد

5:44تعقيدات كثيرة . إنها

5:45من الحياة اليومية .

5:49حسناً ، سننتقل للحديث

5:51عن عملية تطوير

5:52البرمجيات ، وكيف يتم

5:54بناء البرمجيات ، ومن

5:56يشارك في كل مرحلة من

5:59المراحل . ربما تكونوا

6:01قد درست جزءاً من هذا

6:02في مادة أخرى ، لكننا

6:04سنقوم بمراجعته

6:05وسنتعمق قليلاً في

6:07الاختبار . هنا لدينا

6:08الأنشطة الرئيسية

6:10التي تتم خلال هذه

6:11العملية . وأود أن أوضح

6:15أنها ليست خطية بهذا

6:16الشكل ، فهي معروضة

6:18بهذه الطريقة لأغراض

6:20أكاديمية فقط . التحليل

6:25، التصميم ، التطوير ،

6:27الاختبار ، التنفيذ . ثم

6:29تأتي مرحلة الصيانة ،

6:31وهناك مرحلة التخطيط

6:33وهي مرحلة متداخلة مع

6:35كل الأنشطة التي

6:37ذكرتها . قبل البدء في

6:40مشروع تطوير برمجيات ،

6:42يجب تحديد النطاق ،

6:43والموارد ، والمواعيد ،

6:45والتوقعات ، والجدوى ،

6:47والتكاليف أيضاً ، وهي

6:49مهمة جداً . كل هذا يتم

6:53خلال مرحلة التخطيط ،

6:55وبالطبع الخطط هنا

6:56ليست محفورة في الصخر .

7:01لأن هذا هو السبب في

7:03وجود مرحلة تخطيط

7:05يرافقها متابعة وتحكم .

7:12سيتم تنفيذها طوال

7:14دورة حياة المشروع

7:15بأكملها . حسناً ، إيه .

7:26سيتم إدارة المخاطر ،

7:28كما ذكرت لكم ، وسيتم

7:30اتخاذ إجراءات بشأن أي

7:32انحرافات قد تنشأ وما

7:35إلى ذلك . إيه ، لدينا

7:39أيضاً مرحلة ، إيه ،

7:40الأولى وهي مرحلة

7:42التحليل ، وهي أول تقرب

7:44للنظام . خلال هذه

7:46المرحلة ، ما نقوم به

7:48هو معرفة وتحديد ما

7:50يجب على النظام فعله

7:52بالضبط . ما نسعى إليه

7:56هو فهم مناسب لمتطلبات

7:58النظام ، أي خصائصه

8:00ووظائفه . ما الذي

8:04سيقوم به النظام ؟

8:05حسناً . بعد ذلك هناك

8:07مرحلة التصميم . خلال

8:09هذه المرحلة ، نفكر في

8:11كيفية تنفيذ تلك

8:13المتطلبات أو القصص

8:15التي جمعناها . إنها

8:18مرحلة سنتحدث فيها عن

8:20الهندسة المعمارية

8:21وأنماط التصميم . إنها

8:24مرحلة معقدة نوعاً ما ،

8:26لكنها ستكون تكرارية

8:28وتراكمية بشكل عام

8:30طوال المشروع . أي ، أن

8:36ما يتم طرحه في

8:37البداية سيتحسن بمرور

8:39الوقت من خلال

8:40التكرارات المختلفة .

8:44حسناً ، بعد هذه

8:45المرحلة تأتي مرحلة

8:47التطوير الفعلية ، حيث

8:49تُترجم تلك المتطلبات

8:51والقصص إلى أسطر

8:52برمجية ، أي يتم

8:54البرمجة في هذه

8:55المرحلة ، وتُنَفذ

8:57المتطلبات باستخدام

8:59التقنيات التي اختيرت

9:01في مرحلة التصميم . هنا

9:08تجدر الإشارة إلى أن

9:10مرحلة التصميم لا تشمل

9:12فقط الهندسة

9:13المعمارية ، أي أسس

9:14النظام ، بل تشمل أيضاً

9:17تصميم واجهة المستخدم

9:18، على سبيل المثال ،

9:20وتؤثر كثيراً على

9:22تجربة المستخدم . ثم

9:28ننتقل إلى مرحلة

9:30الاختبار أو الـ testing ،

9:32وهو ما نقوم به أساساً

9:34في هذا المقرر الدراسي

9:36. حسناً ، وأجد أنه من

9:38المهم ذكر أننا قد

9:40نتحدث كثيراً عن كل

9:42مرحلة من هذه المراحل ،

9:44وبالتأكيد تدرسونها

9:46في مواد أخرى . حسناً ،

9:49لذا تخيلوا مدى

9:50اختصاري لكل مرحلة ،

9:52لأننا إذا تعمقنا في

9:54أي منها فقد نقضي

9:56أسابيع . أساساً ، يتكون

10:02الاختبار أو الـ testing ،

10:04كما نفعل ، من التحقق

10:06مما يتم بناؤه

10:07ومقارنته بالمتطلبات

10:09أو القصص الناتجة عن

10:11التحليل . وبعد ذلك

10:16لدينا مرحلة أخرى وهي

10:18مرحلة التنفيذ ، والتي

10:20تتكون أساساً من إعداد

10:22البيئة التي سيتم

10:23استخدامها . وهي ما

10:27نسميها بالنشر أو الـ

10:29deployment ، وبعد ذلك نقوم

10:31بمرحلة الصيانة . حسناً

10:34، مع استخدام النظام

10:36ستظهر تغييرات

10:37وتحسينات ، بل وسيتم

10:39اكتشاف بعض العيوب في

10:41مرحلة الإنتاج . إذاً ،

10:44كل هذه التصحيحات أو

10:46التعديلات ستدخل ضمن

10:48ما يسمى بمرحلة

10:49الصيانة . غالباً ما

10:54تكون هناك مرحلة

10:55إضافية بعد هذه وهي

10:57مرحلة تفكيك النظام أو

10:59استبداله . حسناً . و

11:09أحياناً يضطر المرء

11:11إلى إنهاء نظام ما

11:13لاستبداله بآخر . حسناً

11:17، هذا ما يسمى بمرحلة

11:18الاستبدال أو التفكيك .

11:24الآن ، من يشارك في كل

11:26هذه المراحل ؟ هناك

11:30أدوار مختلفة ، ولا

11:31يشارك الجميع في كل

11:33هذه المراحل . أعني على

11:38سبيل المثال ، في مرحلة

11:40التحليل ، يوجد محلل

11:42وظيفي أو مختبر جودة ( QA

11:44) أو مالك المنتج ( PO ) ،

11:48لكن ليس بالضرورة أن

11:50يتواجد كلا الدورين

11:51دائماً . حسناً . أو في

11:53مرحلة التطوير . ذكرت

11:55مبرمجاً ، ومدير قواعد

11:57بيانات ( DBA ) ، وربما

11:58شخصاً مختصاً

11:59بالبيانات ، لكن ليس من

12:01الضروري وجود هؤلاء

12:03الثلاثة دائماً .

12:05أحياناً يكون هناك شخص

12:07واحد فقط ، وأحياناً لا

12:09يظهر أحدهم ، ولكن

12:10باختصار هذه هي

12:12الأدوار . في مرحلة

12:19التخطيط ، نرى مدير

12:21المشروع ، وهو من يدير

12:23الفريق والموارد ،

12:25ويحدث الخطط والمخاطر

12:27، ويعتني بإنتاجية

12:29وربحية المشروع ، كما

12:31يكون ميسراً لحل

12:32المشكلات . حسناً ،

12:38أحياناً توجد مواقف

12:40يتوجب عليه فيها

12:41التدخل للحل ، مثل قول "

12:43لا أستطيع الوصول لهذا

12:45" ، لذا يجب عليه التدخل

12:47. يهمني أن أخبركم

12:51بجميع الأدوار التي

12:53ترونها تقريباً على

12:55الشاشة ، ربما لأنكم

12:57بدأتم بالتعرف على

12:58مجال الاختبار ( Testing ) ،

13:00لأنه إحدى المهام التي

13:02لا تتطلب البرمجة ، بين

13:05قوسين . ربما تجدون بعض

13:09هذه الأدوار مثيرة

13:10للاهتمام وتنتقلون

13:12إليها لاحقاً ، أليس

13:14كذلك ؟ لكن انظروا إلى

13:16أحد هذه الأدوار وهو

13:18ما يسمى بـ " سكرم ماستر

13:21" ( Scrum Master ) ، أو كما يسمى

13:23حالياً في بعض الأماكن

13:25" مدير التسليم " ( Delivery

13:27Manager ) . وهو دور خاص

13:31بالمنهجيات كما ذكرت

13:34لكم ، حيث يعمل كميسر

13:36يركز على أهداف

13:37المشروع ، ويزيل

13:39العوائق ، ويساعدنا في

13:41تنفيذ إطار عمل رشيق (

13:44Agile ) بشكل جيد . بشكل جيد

13:53يعني تنفيذاً يتكيف مع

13:55احتياجاتنا ، وليس

13:57اتباع إطار العمل

13:59حرفياً كما تم تصميمه

14:01نظرياً . لدينا أيضاً

14:09ما يعرف بالمحلل

14:11الوظيفي أو محلل

14:12الأعمال . حسناً ، في

14:15الوقت الحالي ، العديد

14:17من الشركات لا تقوم

14:19بتعيين محلل وظيفي .

14:22حسناً ، في هذه الأيام ،

14:25يتطور دور المحلل

14:26الوظيفي ، إذ يجب أن

14:28يكون ملماً بالأعمال

14:30والأنظمة ، وربما يعمل

14:32كمحلل أعمال . حسناً ،

14:35أي أنهم يدمجون هذين

14:37الدورين في دور واحد .

14:40حسناً . إيه ، حسناً ،

14:47هناك بعض الاختلافات

14:49بين هذين الدورين ،

14:51المحلل الوظيفي ومحلل

14:53الأعمال ، لكن بما أننا

14:55نتحدث على مستوى عالٍ ،

14:57سنعتبرهما شيئاً

14:58واحداً . حسناً . وبشكل

15:04عام ، هو الشخص الذي

15:05يعرف أكثر عن كيفية

15:07عمل التطبيق . نعم ، هو

15:11الشخص الذي يرتدي قبعة

15:13المستخدم النهائي

15:15تقريباً ، ويتمتع

15:16بقدرة كبيرة على

15:18التجريد والتحليل

15:19للقيام بهذا الدور .

15:25كما أنه يقترح وهو دور

15:27ضمن المنهجيات

15:28الرشيقة بالطبع ، وهو

15:30المسؤول عن التأكد من

15:32أن كل ما نبنيه يضيف

15:34قيمة حقيقية للعمل .

15:38حسناً ، هناك أيضاً

15:39المصممون الذين

15:41سيعملون على الجانب

15:42الجمالي وجانب تجربة

15:44المستخدم ، وكيفية

15:46تفاعل المستخدمين مع

15:48هذا النظام . ثم هناك

15:52أيضاً المهندسون

15:53المعماريون الذين

15:55يضعون الأسس وهياكل

15:57التطبيقات على مستوى

15:58قواعد البيانات

16:00والتقنيات وغيرها من

16:01الأمور ، وعادة ما

16:03يتولون الإدارة

16:04التقنية للفريق . هناك

16:08المطورون أو

16:09المبرمجون ، وهم الذين

16:11يكتبون الكود ، أو من

16:12الناحية المثالية

16:14يقومون باختباره

16:15أيضاً من خلال

16:16الاختبارات الوحدوية .

16:18هل تذكرون أنني

16:19أخبرتكم أن المطورين

16:21يجب أن يسلموا

16:22الاختبارات الوحدوية

16:23المنفذة ؟ وهناك فريق

16:26إدارة قواعد البيانات

16:28( DBA ) ، الذين سيتولون كل

16:29ما يتعلق بقواعد

16:30البيانات ، مثل نماذج

16:32البيانات ، والهياكل ،

16:34والمشغلات ( Triggers ) ،

16:35والإجراءات المخزنة ،

16:36والقيود ، وما إلى ذلك .

16:38حسناً ، لن نخوض في

16:39تفاصيل قواعد

16:40البيانات . وهناك فريق

16:42ضمان الجودة ( QA ) ، الذي

16:44تحدثنا عنه طوال هذه

16:46الدورة . وشيء جديد ظهر

16:48قبل سنوات قليلة ، وهم

16:50مهندسو " ديف أوبس " ( DevOps )

16:52، الذين يهتمون بكل ما

16:55يتعلق بالبيئات ،

16:57والتكامل ، وعمليات

16:59النشر . حسناً ، هناك

17:01أيضاً العميل ، وهو

17:03الشخص الذي يدفع ،

17:04والمستخدمون الذين

17:06يستخدمون النظام ؛ لذا

17:08يجب التمييز بينهما :

17:10فليس دائماً يكون

17:12العميل هو نفسه

17:13المستخدم . حسناً ، هناك

17:20العديد من المشاركين

17:22الآخرين ، لكن هؤلاء هم

17:24الأدوار الرئيسية

17:25التي قد تواجهونها

17:27وستتفاعلون معها

17:28يومياً منذ انضمامكم

17:30إلى أي مشروع لتطوير

17:32البرمجيات . حسناً ، لكن

17:38على أية حال ، منهجيات

17:42تطوير البرمجيات .

17:46حسناً ، في الموضوع

17:47السابق ، وفي الشريحة

17:49السابقة ، رأينا

17:51الأنشطة والمراحل

17:53المختلفة التي تتم

17:54خلال عملية تطوير

17:56البرمجيات ، مثل

17:57التحليل ، التصميم ،

17:59البناء ، وما إلى ذلك .

18:03لكن هناك طرق مختلفة .

18:05حسناً . إيه .. ترتبط بها

18:11تلك الأنشطة ببعضها

18:12البعض بمرور الوقت .

18:15لذا ، بناءً على كيفية

18:17ارتباطها وكيفية

18:19تنظيمها ، سنقع في

18:20نموذج دورة حياة معين

18:22أو غيره . إذن ، نماذج

18:28دورة الحياة الأكثر

18:30شيوعاً ، وهناك نماذج

18:32أخرى ، لكننا سنبدأ

18:34بالتعريف بنموذج

18:36الشلال ( Cascada ) . حسناً ،

18:41نموذج الشلال هو ما

18:43نشير إليه عادةً عندما

18:45نتحدث عن المنهجيات

18:47التقليدية . يمكنكم

18:52أيضاً سماعه باسم "

18:54Waterfall " باللغة

18:55الإنجليزية ، حيث يتم

18:57تنظيم المراحل التي

18:59ذكرتها سابقاً بشكل

19:01تسلسلي عبر الزمن . كنت

19:11أقول هذا كمثال فقط

19:13لأغراض أكاديمية ،

19:15لأوضح لكم أن الأمر في

19:17نموذج الشلال ليس مجرد

19:19مثال أكاديمي ، بل هو

19:21هكذا بالفعل : نشاط تلو

19:24الآخر ، ولا يبدأ أي

19:25نشاط منها إلا بعد

19:27انتهاء سابقه . ما هي

19:34مشاكل كل هذا ؟ حسناً ،

19:38من ناحية ، لا توجد

19:40استجابة للتغيير ؛

19:42بمعنى أنه بمجرد أن

19:44نقرر بناء هذا النظام ،

19:46يتم تحديد كل ما

19:47سيحتويه النظام خلال

19:49مرحلة التحليل ثم

19:51ننتقل للمرحلة

19:52التالية . وننتقل إلى

19:55المرحلة التالية . وإذا

20:01اكتشفنا أن شيئاً ما

20:03ليس صحيحاً ، فلا

20:05يمكننا العودة للخلف ،

20:07وهذه مشكلة كبيرة . نعم .

20:12وحتى لو استطعنا

20:13العودة للخلف ، ستكون

20:15تكاليف القيام بذلك

20:17باهظة جداً . علاوة على

20:19ذلك ، لا تبدأ أي مرحلة

20:21إلا بعد انتهاء

20:22المرحلة السابقة . لذا ،

20:24لاحظوا ، عندما يجد

20:26الاختبار عيوباً .

20:28والآن ، ماذا يحدث ؟ يجب

20:30العودة إلى المرحلة

20:32السابقة لتصحيحها .

20:34وهذا مكلف للغاية .

20:38إنها منهجية لديها

20:40أكبر عدد من المشاريع

20:42الفاشلة ، وهي تُستخدم

20:45، لكنها مصممة لفرق

20:47عمل ناضجة ذات منتجات

20:49أو متطلبات مستقرة .

20:52حسناً ، وهذا أمر يصعب

20:55رؤيته في أيامنا هذه

20:57لأن السمة الغالبة

20:59حالياً هي التغيير .

21:01لقد ذكرت لكم هذا

21:03كثيراً في دروس منهجية

21:05" شايني " ( Shine ) . حسناً ، هو

21:08نموذج قليل الفعالية

21:10حالياً ، لكنه سهل

21:12التنفيذ وسهل الفهم .

21:15بالتأكيد يمكنكم تخيل

21:17ذلك مما أخبرتكم به

21:19للتو . حسناً ، لماذا ؟

21:25الآن ، فيما يتعلق

21:27بالنموذج الحلزوني ،

21:29فهو نموذج دورة حياة

21:31اقترحه " بوهم " في

21:32الثمانينيات ، ويعتمد

21:35على دورات تكرارية . ما

21:40يوجه النشاط ، أي ما

21:42سيتم القيام به في

21:44التكرار القادم ، هو

21:46المخاطر . أي أنه يتم

21:49تقييم مخاطر المشروع ،

21:50وفي التكرار التالي

21:52يتم التعامل مع

21:53الجوانب الأكثر خطورة .

21:58لذا ، يتم التعامل مع

21:59الجانب الأكثر خطورة

22:01في بداية المشروع ، ثم

22:03في التكرار التالي يتم

22:05التعامل مع ما يليه في

22:06الخطورة . ومن مزايا

22:13هذا النموذج أنه يقلل

22:15من مخاطر المشروع

22:17ويسمح بالتكيف ، لأن كل

22:19تكرار ينتهي عند حد

22:21معين . ولكن إذا ظهر شيء

22:26أكثر خطورة الآن ،

22:27فيمكنني التعامل معه

22:29فوراً . لكنه غالباً ما

22:32يكون مكلفاً وباهظ

22:33الثمن . نحن لسنا

22:36معتادين على إدارة

22:37المخاطر . لذا ، غالباً

22:40ما يشكل ذلك تعقيداً

22:41ضمن كل تكرار من هذه

22:43التكرارات . هناك أربع

22:51مراحل ضمن هذه

22:52المنهجية : التخطيط

22:54أولاً ، أي تحديد

22:55الأهداف والبدائل

22:57والقيود ، وبالطبع

22:59إجراء تحليل المخاطر

23:01لتقرير ما سيتم

23:02معالجته . ثانياً ،

23:11هندسة ذلك الجزء ، أي

23:13تطوير الجزء الأكثر

23:15خطورة ، ثم التقييم ،

23:17وهو تقييم العميل

23:18للنتائج التي تم

23:20الحصول عليها . وهكذا ،

23:26يتم المضي قدماً في كل

23:28تكرار من التكرارات

23:29التالية بنفس الطريقة .

23:33كما أخبرتكم ، يتم

23:34تقليل مخاطر المشروع

23:36لأننا نتعامل مع

23:38الأمور الأكثر خطورة

23:39أولاً . إنه يسمح لنا

23:43بالتكيف مع التغييرات

23:46، ولكن يجب أن تمتلك

23:47خبرة في إدارة المخاطر

23:49، وهو أمر غالباً ما

23:51يكون مرهقاً ، على

23:53الأقل في صناعتنا .

23:56حسناً . وينتهي الأمر

24:00بإضافة نوع من التعقيد

24:01. من ناحية أخرى ، لدينا

24:10نموذج يعتمد على

24:11النماذج الأولية ، حيث

24:13نبدأ ببناء نماذج

24:15سريعة ، أي إصدارات

24:17سريعة قد تحتوي فقط

24:18على الجوانب المرئية

24:20أو الأكثر تمثيلاً

24:22للحل النهائي بهدف

24:24الحصول على ملاحظات .

24:32مبكرة من العميل . أي

24:34أننا نقدم له بناءً

24:36سريعاً ، نسميه

24:37أحياناً " القشرة " ،

24:39لأنه لا يوجد شيء خلفه

24:41، بل هي فقط الواجهة

24:43الرسومية أو ما يسمى

24:45بـ " الواجهة الأمامية " .

24:48لكن حسنًا ، نحن نعرض

24:50ذلك على العميل ، وهذا

24:52يسمح لنا بالحصول

24:54بسرعة على تعليقات حول

24:56ما يفكر فيه ويشعر به

24:58تجاه تلك الواجهة أو

25:00التصميم . الشيء الجيد

25:05في هذا هو أنه يمكن

25:06إعادة استخدام كود

25:08النموذج الأولي ، أي

25:10إذا أعجب العميل ،

25:11فيمكن أن يصبح هذا هو

25:13الجزء النهائي من

25:14المشروع . وبالإضافة

25:19إلى ذلك ، عندما نكون

25:24على دراية بهدف النظام

25:26ونعرف بالضبط ما نريده

25:28، نكون أكثر ثقة في

25:30مواصلة بنائه . يُستخدم

25:35نموذج النموذج الأولي

25:37هذا عندما لا يكون

25:39لدينا وضوح تام بشأن

25:40ذلك . لذا ، نقوم ببناء

25:44عدة نماذج أولية سريعة

25:46، وهكذا نبدأ في

25:48التوضيح أثناء العمل

25:50وبطريقة اقتصادية

25:52نسبيًا . ما يجب أن نضعه

25:56في اعتبارنا هو عدم

25:58خلق توقعات كاذبة ،

26:00لأنه في كثير من

26:01الأحيان عندما نعرض

26:03هذا الهيكل السطحي على

26:05العميل يقول : " آه ، لقد

26:07انتهى الأمر ، لم يتبق

26:09سوى القليل . " وفي

26:11الواقع ، كل ما هو

26:12موجود هو واجهة ليس

26:14لها وظائف خلفية ، ولا

26:17يوجد سلوك ، وهنا يمكن

26:19أن تتولد توقعات كاذبة

26:21. ومشكلة أخرى نواجهها

26:28غالبًا هي أن هذا

26:30النموذج ، أو هذا

26:31الهيكل السطحي ، لا يتم

26:33تطويره بأفضل طريقة

26:35ممكنة ، لأنه في

26:37الحقيقة شيء سريع

26:38للتعامل مع الموقف

26:40وينتهي به الأمر كجزء

26:42من النظام . إذًا ، ربما

26:49لا يحتوي على أفضل كود

26:51، أو لا يتم استخدامه

26:53بشكل صحيح ، أو لا يتم

26:55استخدام أفضل الأنماط .

26:57جيد . حسنًا ، بعد ذلك

27:01لدينا نموذج آخر لدورة

27:03الحياة . حسنًا ،

27:08وبالحديث بشكل عام ،

27:10ننتقل هنا إلى ما أحبه

27:12، وهو ، آه ، إنها

27:17النماذج التكرارية

27:19والتزايدية التي يتم

27:21فيها تنفيذ دورات

27:23تكرارية . حسنًا ، يتم

27:25تنفيذ الأنشطة معًا

27:27بدءًا من التخطيط

27:28والتحليل والتصميم ،

27:30وكل ما كنت أتحدث عنه

27:32في نموذج الشلال . ولكن

27:35في كل إصدار ، لنقل ،

27:38يتم القيام بكل هذا .

27:43لذا ، سيتم بناء النظام

27:45بطريقة تكرارية ، لأنه

27:47في كل تكرار سيتم

27:49إضافة القليل من

27:50القيمة ، وتزايدية

27:52لأنه يصبح جزءًا مما

27:54سبق وتُضاف إليه هذه

27:56الوظيفة . هناك العديد

28:01من المنهجيات

28:02التكرارية والتزايدية

28:04. هذا النموذج هو ما

28:07جئت لأحدثكم عنه ، وهو

28:09منهجية " أجيل " ( Agile ) .

28:11حسنًا ، اليوم ،

28:12بالنسبة لكم وأنتم

28:14تتعلمون كلاً من

28:15التكراري والتزايدي ،

28:17فهما بالنسبة لكم

28:18متماثلان . حسنًا ، كنت

28:20أقول لكم إن " السبرنت " (

28:23Sprint ) يستغرق أسبوعين

28:25أو ثلاثة أسابيع ،

28:27لنفترض ذلك . هذا سيكون

28:29سبرنت ، وهذا سيكون

28:30سبرنت آخر ، وهذا سيكون

28:32سبرنت آخر . إذًا ، ما

28:34الذي يتم فعله في

28:35السبرنت ؟ التحليل ،

28:37التصميم ، البرمجة

28:38والاختبار ، ثم يتم

28:39الإطلاق للإنتاج .

28:41بالطبع أقولها لكم

28:42هكذا ، ولكن يجب التحقق

28:44من ذلك ، وعمل الكثير

28:45من الأشياء . حسناً ،

28:47لدينا الإصدار الثاني

28:49، والآخر ، إذاً لدينا

28:51تحليل وتصميم ، برمجة

28:53واختبار ، كل هذا وهكذا

28:55ستسير الأمور في كل

28:57دورة عمل ( سبرنت ) . ماذا

28:59يحدث في النماذج

29:00التزايدية ؟ إنه نفس

29:02الشيء بالنسبة لكم في

29:03الوقت الحالي . إنه نفس

29:05الأمر ، سموه تزايدياً

29:07أو تكرارياً ، فهو سيان

29:09. لا يوجد فرق بين هذا

29:11وذاك . على ماذا سيعتمد

29:14كل هذا ؟ وهو ما سنراه

29:16لاحقاً ، ألا وهو قصص

29:18المستخدم . حسناً ، الآن

29:20سنرى كيف تبدو مسألة

29:22قصص المستخدم . دورة

29:27حياة التطوير هي

29:28الهيكل الذي يضم

29:30العمليات والأنشطة

29:31والمهام المتعلقة

29:33بتطوير وصيانة منتجات

29:35البرمجيات ، والتي

29:36تغطي حياة النظام

29:38بأكملها بدءاً من

29:39تحديد المتطلبات وحتى

29:41إنهاء استخدام النظام .

29:48الهدف هنا هو تجنب

29:49التكاليف اللازمة

29:51لتصحيح الأخطاء . حسناً

29:54، أي أننا يجب ألا نطبق

29:56أخطاءً في مرحلة

29:57الإنتاج لأن ذلك سيكون

29:59مكلفاً للغاية . إذاً ،

30:03كخطوة أولى لدينا

30:05التواصل ، وهو اللحظة

30:07التي يطلب فيها العميل

30:09منتج تطوير معين ،

30:10ويتصل بنا لتوضيح

30:12الاحتياجات الملموسة ،

30:14ويتم تقديم الطلبات ،

30:16ثم يبدأ كل شيء في

30:18التبلور والمسار

30:19الصحيح . ثم لدينا

30:23التخطيط والتحليل ،

30:25حيث تبدأ مرحلة

30:26التخطيط الأولية في

30:28التطوير . وهذا يشمل

30:31تحليل قصص المستخدم

30:32والمتطلبات ؛ فنحن

30:34ندقق جيداً في

30:35المتطلبات التي

30:37يطلبها العميل لنرى

30:38أيها أكثر وضوحاً ،

30:40وأيها غير مكتمل أو

30:41غامض . حسناً ، نغوص

30:43بعمق أكبر ، ونقوم بعمل

30:45عروض توضيحية عملية ،

30:48ولكن في النهاية هي

30:50مسألة القيام بتحليل

30:52جيد حتى لا نواجه

30:53مشاكل لاحقاً . بعد ذلك

30:56، ماذا يأتي ؟ تأتي

30:57دراسة الجدوى ، وجمع

30:59المتطلبات ، وفكرة خطة

31:01معالجة البرنامج ،

31:03ويتم تحليل الأجزاء

31:05البرمجية التي تغطي

31:07متطلبات كل مستخدم .

31:10يتم أيضاً بحث الجدوى

31:12المالية والتقنية . ثم

31:17لدينا ما يسمى بتحليل

31:19النظام . حسناً ، في هذه

31:22الخطوة يقوم فريق

31:24المشروع بتخصيص

31:25الموارد وتخطيط المدة

31:27الزمنية للمشروع . يتم

31:30البحث عن قيود المنتج ،

31:32وتحديد تأثيرات

31:34المشروع على المنظمة

31:35بأكملها . ثم لدينا

31:39التصميم ، وفي هذه

31:41المرحلة يبدأ تصور

31:43الحل بمساعدة المراحل

31:45السابقة . يتم إجراء

31:46تصميم منطقي وآخر مادي

31:48، وتُنشأ البيانات

31:49الوصفية والمخططات

31:51والتعليمات البرمجية

31:52الزائفة ، وما إلى ذلك .

31:54حسناً ، سيقوم كل فرد

31:56من فريق التصميم بذلك .

32:03ثم تأتي مرحلة البرمجة

32:05والتطوير ، حيث يتم

32:07اختيار لغة البرمجة

32:09الأنسب ، وتطوير برامج

32:11قابلة للتنفيذ خالية

32:13من الأخطاء ، وبالتالي

32:15تسليم وحدات وظيفية

32:17دقيقة . في نهاية كل

32:27مرحلة من تلك التي

32:28ذكرتها ، لدينا ما يسمى

32:31بـ PMB ، وهو الحد الأدنى

32:33من المنتج القابل

32:34للتطبيق ، والذي

32:36يستغرق تقريباً منذ

32:38بدء المشروع من الصفر

32:40حوالي 15 تكراراً ، وهي

32:46عبارة عن دورات عمل

32:48سريعة ( Sprints ) للوصول

32:49إلى مرحلة الإنتاج ،

32:50وهو ما يمثل الحد

32:51الأدنى من المنتج

32:52القابل للتطبيق . ما هو

32:54الحد الأدنى من المنتج

32:55القابل للتطبيق ؟ هو

32:56المنتج الذي يجب طرحه

32:58في السوق بأقل

32:59المتطلبات الضرورية .

33:01حسناً ، وبعد ذلك يبدأ

33:04العمل على زيادة وظائف

33:06أخرى . ثم لدينا مرحلة

33:09التكرار . حسناً ، قد

33:12يحتاج البرنامج إلى

33:13التكامل مع قواعد

33:15بيانات ، أو أنظمة أخرى

33:17، أو واجهات برمجة

33:19تطبيقات ( APIs ) ، أو

33:20استدعاء واجهات من

33:22العالم الخارجي . ثم

33:26لدينا مرحلة

33:27الاختبارات ، وهنا

33:29نقوم بطبيعة الحال

33:31باختبار كل جزء يتم

33:32تسليمه من التطوير .

33:36يتم أيضاً إجراء

33:37تقييمات لتجنب

33:38الأخطاء ، بما في ذلك

33:40تقييم الوحدات

33:41والبرامج والمنتجات .

33:43وأخيراً ، تقييم

33:45العميل النهائي . حسناً

33:51، إنها مرحلة تكامل

33:53الاختبارات ، وتختتم

33:55بالتحقق والمصادقة ،

33:57مما يساعد في ضمان

33:59نجاح البرنامج . حسناً ،

34:05ثم تأتي مرحلة التنفيذ

34:07. ما هو التنفيذ ؟ حسناً

34:12، هو تثبيت البرنامج

34:14في بيئة إنتاجية ،

34:16وتقييم التكامل

34:17والقابلية للتكيف

34:19والنقل ، وإعداد

34:20التكوينات ، ويبدأ

34:22المستخدمون النهائيون

34:24في استخدامه . هناك

34:28مراحل مثل ، على سبيل

34:30المثال ، مرحلة

34:31التدريب . حسناً ، هذه

34:36مرحلة مثيرة للاهتمام

34:38لا يتم ذكرها كثيراً ،

34:40لكن التدريب وتكيف

34:42المستخدم أمر مهم جداً

34:44، ولهذا سنقدم تدريباً

34:47أولياً لكل مستخدم .

34:51لماذا ؟ لأن

34:52المستخدمين النهائيين

34:54أحياناً يرون النظام

34:56ولا يعرفون كيفية

34:57استخدامه . حسناً ، من

35:01المهم التحقق من مستوى

35:03الاستخدام وتجربة

35:04المستخدم ، وحل أي

35:06صعوبات قد تظهر عند

35:08التعامل مع نظام أو

35:10منصة جديدة . هذا أمر

35:13مهم جداً لأنه يجب

35:14دائماً مرافقة

35:15المستخدم النهائي . أنا

35:17أقول ذلك دائماً .

35:19لماذا ؟ لأنه هو من

35:20سيستخدمه ، وهو من

35:22سيوفر لنا لقمة العيش

35:23مقابل كل العمل الذي

35:25تم إنجازه . ثم لدينا ما

35:29يحدث بمجرد طرحه

35:30للإنتاج ، ومن الواضح

35:32أنه سيكون هناك وظائف

35:34جديدة ويدخل في مرحلة

35:36الصيانة والتطوير . ليس

35:40أقل أهمية ، الصيانة هي

35:43أحد العناصر الرئيسية

35:45لنجاح أي مشروع . في هذه

35:48المرحلة يتم تقليل

35:50الأخطاء الصغيرة ،

35:51ويتم تأكيد حسن سير

35:53عمل البرنامج

35:54وفعاليته واستقراره .

35:58حسناً ، إذا لزم الأمر

36:00يتم تقديم تدريبات

36:02جديدة أو توفير وثائق

36:04حول كيفية التشغيل

36:06والحفاظ على البرنامج

36:07في حالة وعمل مثاليين .

36:10يتم تكييف بيئات

36:12المستخدم ، حسناً ،

36:13المستخدم النهائي . يتم

36:17تحديث الكود

36:18والإعدادات ، حسناً ،

36:20كل ما يندرج تحت

36:21الصيانة والتطوير .

36:27وهذا دائماً مهم جداً ،

36:29لأنه هنا ستظهر

36:30الأخطاء ( Bugs ) أو

36:32التحسينات . يجب أن

36:35تكون دائماً متيقظاً

36:37لذلك ، لأن المستخدم

36:38النهائي أحياناً يكون

36:40محقاً في قوله : " يا أخي

36:42، يمكن أن يكون هذا

36:43بطريقة مختلفة " .

36:44وحسناً ، يجب دائماً

36:46الاستماع إليه . هل

36:50هناك أسئلة حول هذا

36:51العرض التقديمي ؟

36:59>> لا يا أستاذ ،

37:00>> لا أحد لديه أسئلة . هل

37:02كل شيء على ما يرام ؟

37:08جيد . حسناً ، انضم

37:12إلينا المزيد من

37:13الطلاب . كنت أتحدث عن

37:15العمل العملي . البعض

37:18ربما ينقصه هذا ينقصه

37:24إتمامه ، لذا إذا أردتم

37:26يمكنكم إرساله لي

37:27لاحقاً أو يمكننا

37:29مراجعته يوم الأربعاء

37:31أيضاً . إذا أردتم

37:32إرساله لي فلا توجد

37:34مشكلة . انتظروا حتى

37:38أبحث عن العرض

37:39التقديمي الآخر . لا

37:42توجد مشكلة يا شباب .

37:44يمكنكم ، سأعطيكم

37:45المزيد من الوقت .

37:47تطمنوا ، لا توجد أي

37:49مشكلة على الإطلاق .

37:51حسناً ، سنتحدث قليلاً

37:55عما هي قصص المستخدم (

37:57User Stories ) . حسناً ، كنت

38:00أتحدث معكم عن قصص

38:01المستخدم ، وعن منهجية

38:04" أجيل " ( Agile ) . لذا ،

38:06سنتحدث قليلاً عما هو ..

38:08أنتم اعتمدتم في عملكم

38:10على التكليف الأول ( TP1 )

38:12حيث أخبرتكم بقصة

38:14المستخدم التي تحكي ما

38:16كنت أفعله من لحظة

38:17استيقاظي حتى وصولي

38:19للعمل ، وقمتهم أنتم

38:21بوضع سيناريوهات

38:23الاختبار . حسناً ،

38:26سيناريو الاختبار هو

38:28مجرد عنوان يجب أن

38:30يكون وصفياً . الآن في

38:34التكليف الثاني ( TP2 )

38:36سنتعمق أكثر في النظام

38:38، ولكن حسناً ، عن ماذا

38:41سنتحدث هنا ؟ قصص

38:42المستخدم . حسناً ، ما

38:45هي قصة المستخدم ؟ قصص

38:48المستخدم هي جزء مما

38:50كنت أحدثكم عنه حول

38:51نهج " أجيل " الذي يساعد

38:53في تغيير التركيز من

38:55الكتابة عن المتطلبات

38:57إلى الحديث عنها .

39:01تتضمن جميع قصص

39:03المستخدمين في منهجية

39:05" شايد " جملة مكتوبة ،

39:07سطرًا أو سطرين مهمين

39:09للغاية ، وسلسلة من

39:11المحادثات حول

39:13الوظيفة المطلوبة . قصص

39:19المستخدمين هي أوصاف

39:21قصيرة وبسيطة لميزة

39:22معينة تُروى من منظور

39:24الشخص أو المستخدم

39:26النهائي . ما الذي

39:30يريده النظام أو

39:31القدرة حقًا ؟ إذًا ،

39:36هناك كيفن .

39:38>> نعم ، انتبه ، أنت لا

39:40تشارك الشاشة . نعم ،

39:42نعم .

39:42>> أوه ، لحسن الحظ أنك

39:44أخبرتني . ظننت أنني

39:46>> كنت أقرأ الشريحة ،

39:47وأدركت أنك كنت تتحدث

39:49عن الشريحة ولكن لا .

39:51أحسنت ، لقد ربحت نقطة

39:53صغيرة ، أليس كذلك ؟ من

39:55الاختبار الجزئي .

39:58حسنًا ، لحسن الحظ أنك

39:59أخبرتني . شكرًا لك يا

40:01كيفن . لطيف جدًا منك ،

40:03أنا منهك اليوم وقد

40:05بدأنا الإثنين هكذا .

40:08حسنًا ، إذًا ، كيف

40:12تتكون قصة المستخدم ؟

40:16حسنًا ، تتكون من ثلاث

40:18كلمات . ما المقصود

40:22بالملف الشخصي ؟ أريد

40:25هدف البرنامج لتحقيق

40:27النتيجة . غالبًا ما

40:31تُكتب قصص المستخدمين

40:33، ومن الواضح أنها

40:34يمكن أن تكون ، كما

40:36أخبرتكم ، سأعرض لكم

40:38لاحقًا مقاطع الفيديو

40:40حول كل هذا . ربما تنتهي

40:42الدورة التدريبية

40:44بالكامل بمقاطع فيديو

40:45لتشاهدوها في الحياة

40:47المهنية . لقد شرحت لكم

40:49أنني في الحياة

40:50المهنية سأعرض لكم

40:51مقاطع الفيديو ، ولن

40:53أريكم كل المشاكل

40:54الموجودة . هذا من أجل

40:56المسار المثالي . حسنًا

40:58، هكذا يجب أن يتم

40:59الأمر . إذًا ، هناك

41:01برامج مثل " آزور " و "

41:03تريلو " . حسنًا ، الأكثر

41:05شهرة في السوق هو " جيرا

41:07" ؛ وهو مدير مشاريع

41:09تُكتب فيه قصص

41:10المستخدمين ، وتُكتب

41:12فيه تصميمات حالات

41:13الاختبار ، والتنفيذات

41:15، ودورة الاختبار ، كل

41:17شيء موجود هناك . حسنًا

41:19، حيث يتم أيضًا رفع

41:21الأخطاء . لذا فهي تغير

41:23التركيز بقوة من

41:25الكتابة حول الميزات

41:27التي ستتم مناقشتها

41:28داخل قصة المستخدم . في

41:31الواقع ، هذه

41:32المناقشات أهم من أي

41:34نص آخر يتم كتابته .

41:38الغرض من كتابة قصة

41:40المستخدم هو تمثيل

41:42الكيفية التي تترجم

41:43بها وظيفة البرنامج

41:45إلى قيمة للمستخدم

41:47بدقة . بمعنى آخر ، ما

41:50التأثير الذي تحدثه

41:52وظيفة البرنامج هذه

41:54على المستخدم النهائي

41:55؟ حسنًا ، المستخدم

41:58النهائي ، المعروف

41:59أيضًا باسم العميل ،

42:01ليس بالضرورة هو

42:03المستهلك النهائي .

42:06يمكن أن يكون المستخدم

42:08النهائي أيضًا عميلاً

42:10داخليًا ، عضوًا في

42:11الفريق سيستفيد من هذا

42:13العمل . تعد قصص

42:16المستخدمين مكونًا

42:17أساسيًا لماهية

42:19منهجية " شايد " . يمكن

42:22صياغتها بطرق عديدة .

42:24حسناً ، هذا شيء مألوف

42:26جداً لكم بالتأكيد ،

42:28ربما رأيتموه على ورقة

42:30لاصقة على زجاج .

42:31بالتأكيد ، ربما رأيتم

42:33ذلك في أماكن كثيرة ،

42:35لكن الطريقة الأكثر

42:37فعالية لإنشاء وتتبع

42:38قصص المستخدمين هي

42:40باستخدام برنامج

42:41إدارة المشاريع ، كما

42:43أخبرتكم ، مثل " جيرا " ( Jira

42:45) كمثال . حسناً ، إذا

42:46أردتم استخدام " جيرا " ،

42:48يمكنكم ذلك ، فبمجرد

42:49التسجيل تحصلون على ما

42:51يصل إلى خمس تراخيص

42:53مجانية . حسناً ، وهو

42:54مجاني بالكامل

42:56ويمكنكم تجربة كل ما

42:57تريدون . هناك ، يتيح

43:00لكم برنامج إدارة

43:02المشاريع الفعال

43:03إمكانية التعديل

43:05والمتابعة لقصص

43:06المستخدمين في الوقت

43:08الفعلي . حسناً ، لأن

43:11أحداً يقوم بالتحديث

43:12والآخر سيراه محدثاً

43:14على الفور . إذاً ، من

43:17يقوم بكتابة قصص

43:18المستخدمين ؟ عادةً ،

43:22يقوم مالك المنتج ( PO )

43:24بكتابة قصص

43:25المستخدمين بناءً على

43:28أبحاث المستخدمين

43:29وينظمها في قائمة

43:31لفريق التطوير ،

43:33وتُعرف أيضاً بقائمة

43:35الأعمال المتراكمة ،

43:37وأعيد القول بأنها الـ

43:39" باكلوج " ( Backlog ) ، وهي

43:41بمثابة " مخزن " يحتوي

43:43على جميع القصص ، حيث

43:45تكون جميعها مجتمعة ،

43:47وعندما يحين وقت "

43:49السبرنت " ، يتم استخراج

43:51واحدة وتقديرها

43:53بالقول : " حسناً ، هذه

43:55ستستغرق وقتاً محدداً "

43:57. حسناً ، نأخذ قصة أخرى

43:59، وهذه ستستغرق وقتاً

44:01محدداً . نأخذ قصة أخرى

44:03، وهذه ستستغرق وقتاً

44:04محدداً ، مهلاً ، لقد

44:06استنفدنا سعة السبرنت .

44:08حسناً ، أسبوعان . نعم ،

44:10يجب تطويرها

44:11واختبارها ، وعلينا

44:13القيام بكل هذا . حسناً

44:15، انتهينا . إذاً ، هي

44:16ثلاث قصص . عادةً ما

44:18يرغب محلل الأعمال في

44:20إضافة 50 قصة مستخدم ،

44:22لكن الأمر لا يسمح ،

44:24وهنا يأتي دور " سكرم

44:25ماستر " ( Scrum Master ) ليقول : "

44:27مهلاً ، إلى هنا نحن

44:29بخير ، لا يمكننا إضافة

44:31المزيد من القصص . " إنه

44:32يشبه " سكرم ماستر " ، هو

44:34بمثابة حكم المباراة .

44:36حسناً ، إنه ينظم كل

44:38هذه المواقف . إذاً ، من

44:42يستخدم قصص

44:43المستخدمين ؟ حسناً ،

44:45تُستخدم قصص

44:46المستخدمين في الأطر

44:48التي ذكرتها لكم ، مثل "

44:50سكرم " ( Scrum ) و " كانبان " (

44:52Kanban ) . حسناً ، لقد

44:54أخبرتكم أن قصص

44:55المستخدمين في " سكرم "

44:57تساعد الفريق على

44:59تحسين الفهم خلال

45:00التخطيط للسبرنت .

45:03يتمتع " سكرم " بهيكل

45:04أكثر تحديداً مع أدوار

45:06معينة ، تشمل " سكرم

45:08ماستر " ، ومالك المنتج ،

45:10وفريق التطوير . حسناً ،

45:12يتم تقسيم الأنشطة إلى

45:14" سبرنت " ( Sprint ) ، وهي

45:15تكرارات زمنية ثابتة

45:17كما أخبرتكم ، يمكن أن

45:19تتراوح من أسبوعين إلى

45:21أربعة أسابيع . المدة

45:23المثالية هي أسبوعان ،

45:24وبعض الفرق تجعلها

45:25ثلاثة أسابيع . حسناً ،

45:29في المقابل ، في "

45:31كانبان " ( Kanban ) تقوم

45:32الفرق بإضافة قصص إلى

45:34قائمة الأعمال

45:35المتراكمة ، وهي قصص

45:37المستخدم التي تمنح

45:39الفرق السياق والوضوح

45:41اللازمين لإدارة

45:43العمل والالتزام

45:44بالمواعيد النهائية . "

45:50كانبان " أكثر مرونة من

45:52حيث الأدوار . لا يوجد

45:54دور محدد مثل " سكرم " ( Scrum

45:56) ، على الرغم من وجود

45:58مسؤول عن العملية

46:00عادةً . وهنا يكمن

46:02الفرق الذي يجب أن

46:04تدركوه ؛ لا يوجد "

46:05سبرنت " محدد في " كانبان

46:08" . حسناً ، لأنه في "

46:09كانبان " مثلاً ، قد

46:11يستمرون في إضافة

46:12المهام عندما يصل

46:14النظام إلى مرحلة

46:15النضج ويدخل في مرحلة

46:17الصيانة . تخيلوا أن

46:19النظام تم تطويره خلال

46:20عام ، وشهد العديد من

46:22دورات " السبرنت " ، ثم

46:23دخل بعدها في مرحلة

46:25الصيانة . لماذا ؟ لأنه

46:27يجب تغيير هذا وتعديل

46:29ذاك ، ومن خلال ذلك

46:30يقومون بإضافة وظيفة

46:32جديدة . حسناً ، هذا هو

46:34الفرق الكبير بين "

46:36سكرم " و " كانبان " . حسناً

46:38. أريدكم أن تستوعبوا

46:39هذا الفرق . في الوقت

46:41الحالي ، قد يبدو الأمر

46:43بالنسبة لكم متشابهاً

46:44، لأن كلاهما يندرج

46:46ضمن إطار منهجيات

46:47العمل المرنة . كيف

46:50نكتب قصة مستخدم جيدة ؟

46:54ليس من السهل يا رفاق

46:56كتابة قصة مستخدم جيدة

46:58. لقد عملت كمحلل وظيفي

47:00وأؤكد لكم أنه كان من

47:02الصعب علي جداً صياغة

47:04قصة مستخدم جيدة

47:06يفهمها المطور ومسؤول

47:08الجودة ( QA ) . تُكتب قصة

47:11المستخدم في ثلاث

47:12خطوات وتمثل وجهة نظر

47:14المستخدم النهائي .

47:16ثلاث خطوات يجب

47:18اتباعها لكتابة قصة

47:20مستخدم . أولاً ، الملف

47:22الشخصي ، ودور

47:23المستخدم النهائي ،

47:25والحاجة ، والهدف الذي

47:27يسعى إليه كوظيفة

47:29برمجية للمستخدم

47:30النهائي . وثالثاً ،

47:34الغرض ، والهدف من

47:35تجربة المستخدم

47:37النهائي مع الوظيفة

47:38البرمجية . يجب أن

47:41تتضمن قصة المستخدم

47:43هذه المكونات الثلاثة .

47:45حسناً ، سنتعمق في كل

47:47واحد منها ، لكن الأول

47:49هو الملف الشخصي .

47:52الملف الشخصي

47:54للمستخدم النهائي ،

47:56سيقوم بتقييم جمهور

47:57مستهدف محدد . يجب

47:59الأخذ بعين الاعتبار

48:01من سيؤثر عليه هذا

48:02الجزء من البرنامج .

48:06وهنا عادة ما تُطرح

48:07أسئلة عند تحديد الملف

48:09الشخصي . على سبيل

48:11المثال ، لمن نقوم

48:13بإنشاء هذه الوظيفة

48:14البرمجية ؟ ما نوع

48:16خصائص المنتج التي

48:17يريدها المستخدم

48:19النهائي ؟ ما هي

48:20البيانات

48:21الديموغرافية وما

48:22الذي يريده المستخدم

48:24النهائي ؟ حسناً ، يجب

48:26دائماً التفكير

48:27بالطريقة التي يفكر

48:29بها المستخدم النهائي .

48:31حسناً . ثم صف الحاجة .

48:37حسنًا ، صف كيف سيستخدم

48:39المستخدم النهائي

48:40ميزة البرنامج . ولماذا

48:42؟ لأن هذا أمر أساسي

48:45لفهم الفريق لسبب

48:47اختيار الجمهور

48:48المستهدف لاستخدام

48:50تلك الميزة . وعلينا أن

48:53نضع في اعتبارنا ،

48:54وربما يجب طرح أسئلة

48:56هنا مثل ، على سبيل

48:58المثال ، ما الذي يحاول

48:59المستخدم النهائي

49:01تحقيقه ؟ كيف ستساعد

49:03ميزة التطوير التي

49:04سيتم إنشاؤها

49:06المستخدم النهائي في

49:07تحقيق ذلك الهدف ؟

49:09حسنًا . إيه ، لا أعلم ،

49:13على سبيل المثال ، إيه ،

49:15مساعدة أعضاء الفريق

49:17على فهم كيف تساهم

49:19المهام الفردية في

49:20تحقيق أهداف تجارية

49:22أوسع ، على سبيل المثال

49:24، لا أعلم ، شيئًا يخص

49:26العمل . حسنًا . والخطوة

49:30الثالثة ، وهي الغرض .

49:34حسنًا ، هنا من الواضح

49:36أنه يجب طرح أسئلة مثل

49:38، على سبيل المثال ، ما

49:40هي فائدة ميزة

49:41البرنامج ؟ ما هي

49:44المشكلة التي يتم حلها

49:46؟ كيف ستتناسب هذه مع

49:48الأهداف الأوسع ؟

49:50حسنًا ، أنا أطرح عليكم

49:53ضمن هذه العناصر

49:54الثلاثة أسئلة ، لكنها

49:56أسئلة تتبادر إلى ذهني

49:59لأنني ، بعبارة أخرى ،

50:01لدي خبرة كبيرة في قصص

50:03المستخدمين منذ عدة

50:05سنوات . حسنًا ، لكن هذا

50:07لكي لا ... هذا يعتمد

50:09عليكم ، أليس كذلك ؟ لأن

50:11ربما تودون التفرغ

50:13للقيام بـ ... كتابة قصة

50:18مستخدم . لكن دعونا

50:22ننتقل إلى بعض الأمثلة

50:24لماهية قصص

50:25المستخدمين . لماذا

50:27تفهم قصص المستخدمين

50:29الرشيقة ( Agile ) ؟ إيه ،

50:32لكي تفهموا أكثر

50:34قليلاً . أترك لكم هنا

50:37بعض الأمثلة . إذن ،

50:40المثال الأول ، حسنًا ،

50:42وهو عن تطوير المنتج .

50:45بصفتي مدير منتج ، أريد

50:51إيه ، طريقة تمكن أعضاء

50:53الفريق من فهم كيف

50:54تساهم المهام الفردية

50:56في الأهداف التجارية

50:58الأوسع لزيادة

50:59الكفاءة . هذا كتطوير

51:04للأسئلة . بعد ذلك

51:06لدينا ما يتعلق بتجربة

51:08العميل . بصفتي عميلاً

51:10متكرراً ، أتوقع حفظ

51:12معلوماتي لخلق تجربة

51:14دفع أكثر سلاسة .

51:17الثالثة ، تطبيق

51:19الهاتف المحمول . بصفتي

51:22مستخدماً متكرراً

51:24للتطبيق ، أريد طريقة

51:25لتبسيط المعلومات ذات

51:28الصلة بأسرع طريقة

51:29ممكنة . في هذه الأمثلة

51:33الثلاثة ، يمكنكم رؤية

51:35مدى أهمية طرح تحديثات

51:37البرامج من منظور

51:39المستخدم النهائي .

51:42حسنًا ، بهذه الطريقة

51:44ستتم مراجعة

51:45التحديثات مع وضع

51:47التركيز دائماً على

51:48منفعة المستخدم

51:50النهائي . حسنًا ، ما هو

51:58معيار القبول ؟ وهذا

52:01مهم جداً . فيما يتعلق

52:04بتطوير المشروع . حسنًا

52:08، هناك شيء مهم مطلوب

52:10دائماً لضمان الجودة (

52:12QA ) . يجب أن تحتوي قصص

52:16المستخدم على معايير

52:18القبول . حسناً ، يتم

52:23تحديد معايير القبول

52:25من قبل مالك المنتج

52:27وفريق التطوير . لماذا ؟

52:30لأنها تفيد المطور

52:32فيما يجب عليه تطويره ،

52:34وتفيد مسؤول ضمان

52:36الجودة فيما يجب عليه

52:37اختباره . حسناً ، هي

52:40متطلبات يجب أن يلبيها

52:42المنتج ليعتبر

52:43مكتملاً . وهي مرتبطة

52:48جداً بقصة المستخدم ،

52:50ومن الطبيعي أن تكون

52:52مدرجة ضمن وصف قصة

52:54المستخدم . إليكم بعض

53:00الأمثلة لمعايير قبول

53:02قصة المستخدم ، على

53:03سبيل المثال ، عند

53:05تسجيل الدخول ، هناك

53:07سيناريو عندما يرغب

53:08المعلم في البحث عن

53:10بيانات الطالب المسجل

53:12لإدارة تسجيله .

53:18بافتراض أنه دخل إلى

53:20النظام كمعلم ، وعندما

53:22أكون في قسم التسجيل ،

53:23يجب أن أتمكن من البحث

53:25عن بيانات الطالب

53:27المسجل . إذن ، ما هي

53:35الفوائد ؟ وهنا نجد

53:38ثلاث كلمات . بافتراض ،

53:40عندما ، إذن ؟ لاحظوا .

53:42بافتراض ، عندما ، إذن .

53:45هذه الكلمات الثلاث ،

53:47Given و When و Then ، هي

53:49الفوائد الرئيسية

53:51التي ذكرناها سابقاً ،

53:53وهي معرفة متى تكون

53:55قصة المستخدم مكتملة

53:57وتلبي توقعات العميل .

54:01من ناحية أخرى ، حقيقة

54:03أن المعايير تُكتب

54:05بشكل مشترك وليست

54:07مسؤولية مالك المنتج

54:09وحده . حسناً ، هذا

54:13سيسمح لفريق التطوير

54:15بتقديم منظور جديد

54:17للعميل . من الخصائص

54:22الأخرى التي توفرها

54:24كتابة معايير القبول

54:26هي إزالة الغموض عن

54:27المتطلبات . وأخيراً ،

54:32النتيجة المترتبة على

54:34التطوير بناءً على

54:36معايير القبول هي تحسن

54:38جودة المنتج بشكل كبير

54:40، لأننا سنعتمد في

54:42تطويرنا على ما حدده

54:43العميل بشكل صريح ،

54:50وهذا بدوره سيمنحنا

54:52الطمأنينة فيما نقوم

54:54به . إذن ، " بافتراض ،

54:59عندما ، إذن " هي واحدة

55:01من أكثر التقنيات

55:03شيوعاً لكتابة

55:04المعايير وتسمى

55:06بتقنية السلوك ، لأنها

55:08تعتمد أساساً على وصف

55:10سلوكيات وظائفنا .

55:16بافتراض وجود شرط معين

55:18، وعندما يحدث حدث أو

55:21إجراء ، ستترتب على ذلك

55:23نتيجة . حسناً ، هذا هو

55:30المثال الأسهل

55:31الموجود في العرض

55:32التقديمي ، بافتراض أن

55:34المستخدم يريد تسجيل

55:36الدخول إلى نظامنا ،

55:38عندما يُدخل اسم

55:39المستخدم وكلمة

55:41المرور وتكون صحيحة ،

55:42إذن يمكن للمستخدم

55:44الدخول بنجاح إلى

55:45الصفحة الرئيسية .

55:51حسناً ، هذا مثال سهل ،

55:53لكن أحياناً يعتمد

55:55الأمر على تعقيد قصة

55:57المستخدم ، ويجب علينا

55:59مراعاة ذلك . حسناً ،

56:02ولكن هذا أحد أكثر

56:03الأمثلة كلاسيكية .

56:08الآن ، هناك طريقة

56:10فعالة لإنجاز قصة

56:12المستخدم . جيد . وهي الـ

56:163C . ما هي الـ 3C ؟ حسناً ،

56:21هي ثلاث خطوات وصفية .

56:24حسناً ، قصة المستخدم

56:27الفعالة تعتمد بوضوح

56:29على هذه الـ 3C ،

56:30والاختصار هو INVEST .

56:34حسناً ، سنراها لاحقاً

56:36هنا . إذن ، الـ 3C هي :

56:39الحرف الأول C يرمز

56:41للبطاقة ( Card ) ، والثاني

56:44للمحادثة ( Conversation ) ،

56:46والثالث للتأكيد (

56:48Confirmation ) . تقسم الـ 3C كل

56:52قصة مستخدم إلى ثلاث

56:55نقاط مرجعية مختلفة .

56:57جيد ، مما يخلق عملية

56:59أكثر تنظيماً . هنا

57:03سنحلل هذه الـ 3C ،

57:05الأولى هي البطاقة ،

57:06وهي وصف قصة المستخدم

57:09المستخدمة لتخطيط ما

57:11سيتم تنفيذه في

57:12السبرنت . جيد . ثم لدينا

57:19المحادثة ، وهي نقاش

57:21بين العميل ،

57:23والمستخدمين ،

57:24والمطورين ، وفريق

57:26ضمان الجودة لفهم ما

57:28يجب أن تنجزه هذه

57:30القصة . ثم لدينا الـ C

57:35الأخيرة وهي التأكيد ،

57:37وهو اتفاق بين أصحاب

57:39المصلحة على تحقيق

57:40الأهداف والحلول لتلك

57:42القصة لإنهاؤها . تساعد

57:51الـ 3C بوضوح في تقسيم

57:53قصة المستخدم وتوفر

57:54اتجاهاً واضحاً بين

57:56الأطراف المعنية . بعد

58:01ذلك ، كما أخبرتكم ،

58:03لدينا نموذج INVEST . ما هو

58:05نموذج INVEST ؟ نموذج INVEST

58:07يعني : مستقلة ، قابلة

58:09للتفاوض ، ذات قيمة ،

58:11قابلة للتقدير ، صغيرة

58:13، وقابلة للاختبار .

58:16بالانتقال إلى الأولى

58:18، وهي " مستقلة " ، يجب أن

58:20تكون قصة المستخدم

58:21مستقلة ، مما يعني أنها

58:23لا تعتمد على مهام

58:25أخرى وهي مستقلة

58:26تماماً . يجب أن تكون

58:28قصة المستخدم مستقلة ،

58:30ويجب أن تؤدي ما تنص

58:31عليه القصة . جيد ، ثم

58:33لدينا " قابلة للتفاوض " .

58:35يجب أن تكون قصة

58:36المستخدم قابلة

58:38للتفاوض . ماذا يعني

58:39ذلك ؟ هذا يعني أنها لا

58:41تترك مجالاً للجدل .

58:43يجب أن يفهم مختبر

58:44الجودة قصة المستخدم

58:46ويعرف ما الذي يجب

58:48عليه اختباره . جيد ، ثم

58:51" ذات قيمة " . يجب أن تقدم

58:53قصة المستخدم قيمة

58:55للمستخدم النهائي .

58:57حسناً ، لا يوجد الكثير

58:59لأقوله هنا . " قابلة

59:01للتقدير " . يجب أن يكون

59:03من الممكن تقدير حجم

59:05قصة المستخدم . لقد

59:06تحدثت معكم عندما

59:08تكونوا في مرحلة تخطيط

59:10السبرنت ، سيقدمون لكم

59:12قصة مستخدم . سأبحث

59:13الآن لأرى إن كان

59:15بإمكاني الحصول على

59:16قصة مستخدم لنطلع

59:17عليها . أوه . إذن يجب أن

59:22تكون قصة المستخدم

59:24مفهومة . بصفتكم مسؤولي

59:26جودة ( QA ) ، ستقولون : "

59:27دعونا نرى ، سيتطلب هذا

59:29عدداً معيناً من

59:30تصميمات حالات

59:31الاختبار ، وسأختبرها

59:33في كذا ، وسيستغرق هذا

59:35مني ، لا أعلم ، مثلاً ، 5

59:37ساعات " . حسناً ، يجب

59:38عليكم تقدير ذلك في

59:40تلك اللحظة لأن الجميع

59:42سيكونون جالسين على

59:44الطاولة ، المطور ،

59:46ومالك المنتج ( PO ) ،

59:48وسكرام ماستر ،

59:49وسيقولون : " حسناً ، كم

59:51من الوقت ستستغرق

59:53لاختبار هذا ؟ " حسناً ،

59:55يجب أن تفهموا قصة

59:57المستخدم في عقولكم

59:58حتى تتمكنوا من تقديم

1:00:00تقدير . لا يمكنكم

1:00:01القول : " يا شباب ،

1:00:03سأخبركم لاحقاً " . لا ،

1:00:04يجب عليكم قول ذلك في

1:00:05تلك اللحظة يا رفاق .

1:00:07هذه هي المنهجية . ش .

1:00:09يجب أن تكون صغيرة . يجب

1:00:11أن تكون قصة المستخدم

1:00:13جزءاً صغيراً من العمل

1:00:15يمكن مراجعته في فترة

1:00:17زمنية قصيرة . أوضح من

1:00:19ذلك مستحيل ، لأنني

1:00:20أخبرتكم بالفعل ، يجب

1:00:22أن تفهموها لتتمكنوا

1:00:24من تقدير الوقت . لا

1:00:25يمكنكم القول سأقضي

1:00:26ثلاثة أسابيع في

1:00:27الاختبار . لا ، هذا

1:00:29مستحيل يا رفاق . بمعنى

1:00:31أنكم لم تفهموا قصة

1:00:32المستخدم في تلك

1:00:33اللحظة . لهذا السبب ،

1:00:36أثناء اجتماع التخطيط

1:00:38، يجب أن تفهموا قصة

1:00:43المستخدم جيداً . أقول

1:00:45للشباب أحياناً : "

1:00:46اشربوا ثلاثة أكواب

1:00:47قهوة لتكونوا

1:00:48مستيقظين وتفهموا " .

1:00:50وإذا لم تفهموها ، يجب

1:00:51أن تسألوا . لماذا ؟

1:00:53لأنكم ستتسببون في

1:00:54مشكلة كبيرة داخل

1:00:56السبرنت ( Sprint ) . جيد . وأن

1:01:00تكون قابلة للتحقق ، أي

1:01:02قابلة للاختبار . يجب

1:01:04أن تجتاز القصة

1:01:05اختبارات القبول

1:01:07وتلبي معايير القبول .

1:01:11لا يوجد الكثير

1:01:12لتوضيحه هنا . يجب هنا

1:01:16التأكد من صياغة قصة

1:01:18المستخدم بطريقة

1:01:19محددة وقابلة للتحقيق

1:01:21، باتباع هذا الاختصار

1:01:26الذي أخبرتكم به . إذاً

1:01:30، تكمن أهمية أن تكون

1:01:34قصة المستخدم دقيقة .

1:01:36حسناً ، يجب كتابة قصة

1:01:38المستخدم بطريقة

1:01:39فعالة ، فقد تكون أجزاء

1:01:42صغيرة من تطوير المنتج

1:01:44، لكن هذه القصص تساعد

1:01:46في الواقع على توليد

1:01:47نتائج إبداعية لوظائف

1:01:50المنتجات الجديدة .

1:01:52سيكون الاهتمام

1:01:53بالتفاصيل هنا مهماً

1:01:55للغاية لكل واحد منكم .

1:01:59حسناً ، وهناك ثلاث

1:02:01نقاط تلي ذلك . جيد .

1:02:04الأولى ، ضعوا العملاء

1:02:06في المقام الأول . تضع

1:02:10قصص المستخدمين

1:02:11المستخدمين النهائيين

1:02:13في مركز المحادثة .

1:02:15مكون مهم من إطار عمل

1:02:18أجايل ( Agile ) . بعد ذلك ،

1:02:22يمكن للفريق تحديد

1:02:24الأولويات واحتياجات

1:02:26المستخدمين ، وسيتعين

1:02:28عليهم التركيز على

1:02:29كيفية المساهمة في خلق

1:02:31تجربة مستخدم إيجابية .

1:02:36حسنًا ، النقطة

1:02:40الثانية هي تعزيز

1:02:41الحلول المبتكرة . كلما

1:02:46تعمقتم في فهم ملف

1:02:48تعريف المستخدم

1:02:49النهائي ، أصبحت حلول

1:02:51البرمجيات أكثر

1:02:52ابتكارًا . يعود هذا

1:02:57إلى ضرورة التركيز على

1:02:59احتياجات المستخدمين ،

1:03:00التي يمكن ربطها

1:03:02بأهداف العمل

1:03:03الداخلية . كلما زاد

1:03:07التزامكم تجاه أنواع

1:03:09المستخدمين الذين

1:03:11تستهدفونهم ، كانت

1:03:12النتائج أكثر فعالية .

1:03:16وبعد ذلك النقطة

1:03:18الثالثة ، تعزيز

1:03:19التعاون الجماعي .

1:03:24عندما يقوم العديد من

1:03:26أعضاء الفريق بتحليل

1:03:27وتحديد أولويات قصص

1:03:29المستخدم ، سيزدهر

1:03:31التعاون في مكان العمل

1:03:33بشكل كبير . سيؤدي هذا

1:03:37إلى توليد وجهات نظر

1:03:39متعددة تأخذ في

1:03:40الاعتبار تقديم حلول

1:03:42جديدة ، وتجاوز

1:03:43العقبات الموجودة

1:03:45لديكم ، بدءًا من

1:03:46النتائج القابلة

1:03:48للقياس وصولًا إلى فهم

1:03:50متطلبات المنتج . كلما

1:03:56زاد تواصل الفريق ، كان

1:03:58الوصول إلى النتائج

1:04:00المرجوة أسهل . ومن

1:04:06الواضح أن هذا سيولد

1:04:08قيمة مضافة لتجربة

1:04:09المستخدم . إن وضع

1:04:13المستخدم النهائي في

1:04:14المقام الأول هو وسيلة

1:04:16فعالة لتركيز

1:04:17المحادثات حول

1:04:18احتياجات المستخدمين

1:04:20النهائيين . حسنًا . وفي

1:04:22نهاية المطاف ، سيؤدي

1:04:24ذلك إلى خلق قيمة أكبر .

1:04:27من خلال إجراء محادثات

1:04:28حول تجربة المستخدم

1:04:30النهائي . ستتمكنون من

1:04:32إنشاء حلول برمجية

1:04:34أكثر ابتكارًا من

1:04:35شأنها تحسين عملية

1:04:37تطوير المنتجات . إذا

1:04:40تخيلتم أنكم مستخدمون

1:04:42نهائيون و قال التطبيق

1:04:46: " نعم ، لكنني لا أحب

1:04:48هذا ، فأنا من فريق

1:04:50سكرام . " حسنًا ، أنا

1:04:52المطور ، وأنا كل شيء ،

1:04:54ولكن إذا لم يعجبكم

1:04:56الأمر ، فلن تقدروا

1:04:58قيمته ، وبالتالي

1:05:00سيضيع هذا البرنامج .

1:05:02لهذا السبب يجب أن

1:05:04تكونوا دائمًا على

1:05:05تواصل مع المستخدم

1:05:07النهائي ، واسألوه عما

1:05:09يريد تغييره ، وما لا

1:05:10يراه مناسبًا ، فقد

1:05:12يرغب في الوظائف بطرق

1:05:14مختلفة . هنا تكمن

1:05:16أهمية التواصل ،

1:05:18التفكير في الأمر ،

1:05:20رؤيته ، ماذا يحتاج ،

1:05:22هذا لا يعجبني ، أرى أن

1:05:24هذا يمكن القيام به

1:05:26بطريقة مختلفة . لذلك ،

1:05:29يتم أحيانًا دعوة

1:05:31المستخدم النهائي إلى

1:05:32بعض الاجتماعات ليعطي

1:05:34رأيه ويذكر الأشياء

1:05:36التي لا تعجبه أو

1:05:37الأشياء التي تحتاج

1:05:39إلى تحسين . حسناً ، هذا

1:05:43في نموذج الشلال ، أو

1:05:45النموذج الحلزوني ، أو

1:05:47التقليدي ، لم يكن

1:05:48مستخدماً ، كان الأمر

1:05:50مختلفاً ، كما كنت

1:05:52أخبركم ، كان يتم

1:05:54التحليل ، ثم التصميم ،

1:05:56ثم التطوير ، ثم اختبار

1:05:58الجودة . هناك مشاريع

1:06:02عملت بها ، تم تطويرها

1:06:04لمدة 9 أشهر ، ثم جاء

1:06:06دور اختبار الجودة

1:06:08ليجد أخطاء في كل مكان .

1:06:11كان ملف Word يحتوي على ،

1:06:14لا أعرف ، 90 صفحة . كان

1:06:16لدينا ، لا أعرف ، كم

1:06:18عدد حالات الاختبار

1:06:19التي يجب تجربتها ؟ ما

1:06:21الذي كان يحدث ؟ مجموعة

1:06:23التطوير تلك كانت قد

1:06:25بدأت بالفعل في تطوير

1:06:27آخر ، ثم قيل لهم : "

1:06:28انظروا ، اختبار

1:06:29الجودة وجد ، لنقل على

1:06:31سبيل المثال ، 250 خطأ

1:06:33برمجياً " . يا إلهي ، هذا

1:06:35كثير جداً . لا أعرف

1:06:36ماذا أقول . كان على

1:06:38المطور بعد شهر ونصف

1:06:40أن يعود ليرى ما لديه

1:06:42في الكود ، وكان يتأخر

1:06:44كثيراً . حسناً ،

1:06:46المشروع كان يفشل هناك

1:06:48، ولهذا ظهرت هذه

1:06:49المنهجية الجديدة وهي

1:06:51منهجية أجايل ( Agile ) .

1:06:54حسناً ، من هنا بدأ كل

1:06:56شيء وتغير الأمر . منذ

1:07:01سنوات عديدة بدأ

1:07:03استخدام هذا وهو أمر

1:07:05جيد ، ومهم ، ويبدو لي

1:07:07أنني أستخدمه منذ وقت

1:07:10طويل وأستفيد منه بشكل

1:07:12جيد . لا أعرف إذا كان

1:07:18أي منكم يعمل به ، يبدو

1:07:20لي أن نعم . سمعتكم

1:07:22تذكرون موضوع

1:07:24المنهجية ، أنا أتحدث

1:07:26على مستوى واسع ، نعم ،

1:07:28على مستوى آخر ، مستوى

1:07:31عالٍ . ربما أنتم

1:07:33تعملون داخل خلية

1:07:34وترون الأمر بطرق

1:07:36مختلفة ، ولكن مع هذا

1:07:38يمكنكم رؤية كيف يعمل

1:07:40نموذج أجايل من الأعلى

1:07:42. كان هنا شخص يعمل

1:07:45بهذه الطريقة .

1:07:52>> أنا أعلم ذلك ، لكنني

1:07:54لا أتذكر .

1:07:55>> أنا من جانبي ، للتعامل

1:07:58مع شيء ما ، أستخدم "

1:08:00كانبان " ( Kanban ) .

1:08:01>> حسناً ،

1:08:02>> إنه مشروع بدأ بالفعل

1:08:04>> وهو في مرحلة الصيانة .

1:08:06نعم . ونحن نعمل على

1:08:08>> تحسينه أكثر فأكثر .

1:08:11وتعملون باجتماعات

1:08:13التخطيط

1:08:16>> والاجتماعات اليومية (

1:08:18dailies ) ، ونحن ، أي

1:08:19المطورين ، لا تصلنا

1:08:21المهام الأكثر أولوية

1:08:23، إذا جاز التعبير .

1:08:25>> ما هو دورك ؟

1:08:27>> مطور .

1:08:28>> مطور . حسناً . وهل

1:08:31الأشياء التي ذكرتها

1:08:33تحدث معك بشكل أو بآخر

1:08:35؟

1:08:36>> نعم ، نعم . أي أن كل

1:08:38فريق هو عالم بحد ذاته

1:08:40، أليس كذلك ؟ لكن

1:08:41الأمور تسير بتلك

1:08:43الطريقة .

1:08:44>> حسناً .

1:08:45>> نعم ، نعم . لهذا أسأل ،

1:08:48هل رأيت ؟ لأنه في بعض

1:08:51الأحيان تحدث هذه

1:08:53الأمور ، وحسناً ،

1:08:54أحياناً هكذا تسير

1:08:58الأمور يا شباب . يعني

1:09:00أحياناً تكون متعارضة

1:09:02، هذا الذي ... الأمر ليس

1:09:07بالخطية التي أخبركم

1:09:09بها . حسناً . حسناً ، هل

1:09:12من أسئلة ؟ معلومات

1:09:21كثيرة ، ولكن لكي نختصر

1:09:23، فهي عملية توحيد

1:09:24للمعايير أيضاً ، أليس

1:09:26كذلك ؟ لأن جميع

1:09:28الأقسام ، بكونها

1:09:29مكتوبة بلغة غير تقنية

1:09:31، بل باللغة الأصلية ،

1:09:34لنقل ، طبعاً باللغة

1:09:35الأصلية ، تفهم جميع

1:09:37الأقسام ما يتم تطويره

1:09:40في تلك اللحظة .

1:09:41>> طبعاً . نعم ، ولهذا

1:09:44أقول لكم هذا لأن ...

1:09:48>> لأن المختبر ( التيستر )

1:09:50الذي لا يعرف البرمجة

1:09:52أو لا يكتب الكود ،

1:09:54يفهم الوظيفة مباشرة .

1:09:56طبعاً . نعم . إيه ، نعم ،

1:09:59سمِّه ... لنقل سمِّه

1:10:02هكذا ، حسناً ، لكن هذا

1:10:05وراءه ... المشكلة أنك لم

1:10:07تعمل عليه ، أليس كذلك ؟

1:10:10مثل الـ ...

1:10:12>> ها ؟ نعم ، لا ، لكن لكي

1:10:14أشمل كل شيء ، لأنها

1:10:16كانت 12 شريحة عرض مع

1:10:17الكثير من المعلومات

1:10:19خلفها .

1:10:20>> نعم ، نعم . دعونا نرى ،

1:10:22الأمر أكثر من ذلك ،

1:10:24انظروا ، لقد وجدت

1:10:25واحدة ، سأريكم كيف

1:10:27سيكون هذا . لنقم

1:10:28بالأمر وكأننا في

1:10:30تدريب عملي .

1:10:32>> حسناً ، لا ترتبكوا يا

1:10:34شباب مما سترونه .

1:10:36حسناً ، انظروا ، هذه

1:10:39ستكون قصة مستخدم ( User

1:10:41Story ) . حسناً ، هذه ستكون

1:10:44من جيرا ( Jira ) . حسناً ،

1:10:46لدي هنا ملف PDF ، لكنه

1:10:48نفس الشيء . هنا سيكون

1:10:50لدينا كيف يبدو هذا .

1:10:52الأمر يتعلق بشيك

1:10:54إلكتروني . حسناً ، هذا

1:10:56نموذج لقصة مستخدم .

1:10:58كنت أقول لكم ، حسناً ،

1:11:00قصة المستخدم يجب أن

1:11:02تحتوي على وصف . حسناً .

1:11:05ونأتي إلى هنا ونجد

1:11:06الوصف . كيف أريد لكي ... ؟

1:11:10لا ، لا تحاولوا قراءته

1:11:12، سأخبركم أنا ، أي ما

1:11:14هو مفتاح هذا الأمر .

1:11:16هنا لدينا الوصف .

1:11:17لاحظوا أن الوصف

1:11:19أخبرتكم أنه يجب أن

1:11:20يكون جملة مفهومة . من

1:11:22الواضح أنكم لستم في

1:11:24المشروع ولن تفهموه .

1:11:26إذن ، ماذا لدينا بعد

1:11:28ذلك ؟ بعد ذلك لدينا

1:11:31شروط البدء ، وما الذي

1:11:33قلته لكم ، ما الذي

1:11:35يحتاجه الـ QA لتصميم

1:11:37حالات الاختبار ولكي

1:11:39يتمكن المطور أيضاً من

1:11:41تطوير معايير القبول ؟

1:11:46بما أنه عندما ... هنا

1:11:48بالطبع هذه وظيفة ، بما

1:11:50أنه يحدث كذا وكذا ،

1:11:52فهذا سيكون شرطاً آخر .

1:11:55بعد ذلك لدينا

1:11:56التفاصيل . حسناً ، هنا

1:11:59يتم شرح ما يدور حوله

1:12:01الأمر ، وبعد ذلك لدينا

1:12:03التدفق الأساسي ، وهنا

1:12:05يوجد التدفق

1:12:06والاعتبارات . بعيداً

1:12:10عن هذا ، تخيلوا أنكم

1:12:12في المشروع . تخيلوا

1:12:14أنكم ، البعض منكم

1:12:15مطورون والبعض الآخر

1:12:17من فريق ضمان الجودة ،

1:12:18وعلي أن أقول لكم : "

1:12:20حسناً يا شباب ، كم

1:12:21سيستغرق المطور من

1:12:23الوقت في هذا ؟ " " حسناً ،

1:12:25سيقولون : لا ، أنا

1:12:26أحتاج يومين لتطوير

1:12:28هذا . " " حسناً ، انتهينا . "

1:12:30ويقول مسؤول الجودة : "

1:12:32أنا أحتاج 3 أيام

1:12:33لاختباره . " " جاهز . " هكذا

1:12:36يتم إنجاز دورة العمل (

1:12:38السبرنت ) . بعد ذلك ،

1:12:40سأعرض عليكم قصة

1:12:41مستخدم أخرى وسيقول

1:12:43مدير المشروع : " يا رفاق

1:12:45، انظروا ، نحن نقترب

1:12:46من الوصول للسعة

1:12:48القصوى للفريق ولا

1:12:49يمكننا تجاوز هذا

1:12:51التطوير لأكثر من ، على

1:12:53سبيل المثال ، ثلاث قصص

1:12:55مستخدم . " " حسناً ، " هنا

1:12:58من الواضح ، حسناً ، هذا

1:13:00جزء خاص بالنظام ، أليس

1:13:02كذلك ؟ لأن من الواضح

1:13:04هنا لا أعرف ما الذي

1:13:05يحتويه ، لكن يجب أن

1:13:07يكون خاصاً بما هو

1:13:08موجود هنا : التصميم ،

1:13:10الواجهة ، المستجدات ،

1:13:12حسناً ما هي ملفات الـ

1:13:14XML هذه ؛ لا أعرف ما هي ،

1:13:15وبالطبع سنراها

1:13:17لاحقاً ، لكن هنا مثلاً

1:13:18، لدينا بالفعل إنشاء

1:13:20حالات الاختبار . ما

1:13:22الذي فعله هنا ؟ قام

1:13:24كابينو بالفعل بإنشاء

1:13:26حالات الاختبار كمهمة

1:13:28فرعية . حسناً ، هذا ،

1:13:32انظروا ، أنا أعرض

1:13:33عليكم قصة مستخدم ،

1:13:34ولهذا قلت لكم لا داعي

1:13:36للخوف يا شباب ، هذا

1:13:38كبير جداً بالنسبة لكم

1:13:39، لكن لكي تأخذوا فكرة

1:13:41عن طبيعة الحياة

1:13:42العملية . لكنكم

1:13:43ستفعلون ، نعم ، أنتم لا

1:13:45تفهمون ، نعم ، أنتم لا

1:13:46تفهمون يا شباب لأنكم

1:13:47لستم داخل فريق العمل

1:13:49ولا تفهمون طبيعة عمل

1:13:50الشركة . حسناً ، إذا

1:13:52كنتم داخل العمل

1:13:53وتفهمونه ، ستتمكنون

1:13:55من تحديد الوقت الذي

1:13:56سيستغرقه المطورون في

1:13:58التطوير والوقت الذي

1:14:00سيستغرقه المختبرون

1:14:02في الاختبار . ليس ذلك

1:14:05فحسب ، قلت لكم في

1:14:06بداية الدورة

1:14:07التدريبية إن المساق

1:14:09يشبه المروحة . أنا

1:14:14أفتحها تدريجياً ، نعم

1:14:16، أوسعها أكثر فأكثر ،

1:14:18لأنني من هنا سأتعمق

1:14:20أكثر في مجال ضمان

1:14:22الجودة وسنستكشف

1:14:23المزيد وسنرى المزيد

1:14:25من المهام اليومية

1:14:27لمسؤول الجودة ،

1:14:28وسأستمر في تقديم

1:14:30المزيد من الجوانب

1:14:32النظرية . بعد ذلك ،

1:14:36بالطبع ، من خلال

1:14:38المشاريع العملية ( TP )

1:14:40سترون الجانب

1:14:41التطبيقي . لماذا ؟

1:14:43لأنني أستخدم

1:14:44المشاريع 1 و 2 و 3 لكي

1:14:46تقوموا بالجزء العملي

1:14:48وتتمكنوا من استخدام

1:14:50المفاهيم التي قدمتها

1:14:52لكم ، أي النظرية

1:14:54وتطبيقها عملياً . هل

1:14:59يريد أحدكم التحدث ؟

1:15:06يشعرني " المعطى "

1:15:07بالدوار ، أعني ،

1:15:08بالإنجليزية لن

1:15:10يربكني ، لكن

1:15:11بالإسبانية نعم . عندما

1:15:14،

1:15:14>> بالطبع ، لو رأيته هناك

1:15:16لتجاهلته وانتقلت

1:15:18مباشرة إلى الإسبانية

1:15:20بجانبه .

1:15:21>> ولكن الأمر سيان ، كيف

1:15:23أريد أن ؟ المشكلة أنها

1:15:25تبدو غريبة ككلمة "

1:15:26مستجدات " .

1:15:27>> آه ، حسناً .

1:15:29>> حسناً ، إنه " المعطى

1:15:31عندما " ، أي أنه نفس

1:15:32الشيء .

1:15:34>> جيد ،

1:15:37>> على أي حال لم يخبرونا

1:15:38كم تستغرق السبرنتات .

1:15:40سيء ، هذا سيء ،

1:15:42>> أليس كذلك ؟ نعم موجود .

1:15:44المشكلة أنه قديم وهذا

1:15:46لم أقم به . هذا أحتفظ

1:15:48به للاختبار . هذا نعم ،

1:15:51نعم . أعني ، يجب أن يكون

1:15:53معلوماً ، لكن هذا

1:15:55البرنامج كله ، كما

1:15:57أخبرتكم ، جيرا . جيد ،

1:15:59ولكن على أي حال سنرى

1:16:01هذا لاحقاً . أسئلة ،

1:16:05استفسارات .

1:16:07>> لدي سؤال حول " Invest " .

1:16:09عندما تكون في جزء "

1:16:11صغير " ، هنا يدخل

1:16:12الجانب القابل

1:16:13للتفاوض ، أليس كذلك ؟

1:16:14لأن

1:16:15>> بالطبع ،

1:16:17>> دائماً قصة المستخدم ،

1:16:19اعذرني دائماً قصة

1:16:21المستخدم ، يجب أن تتضح

1:16:23لك عما تدور القصة . قصة

1:16:26المستخدم قابلة

1:16:27للتفاوض . إذا رأيتم

1:16:31قصة مستخدم وكأنني

1:16:33قدمت لكم قصة ، فالأمر

1:16:36ليس كذلك . في الحياة

1:16:40الواقعية يا شباب ،

1:16:42سيأتي مالك المنتج ( PO )

1:16:44بجملة من أربع ، لا

1:16:46أعرف ، 30 كلمة ويقول : "

1:16:48مهلاً ، أين معايير

1:16:50القبول هنا ؟ " " لم أضع

1:16:52لكم معايير القبول ،

1:16:54ولهذا أخبرتكم ،

1:16:55معايير القبول يجب أن

1:16:57تطالبوا بها ، وإلا لن

1:16:58تستطيعوا تقدير القصة .

1:17:00" " ما الذي يحدث ؟ " أنتم

1:17:04تقدرون شيئاً ولا

1:17:06تعرفون ما الذي يتم

1:17:07تقديره ، وسيقول مالك

1:17:09المنتج أو محلل

1:17:11الأعمال : " لكنك لم تسأل

1:17:13عن شيء الآن " ، لذا أنتم

1:17:15وقعتم في مشكلة في تلك

1:17:17اللحظة . جيد ، ولهذا

1:17:21يجب أن تكونوا يقظين .

1:17:23يجب أن تفهموا قصة

1:17:25المستخدم ، لكن لا

1:17:26يمكنكم فهمها من الألف

1:17:28إلى الياء . أعني ،

1:17:30عندما تسألون عن قصة

1:17:32مستخدم ، مهندس الجودة

1:17:34( QA ) ، دعونا نركز على

1:17:35الـ QA ، فهو في رأسه

1:17:37يتخيل بالفعل

1:17:38سيناريوهات الاختبار .

1:17:40بهذا سأقوم بعمل ، لنرى

1:17:42، حوالي 15 سيناريو

1:17:44اختبار . جيد . آه ، ما

1:17:48أقوله للشباب هو إذا

1:17:50كنتم تتخيلون خمسة أو

1:17:52ستة سيناريوهات

1:17:53للاختبار ، فأنتم

1:17:55تقللون من التقدير ،

1:17:57هذا تقدير خاطئ

1:17:58وستقعون في مشكلة يا

1:18:00شباب . من المهم جداً في

1:18:05هذا النموذج ضمن

1:18:07منهجية SHI ، أن تقوموا

1:18:09بالتقدير بشكل جيد .

1:18:14أقول لكم هذا مسبقاً ،

1:18:16يجب عليكم التفكير

1:18:18بعمق في قصة المستخدم

1:18:20عند طرحها . يسمى هذا

1:18:23باجتماع التخطيط .

1:18:26حسناً . آه ،

1:18:28>> لأنني كنت أفكر ، على

1:18:29سبيل المثال ، قد يأتي

1:18:31العميل ويقول لي : " انظر

1:18:32، أريد تنفيذ بوابة

1:18:34دفع على الموقع " .

1:18:35>> لا ، لا . وهذا شيء آخر

1:18:37كنت سأقوله لكم تالياً

1:18:39. قصص المستخدم في بعض

1:18:41الأحيان ، كما يقدمها

1:18:42مسؤول المنتج ( PO ) ، تكون

1:18:44عبارة عن خمس قصص

1:18:45مستخدم . ولكن لماذا ؟

1:18:47لأنه لا يمكن تقديرها .

1:18:49إنها طويلة جداً . كلما

1:18:52كانت أكثر تفصيلاً ،

1:18:53كان الأمر أسوأ . هنا يا

1:18:55شباب ، يجب علينا

1:18:57القراءة والتحليل ، لا

1:18:58خيار آخر أمامنا . إذاً

1:19:01، كلما كانت القصة

1:19:02أكثر تفصيلاً

1:19:04وتحليلاً ، فدائماً ما

1:19:06ستنقصها أشياء عند

1:19:07تقديمها يا شباب .

1:19:09سيتعين عليكم دائماً

1:19:11المطالبة بأشياء

1:19:12إضافية . وإذا لم

1:19:13تطالبوا بأي شيء ،

1:19:15فالمطور ومسؤول

1:19:16الاختبار ( QA ) يجب أن

1:19:18يتواصلا بشكل جيد ،

1:19:20لأنهما يجب أن يفهما

1:19:21القصة معاً ؛ فالمطور

1:19:23سيبرمجها ، والمختبر

1:19:25سيختبرها . حسناً ، ليس

1:19:27هذا فقط ، تخيلوا أن

1:19:29المشروع قيد التشغيل

1:19:31بالفعل وفي مرحلة

1:19:33الصيانة . عندما تُعرض

1:19:36عليكم قصة مستخدم

1:19:38لوظيفة جديدة ، يجب

1:19:40عليكم دمجها في النظام

1:19:42، وهنا يجب طرح عدة

1:19:44أسئلة . مهلاً ، بالنسبة

1:19:46لهذه الوظيفة ، هل يمكن

1:19:48استخراجها من هنا ؟

1:19:49إنها مختلفة . حسناً ،

1:19:51يجب عليكم تكليف مسؤول

1:19:53المنتج بالعودة

1:19:54والتحليل لأنه لم يكتب

1:19:56قصة المستخدم بشكل جيد

1:19:58. حسناً ، انتبهوا لذلك

1:20:01لأن يأتي بها ويعتقد

1:20:05أن من خلالكم أنتم

1:20:10سيتم

1:20:10>> بالطبع . وعندما يحدث

1:20:13ذلك أثناء الدورة ( Sprint )

1:20:15، لا مجال للتراجع يا

1:20:18شباب ، لأن الدورة

1:20:19ستضيع وتفشل ، تخيلوا

1:20:22أنكم تهتم ، تظهر مشاكل

1:20:24، ولم تُفهم القصة ،

1:20:26فات الأوان . الوقت

1:20:29المناسب هو اجتماع

1:20:30التخطيط . حسناً ،

1:20:34>> هذا أمر مهم .

1:20:35>> قد تغفل عن اعتمادية

1:20:37لم يخبرك بها مسؤول

1:20:39المنتج ، فتفاجأ بها ،

1:20:41وتصبح لديك وظيفتان ،

1:20:43وتتضاعف الدورة لأنك

1:20:45ستضطر للتطوير .

1:20:46>> حسناً ، ماذا يحدث هنا ؟

1:20:48لقد ضاعت دورة العمل (

1:20:50السبرنت ) . مفهوم .

1:20:52>> من ستلومون في ذلك ؟

1:20:54>> المسؤول عن ضمان

1:20:55الجودة أم الـ

1:20:57>> كلاهما . لأنه لم يفهم

1:20:59أي منهما القصة . لذلك

1:21:01أقول لكم دائماً ،

1:21:03اشربوا ثلاثة أكواب

1:21:04قهوة قبل بدء الاجتماع

1:21:06لأن عليكم أن تكونوا

1:21:07في كامل يقظتكم . عادةً

1:21:09عندما يكون الأمر كذلك

1:21:11، الكثيرون يستخدمون

1:21:12أيام الاثنين ، وبعضهم

1:21:14أيام الثلاثاء . حسناً ،

1:21:15إنه يوم يجب أن تكونوا

1:21:17فيه مستيقظين تماماً

1:21:19للقيام بذلك . حسناً .

1:21:22>> نعم .

1:21:24>> أي أسئلة أو استفسارات

1:21:26؟ حسناً ، من لم ينهِ

1:21:33العمل العملي يا شباب ،

1:21:35يمكنه إنهاؤه وإرساله

1:21:37لي . أنصحكم ، كما أفعل

1:21:40في كل فصل دراسي ، بأن

1:21:42تبدؤوا بمراجعة

1:21:44النظرية يا شباب .

1:21:47حسناً ، لكي تبدؤوا

1:21:49بالانسجام مع

1:21:50الامتحان الجزئي ،

1:21:52لأنكم إذا أردتم

1:21:53مراجعة كل شيء لاحقاً

1:21:55فسيكون الأمر كثيراً

1:21:57جداً . حسناً ،

1:22:01>> حسناً .

1:22:02>> أسئلة ، استفسارات ؟

1:22:08نعم ، هل ستؤكد على

1:22:10الفرق بين النموذج

1:22:12التزايدي و

1:22:15>> أوه ، لقد

1:22:16>> النموذج التكراري ،

1:22:17>> أليس كذلك ؟ بالنسبة لي

1:22:19هما شيء واحد . طالما

1:22:21أنكم تعرفون كيف تتم

1:22:23التكرارية ، أي دورة

1:22:25عمل للتحليل ، التطوير

1:22:26، الاختبار ، ثم

1:22:28الإطلاق للإنتاج ،

1:22:29سواء كان ذلك حسب

1:22:31الإصدار أو رقم الدورة

1:22:33، سموه كما شئتم ،

1:22:34فالأمر سيان .

1:22:36>> رائع .

1:22:39>> هل هناك أسئلة أو

1:22:40استفسارات ؟ حسناً ،

1:22:45يوم الأربعاء ، أرجوكم

1:22:47استغلوا حصة الأربعاء

1:22:48وراجعوا يا شباب ، لأن

1:22:50الأمور ستتراكم عليكم

1:22:52لاحقاً . الامتحان

1:22:53الجزئي الأول ، للأسف ،

1:22:55يحتوي على الكثير من

1:22:57النظرية يا شباب . من لم

1:22:58يقم بالعمل العملي

1:23:00يمكنه إرساله لي ،

1:23:01وسألقي نظرة عليه

1:23:03لاحقاً . حسناً ، إذن

1:23:05انتهينا اليوم . نلتقي

1:23:09يوم الاثنين وأرجوكم

1:23:10استغلوا يوم الأربعاء .

1:23:13حسناً ،

1:23:15>> فكرة يوم الأربعاء هي

1:23:17أن تراجعوا ما تم شرحه

1:23:18يوم الاثنين . هكذا

1:23:20يكون الأمر أسهل عند

1:23:21اقتراب الامتحان .

1:23:24حسناً ، هل هناك أي

1:23:26سؤال أو استفسار ؟ إذا

1:23:27لم يكن هناك ، سأترككم

1:23:29ويمكنكم الذهاب بسلام .

1:23:31>> إلى اللقاء يوم

1:23:32الاثنين .

1:23:33>> نراك يا أستاذ . شكراً .

1:23:35نلتقي .

1:23:36>> وداعاً .

1:23:37>> وداعاً . نراك . وداعاً .

1:23:40لا .