المنهجية كمنشئ: تعليمات التجميع

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



تحت القص ، سيتحدث فيليب ديلجادو ( dph ) عن النهج الهندسي لتشكيل منهجية. جميع المشاريع والفرق مختلفة ، والقادة فريدون. تناسب منهجية واحدة للجميع لن تنجح - ببساطة لا يوجد أي منها. سيتعين علينا أخذ مصمم وبناء شيء فريد منه. في فك تشفير أحد أفضل تقارير TeamLead Conf ، لن يكون هناك أسرار سرية لرهبان شاولين - فقط التفاهات التي تم التحقق منها بالتجربة. نحن في انتظار كتالوج تفاصيل منهجية التطوير ، وما الذي يجب البحث عنه عند تصميمه وتنفيذه ، وقواعد منهجيات إعادة البناء. لجميع الأفكار ، يتم إعطاء أمثلة حقيقية من تجربة Philip. خلال حياته المهنية ، جرب كل شيء من Visual Basic إلى SQL المتشددين ، وطور أكبر محرك مراهنات في روسيا و Yandex.Money ، ويعمل الآن على مشاريع Java المحملة. تقدم بانتظام عروضاً في مؤتمرات مختلفة ، بما في ذلك HighLoad ++.

مهمة

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

كتب كنت بيك ، في نهاية كتابه عن SCRUM:

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

لذلك ، فإن أول شيء فعله هو معرفة ما تخافه من العمل .

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

مخاوف مختلفة تؤدي إلى منهجيات مختلفة. يؤدي الخوف من الدفع الزائد إلى توظيف مطورين رخيصين يسهل تغييرهم - إنه SCRUM. الخوف من الخطأ يؤدي إلى GOSTs أو RUPs مع مجموعة من الوثائق الرسمية.

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

بالإضافة إلى المخاوف ، لدى رجال الأعمال رغبات لأي أغراض لتحسين العمليات:

• بسرعة.
• رخيصة.
• يمكن التنبؤ بها.
• بطريقة محكومة ؛
• الجودة؛
• قابلا للتطبيق؛
• haypovo.

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

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

بالإضافة إلى رغبات العمل ، تحتاج إلى معرفة القيود الهامة.

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

إنها القيود الأساسية التي تميز ، على سبيل المثال ، عمليات FixPrice عن عمليات Time & Material.

في مشروعنا لنظام الدفع ، كما اتضح فيما بعد ، كان مخيفًا أن نفعل وقتًا طويلًا وأن لا نخاف ، ومخيف من حيث الموثوقية والأمان ، لكن من المستحسن القيام بكل شيء بسرعة. في الوقت نفسه ، لا توجد منتجات في بداية العمل ، ولا يوجد مطورون ، لكن يوجد متخصصون في مجال الموضوع (على سبيل المثال ، أنا). فقط كبيرة ومستقلة تماما عن كل كتل أخرى واضحة: المعالجة ، والعملاء ، والتكامل ، والمكتب الخلفي والمكتب الأمامي.

بعد معرفة الأهداف والقيود ، يمكنك البدء في بناء منهجية ، لفهم بالضبط كيف سنطور النظام المرغوب - على الأقل في المرحلة الأولى.

نحن نبني منهجية لبدء المشروع

ولكن ما هي التقنية؟ ماذا نريد أن نبني بشكل عام؟ الإجابة على الأسئلة هي صورة جميلة أليستير كوبر مع مجموعة من النقاط.



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

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

اختيار القطع الأثرية

نحن نأخذ المخاوف ونفهم ما هي القطع الأثرية التي تقلق المخاوف.

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

نحن تشكيل العمليات

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

نتيجة لذلك ، هناك عمليتان بالضبط: تحديد مهمة كبيرة - التفكير في حل ما ، والتحقق من ما تم إنجازه . هذه العمليات طويلة وبحوثية وترتبط قليلاً مع بعضها البعض ، مما يؤدي إلى ممارسات التنمية المناسبة.

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

---

التراجع: عن التوظيف

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



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

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

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

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

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

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

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

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

كلما ارتفع مستوى المرشح ، قلت المقابلة.

ما الناس الآخرين التي تحتاجها؟

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

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

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

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

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

تم الاستعانة بمصادر خارجية لقاعدة البيانات بنجاح. تعجبني حقًا فكرة "أخذ الكفاءات في قاعدة البيانات في مكان ما خارجها" - العثور على مثل هذا الشخص في فريق العمل عادة ما يكون غير واقعي إذا لم تكن لديك شركة ضخمة ، ويطلب من 5 أشخاص على الأقل دعم قاعدة بيانات مهمة 24 * 7. نحن أيضًا قمنا بالتعاقد الخارجي مع DevOps Guru ، ولكن ليس بنجاح ، هذا الدور أكثر صعوبة بالنسبة لفناني الأداء الخارجيين.

تم شغل الأدوار الاجتماعية أيضًا (وكان هناك بعض النقاد).

---

ممارسة

لذلك ، اكتشفنا التحف اللازمة ، واكتشف ما يحتاجه الناس وما متطلبات العملية. ما حدث ، كيف بالضبط تنظيم التنمية:

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

عندما يتحدث الناس عن أساليب مماثلة وغير رسمية للغاية ، فإنهم يقولون ببساطة: " لدينا رشيقة".

كما حصلنا على الكلاسيكية "لدينا رشيقة". لكنني فهمت بوضوح سبب هذا الأسلوب ولماذا كان "رشيقًا" ، وليس شيئًا أكثر تحديدًا وتعقيدًا. وأنا (والأعمال) ، كانت هذه التقنية مناسبة تمامًا.

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

---

الانحدار: مصفوفة بورن

