المساء. ستنتهي مقابلة أخرى للبحث والتطوير ، ويتم إعداد المقابلات على أسئلة غير متوقعة من زميل في المستقبل. ولكن لا توجد مفاجآت: النسبة التي استنتجها Wilfredo Pareto تعمل أيضًا هنا. في 80٪ من الحالات ، نسمع أربعة أسئلة - حوالي 20٪ من العدد الإجمالي المستلم. كيف يتم ترتيب عمليتك؟ ماذا سأفعل؟ كيف تصبح قائدًا / قائد فريق في السنة؟ ماذا عن الانتقال إلى أوروبا؟
في هذا المنشور ، سوف نجيب على السؤال الأول ونتحدث عن عملية التطوير في Veeam - من فريق إلى فريق هذه الإجابة تتغير أقل.
إذن العملية. هذه سلسلة متكررة من الإجراءات تؤدي إلى النجاح كل يوم ، أو على الأقل في بعض الأحيان. لقد تعلمت كيفية طهي البرش وفي كل مرة يتحول إلى طعم متساوي - عملية. وقوف السيارات ليس ضربة - أتقن العملية. تسمح العملية للدماغ بعدم التفكير في روتين في كل مرة ، وتحويله إلى عمل ميكانيكي. يتم تحرير الدماغ للإبداع.
عملية التطوير هي سلسلة من الإجراءات التي تحول رغبات المستخدمين إلى منتجات ملموسة. يتم صياغة هذه الرغبات من قبل المحللين ومديري المنتجات ، ويتم تنفيذها من قبل المطورين ، ويتم تقييمها بشكل نقدي من قبل المختبرين ، ويصفها الكتاب الفنيون.
نحن في Veeam نصنع منتجات ضخمة للنسخ الاحتياطي والنسخ المتماثل لمركز البيانات - حتى لا تفقد أي شيء. منتج محاصر كلاسيكي بدون عميل محدد. للوهلة الأولى ، الشيء بسيط ، ولكن هناك فروق دقيقة ، لذلك نحن نفعل ذلك للعقد الثاني.
الفاعلون
كل إصدار هو نتيجة عدة مجموعات:
- مديري المنتجات أو المحللين . يضعون أولويات عملهم ، ويتواصلون مع العالم الخارجي - العملاء والشركاء. يمكن للشراكة أن تشمل التكنولوجيا. على سبيل المثال ، يمكن للموزع أن يخبر ما ينقصه لزيادة المبيعات ، ويمكن لمصنّع برنامج مراقبة الأجهزة الافتراضية أن يخبر عن خطط المستقبل. بالنسبة لهذا الفريق ، "مهارات التحدث" ، تعد القدرة على التقاط الاتجاهات وتحديد أولوياتها في تيار عاصف من الآراء أمرًا مهمًا. ثم دافع عن الموقف المختار ، قل لا ، اشرح لماذا تم عمل شيء بهذه الطريقة ، وليس بطريقة أخرى. لا يهم في البيانات الصحفية ، في المؤتمرات أو بشكل خاص. هؤلاء الناس يعلمون عالم المبيعات.
- الدعم الفني خط المساعدة لعملائنا. أهم مؤشرات الفريق هي وقت الاستجابة للمشكلة ووقت حلها (SLA). يتم تقديم حوالي بضعة آلاف من المكالمات خلال الشهر. الفريق متعدد الطبقات ، ويشمل كلا من مجموعات التفاعل مع العملاء ، ومجموعات تحليلات المكالمات ، وتطوير الحلول ، وما إلى ذلك. استنادًا إلى المعلومات التي تلقاها الدعم ، تتم صياغة قائمة بالتحسينات والإلحاح - سواء للتنفيذ في إصلاح خاص أو التحديث التالي أو تأجيل الإصدار الرئيسي.
- مطورو R & D. الأشخاص الذين يجسدون الطلبات في التعليمات البرمجية.
- اختبار أو QA . المختبرين الأوائل ، ومجموعة اختبار الخزان وحامل اهتزاز في نفس الوقت. إنهم لا يتحققون فقط مما تم تنفيذه بالفعل - بل يتواصلون أيضًا مع العمل في مرحلة الحمل. بتكرار مهام المسؤولين في بنية تحتية قريبة من القتال ، من الأسهل فهم مدى ملاءمة الواجهة التي تم إنشاؤها أو إنتاجية الخوارزميات المحددة. عندما يأتي الدعم الفني إلى استنتاج أن هناك خلل في المنتج ، فإن QA تعيد إنتاج السيناريوهات الإشكالية وتراقب الإصلاحات.
- فريق الكتاب الفنيين. ينشئون وثائق للمستخدم النهائي ، بالإضافة إلى وثائق محددة مثل "كيف يعمل" و "دليل النشر". يحصلون على مواد للعمل من المطورين والمختبرين والمحللين.
تفضل بعض الفرق المساحات المفتوحة ، ولكن غالبًا - الخزاناتيتم ربط الفرق من خلال نظام محاسبة المتطلبات. قمنا بتطبيقه على أساس نظام Microsoft Team Foundation System ، حيث استخدمنا تاريخياً كنظام تخزين إصدار مصدر. يقوم النظام بتخزين المتطلبات (المتطلبات) والعيوب (الأخطاء) واستدعاءات الدعم (المشكلات) ، مما يتطلب مشاركة ضمان الجودة والمطورين. تتضمن كل قضية مئات المشاركين الذين يعملون على آلاف المهام والمتطلبات والعيوب. يساعد النظام في الحفاظ على كل هذا ، والأهم من ذلك ، توزيع الحمل بالتساوي ، وتحديد أولويات المطورين.
حلقات الأشجار: دورات التطوير
تطوير منتجاتنا دوري ، تنتهي كل دورة بإصدار الإصدار التالي - الإصدار. إليك ما ينعكس في الإصدارات:
- اتجاهات السوق طويلة الأمد . على سبيل المثال ، المحاكاة الافتراضية وظهور البنى التحتية السحابية. يستغرق تغيير نماذج عمل تكنولوجيا المعلومات سنوات - في هذا الوقت ، ينتقل المستخدمون من الشك والرفض ("ما هذا بحق الجحيم") إلى الاعتراف الجماعي ("نعم الجميع يفعل ذلك"). أدت المحاكاة الافتراضية لمراكز البيانات في وقت واحد إلى ظهور شركة Veeam ، نظرًا لأنه في ظل ظروف المحاكاة الافتراضية ، كانت المنتجات القديمة لنسخ الأجهزة الاحتياطية غير فعالة.
- دعم المنصات الجديدة . ذات مرة ، كان Veeam مخصصًا فقط لمراكز البيانات الافتراضية القائمة على منصة VMWare. مع تزايد عدد وحجم العملاء ، هناك حاجة لدعم منصات جديدة. بالإضافة إلى برنامج VMWare ، ظهرت أجهزة مراقبة افتراضية أخرى (Hyper-V) ، وخوادم فعلية ، ومنصات سحابية (AWS ، Azure) ، وما إلى ذلك.
- التغييرات التكتيكية في السوق . يتم إصدار الإصدارات التالية من أنظمة التشغيل وبرامج مراقبة الأجهزة الافتراضية. اكتسبت الخبرة باستخدام الإصدارات السابقة من منتجاتنا. على سبيل المثال ، هذه هي الطريقة التي حصلنا بها على دعم على مستوى العنصر - الاسترداد الانتقائي من خوادم التطبيقات الشائعة مثل Microsoft Exchange و Microsoft SQL Server و Oracle D Database وما إلى ذلك.
- عيوب . على الرغم من كل جهودنا ، لا حياة ، وتقدم مفاجآت. بالطبع ، نحاول التقليل منها.
كل ربع سنة نحصل على تحديثات (تحديثات) ، مرة واحدة سنويًا - إصدارات رئيسية (رئيسية). إنهم جيدون في أنهم يقللون من النفقات العامة لإنشاء وظائف حجمية تتعلق بدعم المنصات الجديدة وتغيير النماذج. استنادًا إلى تفاصيل الميزانية ، تكون أقسام تكنولوجيا المعلومات للعملاء أكثر نشاطًا في نهاية العام ، لذلك نطرح إصدارات كبيرة أيضًا في هذا الوقت.
تتضمن التحديثات الفصلية أساسًا هدفين: دعم الإصدارات الجديدة من الخوادم المحمية واستكشاف الأخطاء وإصلاحها. في التحديثات ، نجمع كل تصحيحات العيوب التي اكتشفها العملاء منذ إصدار النسخة الرئيسية. أيضًا ، بمساعدة التحديثات ، نرد بسرعة على التغييرات في الأنظمة الأساسية المدعومة. بموجب شروط اتفاقية مستوى الخدمة ، يجب أن يضيف Veeam دعمًا للإصدار الجديد من برنامج Hypervisor في مدة
لا تزيد عن ثلاثة أشهر .
وماذا لو لم يعمل المنتج لعميل معين؟ في هذه الحالة ، نصدر إصلاحًا خاصًا - بعبارة أخرى ، عكاز. يتم إصدار هذه الإصلاحات كل أسبوع ولا ترتبط دائمًا بالعيوب في المنتج. على سبيل المثال ، قد لا تكون إعدادات أمان العميل متوافقة مع المنتج. من خلال إصدار إصلاح خاص ، نقوم بتحليل تكرار المشكلة ونقرر ما إذا كان سيتم تضمين الإصلاح في التحديث ربع السنوي التالي.
من الفجر إلى الغسق: إطلاق وقائع
تبدأ كل دورة إطلاق بالتخطيط - على مستوى المنتج ككل وعلى مستوى المتطلبات الفردية. في الحالة الأولى ، يتم حل مشكلة أولويات العمل وتوزيع المتطلبات بين الفرق. بادئ ذي بدء ، تتم مناقشة المتطلبات أو الملاحم الأكثر إلحاحًا. بطريقة جيدة ، لا ينبغي تخصيص أكثر من 60 ٪ من إجمالي حجم العمل على الإصدار إلى الملحمة ، بحيث يكون هناك وسادة زمنية. يتم تخطيط المنتجات على مستوى رؤساء الأقسام - المنتجات ، المختبرين ، المطورين.
يتم تقسيم المطورين والمختبرين إلى فرق. العدد الأمثل للأشخاص في الفريق هو خمسة. الفرق هي وظيفية وعالمية. في الحالة الأخيرة ، يكون الفريق مكتفياً ذاتياً ، ويضم مطورين ذوي خبرة في العديد من المجالات. الأوامر الوظيفية أكثر تركيزًا - فهي تعمل على واجهة المستخدم ، ومكونات النظام ، وما إلى ذلك. يشكل الأشخاص من الفرق الوظيفية المختلفة فرقًا افتراضية تبدأ في تنفيذ المتطلبات. يجتمع هنا على الأقل ممثلون لمجموعة PM ، وفرق التطوير والاختبار. يتم تعيين قائد الفريق قائد الفريق لأحد الفرق الوظيفية.
يبدأ العمل على الشرط. يجتمع الفريق الافتراضي أسبوعيًا. يتحدث المشاركون عن النجاحات التي تحققت خلال الأسبوع الماضي ويخططون للعمل في اليوم التالي.
يدير رئيس الفريق المسؤول عن الإشراف الاجتماعات ويسجل النتائج. كما أنه يحل المشكلات التي لا يمكن حلها ضمن فريق افتراضي. على سبيل المثال ، إذا كنت بحاجة إلى نقل التواريخ أو تأجيل جزء من المهام.
داخل فرق التطوير الوظيفي أو الاختبار ، تكون نقاط التحكم أكثر تباعدًا. كقاعدة ، تنقسم الخطة الأسبوعية إلى مهام لا تزيد عن يومين إلى ثلاثة أيام. ترسخت بعض الفرق في الممارسة العملية مع التقلبات اليومية ؛ في مكان ما ، يعمل التفاعل من نقطة إلى نقطة بين قائد الفريق والفريق بكفاءة أكبر.
غرفة اجتماعات نموذجية لمناقشة الوضع الحالي للمشروعتنقسم جميع عمليات التطوير إلى تكرارات أسبوعية أو نصف شهرية. خلال التكرارات الأولى ، تحتاج إلى إنشاء وظيفة تعمل في الحد الأدنى والتي ستنمو لاحقًا لتصبح اللحم - على سبيل المثال ، واجهة مستخدم متقدمة ، وواجهة برمجة تطبيقات للعملاء ، وما إلى ذلك. والأهم من ذلك ، فإن وجود هيكل عظمي يسمح بالفعل للمختبرين بالحصول على ميزة.
تتضمن دورة الإصدار إصدارات ألفا وبيتا. بمساعدتهم ، نعرض ميزات جديدة للعالم الخارجي ونجمع التعليقات مسبقًا. إذا لزم الأمر ، يتم تغيير القرارات المتعلقة بالعمارة أو الوظيفة. يتم إحضار السيناريوهات إلى حالة ألفا وبيتا ليس على الفور ، ولكن على دفعات. كقاعدة ، هناك حوالي بيتا في دورة الإصدار.
بعد المرحلة التجريبية ، تدخل الفرق في وضع اختبار الانحدار. في هذه المرحلة ، يعمل المنتج ككل بالفعل ، وقد تم بالفعل تقوية واجهة المستخدم والنصوص البرمجية وتغييرها بكثافة أقل. يأتي دور فريق من الكتاب التقنيين. في الوقت نفسه ، يتم تدريب فرق الدعم الفني.
يتم إجراء اختبار الانحدار في دورات لمدة أسبوعين. يتم تحديد وقت الدورة بالوقت المطلوب لعرض جميع سيناريوهات المنتج. كلما زاد حجم المنتج ، زاد عدد السيناريوهات ، وبالتالي الدورات. يتم تعريف كتلة التعليمات البرمجية قبل الحلقة الأخيرة. هذا يعني أنه سيتم إجراء تغييرات مهمة فقط على المنتج - وفقط بعد العديد من مراجعات الكود. هناك حاجة إلى مثل هذه الأساليب الصارمة حتى لا يتم إدخال عيوب جديدة عن طريق الخطأ في المنتج.
كلما اقتربت لحظة الإصدار ، كلما زاد وقت الفراغ لدى المطورين وأقل من الجميع. يحتاج مديرو المنتجات إلى إعداد النشرات الصحفية وتنسيق عمل خدمات التسويق. يجب على المختبرين التحقق من الإصلاحات وإجراء اختبار الانحدار النهائي. الكتاب التقنيون يضيفون وثائق المستخدم. في هذا الوقت المناسب ، يطور المطورون أنشطة بحثية لمتطلبات الإصدار التالي.
وهنا لحظة مثيرة تسمى RTM - جاهز للسوق. وهذا يعني أن المنتج جاهز بالفعل للتوزيع على المستهلكين. في غضون أسبوعين ، سوف يعذبه الصحفيون ومقدمو الخدمات. سيتم عرضه في العروض التقديمية. بعد أسبوعين ، سيكون المنتج متاحًا للجميع. في الوقت الحالي ، تحدث تغييرات داخلية أيضًا: يتم إعداد فروع جديدة للتطوير ، ويتم إيداع الشفرة. وبالطبع ، ترتفع البنية التحتية للنسخة التالية. بعد الإصدار العام (GA) ، حان وقت الدعم الفني. والباقي يعمل بالفعل على الإصدار التالي.
حول الأولويات
وأخيرًا ، القليل من الأجهزة. كما تعلم ، في ثالوث "سريع وعالي الجودة وغير مكلف" يمكنك اختيار خيارين كحد أقصى. الجودة والتوقيت والوظائف يتقاتلون باستمرار فيما بينهم. في منتجنا المعبأ ، تأتي الجودة أولاً. حسنًا ، ولكن ما هي بعض المجالات التي لا تهم الجودة فيها؟ بالطبع لا. السؤال كله هو تعريف الجودة.
بالنسبة لنا ، الجودة هي:
- الحفاظ على الموثوقية والأداء في تكوينات حديقة الحيوان . أحد العملاء لديه مركز بيانات متواضع من خادمين من وقت معركة بورودينو ، بينما يحتوي الآخر على بنية تحتية متطورة في حظيرة قريبة مع Amazon. يجب أن يعمل المنتج بشكل مناسب في كلتا الحالتين.
- سهولة الاستخدام . يجب أن يكون المستخدم على الأقل للتوتر والتأقلم بالتأكيد دون أي تعليمات. لكن البساطة المماثلة ليست بعيدة دائمًا عن البساطة الخارجية - حاول العبور بسلاسة مع القنفذ.
- الوراثة الاستثمارات في الشركات طويلة الأجل ، ولن يتم إنفاق مديري الحسابات المالية على تكنولوجيا المعلومات بدون سبب وجيه. لذلك تحتاج إلى الحفاظ على التوافق مع كل من الإصدارات السابقة والمنتجات ذات الصلة. في كثير من الأحيان أثناء إعادة بناء مراكز البيانات ، يتم إغلاق خوادم البريد الإلكتروني في حقبة الثمانينيات في الجدار. وكلهم ضجيج ولا يعتقدون أن يموتوا.
مع هذه المجموعة من الأولويات للحفاظ على الجودة ، تحتاج دائمًا إلى الجمع بين شيء ما ، للمطورين والمختبرين. يمكن أن تؤدي التغييرات الصغيرة في سلوك الوظائف إلى اختبار التكامل القسري لنصيب الأسد من المنتج. حاول إضافة دعم اللغة الآسيوية للمنتج وفهم ما يدور حوله. لذلك ، فإن مسألة الأولويات هي مسألة مناقشة مشتركة لرؤساء الشركات والمختبرين والمطورين.
الأولوية الثانية التي لا يمكن تدميرها تقريبًا هي التوقيت. في حالة التحديثات ، يتم تحديد تواريخ الإصدار بواسطة اتفاقية مستوى الخدمة ، في حالة الإصدارات الكبيرة - من خلال تقويم الأعمال. وفقًا للإحصاءات ، في كل دورة إصدار ، يتم إنفاق 50٪ تقريبًا من الوقت على التطوير ، و 50٪ على جلب المنتج إلى الذهن (مرحلة إصلاح الأخطاء).
ما يمكن تغييره هو وظيفة الإصدار التالي. قائمة المتطلبات ذات الأولوية ، أو المتراكمة ، تساعد هنا. من الناحية النظرية ، كل شيء بسيط: اختر وظيفة الأولوية التالية من التراكم ، وانظر في الوقت المتبقي. عندما يكون الوقت قريبًا من النهاية ، أوقف الإصدار التالي من المنتج وحرره. الشيطان مخفي في الفروق الدقيقة:
- عدم التأكد من المتطلبات . على سبيل المثال ، يمكن تحسين مطلب "دعم النسخ الاحتياطي للأجهزة المادية على نظام التشغيل Linux". ما النوى التي يجب دعمها؟ ما توزيعات؟ ما أنظمة الملفات؟ يمكن تنفيذ واحد ومتطلبات عالية المستوى في شهر أو سنة. السؤال كامل.
- الفرق لديها تخصصات . لا يمكن لأي فريق اتخاذ جميع المتطلبات. لن يكتب مطور C # برامج التشغيل ؛ لن يتعامل مطور مكونات النظام دائمًا مع تطوير الويب.
- تعتمد المتطلبات على بعضها البعض . لا يكون هذا مرئيًا دائمًا على مستوى سيناريوهات المستخدم ، ولكن هناك مثل هذه العلاقات في الداخل. من وجهة نظر العالم الخارجي ، قد يكون دعم النسخ الاحتياطي من أنظمة الملفات NTFS و ExtFS متطلبات بأولويات مختلفة ، ولكن في الداخل ستحتاج إلى كتابة محرك مشترك أولاً.
- تنقسم المتطلبات إلى مؤجلة وغير قابلة للتأجيل . إذا كان السوق ينتظر في الإصدار التالي لبعض الوظائف ، وتم الإعلان عنه ، فلن يعمل على تأجيله.
- جزء من المتطلبات ينطوي على البحث . بدون نتائج البحث ، من المستحيل التخطيط لتعقيد المهمة (ربما يكون من المستحيل على الإطلاق) ، وقد يكون من الصعب التنبؤ بهذه النتائج.
هنا يأتي دور التنمية الرشيقة. بالنسبة لنا ، التطوير الرشيق يعني الحاجة إلى إعادة التطوير الدورية. أصبحت الظروف الجديدة معروفة - تغيير الخطط. تمت إضافة متطلبات الأولوية الجديدة إلى الخطط المتغيرة المتراكمة. ليس لدينا وقت مع متطلبات غير متأخرة - نقطع جزءًا من المهام أو نغيرها. في نظرية التحكم الفني ، يسمى هذا نظام التغذية المرتدة. تذكر كيف يعمل الطيار الآلي.
يعتمد أي تخطيط في الشروط المذكورة أعلاه على حكم الخبراء. التقييم الخبير لقائد الفريق هو العنصر الذي يجعل العملية اللاحقة بأكملها واضحة ومنظمة. اسم آخر لتقييم الخبراء هو "طريقة الحول اللينيني" ، كما يحب ألكسندر أورلوف من ستراتوبلان أن يكرر. هذا عندما تتخذ قرارًا بناءً على الخبرة والحدس السابقين. على الرغم من الانتقادات المحتملة ، يعمل هذا. يعمل مثل جميع عملياتنا الموصوفة أعلاه. إذا كانت لا تزال لديك أسئلة حولها ، فإننا ندعوك للتعليق.
ما هي الخطوة التالية؟
تكنولوجيا العملية الحالية مريحة ودافئة مثل النعال المنزلية. المشكلة الوحيدة هي أنه في Veeam ، تدفعك بعض المجلات غير المرئية دائمًا: بشكل أسرع وأكثر وأكثر وأكثر.
في الآونة الأخيرة ، تم بناء مكاتب تجريبية في فنلندا وجمهورية التشيك ، ونحن نستعد هذا العام لافتتاح مركز براغ للبحث والتطوير لعدة مئات من الأشخاص.
بهو مكتبنا في براغظهر مؤخراً مكتب تطوير في إسرائيل ، وتزداد الفرق في كندا وألمانيا. يتزايد عدد مشروعات التطوير المشتركة مع HP و NetApp و Nutanix و EMC.
يتحول المصنع إلى ناقل موزع جغرافيًا ، وفي الوقت نفسه تتبلور العمليات الجديدة. ومع ذلك ، هذا موضوع لمقال منفصل.
ابق على اتصال.