مرحبا بالجميع! أردت اليوم أن أتحدث عن عمليات التطوير. مع نمو الشركة ، لا تتطور الأعمال نفسها فحسب ، بل تتراكم المشكلات أيضًا ، لا سيما أثناء عملية التطوير. غالباً ما يحاولون حلها عن طريق إدخال بعض الممارسات والمنهجيات الجديدة الفتية. للأسف ، فإن إعادة التنظيم القسري للعملية وفقًا للكتب والدورات التدريبية غالبًا ما تؤدي إلى مشاكل أكبر - تسخر من الناس.
لقد تحدثت مؤخرًا في مؤتمر
Saint TeamLead Conf 2019 ، في تقرير تحدثت عن كيف تمكنت من العثور على عدد من المشكلات في سير العمل ومن ثم التغلب عليها تدريجياً. سأحاول هنا وصف أفضل الممارسات التي ساعدتني ليس فقط على إنشاء سير عمل ، ولكن أيضًا للتوقف عن الاستهزاء بالمطورين. لقد غير الموظفون موقفهم تجاه الشركة ككل وعملية العمل.
تحديات عملية التنمية
لذلك ، عندما لم تثمر المقاربات الجاهزة عن نتيجة ، وكنا على وشك الإحباط ، بدأت في تحليل العمليات وبدأت بتحليل كل شيء بالعظام. والنتيجة قائمة بالمشكلات:
- إن مجلس الإدارة مثقل بالمهام - كانت هناك فوضى حقيقية عليه. عند النظر إلى اللوحة ، كان فهم العمليات شبه مستحيل.
- لم تكن هناك تقييمات طبيعية - لم نكن نعرف كيفية إجراء تقييم صحيح للمهام وفقًا للمهلة الزمنية ، وبسبب هذا ، كانت المواعيد النهائية في طريقها إلى العمل ، وأصبح قادة الأعمال قيد التطوير.
- كنا نحدد باستمرار المواعيد النهائية - لا يمكننا أن نقول بالضبط متى ستنتقل الميزة إلى الإنتاج ، وغالبًا ما قمنا بتطبيقها في وقت متأخر كثيرًا عما كان مخططًا له بسبب عوامل خارجية ، على سبيل المثال ، لجأ العمل وطلب منا القيام ببعض الميزات العاجلة في المقام الأول.
- لم يكن هناك فهم لكيفية تسريع عملية التطوير - توظيف أشخاص جدد وتحميل المهندسين بنسبة 100٪ لا يجعل العملية دائمًا أسرع.
- التخطيط والمهام العاجلة - إذا كان من الممكن ، مع المهام الحالية ، وضع الخطط والإشارة إلى التواريخ التقريبية ، فالمهام العاجلة التي عادةً ما تطير من العمل تخطت جميع الخطط.
- الاجتماعات تستغرق وقتًا طويلاً - خطأنا الأكثر شيوعًا: لا يعمل شيء ما أو نحتاج إلى تحديد أولويات المهام - ودعنا نجتمع ونناقش. أو اجتماعات منتظمة ، حيث جلس المطورون لمدة ساعة أو ساعتين ولم يفهموا ماذا كانوا يفعلون هناك.
- مشكلة تحفيز ومشاركة الفرق - غالبًا ما تم إسقاط بعض العناصر من قبل السلطات من أعلى ، دون أن يسأل عن رأي فريق التطوير ، هذا لم يرسم الأجواء في الفريق.
في الواقع ، فإن مهمة أي قائد ، سواء كان TL أو CTO ، هو أنه ينبغي أن يصبح الرابط بين الأعمال التجارية والتنمية.
للخروج بطريقة ما من هذا الموقف ، تحولنا إلى طريقة كانبان. ماذا يقول لنا؟ دعونا تحسين ما هو بالفعل هناك. حسنًا ، ذهبنا لتحسين عملية التطوير لدينا.
وضع النظام على السبورة
بدأنا في المجادلة: إذا أكمل المساندون مهمتهم وسلموا إلى الواجهة الأمامية ، فهل سيبدأون على الفور؟ بالنظر إلى السبورة ، هذا غير مفهوم. وفقًا لمبادئ Kanban ، قمنا بتقسيم كل اتجاه من مجالات التطوير (كان لدينا 5 منها: الواجهة الخلفية ، الواجهة الأمامية ، DevOps ، QA والتصميم) إلى عمودين: Do and Done. أصبحت المشكلة على الفور واضحة: عرض النطاق الترددي لدينا لا يسمح لنا بالقيام بالعديد من المهام التي يريدونها منا.
يقول Kanban أيضًا: دعنا نقدم حد
WIP ونحد من عدد المهام. كيف يمكننا وضع حدود؟ تجريبيا. بالطبع ، لقد فاتتهم عدة مرات ، لكنهم التقطوها حتى لا نضطر إلى تجميع المهام في أضيق مكان. هناك ربح إضافي من WIP-limit هو أحد المشغلات ، والذي يقول إنه بمجرد أن تنجزنا المهمة ، يمكننا أخذ ما يلي. هذا هو نوع من نظام السحب.
ماذا أدى هذا إلى؟ بدأ المهندسون أكثر اهتمامًا بالمهام ، لأنه عندما يتعذر عليهم حل مشكلة ما ، يتم وضع مانع عليها. لا يمكن القيام بالمزيد من المهام ، نظرًا لوجود حد WIP ، يجب على المهندسين الانتظار حتى يساعدوا في حلها. هناك فرصة للبقاء دون مهام.
عندما بدأنا في تحليل مشكلة إعادة المهام بالتفصيل ، اتضح أن كل شخص يقوم بها بشكل مختلف ، على سبيل المثال ، شخص ما يكتب الاختبارات ، ولا يقوم شخص ما بذلك. كانت هناك قواعد في هذا الصدد ، ولكن تلك التي خذلتها السلطات. لم يحلوا مشكلة المطورين. قدمنا قواعد جديدة (
تعريف Done ) ، والتي يتم دمجها في المجلس. يمكن أن تعمل على حد سواء في بعض الأعمدة ، وعلى نوع البطاقة. على سبيل المثال ، بالنسبة لواجهة برمجة التطبيقات ، تحتاج إلى الواجهة الخلفية لتوثيق جميع الطرق والأشياء. كانت القواعد في متناول الجميع ومرئية على السبورة ، والأهم من ذلك أنها جاءت من المهندسين أنفسهم وحلوا مشكلاتهم. إذا لم يتم القيام بشيء ما ، رأى المهندس ذلك وذهب للقيام بذلك.
مهام الصف
لم نكن نعرف كيفية تقييم المهام بحلول المواعيد النهائية ، ويخبرنا كانبان: "لا توجد تقديرات". ما يجب القيام به نحن تراكمت الإحصاءات وبنينا مثل هذا الجدول الزمني. هذا هو المخطط الطيفي ، واعتماد عدد من المهام في الوقت المحدد.
بدأنا في دراستها ، ورأينا على الرسم البياني 3 قمم تتوافق مع ثلاثة أنواع من العمل. بناءً على هذه الأنواع ، تم وضع تصنيف ومعايير لمثل هذا العمل. لقد قدمنا هذه الأنواع في لوحة المهام ، ثم قمنا بإضافة قواعد إضافية لكل عملية. حصلنا على ما يلي:
اتفقنا مع العميل ، أي مع الشركة ، على اتفاقية جودة الخدمة (SLA). يأتي المدير إلينا ويسأل: "وكم ستجعل هذه الميزة؟" لا يمكننا تحديد مقدار ما سنفعله بالتأكيد ، ولكن يمكننا أن نقول كم من الوقت سوف يتم إنفاقه على مجموعة كاملة من هذه المهام. لم تكن هناك حاجة لبوكر scrum ، وتوقفنا عن تعذيب الناس بأسئلة التوقيت. لقد ألقينا نظرة على الإحصائيات ودعانا إلى تواريخ العمل.
بالطبع ، كان هذا النهج أيضا عيوب. على سبيل المثال ، لم ينجح هذا مع المهام من نوع جديد ، والتي ببساطة لم يكن لدينا إحصاءات. لقد تظاهروا بأنهم كانوا بطرق قديمة ، لكنهم جمعوا بعد ذلك كمية كافية من البيانات وظهرت هذه المشكلة بلا معنى.
ثم واجهنا حقيقة أن بعض المهام بدأت تقع في أنواع أخرى من العمل. لقد أجرينا القليل من الأبحاث ووجدنا أن بعض المهام تم تنفيذها بشكل أسرع ، لأن الشركة وعدت الشركاء هناك بشيء وطلبوا من المطورين القيام بها على وجه السرعة. وكانت بعض المهام على العكس ليست مهمة ، فقد تم تأجيلها. لذلك لدينا أولويات ، أي الاتفاقيات المتعلقة بفئات خدمة الخدمات (CoS) ، وضعناها على السبورة. وحتى لا يسيء العمل إلى الشركة ولا يضع إلحاحًا متزايدًا لجميع المهام ، فقد تم إدخال حدود WIP الأفقية.
كيفية تسريع التنمية
تحولت مرة أخرى إلى إحصاءات تعقب المهمة. لقد وجدنا أن العديد من المهام معلقة على اللوحة تحسباً للتحسينات أو الفحوصات أو البيانات الإضافية ، أي أنها أدركت أنه يمكن تسريع عملية التطوير. لقد بدأوا في النظر في عدد المهام المتراكمة ، ومقدار الخمول ، ووجدوا أن بعض الميزات تم تطويرها أقل مما توقعوا القبول. قررنا تحديد يوم لقبول الميزات ، وتم تقليل وقت إصدار المهام. ثم قمنا بتثبيت القرص المضغوط (التسليم المستمر) وبدأنا في إرسال الإخطارات.
أصبح من الواضح أننا نحتاج إلى أداة لتقييم تحسيناتنا. قررنا استخدام مخطط التدفق التراكمي. باختصار ، كيف تم بناؤه: نخصص لونًا لكل مركز عمل (الأعمدة الموجودة على اللوحة) ، ونأخذ إحصائيات عن عدد العناصر (المهام) الموجودة في وحدة زمنية في عمود ، ونرسمها على الرسم البياني ، ونضعها تحت الآخر. على الرسم البياني ، محور X هو الوقت ، والمحور Y هو عدد المهام.
ماذا حصلنا من هنا؟ من السهل هنا رؤية مهلة (وقت الإنتاج) - الخط الأفقي (عرض التدفق على طول المحور X) يبدأ ببيان المشكلة ويصل إلى مرحلة الاستعداد. وبالتالي ، يمكنك هنا رؤية كيف تمر المهمة بكل مراحل التطوير - يتقاطع الخط مع كل الألوان ، كل منها يتوافق مع مرحلته. وأيضًا الحد الأقصى للوحة WIP - ارتفاع التدفق على طول المحور Y. كيف تزيد سرعة التطوير؟ يمكنك تقليل حد WIP (أي جعل التدفق على الرسم البياني أضيق) ، أو يمكنك جعل التدفق الخاص بنا ، الموجه من الأصل إلى الركن الأيمن العلوي من الرسم البياني ، يميل إلى الارتفاع أكثر (أي لرفع اتجاه التدفق لأعلى ، تقليل زاوية لها بالنسبة للمحور Y). لتوجيه التدفق نحو الأعلى ، يمكنك تقديم بعض الممارسات الجديدة ، على سبيل المثال ، تطبيق Docker أو إنشاء قاعدة معرفة مريحة. لا يجب أن يكون هذا ابتكارًا تقنيًا ؛ يمكن أيضًا أن يكون للنهج الجديد في الإدارة تأثير كهذا.
وبالتالي ، حصلنا على أداة أظهرت بوضوح أي تحسينات تعمل وأيها لا تعمل.
تخطيط الأعمال ، مهام عاجلة وغير مجدية
كان تخطيط تطوير الأعمال أكبر ألم. ماذا فعلنا؟ بعد تلقي المهمة من العمل ، تم عقد اجتماع بين المحلل والمطور ، حيث تم تحليله ، وحلول المطور المقترحة. ونتيجة لذلك ، فهمنا مقدار الموارد المطلوبة وما هي الموارد المطلوبة. وعندها فقط وضعت الشركة دون مشاركتنا خططها ونظرت في مدى إمكانية إطلاق الميزات. في كانبان ، وهذا ما يسمى
إيقاع التجديد .
وبشكل نسبي ، فإننا نخصص فتحات بحجم معين ، وفقًا لحدود WIP ، حيث يمكنك وضع المهام. تحتوي كل فتحة على عدد محدود فقط من المهام. بطريقة أخرى ، تسمى هذه الطريقة "تخطيط الكأس".
لقد صنعنا أداة بسيطة للأعمال (جدول في Excel) ، والتي يمكن أن تخطط بصريا. قاتل المديرون فيما بينهم ، وجادلوا بأن مهمتهم أكثر أهمية ، ثم أتوا إلينا وأعطوا المهام للتطوير.
نظرًا لأن لدينا قيود بالفعل ، كان العمل أكثر اهتمامًا باختيار المهام ، واختار أهمها ، ولم يغرقنا بأي هراء حدث لهم. إضافة واحدة كبيرة: لقد اختاروا المهام بأنفسهم دون مشاركتنا ، دون صرف انتباه المطورين عن الاجتماعات ، لقد عملوا بهدوء ولم يقضوا وقتًا في الاجتماعات.
كما وجهنا انتباهنا إلى مشكلة المهام العاجلة. بدأوا في تحليل الإحصاءات المتعلقة بهم وأدركوا أن هذه المهام ليست ملحة للغاية. على سبيل المثال ، نحتاج إلى ترويج للتغيير الموسمي للعجلات من سائقي السيارات. نحن نعلم أن هذا يحدث دائمًا مرتين في السنة. بمجرد تكرارها ، دعونا نحتفظ بفتحات لمثل هذه المهام على اللوحة مسبقًا. لن يكون هناك شيء عاجل - سنأخذ مهمة أخرى من قائمة الانتظار ، ولن نبقى بدون عمل. نتيجة لذلك ، وجدنا أن 60 ٪ من المهام العاجلة ليست في الواقع عاجلة.
كانت هناك مشكلة أخرى. غالبًا ما رأينا ميزات ، والتي رفضت العمل في النهاية ، لأنها تحولت إلى فائدة من وجهة نظر العمل. اقترحنا أن تقوم الشركات بميزات MVP تتطلب وقتًا أقل عدة مرات من التطوير التقليدي. بدأت إزالة الملاحظات بشكل أسرع ، وبدأ المهندسون يدركون أن هذه كانت تجارب. في السابق ، عندما أُلقيت أسابيع من العمل في سلة المهملات ، شعروا بالقلق ، فقد سمموا حياتهم.
لقد بدأنا في اختبار 85٪ من الميزات بطريقة تمكنت في النهاية من توفير الكثير من الوقت ، ثم قضيناها في فرضيات تم اختبارها في الممارسة العملية. لقد جلبوا بالفعل أموال الشركة. أيضًا ، إذا حدث خطأ ما في هذه العملية ، يمكن لعميل الميزة من العمل إجراء تصحيحات في مرحلة مبكرة ، وليس خلال دورة التطوير بأكملها.
ونتيجة لذلك ، تم اكتشاف هذه الحقيقة التي لا تعمل جميع الأفكار. وبما أنهم لا يعملون ، فلا تعملهم. منذ ذلك الحين ، توقف المطورون عن العمل في عمل القرود ، وفعلوا ما تجلبه الشركة بالضبط.
اجتماعات
لقد أدت التحسينات التي أدخلناها في ذلك الوقت إلى مقتل عدد من الاجتماعات غير المجدية. لم تعد مناقشات تحديد الأولويات ، نظرًا لأننا قدمنا هذا إلى العمل ، فقد خططنا أيضًا دون مهندسين. كما تخلينا عن مداهمات المديرين التي استغرقت خمس دقائق بطلب "المساعدة السريعة". كان هناك فقط اجتماعات ضرورية حقا. قدمنا أيضًا القاعدة التي تقضي بتحديد الاجتماعات الآن لفترة محددة حتى يتمكن الجميع من التخطيط لجدولهم الزمني.
نتيجةً لذلك ، تم تحويل جميع الاجتماعات حول علم boltology إلى أنواع الاجتماعات التالية:
- عندما يرغب المحلل في مناقشة مشكلة معينة مع مهندس ، على سبيل المثال ، لإيجاد الحل الأمثل أو التحلل ؛
- عندما يكون هناك شيء عالق على السبورة. في هذه الحالات ، اجتمعنا وسرنا على طول اللوحة من اليمين إلى اليسار ، وسألنا المهندسين عما حدث ، ومن يمكنه المساعدة. من المهم أننا انتقلنا من المهام ، ولم نحاول حساب ما يفعله الناس ؛
- عندما خططوا لمهام العدو (إيقاع للتجديد) ؛
- عندما أخذوا الميزات ؛
- اجتماعات بين فرق التطوير ، على سبيل المثال ، عند مناقشة تنسيق واجهة برمجة التطبيقات أو تحديد الأحداث المراد إرسالها.
النقطة الأساسية: لقد دعينا إلى اجتماعات فقط أولئك الأشخاص الذين شاركوا مباشرة في موضوع المناقشة ، ولم يتصلوا بمستمعي المرشحين ، كما كان من قبل. لقد غيّر المهندسون بشكل أساسي موقفهم من الاجتماعات ، قبل أن لا يعجبهم ، ولكن الآن هو العكس ، يبدو أنهم ضروريون ومفيدون لهم.
فريق الدافع والمشاركة
كل ما قمنا بتنفيذه: أدت حدود WIP ، وتقييم المهام بناءً على الإحصاءات ، ورفض المهام غير المجدية ، وما هو موضح أعلاه ، إلى توفير وقت للمهندسين. ماذا سيفعلون الآن؟ أكبر فكرة خاطئة هي أن أحدا لن يفعل أي شيء. لقد سمعتُ نفسي مرارًا وتكرارًا من الرجال: "كنت سأعيد تشكيل هذا الكود ، وإلا فإن ساق الشيطان ستنهار". نعم ، في البداية يحصل المهندس حقًا على قسط كافٍ من النوم والراحة لمدة 2-3 أسابيع ، ثم ماذا؟ يجلس بدون مهام ، ويبدأ في الاتصال بزملائه باقتراح المساعدة ، ويساعد على إكمال المهام ، ثم يجلس الاثنان بالفعل بدون مهام. "دعنا نرسل إصلاح الخلل" - العمود مع الخلل كان فارغًا. "أرسل الرمز الذي سنقوم بإعادة تشكيله" - أصبح الرمز أسرع في الكتابة ، ويمكن زيادة حد WIP. ثم يبدأون في تنفيذ CD / CI ، كتابة قاعدة المعرفة. ماذا حدث يبدأ المهندسون في القيام بالكثير من الأشياء المفيدة ، والتي لم تصل إليها أيديهم. هذه هي السرعة التي تريدها الشركة ، لكن لسبب ما لا يمكنها الحصول عليها من أي شخص. في السابق ، كان المهندس غاضبًا ، أراد أن يكون الجميع وراءه ، والآن تغير النموذج الإنساني إلى: "الآن كيف يمكنني مساعدتك؟" زاد عدد المبادرات ، وكلها جاءت من الأسفل ، وليس من أعلى. وفي النهاية ، اتضح أنها أكثر فائدة.
ملخص النتائج
- تمكنا من العثور على عنق الزجاجة في النظام وفهم أننا لا نستطيع أن نفعل أكثر مما نستطيع.
- توقفوا عن رمي المطورين العمل عديمة الفائدة وتحرير الوقت لمزيد من المهام المفيدة.
- عندما لم يكن لدى المهندسين ما يفعلونه ، بدأوا في تقييم المهام بشكل أفضل ، وأشعلوا الأخطاء ، وبدأوا في أتمتة العمليات ، وظهرت قاعدة معارف.
- توقف المهندسون عن التشديد وأصبحوا لطفاً.
- تمكنا من تسريع 4 مرات من إصدار ميزات جديدة من خلال التحسينات وتحسين العمل (زيادة حدود WIP بسبب الأتمتة والتحسينات).
- لقد حصلنا على إحصائيات للأعمال وفهمًا واضحًا لما يحدث وكيف يجري التطوير.
- لقد تعلمنا توفير الوقت (رفض المهام غير الضرورية ، وبدأنا في التفكير في المهام مقدمًا لتجنب عوامل إضافية ، وما إلى ذلك).
- عقدت الاجتماعات والاجتماعات عندما تكون هناك حاجة إليها بالفعل (أصبحت أكثر مرونة).
- الجميع بدأ يفكر أكثر ، زاد عدد المبادرات. المبادرات التي تولد في فرق هي دائما أفضل من تلك التي تأتي من أعلى. استمرت العملية باستمرار ، وانخرط الجميع فيها.
النتائج
في هذا المقال والتقرير ، أردت أن ألفت الانتباه ليس فقط إلى الأدوات والأساليب التي طبقتها ، بل إلى الجانب الأكثر أهمية ، والذي غالباً ما يمر دون أن يلاحظه أحد ، ولكن ، في رأيي ، ليس أقل أهمية. بدأنا هذا كله البيريسترويكا ، لأن لدينا آلام وأردنا التخلص منها.
يمكنك تنفيذ شيء ما "على المقدمة" من خلال قراءة الكتب الذكية أو الاستماع إلى تقرير عن المنهجيات المرنة ، لذلك من الممكن تسريع عملية التطوير أو المنتجات بشكل أفضل. لكن غالبًا ما ننسى أن الناس يصنعون هذه المنتجات ، وكلما صنعنا حياتهم بشكل أفضل ، كلما صنعوا منتجات أفضل. على سبيل المثال ، أذهب إلى اللاعبين وأسأل: "وما هي آلامك؟ ما هو الخطأ؟ "، قبل البدء في تنفيذ شيء ما. وبفضل هذا النهج فقط ، تمكنت من فعل ما تريده الأعمال - السرعة والجودة في التطوير.
ملاحظة : قيل لي عن شركة واحدة في أوروبا ، عندما تأتي إلى المكتب هناك ، قد يبدو أن الفوضى الكاملة تسود: المطورين ، مثل الجبن في الزبدة ، وأجهزة تشغيل اللعب ، لا يعمل أحد. ولكن هذا فقط للوهلة الأولى ، هناك جو تم إنشاؤه خصيصًا للأشخاص حتى يتمكنوا من الإبداع والتحسين. في الفترة الفاصلة بين مهام الترفيه ، كتبت إحدى الركبتين حلاً تم تنفيذه فيما بعد ، وبدأت تجني أرباحًا للشركة. آمل أن تتحرك إدارتنا الروسية في هذا الاتجاه في المستقبل القريب. وإذا كان لديك سبب خاطئ لسبب ما ، فكر فيما تفعله. حسنا ، أو رمي هذه المادة إلى رئيسه ، ولكن ماذا لو كان يساعد :)