زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟
Printable View
زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟
سلام عليكم
اصلا مشكل بعضي از کساني که ميخوان بصورت شئ گرا طراحي کنن و از معماريه لايه اي استفاده کنن همين است.
بخصوص وقتي از فريم ورک دات نت ميخوان استفاده بکنن.
تو بعضي مواقع گيج کننده ست.
بعضي ها ميرن سراغ جاوا چون ميتونن دقيقا اون چيزي رو که ميدونن پياده کنن.
من زياد حرفه اي نيستم ولي ...
معمولا ما از معماريه 3 لايه يا n لايه استفاده ميکنيم
فريم ورک دات نت توي خيلي مواقع اومده براي راحتي کار کاربران ابزار هايي رو قرار داده که بصورت ويزارد مثلا لايه DAL رو پياده سازي ميکنه. اون وقت کدش رو تو لايه نمايش بايد بزاريم !!!
من که خودم خوشم نمياد از اون استفاده کنم ...
کلا راحت ترم که لايه ها ، کلاس ها ، متد هاي مربوط رو خودم بنويسم.
هدف مايکروسافت اينه که کد نويسي به حدالقل برسه.
اما بهتره کار خودمون رو بکنيم و در کنارش با اون ابزار ها هم آشنا باشيم (بعضي وقتها کار آدم رو زودتر راه ميندازه).
بحث زياده اگه فرصت شد بازم مينويسم ...
يا علي
طراحي زياد ارتباط به platform نداره
شما بايد بتونيد مدلي رو طراحي کنيد که هر تيم developing اي با هر platform اي بتونه اونو پياده سازي کنه
اگر تو کتابهاي uml دقت کرده باشيد بيشتر مسالها روي soda machine زده ميشه که يک دستگاهي هست که پول ميگيره و قوطي نوشابه پس ميده.
متاسفانه بيشتر طراح ها موقع آناليز ميرن سراغ platform و کارو خراب ميکنن
من به شخصه ترجیح می‌دهم از کمک‌های دات نت در این طور مواقع استفاده نکنم و خودم چیزهایی را که لازم دارم دقیقا به همون صورت مورد نیاز درست کنم. بعضی جاها را هم سراغ دارم که از این طور امکانات دات نت استفاده نکرده‌اند و خودشان طراحی کرده‌اند...نقل قول:
فريم ورک دات نت توي خيلي مواقع اومده براي راحتي کار کاربران ابزار هايي رو قرار داده که بصورت ويزارد مثلا لايه DAL رو پياده سازي ميکنه. اون وقت کدش رو تو لايه نمايش بايد بزاريم !!!
سلام علیکم
میشه لطفا بگید کجا لایه به صورت اوتوماتیک تولید میشه ؟نقل قول:
نوشته شده توسط Elham_gh
البته من خودم گفتم که مثلا یه چیزی مثل لایه data access تولید میکنه ، ولی وقتی دقت میکنی چون در جای خودش قرار نمیگیره دیگه نمیشه بهش بگیم لایه چون لایه Dal در لایه نمایش قرار داده میشه.
شما وقتی که میخواهید مدل های طراحی رو ایجاد کنید ، باید نسبت به زبان برنامه نویسی و امکانات اون شناخت خوب داشته باشید.نقل قول:
نوشته شده توسط KambizZandi
یک نکته رو همیشه گفته اند :
برای اینکه یک طراح خوب باشی باید قبلش ، مدتی خوب برنامه نویسی کرده باشید.
اون چیزی که شما دارید در موردش صحبت میکنید ، Analysis هست نه Design.
در Analysis هم کلاس دیاگرام داریم با جزئیات خیلی کمتر.
در Design عمدتا 3 قسمت زیر رو حتما داریم :
sequence
collaboration(نباشه هم طوری نیست.)
class
در مدل طراحی (Design model)برای کشیدن class ها باید نسبت به زبان و امکانات اون شناخت داشته باشید.
اما من حرفه ای نیستم و خیلی هم بی سوادم ...
لطفا بقیه هم نظراتشون رو بگن تا ما هم بهتر بدونیم ...
یا علی
خیلی از شرکت ها هستند که تولید خودکار این لایه ها رو در اختیار برنامه نویس قرار میدهند مثلا CodeSmith یا Nhibernate و ... ولی شخصا معتقدم اگه خودت بتونی یه tools بنویسی که بتونه این کار رو برات انجام بده و سورسشم دست خودت باشه در آینده انعطاف بیشتری خواهی داشت
اولین سوال framework چی هست؟نقل قول:
نوشته شده توسط Elham_gh
دومین سوال این لایه ها برای چی هستند و چرا لایه بندی می کنیم؟
سومین سوال اگر لایه ای وجود نداشته باشیم چگونه از frameworkها استفاده کنیم؟
تفاوت لایه های فیزیکی با لایه های منطقی چی هست و چه ارتباطی با هم دارند؟
در صورتی که وقت بزاری و بری دنبال جواب این سوالات اون موقع متوجه می شی که اصلا سوالتون اشتباه بوده.
در جوابتون این رو می تونم فقط بگم که طراح کاملا وابسته به تکنولوژی باید عمل کنه تا بتونه طرحشو پیاده سازی کنه.نقل قول:
نوشته شده توسط KambizZandi
وقتی صحبت از تکنولوژی می شه بحث سخت افزار ، نرم افزار ، سیستم عامل و و و بوجود می آید.
در بخش انالیز سیستم می تونم تا حدی باهاتون هم عقیده باشم.
شما دوست عزیز ظاهرا اطلاعاتت در این زمینه خیلی کمه ، این سوالهایی هم که کردی سالهاست جواب داده شده و به اثبات رسیده !نقل قول:
نوشته شده توسط javaphantom
امروزه کسی نیست که امتیازات کار کردن در یک چهارچوب مشخص(Framework) رو انکار کنه ،امتیازات طراحی به روش لایه ای هم سالهاست که برای شرکت های نرم افزاری مشخص شده و بحث سر مزیتهای اون خودش یه کتابه و از حوصله این تاپیک خارج ، امروزه کمتر شرکت معتبری رو میتونی پیدا کنی که در طراحی محصولش به صورت لایه ای عمل نکرده باشه
آقای Zachman (با تلفظ صحیح زچمن) در دهه 70 میلادی در مقاله ای که بعدها به کتاب پرفروش Enterprises Unified Processign With Zachman Framework تبدیل شد اثبات کرد که هر نرم افزار کامپیوتری به حداقل 3 لایه منطقی تفکیک شده و مستقل از هم قابل تقسیم هستنقل قول:
نوشته شده توسط javaphantom
خسته نباشی عزیز. من هدفم از طرح و پرسش این سوالات این نبود که شما بیایی و به من یادآوری کنی که عقب هستم و بلد نیستم وهرچی که نوشتی و یا اینکه جوابه منو بدی.نقل قول:
نوشته شده توسط Microsoft.net
هدف اصلی من این بود تا مطرح کنند این سوال که لایه به چه درد می خوره با وجود فریم ورک برن و تحقیق کنند تا اولا تعریف رو بدونند و بعد علت وجود لایه و نیازآنها.
ولی خوب یک جورایی جواب ایشون رو هم دادین ممنوم.
سلامنقل قول:
نوشته شده توسط javaphantom
شما هم اشتباه کردید که این سوال های (فکر کنم میگن استفهامی) رو کردید چون ایشون خودشون میدونن ...
و بهتره مسئله رو حل کنیم ... نه اینکه سوال رو با سوال جواب بدیم
موفق باشید.
یا علی.
ببخشید , اما گویا یه کم اشتباه شد.
دوست عزیز ممنون که یاد آوری می کنی برم مفاهیم framework و لایه و... رو یاد بگیرم!!!
سئوال من چیز دیگه ای بود!!
من خودم 12 ساله دارم کار می کنم. و 8 ساله که طراحی می کنم! پس حداقل این مفاهیم و می دونم.
سئوال من این بود که تا حالا , در طراحی هام تمام لایه ها و .... هر چی که لازم بوده طراحی می کردم. الان خیلی از پیاده سازها به استفاده از framework ها روی اوردن. که خیلی از اینها لایه های مختلف یک application و ارتباط بین لایه ها رو پیاده سازی می کنه. حالا با وجود چنین fraemwork هایی طراحی لایه ها رو چطور باید دید؟؟؟
می تونم نام یکی از فریم ورکهای استانداری که خودش لایه درست می کنه رو بدونم؟نقل قول:
نوشته شده توسط Elham_gh
اگر منظورتون ایجاد لایه های منطقی که از طریق pattern mvc هست که امروزه به اون معمار سه لایه هم گفته می شه که خود این معماری سه لایه جای بحث و گفته گو داره چون این pattern رو شما می تونید در یک معاری دو لایه و همینطور n لایه استفاده بکنید. ربطی به فریم ورک نداره این یک pattern هست و اگر frameworkی اونرو پیاده سازی می کنه مثل struts که تازه استادارد هم نیست ربطی به معماری چند لایه نداره.
فریم ورک spring روی pattern دیگه ای به نام Dependency Injection کار می کنه. یا مثلا فریم ورک hibernate که یک فریم ورک مستقل در لایه مخصوص خودش هست.
هیچ یک از این فریم ورکها لایه درست نمی کنند. البته هر چند شما ۲۰ سال توی کار design و معماری نرم افزار بودید و منی که ۲ ماه تازه وراد کار کامپیوتر شدم کوچکتر از این هستم که بخوام جلوی شما حرفی بزنم. ولی واقعا بعنوان یک استاد در طراحی و معماری سیستم های بزرگ و سازمانی و با این تجربه می تونم ازتون خواهش کنم یک فریم ورک استادنداری یا غیر استانداردی رو به من معرفی کنید که برای لایه درست کنه؟
لایه های مختلف یک application ؟نقل قول:
نوشته شده توسط Elham_gh
اگر منظورتون application های سازمانی Enterprise باشه در پست قبلی هم گفتم هر فریم ورکی باید توی لایه خودش اعمال وظیفه کنه بازم تولید لایه نمی کنه. من کار به استاندارد عقب مونده ماکروسافت ندارم که چه معماری استفاده می کنه. منظور من فریم ورکهای استاندارد بزرگی هست که امروزه برای برنامه های سازمانی بزرگ استفاده می شه و اونها هیچ کدام لایه درست نمی کنند یا لایه های application رو طراحی، تولید یا هرچی که دوست دارید بزاریداسمشونو تولید نمی کنند.
ما بحثی داریم به نام component و به دنبال اون SOA (service oriented architeture) بحث استاندار بودن و به دنبال اون معماری نرم افزار. من به شخصه تا حالا ندیدم فریم ورکی بیاد و تمامی این لایه ها رو بسازه یا تولید کنه بعد ارتباط بین اونها رو برفرار کنه، کار رو تمموم کنه بره.
اگر شما همچین فریم ورکی رو دارید از من به شما نصحیت البته من کوچیک شما هم هستم شما استاد بنده هستید ولی استفاده نکنید بهتره.
شرکتهای بزرگ IT دنیا در حال حاضر کلی هزینه می کنند تا فریم ورک های شون در لایه های مخصوص به خودشون با سرعت بالاتر و استفاده راحتر کار کنه و حتی باز فریم ورک جدا می سازند برای اینکه این رابطه ها رو بهم نزدیکتر کنه
خوب شما یکدونه همه کارشو دارید
LLBL و netTiersنقل قول:
نوشته شده توسط javaphantom
در مورد موضوع صحبت کنید،پستهای نامرتبط پاک شدند
من تا حالا دنبال این جور فریم ورک ها نبودمنقل قول:
نوشته شده توسط Elham_gh
اصلا نمیدونستم ...
ا زکدوم شرکت هستند ؟ قابل دانلود هست تا ما هم استفاده کنیم شاید به نتایجی رسیدیم ..
تا حالا من متوجه چیز دیگری بودم . جواب سوال شما رو میدادم و تا حالابا این نرم افزار ها کار نکردم که بتونم جواب دقیقی بدم.
ممنون
یا علی
دوست گرامی Modifier ,
من هم رسما با اینها هنوز کار نکردم. اما خوب استراتژی بسیاری از شرکتها و سازمانها الان داره به این سمت می ره. اینکه بشه free تو اینترنت پیدا کرد یا نه رو نمی دونم. اما احتمال زیاد هست چون خیلی هاشون که اصلا Open source هستند.
مشکل اينه که بيشتر برنامه نويسان سعي ميکنن خودشون رو در اجراي تمام قسمت هاي پروژه دخيل بدونن
منم اولا که داشتم برنامه نويسي ياد ميگرفتم (19 سال پيش) همينجوري بودم تا اينکه چند سال پيش وقتي با يکي دو تا تيم اونوري کار کردم تازه فهميدم که دانشگاه هاي اينجا و ebook هايي که هي دست به دست ميگرده و خلاصه تمام اين مواردي رو که ما بهشون استناد ميکنيمو بايد از نو بررسي کرد و چشم بسته به هيچ چيزي اعتماد نکرد.
قبلا گفتم و بازم ميگم بحث طراحي (حالا شما ها هر اسمي ميخواين روش بذارين) نبايد!! وابسته به زبان برنامه نويسي باشه که البته اين موضوع با توجه به نوع پروژه قابل بحث و مدل سازي هست.
مثلا در يک سيستم عامل قطعا نميشه platform رو نديده گرفت (کما اينکه اونم ميشه) ولي هرچه بيشتر به سطح برنامه هاي کاربردي نزديک ميشيم اين وابستگي بايد کم بشه.
من يک مدلي رو چند وقت پيش طراحي کردم که 36 تا لايه داشت. برنامه نويسايي بودن که به اين مدل ايراد ميگرفتن و نميتونستن اونو اجرا کنن اما با بچه هاي اونور براحتي اين پروژه اجرا شد. چون ديد آدم بايد صحيح باشه و هي به چيزايي که بلديم گير نديم.
بقيشو بعدا ميگم.
دوست عزیز KambizZandi
با فرض اینکه محیط پیاده سازی تاثیر گذار نیست در طراحی, حالا اگه طراحی تو طراحیش بیاد و از MultiInheritance استفاده کنه. برنامه نویس Net. چطور اونو پیاده کنه؟
در ضمن از اینکه شما یک همچین تجربه ایی رو دارید , خوشحال میشیم که از تجربیاتتون استفاده کنیم. چون چنین تجربیاتی واقعا کم و ارزشمندند.
اما در مورد سئوال من, گمانم من سئوالم رو بد مطرح می کنم که دوستان سئوال من رو اشتباه متوجه می شن. چون سئوال من ربطی به زبان برنامه نویسی نداشت.
زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟
اگر به لايه هايي که توسط Framework هابه طور اتوماتيک توليد ميشوند و Interface آن ها آگاهي داشته
باشيد ; چه ايرادي دارد که از آنها استفاده نکنيد؟ و اگر لايه هايي که لازم داريد در Framework موجود نيست يا شما اطلاعي از آن نداريد چه چاره اي غير از طراحي و توليد آن داريد؟
این جواب من بود یا توضیح سئوال من؟ چون من دقیقا همین سئوال رو دارم. با این تفاوت که ما همیشه مسلما می دونیم که farmework مون چه لایه هایی رو ایجاد می کنه. اما دقیقا سئوال من همینه "آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟"نقل قول:
نوشته شده توسط mak1387
ممنون
شرمنده . پشت دستگاه همکارم نشسته بودم که پیغام قبلی را پست کردم. حواسم نبود به اسم ایشون ثبت شد. پست قبلی مربوط به من هست .
بازم معذرت می خوام.
نقل قول:
نوشته شده توسط KambizZandi
با یک مطلب دیگه هم برخورد کردم در سایت مایکروسافت.در سایت اومده مدرک MCSD برای کسانی مناسب است که:
و بعدش می گه مطالبی که برای گرفتن این مدرک لازم دارید بلد باشید عبارتند از:نقل قول:
Choose the MCSD credential if you:
• Analyze and design leading-edge enterprise solutions with Microsoft development tools, technologies, and platforms.
• Have at least two years of experience in a lead developer role analyzing business and technical requirements, and defining solution architecture.
نقل قول:
Core exams: Web Application Development
Exam 70-3051: Developing and Implementing Web Applications with Microsoft Visual Basic .NET and Microsoft Visual Studio .NET
Exam 70-3151: Developing and Implementing Web Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET
Core exams: Windows Application Development
Exam 70-3061: Developing and Implementing Windows-based Applications with Microsoft Visual Basic .NET and Microsoft Visual Studio .NET
Exam 70-3161: Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET
Core exams: Web Services and Server Components Development
Exam 70-3101: Developing XML Web Services and Server Components with Microsoft Visual Basic .NET and the Microsoft .NET Framework
Exam 70-3201: Developing XML Web Services and Server Components with Microsoft Visual C# and the Microsoft .NET Framework
Core exam: Solution Architecture
Exam 70-3001: Analyzing Requirements and Defining Microsoft .NET Solution Architectures
Elective exams
Exam 70-2291: Designing and Implementing Databases with Microsoft SQL Server 2000 Enterprise Edition
Exam 70-2302: Designing and Implementing Solutions with Microsoft BizTalk Server 2000 Enterprise Edition
Exam 70-2342: Designing and Implementing Solutions with Microsoft Commerce Server 2000
Exam 70-235: TS: Developing Business Process and Integration Solutions Using Microsoft Biztalk Server 2006
Exam 70-3011: Managing, Organizing, and Delivering IT Projects by Using Microsoft Solutions Framework 3.0
Exam 70-3301: Implementing Security for Applications with Microsoft Visual Basic .NET
Exam 70-3401: Implementing Security for Applications with Microsoft Visual C# .NET
Exam 70-431: TS: Microsoft SQL Server 2005 – Implementation and Maintenance
Exam 74–135: Developing E-Business Solutions Using Microsoft BizTalk Server 2004
سلامت باشيدنقل قول:
نوشته شده توسط Elham_gh
ببينيد حرف من کلا اينه که هر جايگاهي در مسير پروژه بايد ايزوله بشه تا نتيجه ي خوبي بگيريم. اين حرف من توهين به ذهنيت افراد اينجا که به نوعي همکار من تلقي ميشن نيست. اما منظور اينه که طراح نبايد کاري به اجرا داشته باشه. اجرا نبايد کاري به تست داشته باشه. آناليز نبايد تو کار بقيه دخالت کنه و ...
اصلا به خاطر همين چيزاست که uml و rup و ... بوجود اومدن.
اما موضوع اينه که يک برنامه نويس حرفه اي وقتي مدلي استانداري رو براي اجرا بهش ميدن ديگه خودش بايد بتونه از پس اون بر بياد.
مثلا همين multi inheritance رو هر برنامه نويسي با روش خاصي ميتونه حل کنه مثل استفاده از interface با مديريت مرکزي عناصر که البته همه جا خوب نيست چون گلوگاه ايجاد ميکنه يا حتي استفاده از property هايي که به کلاسهاي خاصي وصل ميشن.
به هر حال من احساس ميکنم اين بحث داره تبديل به يک مقاله خوب و ارزشمند ميشه و بسيار مايلم دوستان ديگر هم طرح نظر کنن تا همه بتونيم مطالب جديدي ياد بگيريم.
اما دوست عزیز , جناب KambizZandi
بحث من اصلا دخالت برنامه نویس ویا بالعکس نیست. من هیچ دخالتی تو کار برنامه نویسامون ندارم. اونا هم کاری به کار من ندارند.
الان سیاست کاری بر مبنای استفاده از یک فریم ورک آماده است. که این فریم ورک 5 لایه می سازه.
من نمی تونم به عنوان طراح بیام یک سیستم با معماری 3 لایه طراحی کنم که هیچ ربطی هم به لایه هایی که توسط فریم ورک ساخته می شه نداره. می تونم؟
حالا می گم من به عنوان طراح چی کار کنم؟ اون لایه ها رو تو طراحیم بیارم ؟ که جالب نیست. نیارم که خوب نمیشه!!! پس چه کنم؟
بعدشم اینکه شما می گید برنامه نویس خودش می دونه که چه جوری multiInheratance رو پیاده کنه , که با توجه به سواد نه چندان بنده درست نیست.درسته؟
دوستان دیگه نظری در این مورد ندارند؟
من فکر ميکنم موضوع طراحي application با موضوع نقشه هاي اجراي يک طراحي قاطي شده
هر کدوم موضوع جداگانه اي هستند
ممکن هست در طراحي نقشه ي اجرايي يا همون developing diagram ها لايه ها رو بياريم اما آوردن لايه ها در طراحي اصلي application رو تا حالا نشنيده بودم
اين موضوع برميگرده به اينکه يک تيم بياد و کل پروژه رو از 0 تا 100 طراحي کنه که اينکار غلطه. بلکه هر تيم پس از دريافت طراحي اصلي خودش مياد و با توجه به توانايي هاش طراحي لايه هاي زيرين رو انجام ميده
موفق باشيد
کی همچین چیزی گفته؟! مثلا یکی بخواد بصورت Test-Driven کار کنه، چطور میتونه در مراحل مختلف پروژه کاری به تست نداشته باشه؟!نقل قول:
اما منظور اينه که طراح نبايد کاري به اجرا داشته باشه. اجرا نبايد کاري به تست داشته باشه. آناليز نبايد تو کار بقيه دخالت کنه و ...
حتی مایکروسافت هم به این نتیجه رسیده که اینی که شما میگید، نتیجه جالبی نداره:
http://blogs.msdn.com/e7/archive/200...he-bottom.aspx
ایزوله کردن لایه های یک نرم افزار به معنای ایزوله کردن کار تیم نرم افزاری از هم نیست. البته منظور دخالت در کار هم نیست، بلکه باید از کار هم آگاه باشند، و حتی در بخش هایی از کار دیگران مشارکت داشته باشند.
این دیگه جدید بود.نقل قول:
نوشته شده توسط KambizZandi
الان داره طراحی به سمتی می ره که تا جای ممکن همه چی مدل شه تا برنامه نویس کمترین اثر و تصمیم رو داشته باشه تا جایی که دارن هرروز بیشتر روی case tools ها کار می کنند که بتونه خودش کد لازم رو تا جای ممکن پیاده کنه. حتی تا طراحی و مشخص کردنstored procedure ها.
با این حرف شما 2 تا شاخ الان روی سر اینجانب سبز شده.
حتی شرکت موفقی رو تو تهران می شناسم که اولین شرکتی بود که از RUP استفاده کرد و وقتی با مدیر عاملش حرف می زدم(4 سال پیش) می گفت ما اصلا کد نمی زننیم, فقط مدلهامونو درست در میاریم.و ابزار کدمونو تولید می کنه. البته با اون اغراق قبول نداشتم و لی خوب. این روش کار درسته.
ببنید RUP چند نقش برای آنالیز و طراحی در نظر گرفته و با چه ظرافتهایی و چند نقش برای پیاده ساز. برای اینکه تا اونجا که ممکنه از اعمال سلیقه برنامه نویس جلو گیری شه.
حتما حق با شماست
اما تجربه ي من و کارهاي موفقي که ديدم چيز ديگه اي ميگه
اگر قرار باشه هر کسي تو پروژه يه چيزي به فکرش برسه و اونو اجرا کنه که سنگ رو سنگ بند نميشه
هرکسي از طراح گرفته تا تستر بايد کارشو طبق الگوهايي که براش تعريف ميشه انجام بده و 100 البته از هنر خودشم براي بهترين حالت اجرا استفاده کنه
اما اگر بخواد تا يک ايده به ذهنش رسيد اونو اجرا کنه که پروژه از بين ميره
بنابراين طراحان بخش هاي مختلف (حتي طراحي و مدلينگ تست) وطيفشون اينه که تمام نقشه ها رو با دقت بکشن نه اينکه يه چيزي بگن و بقيه رو تو دردسر بندازن
موفق باشيد
بله، هر کس باید مطابق الگویی که براش تعریف شده کار کنه، ولی باید در این کار تعامل مناسبی با سایر افراد داشته باشه. بخصوص که هر Iteration وقتی شروع میشه، بازخورد کار تمامی افراد تیم (طراح، تستر، برنامه نویس، و...) در Iteration قبلی، بر آن اثر میزاره.نقل قول:
اگر قرار باشه هر کسي تو پروژه يه چيزي به فکرش برسه و اونو اجرا کنه که سنگ رو سنگ بند نميشه
هرکسي از طراح گرفته تا تستر بايد کارشو طبق الگوهايي که براش تعريف ميشه انجام بده و 100 البته از هنر خودشم براي بهترين حالت اجرا استفاده کنه
اما اگر بخواد تا يک ايده به ذهنش رسيد اونو اجرا کنه که پروژه از بين ميره
طراح وظیفه مدیریت تکنیکی (نه تجاری یا مدیریتی) پروژه را برعهده داره، پس باید تعاملش با سایر اعضاء بیشتر باشه، هر اعضاء به وی به عنوان یک تکیه گاه مطمئن نگاه کنند. طراح نباید مانع از ابراز ایده های افراد شود. بلکه باید ایده ها را راهبری کند تا به آنچیزی که در Vision مدنظر قرار گرفته نزدیک شوند. برنامه نویس یا Tester ایی که ابتکار عمل و امکان بیان ایده هایش ازش گرفته شود، محصول خوبی هم تولید نمی کند! شما سعی می کنید نخبه ترین و بهترین افراد را برای تیم خودتان جمع آوری کنید، در هنگام استخدام به استعدادهای آنها و توانایی هایشان دقت می کنید، پس منطقی نیست که وقتی آنها را استخدام کردید، ایده و ابتکار عملشان را از آنها بگیرید، و از آنها انتظار داشته باشید که مثل یک ماشین بی فکر فقط ایده های شما را پیاده سازی کنند! اگر به آنها و ایده هایشان بها بدهید، و ایده های آنها را در کانال های مناسبی که می دانید به سود پروژه هست، هدایت کنید، محصول شما کیفیت بیشتری خواهد داشت. اعضاء تیم شما هم رضایت بیشتری خواهند داشت. یک طراح خوب باید مطمئن شود که اعضاء تیمش به طرح آماده شده و مسیری که طی می کنند اعتقاد دارند، و آن را کاملا درک می کنند. برای اینکه این اعتماد بوجود بیاد، طراح باید در تمامی مراحل کار اعضاء تیمش حضور داشته باشه، البته نه اینکه در کارهای تیم دائما دخالت کند، و حرف خودش را به کرسی بنشاند، بلکه با اعضاء تیم همراه باشد، نظراتشان را بشنوند، هر جا از وی راهنمایی خواستند، به آنها کمک کند، هر جا احساس کرد انتقادی از وی یا طرحش وجود دارد، دیدگاههای منتقدات را با رعایت انصاف بشنود، اشتباهات خودش را به راحتی قبول کند. این نوع رفتار باعث می شود که به مرور اعضاء تیم با نظرات و طرز فکر یکدیگر، بخصوص ایده های طراح بیشتر آشنا شوند، و توانایی های یک دیگر را بهتر بشناسند. در این صورت، طراح زحمت کمتری برای توجیه اعضاء تیم خواهد کشید، چون اعضا بیشتر با طرز فکر او آشنا هستند، و با یک توضیح مختصر هم متوجه منظور وی می شوند.
از نظر من نمودارهای بسیار دقیق فقط زمانی واقعا کاربرد دارند که Implementer شما یک نرم افزار زبان نفهم باشد که باید همه جزئیات را برایش مشخص کرد، وگرنه کدهای بی کیفیت تولید می کند. اما برای اعضاء تیم باید به جزئیات نمودارها تا حدی پرداخته شود که برای اعضاء قابل درک باشد.نقل قول:
بنابراين طراحان بخش هاي مختلف (حتي طراحي و مدلينگ تست) وطيفشون اينه که تمام نقشه ها رو با دقت بکشن نه اينکه يه چيزي بگن و بقيه رو تو دردسر بندازن