تأثير تقسيم الفرق على المشروع

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

[مصدر الصورة من هنا]

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

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

سنة 1967 فيه واحد اسمه ملفن كونواي Melvin Conway قال -ما معناه - إن المؤسسات لما بتيجي تصمم أي نظام، بيطلع التصميم بتاعهم مطابق لهيكل تقسيم الفرق و إزاي بيتواصلوا مع بعض. وده نص كلامه:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
سنة 1975 فريدريك بروكس Frederick Brooks في كتابه الشهير The Mythical Man-Month خد الكلام ده وسماه قانون كونواي Conway's Law وبعد كده الكلام ده انتشر بالاسم ده.

فيه دراسات اتعملت بعد كده على الفكرة دي، منها دراسة عملتها مدرسة هارفارد للأعمال Harvard Business School سنة 2007، وقارنوا في الدراسة دي بين أكواد بعض المشاريع بتقوم بنفس الوظيفة، واكتشفوا إن البرامج مفتوحة المصدر اللي طورها مبرمجون متفرقون تميل لتكون أحسن تقسيما و أقل اعتمادية فيما بين أجزائها loosely-coupled وعلى العكس من ذلك البرامج اللي طورها فريق واحد متفرغ للمشروع أقرب ما تكون لوحدة واحدة monolith والاعتمادية فيما بين أجزائها كبيرة tightly-coupled. واكتشوفوا برضو إن جودة أو سوء التواصل بين الفرق بينعكس على جودة أو سوء التكامل بين أجزاء المشروع اللي هما شغالين عليها.

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

القانون ده بيشتغل بالعكس برضو، فزي ما تصميم البرنامج بيتأثر بالهيكل الإداري في المؤسسة، بيأثر فيها برضو، وده بيظهر قوي في الأنظمة القديمة، فمثلا لو كان البرنامج متقسم ل3 طبقات tiers: قاعدة بيانات، و إجراءات الأعمال Business Logic و واجهة المستخدم، وكل طبقة من دول كان عاملها ناس متخصصة في الحتة دي بس، يعني مثلا طبقة قاعدة البيانات مليانة stored procedures و وطبقة واجهة الاستخدام فيها شغل javascript عملاق و حاجات متقدمة جدا في التفاعل مع المستخدم، هاتلاقي إن بعد فترة المؤسسة مضطرة تستمر في تشغيل ناس متخصصة في كل طبقة من ال3 دول عشان البرنامج يفضل عايش.

طيب إزاي بقى نخلي القانون ده يعمل لمصلحتنا مش ضدنا؟- لازمة القانون ده إنه لو تم توزيع الفريق اللي بدأ المشروع إلى فرق مستقلة، فبنية المشروع الأساسية Application Architecture ستعمل "ضد" المشروع ما لم يتم تغييرها. فريديريك بروكس - اللي نشر الفكرة، زي ما قلنا فوق - قال إن تصميم أول نسخة من المشروع غالبا بيكون مش أفضل حاجة، و فيه احتمال كبير إنك تضطر تغير فيه حاجات كتير، ولذلك فمرونة المؤسسة في تقسيم وإعادة تقسيم الفرق مهم جدا في تصميم المشروع. بعبارة أخرى: تأكد أن بنية المشروع Application Architecture متوافقة دائما مع التقسيم الإداري للمؤسسة و إلا هاتلبس في الحيطة يا معلم!
- الكود الواحد محتاج تواصل على مستوى التفاصيل الدقيقة fine-grained communication، لا تستطيع الفرق الموزعة القيام به، في الحالة دي أحسن حاجة تعملها إنك يا إما تجمع الفرق الموزعة في فريق واحد أو إنك تفصل الكود الواحد بحسب تقسيم الفرق، والتواصل في الحالة الثانية دي هايكون عند الضرورة فقط.
- حاول تخلي تقسيم الفرق ييجي *بعد* وضع الarchitecture اللي أنت شايف إنه مناسب من الناحية الفنية للمشروع.
- الفريق اللي بيشتغل على كود واحد خليه بقدر الإمكان قريب من بعضه، يعني لو في نفس المكتب يبقى مية مية، أقل من كده شوية لو في نفس الدور، وكل ما بيبعد أعضاء الفريق عن بعضهم بيبقى أوحش.

آخر حاجة، اعتبروا الكلام ده مدخل للmicroservices و الdistributed systems ...أي خدعة :)

ما تنسوش تنشروا المقالة لو حسيتوا إنها مفيدة 

-------------------

مصادر استفدت منها:

http://www.melconway.com/Home/Conways_Law.html

https://en.m.wikipedia.org/wiki/Conway%27s_law

https://www.thoughtworks.com/insights/blog/demystifying-conways-law

https://haacked.com/archive/2013/05/13/applying-conways-law.aspx/

http://whatis.techtarget.com/definition/Conways-law

http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf