در اسکرام اعضا برابرند یا هر کدام نقش و سمتی دارند؟

خیلی وقت‌ها تو استانداردها و روش‌های مدیریت پروژه به توصیه‌های متناقض بر می‌خوریم. شاید برای شما هم پیش آمده باشه،  مثلا تو خیلی از چهارچوب‌های چابک با تشویق اعضای تیم پروژه مخالفیم، در حالی که داشتن نظام تشخیص و تشویق تو PMBOK لازمه!خوب، حالا کدوم درست می‌گه؟ باید چیکار کنیم؟ 

یا مثلا داشتن تعریف‌های دقیق و شفاف از نقش‌ها و مسئولیت‌ها تو PRINCE2 واجبه (از اصول زیربناییه)، در حالی که مثلا تو تیم تولید اسکرام تعریف هیچ نقش و سمتی مجاز نیست، همه مثل هم هستن. کدوم درست می‌گه؟ با من همراه بشید تا به این سوال پاسخ بدم

Agile دوای درد تیم ها - قسمت دوم

سلام امیدوارم خوب و سرحال باشید؛ در مقاله اول اجایل دوای درد تیم ها برای شما از نیاز هایی که باعث شد اجایل متولد بشه گفتم، این که چه اتفاقی افتاد که آن 17 نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال 2001 اقدام به انتشار چنین روشی کردند! در ایم مقاله سعی می کنم به شما را با توسعه نرم افزار به روش اجایل به زبان بازاری آشنا کنم! پس با من همراه باشید!

Agile دوای درد تیم ها - قسمت اول

می خواهم خیلی ساده و به زبان بازاری راجع به تفکر چابک یا اجایل (Agile) با شما صحبت کنم؛ دانستن این مطلب به شما کمک می کند موفق تر از قبل باشید، قبل از اینکه چیزی به اسم نرم افزار یا کامپیوتر (به معنای امروزی) وجود داشته باشه شرکت ها و صنعت گرانی مثل فورد یا تویوتای ژاپن با چالش هایی در زمینه تولید محصولات مشتری پسند و با کیفیت مواجه بودند. اونا سعی می کردند که با هزینه پایین و کیفیت بالا یک روش تولید کشف کنند.خب طبیعیه که روش های زیادی را ساختن و پاکش کردند! و ناگهان کامپیوتر ها به دنیا آمدند یعنی ببخشید پا به خانه ها و سازمان های ما گشودند که صنعتی جدید به اسم توسعه نرم افزار به وجود آمد، هر جا سخن از محصول است پای یک مشتری در میان است ( بعله) و نتیجه صنعت طراحی و توسعه نرم افزار تولید محصولات نرم افزاری است. هر جا پای مشتری در میان باشد حق هم با او خواهد بود. با به وجود آمدن این صنعت شرکت های زیادی وارد این صنعت شدند و این معادل با تولید محصولات زیاد بود، آیا محصولات با کیفیت بودند؟ آیا مشتریان خوشحال بودند؟ آیا توسعه گران نرم افزار ها از کار خود راضی بودند؟ و …