حلول تطوير البرمجيات

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

1. 1.    التحليل Analysis
2. 2.    والتصميم Design
3. 3.    التطبيق  Implementation
4. 4.    والإختبار  Testing
5. 5.    والإنهاء Production.

1. المرحلة الأولى : وهى مرحلة التحليل ويتم فيها تحليل ومعرفة متطلبات العميل ...  ماذا  يريد العميل من السيستم الذي يتم برمجته ، لازم اسمع منه كل الكلام اللي يقوله، ويتم تحويل الكلام هذا إلى ملفات يستفيد منها المبرمج الاخر.
2. المرحلة الثانية : وهي مرحلة التصميم System Design، او تصميم ملفات النظام وكيف الملفات تتعامل مع بعضها، وماهي طريقة البرمجة اللي نستخدمها
3. المرحلة الثالثة : وهي التطبيق، بناءاً على ناتج مرحلة التصميم والتحليل، اختار لغة البرمجة اللي  سوف اطبق بها وابدأ انفذ المشروع، وطبعا هذه  اطول مرحلة في المشروع كله.
4. المرحلة الرابعة :وهي اختبار المشروع من خلال معايير وهل هو سوف ينفذ الوظيفة المطلوبة منه من حيث الشكل والتنفيذ والمضمون.
5. المرحلة الخامسة والأخيرة : وهو التحول إلى Production، ومن ثم اختبار الـ Production.
6. كل مرحلة من هذه المراحل  لا تستطيع  تدخل فيها إلا لما تكون انتهيت تماماً من المرحلة اللي قبلها، يعني لا تستطيع  تدخل على مرحلة التطبيق إلا لما تكون انتهيت تماما من مرحلة التصميم Design، وهكذا مع باقي المراحل.
7. طبعا النظام هذا لدية  عيوب كثيرة اولها   كل مرحلة لاتبدأ  إلا لما تكمل المرحلة اللي قبلها، و معناه إن المبرمج  لايبدأ  يشتغل إلا اذا المرحلتين اللي قبلها يكونوا مكتملتين تماماً، طبعاً ده مضيعة للوقت.
8. العيب الثاني والخطير، وهو ان العميل لا يريد ان  يرى سيء إلا مع نهاية المشروع، لا يوجد  دخل للعميل في اي مرحلة من مراحل المشروع لأنه بالطبع لايفهم حاجة، وهذا مشكلته بالظبط ان في نهاية المشروع لو العميل فوجئ بإن النظام ليس اللي طلبه، هذه  مشكلة  كبيرة جداً، وراح نبدا  المشروع من أوله لآخره.