في عام 1980 ، رسم أليستير كوبرن مصفوفة عن تعقيد المشروع .


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

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

دعونا نحاول وضع نظام الدفع لدينا في هذه المصفوفة. المصفوفة مريحة للغاية كنموذج لفهم التعقيد المقدر لمشروعك ، نظامك.

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

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


لدينا فريق من حوالي 20 شخصًا ، لذلك ندخل في ميدان E30 . هذا أمر سيئ ، لأن مثالًا جيدًا على التقنية في هذا المربع هو عملية Rational Unified الكاملة - العمليات الرسمية ، العديد من الوثائق ، البيانات الواضحة. 20-30 الناس لا يستطيعون التعامل مع هذا. عليك استئجار 50 ، وسوف تنمو الصعوبة مثل كرة الثلج. عادة ما تتم كتابة أنظمة مماثلة في مثل هذه المنهجيات من قبل مئات الأشخاص أو أكثر.

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

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

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

لكن هذه الأجزاء قليلة. لذلك ، فإن مصفوفة Cowbern للمشروع هي كما يلي.


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

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

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

---

لتلخيص

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

هذا مخطط تصميم هندسي كلاسيكي: لدينا متطلبات ، ثم حددنا الهيكل ، ثم برمجناه.

أساليب التصميم هي ممارسة هندسية ، وهي عملية هندسية لا تختلف عن برمجة وحدة نمطية.

ممارسات المرحلة الأولى

القليل من الممارسة لصرف الانتباه عن النظرية إلى الواقع.

الحق في "لماذا؟"

هذه هي ممارستي المفضلة.

يحق لكل موظف أن يسأل عن أي مهمة: لماذا تفعل ذلك ، لماذا تفعل ذلك بهذه الطريقة ، ومن يحتاج إليها على الإطلاق؟

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

لا تعمم على ثلاثة

, . , , .


— , , . — — , . , , .

IDE Driven Development

JetBrains — ! , IDE.

, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .

, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .

. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .

, — , . : , ,

, : . . .

• . , , .
• . , , , , - .
• . 3 -, , , , . , .
• . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .

.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .

— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?

Planning poker . « » — . , , . Planning poker , .

. :

• ;
• product owner ;
• ;
• .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?

, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

• ;
• ;
• .

.

: , , .

Jira , « » ? - -? ?


, , . , junior product manager — , , , .

, — . . , . — !


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

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

كيفية تغيير المنهجية وليس قتل المشروع

لذلك ، في 9 أشهر قمنا بتغيير 3 طرق: "لدينا رشيقة" ، SCRUM ليوم واحد وكانبان. كيفية التأكد من أنك لا تفقد الموارد؟ كيفية تغيير المنهجية على الإطلاق ، وليس قتل المشروع في نفس الوقت؟

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

الشيء الرئيسي هو أن نفهم متى يتغير.

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

إذا فكرت "كيف". إذا فهمت كيف ستأتي من النقطة أ إلى النقطة ب ، فقم بالتغيير. حتى تأتي مع - لا حاجة.

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

تدريب

نبدأ مقدما. بالنسبة لفريق صغير ، يبدأ الإعداد قبل شهر من التغيير.

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

على سبيل المثال:

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

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

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

عندما يكون لديك بالفعل قصص مستخدم ، يمكنك البدء في تحويلها إلى ممارسات.

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

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

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

اختيار الأدوات

تحدد الأداة الميزات . هناك رأي شائع بأن الأدوات ليست مهمة ، أو أن أي أداة مناسبة - هذا هراء.

إذا كانت الأداة غير مريحة للاستخدام ، فلن يتم استخدامها.

علاوة على ذلك ، الباعة يكذبون دائما. إذا قالوا إن أداتهم يمكن أن تفعل "1 و 2 و 3" ، فعلى الأرجح لن يتمكنوا من فعل "1" و "2" أحيانًا و "3" ، لكن ذلك سيء جدًا. تأكد من التحقق من كل شيء.

نحن نناقش بنشاط

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

في هذه المرحلة ، قد يظهر الأشخاص تجربة سلبية سابقة من خلال إدخال تقنيات أخرى.

- آه ، هراء! كان لدينا بالفعل هذا ولا شيء جاء منه.

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

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

لسوء الحظ ، لا توجد حلول عالمية. بناء على وضعك.

مقدمة من

القيمة الرئيسية في إدارة تكنولوجيا المعلومات هي الاحترام.

نحن نوفر وقت شخص آخر . إذا كنت بحاجة إلى نقل المهام من نظام تعقب واحد إلى آخر - كتابة برنامج نصي ، فقم بتوظيف Mechanical Turk للقيام بذلك نيابة عنك. حل هذه المشكلة حتى لا ينقل المطور جميع مهامه من نظام إلى آخر لمدة أسبوع - وهذا مظهر من مظاهر الاحترام.

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

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

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

قبلة اجعل الأمر بسيطًا ، على الأقل في البداية. لا تبالغ.

دعم

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

استنتاج

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

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

تغيير المنهجية هو مشروع سمارت الكلاسيكي . استخدم كل ما تعرفه عن إدارة المشروع: تحديد معايير النجاح ، والتحقق في نهاية الامتثال لمجموعة المهام ، وتذكر الوقت المحدود ، إلخ.

بلدي البيان الشخصي

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

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

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

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

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

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

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

في لجنة برنامج TeamLead Conf ، نحن أيضًا أكثر دراية بنظام Lego القديم ، لذلك نختار مكعبات في البرنامج يمكنك من خلالها بناء العمليات التي تناسبك. بالنسبة لمؤتمر الخريف في سان بطرسبرغ ، تم بالفعل تجميع مجموعة مكونة من 15 جزءًا ، لكننا ما زلنا نقبل طلبات التقديم - الكتابة .