كتاب "رشيقة نقية. أساسيات المرونة

مرحبا ، هابروجيتلي! لقد سلمنا إلى دار الطباعة حداثة أخرى! لقد مر ما يقرب من عشرين عامًا منذ ظهور البيان الرشيق. أدرك روبرت مارتن الأسطوري (العم بوب) أن الوقت قد حان للتخلص من الغبار من مبادئ أجيل ، ومرة ​​أخرى للتحدث عن النهج المرن ليس فقط للجيل الجديد من المبرمجين ، ولكن أيضًا للمتخصصين من الصناعات الأخرى. كان مؤلف كتب "Clean Code" و "Ideal Programmer" و "Clean Architecture" ، التي كان محبوبًا لدى موظفي تكنولوجيا المعلومات ، من أصول Agile. تزيل Pure Agile سوء الفهم والارتباك الذي جعل استخدامهما أصعب من الخطة الأصلية على مدى سنوات وجود Agile. في الأساس ، إن Agile هي مجرد مجموعة صغيرة من الأساليب والأدوات التي تساعد الفرق الصغيرة من المبرمجين على إدارة المشاريع الصغيرة ، ... ولكنها تؤدي إلى نتائج رائعة ،لأن كل مشروع كبير يتكون من عدد كبير من الطوب. خمسة عقود من العمل مع مشاريع من جميع الأنواع والأحجام التي يمكن تخيلها تسمح للعم بوب بإظهار كيف يجب أن يعمل Agile بالفعل. إذا كنت ترغب في فهم فوائد Agile ، فلا تبحث عن طرق سهلة - فأنت بحاجة إلى استخدام Agile بشكل صحيح. يخبرك Pure Agile بكيفية القيام بذلك للمطورين والمختبرين والمديرين ومديري المشاريع والعملاء.

مقتطفات. أول شيء يجب معرفته

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

في الوقت نفسه ، يمكن أن تتغير المتطلبات في دفق مستمر لا يمكن إصلاحه.

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

تختفي بعض القديمة. تتغير واجهة المستخدم بسرعة - في غضون أسابيع ، إن لم يكن في أيام.

هذا ما يبدو عليه عالم تطوير البرمجيات. في هذا العالم ، يتم تحديد المواعيد النهائية ، وتتغير المتطلبات باستمرار. وبطريقة ما ، في سياق كل هذا ، يحتاج المطورون إلى إكمال المشروع بنجاح.

مجموعة

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

كان الأول من مايو. دعا مدرب كبير مرؤوسين إلى غرفة الاجتماعات.

بدأ الرئيس: “لدينا مشروع جديد. من الضروري الانتهاء منه في الأول من نوفمبر. ليس لدينا متطلبات حتى الان. سيتم الإعلان عنها في الأسبوعين المقبلين. كم من الوقت سيستغرق لتحليل المشروع؟ "

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

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

تمتم شخص ما بتساؤل: "شهرين؟" اعتبر الرئيس موافقته على الشروط: "عظيم! فقط ما كنت أفكر فيه. أخبرني الآن كم يستغرق التصميم؟ "

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

"هذا صحيح! - ابتسم الرئيس الكبير بإشراق. - كما اعتقدت. ولدينا شهرين متبقيان للتنفيذ. شكرا للجميع ، أنت حر! "
ربما تذكر العديد من القراء أن شيئًا كهذا حدث لهم بالفعل. من لم يكن لديه هذا ، أنت محظوظ!

مرحلة التحليل

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

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

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

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

ثم في الأول من يوليو تحدث معجزة. اكتمال التحليل.

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

مرحلة التصميم

ماذا تفعل الآن؟ بالطبع ، سنقوم بتصميم. لكن ما هو التصميم ؟

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

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

ثم تحدث معجزة جديدة. في الأول من سبتمبر ، أكملنا التصميم فجأة. و لماذا؟ نعم لأن. الأول من سبتمبر. وفقًا لجدول العمل ، كان يجب أن نكون قد انتهينا بالفعل. لا حاجة للتردد.

لذا طرف آخر. بالونات وخطب. وننتقل إلى المرحلة التالية - التنفيذ.

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

لا توجد طريقة موضوعية لمعرفة ما إذا كانوا محتجزين في الواقع. لذلك ، اتضح استكمال هذه المراحل في الوقت المحدد.

مرحلة التنفيذ

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

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

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

في حوالي 15 أكتوبر ، قال أحدهم ، "ما هو تاريخ اليوم؟" متى تأخذها؟ " ونفهم هنا أنه لم يتبق سوى أسبوعين ولن ننتهي أبدًا بحلول الأول من نوفمبر. وفجأة ، وللمرة الأولى ، اكتشف عملاؤنا أن هناك بعض المشاكل في المشروع.

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

وهم على حق ، أليس كذلك؟

ماراثون البقاء

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

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

أسميها الانتفاخ خارج نطاق السيطرة. سنعمل بشكل أفضل في المرة القادمة باستخدام طريقة لا تعمل.

»يمكنك الطلب المسبق على الموقع الإلكتروني للناشر.

عند دفع النسخة الورقية من الكتاب ، يتم إرسال pdf إلى البريد الإلكترونيبأول 105 صفحات من الكتاب.