• سكرم (تطوير البرمجيات)

  سْكْرَمْ (بالإنجليزية: Scrum) هو أحد إطارات العمل وفقاً لمقاييس منهجية تطوير البرمجيات أجايل لإدارة تطوير المنتجات. يتميز بأنه ذو نمط تكراري وتزايدي (اضطرادي). استراتيجية تطوير المنتجات هذه تمتاز بكونها طريقه مرنة وشمولية (بالإنجليزية: holistic), حيث يعمل فريق المطورين جميعاً كوحدة واحدة من أجل تحقيق هدف محدد مسبقاً. هذه الطريقة تختلف اختلافاً كلياً عن الطريقة التقليدية التي تعتمد على التسلسل في عملية تطوير أي منتج معين بل وتتحداها.
  من أهم ميزات هذه الطريقة أنها تعطي إمكانيات كبيرة للفريق لإدارة نفسه بنفسه، وتشجع على تواجد الفريق بشكل جماعي في نفس المكان أو عن طريق التواصل الحثيث عن طريق الاتصال عن بعد (الأنترنت، الهاتف). فهناك تركيز واضح على التواصل بين أعضاء الفريق الواحد من خلال اللقاءات اليومية وجها لوجه ومن خلال المحافظة على الانضباط في جميع جوانب المشروع. طريقة السْكْرَمْ تم تطويرها من رحم تطوير تقنيات البرمجيات لكنها منفصلة تماماً عنها. يتم حالياً استعمال هذه الطريقة في مجالات عديدة.
  وهناك مبدأ أساسي لاستراتيجية سْكْرَمْ هو اعترافها أنه خلال مشروع فإن العملاء يستطيعون تغيير رغباتهم ومتطلباتهم (غالباً ما تسمى "متطلبات ملحة")، وأن التحديات غير المتوقعة لا يمكن معالجتها بسهولة بطريقة تنبؤية أو تخطيطية تقليدية.
  على هذا النحو، فإن سْكْرَمْ تتبنى مبدأ التجريبية وقبول أن المشكلة لا يمكن أن تفهم بشكل كامل أو تحدد تماماً، مع التركيز بدلاً من ذلك على تكثيف قدرة الفريق على تسليم مراحل تطور المنتج بسرعة والاستجابة للمتطلبات الناشئة.
  نشأت التسمية سْكْرَمْ من لعبة كرة قدم الرغبي، حيث ان سْكْرَمْ هو الطريقة التشكيل التي يبدأ بها لعب الفريقين بعد حدوث توقف نتيجة مخالفة بسيطة، وتكون كالآتي: يصطف اللاعبون الأماميون من الفريق مع تشابك أذرعهم منكبين ورؤوسهم إلى الأسفل، في مقابل مجموعة مماثلة من الفريق الآخر مكونين تكتل زحامي يدفع كل منهما الاخر. ثم يتم طرح الكرة في الزحام حيث يحاول كل من الفريقين كسبها الي جانبه بواسطة الركل ذهابا و ايابا بحيث يتحرك الفريق كله ككتلة واحدة.

  الأدوار في سكرم

  هناك ثلاثة أدوار أساسية ومجموعة من الأدوار الثانوية. الأدوار الأساسية يشار إليه سابقا بالبقر والأدوار الثانوية بالدجاج (كما في قصة الدجاج والبقر: ففي عجة البيض بالبسطرمة تحتاج التضحية بالبقر فدورها فيها اساسي و لكن الدجاج دوره ثانوي و ان كان كل منهما مهم.

  قائمة مهام المنتج Product backlog

  قائمة مهام المنتج Product backlog هو قائمة مرتبة من المتطلبات المحفوظة لمنتج .
  وهو يتألف من الخصائص ، الإصلاحات ، متطلبات غير وظيفية ، وما إلى ذلك كل ما يجب القيام به من أجل تقديم منتج قابل للحياة بنجاح.
  بنود قائمة مهام المنتج Product backlog Items (PBIs) هي مرتبة من قبل مالك المنتج Product Owner بناء على اعتبارات مثل المخاطرة، القيمة التجارية، الاعتماديات، التاريخ المطلوب، الخ
  عادة العناصر المضافة إلى القائمة تكون في شكل قصص المستخدم.
  قائمة مهام المنتج هو ما سوف يتم تسليمه، بالتسلسل او الترتيب الذي يجب تسليمه به.
  القائمة مفتوحة وقابلة للتحرير من قبل أي شخص، ولكن مالك المنتج هو المسؤول في النهاية عن ترتيب البنود المدرجة على القائمة لفريق التطوير للاختيار.
  تحتوي قائمة مهام المنتج Product backlog على تقييم مالك المنتج من قيمة الأعمال وتقييم فريق تطوير من جهود التنمية، والتي هي في كثير من الأحيان، ولكن ليس دائما، تذكر علي هيئة نقاط باستخدام تقييم ارقام متسلسلة فيبوناتشي .
  هذه التقديرات تساعد مالك المنتج لقياس خط زمني وقد تؤثر على ترتيب البنود المتراكمة.
  على سبيل المثال، إذا كانتا "إضافة التدقيق الإملائي" و "إضافة دعم الجدول" مهمتين لهما القيمة التجارية نفسها للعميل، فان مالك المنتج قد يقدم المهمة ذات المجهود الاقل في التطوير (لأن العائد على الاستثمار (ROI) سيكون أعلى) او يقدم تلك ذات المجهود الاعلي (لأنها أكثر تعقيدا أو أكثر مخاطرة، هو يريد أن يتخلص من هذه المخاطرة مبكرا).
  قائمة مهام المنتج Product backlog والقيمة التجارية لكل بند فيها هو من مسؤولية مالك المنتج.
  حجم كل بند من بنود قائمة مهام المنتج Product backlog(اي التعقيد أو جهد أي قدر) يحدده فريق التنمية، والذي يساهم في تحجيم البنود، سواء على حسب الصعوبة أو عدد ساعات العمل المقدرة في تطويرها.
  هناك سوء فهم شائع بأن قصص المستخدم الوحيدة التي يسمح بها في قائمة مهام المنتج Product backlog . على النقيض من ذلك، سكرم محايدة في اي تقنيات تقوم باضافة البنود. وينص سكرم على:
  البنود في قائمة مهام المنتج Product backlog تكتب بأي شكل من الأشكال مدامت واضحة ومحفوظة.
  خلافا لسوء الفهم الشائع، فانها لا تحتوي على "قصص المستخدم" و لكن تحتوي ببساطة على البنود. ويمكن التعبير عن هذه البنود كقصص مستخدم user stories، حالات الاستخدام use cases، أو أي اسلوب لذكر متطلبات أخرى يراه الفريق مفيد.
  ولكن أيا كان الاسلوب، ينبغي أن تركز معظم البنود على تقديم او اضافة قيمة تجارية للعملاء
  سكرم ينص على أن يتم تحديد دور مالك المنتج : مالك المنتج هو المسؤول عن تعظيم قيمة المنتج وعمل فريق التطوير. مالك المنتج يجمع المدخلات، ويأخذ ردود الفعل من قبل كثير من الناس، ولكنه يبني في نهاية المطاف القرار فيما يتم بناؤه. كما أنه وحده المسؤول عن إدارة قائمة مهام المنتج Product backlog .
  يتم استخدام قائمة مهام المنتج Product backlog في:
  • تحديد طلبات تعديل المنتج: هذا يمكن أن يشمل إضافة ميزات جديدة، لتحل محل الميزات القديمة، وإزالة الميزات وإصلاح المشاكل
  • ضمان ان فريق التطوير يقوم بتسليم منتج ذى قيمة تجارية تزيد من استفادة صاحب العمل
  عادة، صاحب المنتج وفريق SCRUM معا يقوما بكتابة كل ما يحتاج إليه العمل ووضع الأولويات ويصبح هذا هو المحتوى للسباق الأول sprint، ,هو كتلة العمل باطار زمني مركز على العناصر المحددة التي يمكن استيعابها ضمن هذا الإطار الزمني. هذا و يسمح لقائمة مهام المنتج أن تتطور وفقا لتطرق معلومات جديدة حول المنتج وعملائه، والعمل الجديد يدرج في السباقات المقبلة next sprints.
  تشمل قائمة مهام المنتج العناصر التالية عادة: الخصائص، والمشاكل، والعمل الفني، واكتساب المعرفة.
  في المجال تطوير الويب، وهناك التباس بين الخصائص والمشاكل bugs، من الناحية الفنية الميزة الخصائص "مطلوبات"، في حين أن المشاكل هو سمة من سمات هذا هو "غير مقصودة" أو "غير مرغوب فيه" (ولكن قد لا يكون بالضرورة شيء معيب).
  ومثال على العمل الفني : "تشغيل اختبار الفيروسات على كافة محطات العمل للمطورين".
  ومثال على اكتساب المعرفة يمكن أن يكون بند من بنود سكرم في قائمة المنتج حول البحث مكتبات وورد برس Wordpress ثم عمل اختيار.

  ادارة قائمة مهام المنتج product backlog بين مالك المنتج product owner و فريق سكرم scrum team

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

  مصطلحات

  وغالبا ما تستخدم المصطلحات التالية في عملية سكرم.
  فريق سكرم Scrum Team
  يتكون من مالك المنتج Product Owner ، سكرم ماستر Scrum Master فريق التطوير Development Team
  مالك المنتج Product Owner
  الشخص المسؤول عن الحفاظ على قائمة مهام المنتج والذي يمثل مصالح أصحاب العمل، وضمان قيمة العمل الشخص فريق تطوير
  سكرم ماستر Scrum Master 
  مسؤول عن عملية سكرم، والتأكد من أنها استخدمت بشكل صحيح , والعمل أقصى استفادة منها
  فريق التطوير Development Team
  هي مجموعة من الناس مسؤولة عن تقديم اضافات ممكنة التسليم من المنتج في نهاية كل Sprint
  Sprint burn down chart
  مستوى التقدم على مدار السبرنت
  Release burn down chart
  مستوى التقدم في البنود المنجزة من قائمةالمنتج
  Product backlog (PBL)
  قائمة مهام المنتج (PBL) قائمة المتطلبات المجملة مرتبة حسب أولوياتها
  Sprint backlog (SBL)
  قائمة الأولويات من المهام التي ينبغي الانتهاء منها خلال سبرنت
  Sprint
  فترة زمنية (عادة 1-4 أسابيع) و الذي تحدث التنمية فيه على مجموعة من بنود قائمة مهام المنتج التي التزم بها الفريق
  كما يشار إليها عادة بوصفها دورة زمنية Time-box or iteration
  Spike
  هو فترة محددة الوقت تستخدم لبحث مفهوم و / أو لإنشاء نموذج بسيط prototype.
  يمكن أن يتم الاتفاق على عقده بين دورات سبرنت أو لفرق الأكبر، يكون مقبولا اعتبارها واحدة من أهداف تسليم السبرنت.
  وغالبا ما يقدم سبايك قبل تسليم بنود معقدة من قائمة مهام المنتج من أجل تأمين الميزانية، توسيع المعرفة، و / أو إنتاج دليلا على المفهوم proof of concept.
  يتم الاتفاق على مدة والهدف (السبايك) مقدما بين مالك والمنتج وفريق التطوير قبل بداية.
  وخلافا للالتزامات سبرنت فان سبايك قد لا يسلم تطويرات ملموسة ممكنة التسليم، او وظائف ذات قيمة.
  على سبيل المثال، فإن الهدف من سبايك قد يكون الوصول بنجاح إلى قرار بشأن مسار العمل.
  ينتهي سبايك عندما يحين الوقت، وليس بالضرورة عندما يتم تسليم هذا الهدف.
  Tracer Bullet
  اطلاقة التتبع هي سبايك بالتخطيط الحالي، والتكنولوجيا الحالية، والمجموعة الحالية من أفضل الممارسات التي تؤدي إلى جودة الإنتاج. قد يكون مجرد تنفيذا على نطاق ضيق جدا لبعض الوظائف ولكن ليس عملا مؤقتا يرمى بعد ذلك . ومن جودة الإنتاج وبقية الدورات يمكن متابعة بناء هذا العمل.
  الاسم لديه أصول عسكرية من تتبع مسار رصاصة ، مما يسمح للتصحيحات.
  غالبا ما تكون هذه التطبيقات هي "لقطة سريعة" من خلال جميع طبقات البرنامج، مثل ربط حقل إدخال form's input field إلى back-end ، لإثبات ان الطبقات ستربط كما هو متوقع.
  Tasks
  المهمات Tasks تضاف إلى قائمة مهام السبرنت في البداية و مقسمة إلى ساعات.
  لا ينبغي أن تتجاوز كل مهمة 12 ساعة (يوم أو يومين)،
  ولكن من الشائع للفرق الاصرار على أن المهمة لا تاخذ أكثر من يوم لانجازها.
  تعريف منجز Definition of Done (DoD)
  تعريف منجز هو معايير لتحديد ما إذا كان بند القائمة المنتجقد تم انجازه كاملا.
  في كثير من الحالات يتطلب DoD أن جميع الاختبارات تكون ناجحة. تعريف "منجز" قد تختلف من فريق سكرم إلى آخر، ولكن يجب أن تكون متسقة ضمن الفريق الواحد.
  اللزوجة Velocity
  هي قدر الجهد الكلي الذي يكون الفريق قادرا على انجازه في سبرنت. الرقم يحسب من تقييم العمل (عادة في قصة المستخدم كنقاط) المنجز من قائمةمهام سبرنت الماضية.
  تجميع بيانات عن قيمة اللزوجة للفريق هو دليل توجيهي لمساعدة الفريق في فهم مقدار العمل الذي يمكن القيام به في المستقبل
  Impediment
  ما يمنع أحد أعضاء الفريق من أداء العمل بأكبر قدر من الكفاءة.
  Sashimi
  مصطلح يستخدم لوصف واحد أو اكثر من قصص المستخدم، موضحين انها شرائح رقيقة من خصائص المنتج
  Abnormal Termination
  المنتج المالك يمكنه إلغاء سبرنت إذا لزم الأمر.
  مالك المنتج قد يفعل ذلك مع معطيات من الفريق، سكرم ماستر أو الإدارة.
  على سبيل المثال، قد ترغب الإدارة لإلغاء سبرنت اذا كانت الظروف الخارجية تناقض القيمة المكتسبة من هدف السبرنت.
  إذا تم إنهاء السبرنت بشكل غير طبيعي، فإن الخطوة التالية هي عقد اجتماع تخطيط سبرنت الجديد، حيث يناقش سبب الإنهاء
  ScrumButاستثناء سكرم
  (أو سكرم لكن) هو استثناء من منهجية سكرم ال"نقية"، حيث يغير الفريق منهجيتة لتكيفه معها
  ScrumBag
  (أو سكرم حقيبة) يشير إلى اي شخص أو مجموعة، أو أي عوائق أخرى يمكن أن تكون عقبة.