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

تحاول التقاط كل البيض

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

نختار سلسلة أدوات

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

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

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

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

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

الكتب لا تكذب

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


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

عصا واحدة تؤلم ، العديد من العصي مميتة

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

لتلخيص

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

ملاحظة:

في ما يلي نموذج قائمة وتوقيت الخطوات التي اتبعناها:

1. تشكيل التخطيط ~ 4 أشهر
2. العمل مع اتصالات قصيرة ~ شهر واحد
3. ابحث عن سلسلة أدوات مناسبة وتطوير سير العمل ~ شهرين
4. اختيار المنهجية ~ شهرين
5. إدخال سكروم في سير العمل ~ 8 أشهر

وهنا مجموعة صغيرة من الرئيس التنفيذي لدينا:

1. فهم رشيقة - أندرو ستيلمان وجنيفر غرين
2. "طريق سيد سكروم" - سوزان شوخوف
3. "سكروم طريقة ثورية لإدارة المشاريع" - جيف ساذرلاند
4. "طريقة كانبان البديلة للرشيق" - ديفيد أندرسون
5. على رأس التحول. تطبيق مبادئ Agile و DevOps في جميع أنحاء الشركة "- Harry Gruver و Tommy Mauser