ما هي المشكلة الرئيسية في تطوير البرمجيات (أو ربما في أي وظيفة)؟ عندما طرحت على زملائي سؤالًا ، تلقيت إجابات مختلفة: التغييرات في المتطلبات ، وعدم تطابق التوقعات ، وجودة الرمز ، والتفاعل مع الفرق الأخرى ... التلخيص لنفسي - يعد التواصل أحد أهم المشكلات.
أثناء التواصل ، يفهم الجميع كل شيء بطريقته الخاصة ، ويفسره بطريقة مختلفة عن ما قيل. يحتفظ العميل في رأسه صورة معينة يحاول تحويلها إلى كلمات وصور ، ويقوم المطور الذي يسمع هذه الكلمات بتحويلها في رأسه إلى نوع من صورته. وفي هذه السلسلة يمكن أن يكون هناك العديد من الروابط.
في محاولة لحل هذه المشكلة ، يكتب الناس ToR مفصلة. ولكن هل هذا يحل المشكلة؟ نفس الأسئلة ، كما أراها ، طرحها بوب مارتن ومارتن فاولر مع زملائه عندما كتبوا بيان Agile في فبراير 2001. دعنا نحاول أن نتعرف عليها معًا حول هذه المسألة ، وفي بيان Agile نفسه.
القصة
في شتاء عام 2000 كان هناك اجتماع لقادة ما يسمى البرمجة المتطرفة ، وناقشوا منهجيات التنمية ونتيجة لذلك بدأوا في تقديم بعض منهجيات الضوء. قليل من الناس مهتمون (لا أريد الإساءة إلى أي شخص) ، على الأرجح أنهم قاموا بمزيد من النكات حول هذا الموضوع. ومع ذلك ، نظمت العديد من الغرباء في هذا الاجتماع خاصة بهم بعد عام. بدأ كل شيء بحقيقة أن بوب مارتن (الذي ألف الكتاب الشهير عن جودة الكود) ، أرسل رسالة إخبارية إلى قادة الاجتماع الأخير - دعنا نلتقي ونتحدث. في الواقع لا شيء ملموس. لبعض الوقت تشاجروا حول المكان والزمان. نتيجة لذلك ، اجتمعوا في 11 فبراير 2001 ، في ولاية يوتا ، في منتجع للتزلج. 17 شخصًا من قطاع التنمية ، بما في ذلك بوب مارتن ومارتن فاولر وغيرهم. لقد شربوا ، ذهب فاولر للتزلج ، وبعد مناقشات ، ظهر
بيان أجيل .
من حيث المبدأ ، يمكن نقل كل ما هو مهم حرفيًا بواسطة صفحة نصية ، يمكن قراءتها
هنا .
ولكن مثل كل شيء قصير ومدروس بدقة ، لفهم هذا ببساطة من خلال قراءته لم يكن بالأمر السهل بالنسبة لي شخصياً. لذلك ، دعونا نفكر بالتفصيل في أذهان الأشخاص الذين وقعوا على بيان Agile.
مبادئ رشيقة
هذا ، دون إنكار أهمية ما هو صحيح ،
ومع ذلك ، نحن نقدر ما هو على اليسار أكثر.
يعد هذا جانبًا مهمًا للغاية يجب مراعاته دائمًا عند قراءة البيان ، بل كل يوم في العمل. دعنا نناقش البيانات الرئيسية.
الأشخاص والتفاعل أكثر أهمية من العمليات والأدوات
للوهلة الأولى ، قد يبدو هذا بمثابة دعوة للتخلص من جميع مشاريع Jira ، وتتبع الأخطاء ، ومسجلات الوقت وغيرها من الأدوات وجميع العمليات التي تم تكوينها. ما يمكن أن يكون أسهل هو مناقشة لفظي مع زملائه ما يفعله شخص ما. إذا كان الجميع فقط سعداء. ولكن يبدو قليلا الطوباوية ، أليس كذلك؟
يوحي هذا المبدأ أنه عند بناء عملية تطوير أي شيء ، من المهم أن نتذكر لماذا يتم ذلك ولمن ولأي غرض. ليس من المنطقي إنشاء عملية من أجل العملية نفسها. لأن العمل سيتم في النهاية من قبل الناس ، أنت وأنا ماذا سيحدث إذا تم استبدال كل شرارة ، كل الاهتمام في أعيننا بمهمة في yutrek أو الخلل في الجير؟ لا قيمة لعملية منظمة منظمة توفر أمانًا كاملاً قبل العميل ، ولكنها لا تحل مشكلات التطوير الحقيقية. التفاصيل البيروقراطية (الرسمية) يمكن أن تؤدي بسهولة إلى فقدان الأشخاص في المشروع. أنا أميل إلى الاعتقاد أن الشيء نفسه ينطبق على التخطيط. متى كانت آخر مرة قمت فيها بالتخطيط ، والتي تبين في النهاية أن 60 إلى 70 في المائة على الأقل كانت دقيقة؟
في رأيي ، يمكن أن يبدو مبدأ البيان هذا كالتالي:
عمليات للناس ، وليس للناس للعمليات
كيف يشير البيان إلى أننا نقترب من تنفيذ هذا المبدأ؟
- يجب أن يعمل المحترفون المحفزون على المشروع.
- التواصل المباشر هو الأكثر عملية وفعالية.
- أفضل المتطلبات والحلول المعمارية تأتي من فرق التنظيم الذاتي.
- يجب على الفريق تحليل عملهم باستمرار وتحسين هذه العملية.
ماذا فريق تطوير بشكل عام؟ المنتج للعميل.
منتج العمل هو أكثر أهمية من الوثائق الشاملة
إذا تم تفسيرها كما هي ، على الجبهة ، أعتقد أن الكثيرين سيوافقون. ولكن ماذا ترى هنا؟ شخصيا ، أرى هنا أن المنتج الذي يعمل ويعمل في
الوقت المحدد ، هو أكثر أهمية من التعليمات البرمجية المكتوبة تمامًا. هذه كلمات قاسية ومخيفة في كثير من النواحي ، لذلك لا ينبغي أن أقول ذلك. لكن حياتي المهنية كلها ، التي تعلمت من أشخاص مختلفين ، أصبحت أكثر اقتناعًا بالفكرة - إذا اخترت مشروعًا مثاليًا من حيث الكود والعمارة ، ومشروعًا ليس جميلًا بداخله ، ولكنه يفيد العالم ، فسأختار المشروع الثاني. ونعم ، سوف أقوم بتحسينه بأفضل ما لدي من قدرات وقدرات.
وهنا يجب أن تفكر للحظة. ولكن ما الذي يمكن عمله لجعل هذه المشاكل أقل شيوعًا؟ بحيث لا يتعين علينا الاختيار بين إعادة تشكيل وحدة نمطية وتطوير ميزة جديدة؟
- يجب إصدار منتج عامل قدر الإمكان.
- المنتج العامل هو مؤشر رئيسي للتقدم.
- الاهتمام المستمر بالتميز التقني والجودة يعزز مرونة المشروع.
- البساطة والتقليل ضرورية.
إيلاء الاهتمام لهذه النقطة حول التميز التقني. الحفاظ على الشفرة في حالة جيدة (ضرورية) ونوعية كافية ، يسهل علينا أن نتحمل التغييرات في المتطلبات ، وبالتالي ، التغييرات في الكود.
جميع المبادئ ، أذكرك ، ليست سلبية. واحد لا يستبعد الآخر. هذا هو حول تحديد الأولويات. كل شيء مهم - المنتج وجودة الكود والوثائق. ولكن ماذا تختار ، متى تختار؟ العمل في توازن معين بين الجودة والمنتج ، من الأسهل وضع المنتج في الأولوية ، دون إنكار الجودة.
كمثال من حياتي ، أتذكر العمل في مشروع مصرفي لعميل روسي. تم تنفيذ العمل بمشاركة محللين وبشكل صارم على المعارف التقليدية الحجمية. مرة واحدة كل ستة أشهر ، انتقل المدير إلى المكتب الرئيسي للعميل وعرض نتائج العمل. من السهل تخمين أن النتائج كانت مختلفة بشكل كبير عن توقعات العميل كقاعدة عامة. كان محاسب العميل ، الذي رأى النظام الجديد لأول مرة ، وكان يعرف عمومًا أنه تم إنشاؤه ، في حالة من الرعب - لم يكن هناك شيء مثل عملية عمله المعتادة في النظام الجديد. وهو ما يقودنا إلى الموضوع التالي.
التعاون مع العميل أهم من التفاوض على شروط العقد
يجب أن تكون حذرا جدا مع هذا البيان. ومرة أخرى ، تذكر أنه لم يتم إنكار الجانب الأيمن من البيان. على العكس من ذلك ، نقول أن العقد مهم. فقط عندما نزن شروط العقد والتعاون ، والشراكات طويلة الأجل الصحيحة ، فإن العلاقة ستكون أكثر أهمية. دون إنكار الثانية. أوجه هذا الانتباه إلى هذا لأننا نعيش في العالم الحقيقي وأحيانًا يتعين علينا العمل مع عملاء مختلفين للغاية. هناك حالات يمكن فيها للعميل لأغراضه الأنانية الاستفادة من السذاجة ، وعلى حساب العقد ، يتغلب على الشروط غير المقبولة للمطورين.
ومع ذلك ، إذا تحدثنا عن عميل جيد مجردة
في فراغ ، فإن الحفاظ على علاقة طويلة الأمد تؤدي إلى مشاريع جديدة سيكون أكثر أهمية.
كيف يمكن تحقيق الفهم والامتثال للتوقعات خلال المشروع؟
- خلال المشروع ، يجب أن يعمل مطورو وممثلو الأعمال المخصصة يوميًا.
- التواصل المباشر هو الأكثر عملية وفعالية.
في الوقت نفسه ، لا ينبغي لأحد أن ينسى بالتأكيد تأكيد الاتفاقيات من أجل سلامتهم. هناك بالمناسبة (لحسن الحظ نادراً ما) عملاء يرفضون عمومًا الدفع بعد الاتفاقات.
مهما كان العميل ، يكون نشاط المطور دائمًا مفيدًا.
أود أن أضيف بمفردي أن هذا يجب أن يعمل في كلا الاتجاهين.
هذا يقودنا إلى استمرار منطقي - تغييرات في العمل والخطط. قليل من الناس يرغبون في إجراء تغييرات ، إنها في طبيعة الإنسان ، إذا فكرت في ذلك. أي نظام يسعى للحصول على نقطة معينة من التوازن والثبات. لكن التطور يرتبط دائمًا بالحركة والتغيير.
يعد الاستعداد للتغيير أكثر أهمية من اتباع الخطة الأصلية.
لا يتم رفض وجود خطة على هذا النحو. على العكس ، الخطة مهمة. لكن من الأهمية بمكان أن نكون مستعدين لتغييرها ، إذا أدركنا في مرحلة ما أن هذه الخطة لم تعد تعمل في البيئة الحالية.
مثال على ممارسة زملائي هو مشروع لفحص الضرائب في واحدة من بلدان رابطة الدول المستقلة. مشروع الدولة ، في جوهره ، والمعارف التقليدية ، والتشريعات ، لم يكن هناك أي حديث عن أي رشيقة. لكن كان على الفريق إظهار المرونة في الوقت الذي غيّرت فيه الدولة في بلد العميل تشريعها الضريبي حتى لا يكون للمشروع معنى على الإطلاق في الشكل الذي تم التخطيط له به. اضطررت إلى تغيير المواصفات الفنية وإعادة المشروع على وشك الانتهاء حتى يتمكن العميل من استخدامه. خلاف ذلك ، لن يكون هناك أي نقطة في العمل ، حسنا ، ربما باستثناء الأرباح على هذا النحو.
ربما ليس هذا هو المثال الأكثر إيضاحًا ، حيث إن التغييرات قد نشأت بسبب عوامل خارجية. ومن ناحية أخرى ، يمكن للعميل ، مرة أخرى بسبب عوامل خارجية ، للتو إلى ضرورة تغيير المتطلبات. خلاف ذلك ، لن يحصل على ميزة تنافسية.
كل هذا يلامس موضوعًا مؤلمًا بعض الشيء بالنسبة لي. ولكن ماذا لو كنا نفعل مشروعًا لمدة عام كامل ، ثم بعد عام يقول العميل - حسنًا ، أنت عظيم ، والآن سنضع كل هذا في الأرشيف ، ولن نستخدمه وسنبدأ مشروعًا جديدًا. أنا مؤلمة تجاه هذا ، لقد كانت لدي تجربة مماثلة. ولكن حقا - ماذا حدث؟ ساعد العمل المنجز العميل على فهم أن المسار المختار غير صحيح. أو غير فعالة. للحصول على ميزة تنافسية ، تحتاج إلى العمل بشكل مختلف ، والقيام بمشروع آخر. وقد تلقى هذه المعرفة بمساعدتنا.
ما هي جوانب عملنا التي ستساعد على تسهيل هذه الزوايا وتجعل المرونة أقل إثارة للخوف؟
- تسليم البرامج العادية والمبكرة.
- التغييرات مرحب بها حتى في المراحل اللاحقة.
- تساعد التغييرات في تزويد العميل بميزة تنافسية.
في الوقت نفسه ، نحن نعيش في العالم الحقيقي ، مع أناس حقيقيين ، حيث لا ينبغي رفع أي حكم ، بما في ذلك هذا ، إلى المطلق. نعم ، نرحب بالتغييرات عندما تؤدي إلى إضافة قيمة إلى المنتج النهائي. ولكن من المهم الحفاظ على التوازن. إذا قمنا بإجراء تغييرات إلى ما لا نهاية ، فلن نقوم مطلقًا بإصدار منتج في الإنتاج. لذلك ، في مرحلة ما يجب أن تقول - توقف ، نصدر المنتج ، ونفحص كل شيء في الممارسة ، ونبدأ في عمل الإصدار الثاني ، والذي سوف يحتوي على هذه التغييرات. في كل مرة يوضح مع العميل - ما هي القيمة التي يراها في هذا التغيير أو ذاك.
قرأت مؤخرا العبارة على Facebook ،
إذا لم تخجل من منتجك ، فأنت دخلت السوق بعد فوات الأوان
يعكس بدقة جوهر ما سبق. نحتاج إلى البحث عن نقطة توازن معينة ، يكون فيها المنتج جاهزًا بما يكفي للإصدار التالي من حيث التغييرات ، والذي لم نبدأ فيه بعد في بذل الكثير من الجهد على التغييرات الطفيفة.
بدلا من تلخيص
لا يصف مُنشئو بيان Agile أي قواعد ، بل والعكس صحيح. لكنها تثير قضايا مهمة في عملنا - تفاعل الأشخاص والمطورين والعملاء ، والاستعداد للتغيير. هذه المبادئ مهمة في الطبيعة. مع الأهمية التي لا يمكن إنكارها للتوثيق والعقود والعمليات والتخطيط والتفاعل البشري والاستعداد للتغييرات القيمة وتقديم شيء مفيد للعالم ، كلها أمور أكثر أهمية.