روش شناسی برنامه ریزی چابک روش توسعه چابک

سیستم کارخانه تویوتا قبلاً به یک مدل مدیریتی کلاسیک و موفق تبدیل شده است. هر کارمند شرکت این فرصت را داشت که در هر زمان نوار نقاله را متوقف کند تا نقص، نقص عملکرد یا پیشنهاد منطقی خود را ارائه دهد. فلسفه چابک بر این رویکرد استوار است. در ابتدا متدولوژی Agile در حدود 10-15 سال پیش روشی برای توسعه نرم افزار در تیم های کوچک بود. AT این لحظهروش شناسی چابک فرهنگ جدیدی برای مدیریت شرکت های بزرگ است. امروزه هر مدیر مترقی می داند Agile چیست.

محصولات و خدمات، به عنوان یک قاعده، طبق یک طرح کلاسیک واحد ایجاد می شوند. این امر به ویژه برای صنعت IT صادق است. چنین طرحی آبشار یا متدولوژی توسعه تکراری نامیده می شود و در زبان انگلیسی- توسعه آبشار ("آبشار"). چرا این طرح به این نام نامگذاری شده است؟ نکته این است که اگر قبلاً طرح محصول نرم افزاری را تأیید کرده اید، نمی توانید آن را به حالت تعلیق درآورید یا قبل از اجرا تنظیماتی را انجام دهید. این یک اصل کاملا متفاوت دارد. روش شناسی چابکآبشار مفهومی است که در آن صدق نمی کند. این یک رویکرد کیفی جدید برای توسعه محصول است. این روش مبتنی بر یک ایده ساده است - هر شرکت کننده این فرصت را دارد که پیشنهادات مفیدی برای بهینه سازی فرآیند ارائه دهد، نوار نقاله را متوقف کند تا در وظایف و علت مشترک تجدید نظر کند.

روش شناسی چابک دارای چارچوبی است که دارای تعدادی ویژگی است. از جمله:

• پاسخ سریع به تغییرات
• سازماندهی مستقل فرآیند تولید.
• قابل پیش بینی بودن
• وجود پیوسته و ثابت بازخورد.
• جداسازی ریسک ها

در بسیاری از شرکت ها، هنگام توسعه محصولات، متخصصانی که وظایف مهم تولید را حل می کنند، در بین بخش های مختلف توزیع می شوند که اغلب در تضاد با یکدیگر هستند. این امر به ویژه برای کارمندان بخش عملیاتی، توسعه دهندگان و آزمایش کنندگان صادق است. اگر محصولات به درستی فروخته نشوند و از این طریق درآمد کسب کنند، طرفین درگیری یکدیگر را مقصر می دانند. در عین حال معمولاً در چنین مواقعی همه مقصرند.

روش شناسی چابک - رویکردی که شامل حضور همه کسانی است که در حال توسعه هستند نرم افزار. در عین حال، هر متخصص کار خود را انجام می دهد. روش شناسی چابک این امکان را فراهم می کند که ببینیم همه شرکت کنندگان در فرآیند با یک هدف متحد هستند - ایجاد محصولات با کیفیت برای مشتریان خود.

هنگامی که متدولوژی Agile اعمال می شود، کل فرهنگ تجاری شرکت تغییر می کند. برنامه های MBA شامل یک دوره کامل در مورد ساختار سازمانی یک شرکت است که در مطالعه آن می توان با اصطلاح "تعادل" مواجه شد، زمانی که همه کارمندان و شرکت کنندگان در استارت آپ ها و استارت آپ ها مشکلات رایج را حل می کنند. تمرین نشان می دهد که در چنین شرکت هایی است که تیم ها متحدتر هستند و با کارایی و کارایی بالا کار می کنند. وقتی صحبت از آوردن ایده های جدید به بازار و افزایش کارایی می شود، روش Agile بهترین ابزار است.

البته برخی از شرکت ها نیازی به متدولوژی Agile ندارند. ما به عنوان مثال در مورد ادارات دولتی صحبت می کنیم ، زیرا اساس فعالیت آنها هنجارهای قانونی است. اگر قوانین بازی به طور منظم تغییر کند، تعامل با دولت غیرممکن است.

به این معنا که زیرساخت های سازمانی را می توان در دو نسخه ارائه داد که کاملاً متفاوت از یکدیگر هستند. اولی یک شرکت بوروکراسی سختگیرانه است که تعدادی تشریفات را رعایت می کند. این گزینه حق وجود دارد و در شرایط خاص به خوبی کار می کند. نوع دوم، استارت‌آپ‌هایی هستند که افرادی را با یک دیدگاه و هدف مشترک گرد هم می‌آورند که اساساً چیز جدیدی خلق می‌کنند. متدولوژی چابک البته به تیم احساسی که بر روی تولید یک محصول با کیفیت کار می کنند نزدیکتر است. در صورت بروز مشکلات در هر یک از مراحل، آنها در چارچوب روش Agile توسط همه متخصصان شرکت یا شرکت کنندگان استارت آپ حل می شوند.

اصول اولیه روش شناسی چابک

یک مانیفست چابک وجود دارد که در مورد اصول اساسی روش شناسی صحبت می کند:

1. مهمترین چیز این است که یک محصول ارزشمند را به طور منظم و از قبل تحویل دهید و در نتیجه نیاز مشتری را برآورده کنید. مطابق با این اصل روش شناسی Agile، سازندگان محصول موظفند نه تنها الزامات ذکر شده در اسناد پروژه را اجرا کنند، بلکه به مصرف کننده نیز در اسرع وقت اطلاع دهند که چه نوع محصولی با چه ویژگی ها و ویژگی هایی خواهد بود. در صورتی که محصول رضایت مشتری را جلب نکرد، اصلاح آن با در نظر گرفتن نظرات عاجل ضروری است. از آنجایی که وارد شدن به محیط بازار محصول جدید، خطر بزرگی برای اشتباه وجود دارد، استفاده از آن منطقی است الزامات فنیبرای ایجاد حداقل محصول قابل دوام (MVP) که وظیفه اصلی آن بررسی میزان تقاضای کیفیت های کلیدی در بین خریداران و ارزیابی سطح تقاضا است.
2. الزامات را می توان تغییر داد و اگر در مورد بهبود کیفیت رقابتی محصول صحبت کنیم، این به طور مثبت درک می شود. معمولاً در پایان مرحله نهایی توسعه تغییر می کنند. این اصل از روش شناسی Agile امروزه بسیار مهم است، زیرا محصولات صنایع پیشرفته در در اسرع وقتمنسوخ می شود و جای خود را به جدید می دهد. شما می توانید تعدادی از الزامات را برای محصول در پایان ساخت آن ایجاد کنید. این معمولاً به دلیل تغییرات در بازار یا در محیط رقابتی ایجاد می شود. توجه داشته باشید که اجرای این اصل اگر در مورد مدل مدیریت آبشاری صحبت می کنیم یا واقعی باشد غیرممکن است، اما برای اسپانسر مبلغی دور از انتظار خواهد بود. اما هرچه فناوری‌های بیشتری با هم ادغام شوند، آماده‌سازی نسخه بعدی محصول برای جلوتر ماندن از رقبا مرتبط‌تر خواهد بود.
3. تیم و مشتری باید به طور مستمر در تمام مراحل تولید محصول تعامل داشته باشند. این قانون تقریباً مشابه خواسته های مشتری است. از همه مهمتر است. اگر تعامل دائمی وجود نداشته باشد، دستیابی به اهداف تعیین شده دشوار است.
4. روش شناسی چابک بیان می کند که تنها متخصصان با انگیزه باید در اجرای پروژه ها مشارکت داشته باشند. مراقب ایجاد شرایط مناسب باشید و به کارشناسان اعتماد کنید. در این صورت احتمال اجرای پروژه با کیفیت بسیار بالاست. علم مدرننشان می دهد که تحریک کار فکری با انگیزه های مالی دشوار است. بنابراین، شما باید فقط با متخصصانی همکاری کنید که انگیزه اصلی آنها خود پروژه است. تنها چیزی که نیاز دارند این است که بتوانند در شرایط قابل قبول کار کنند و اعتماد مشتری را جلب کنند.
5. بهترین راهارتباط تماس شخصی است مطلوب است که همه افراد درگیر در پروژه در یک منطقه مشترک واقع شوند. بگذارید یک ساختمان باشد. در حالت ایده آل، خود مشتری نیز باید آنجا باشد.
6. اگر محصول کار کند، پروژه پیشرفت می کند. مشتری به محصول نهایی با ویژگی های خاص علاقه مند است. یکی دیگر از گام های موفقیت آمیز دیگر برای او معنایی ندارد. مشتری باید ببیند که محصول در حال توسعه است و مهمتر از همه این که کار می کند و شرایط ذکر شده را برآورده می کند. اگر شکل و محتوای آن به مدل مورد نظر نزدیک باشد، توسعه دهندگان به طور موثر کار می کنند.
7. حامیان مالی، مشتری و توسعه دهندگان باید از سرعت ثابت فعالیت مراقبت کنند. اگر همه شرکت کنندگان در فرآیند با یک ریتم ثابت عمل کنند، دیگر نگران احتمال عجله کار یا عدم رعایت ضرب الاجل ها نیستند.
8. همچنین باید به برتری فنی و کیفیت طراحی توجه شود. روش شناسی چابک بیان می کند که توسعه یک پروژه باید انعطاف پذیر باشد، بدون اینکه کیفیت محصول را به خطر بیندازد و ویژگی های آن را ساده کند. توجه داشته باشید که اغلب برای تسریع روند ایجاد یک پروژه و بهینه سازی آن به این کار متوسل می شود.
9. اصل سادگی را فراموش نکنید. با استفاده از آن، احتمال انجام اقدامات غیر ضروری را به حداقل می رسانید. نکته ساده کردن ویژگی های محصول نیست، بلکه خلاص شدن از شر عملیات غیر ضروری و درج نکردن چیزی غیر ضروری برای استفاده مورد نظر در پروژه است.
10. تیم های خودسازمان همیشه بهترین ایده های معماری، فنی و غیره را تولید می کنند. نویسندگان مانیفست چابک در این مورد متقاعد شده اند. بنابراین، همه اعضای تیم باید الزامات را توسعه دهند و با هم تصمیم بگیرند. اگر اعضای تیم علایق و اهداف مشترک داشته باشند، خود سازماندهی مؤثرتر می شود.
11. شرایط بیرونی دائما در حال تغییر است. در این راستا باید مدام با شرایط تحلیل و تطبیق داد، به دنبال راه هایی برای بهبود کارایی فعالیت ها بود. متدولوژی چابک به طور خاص بر روی انعطاف پذیری توسعه دهندگان متمرکز است. این چیزی است که شما باید برای آن تلاش کنید.

نظر متخصص

دیدگاه های روش شناسی چابک در روسیه

آندری کوچشکوف,

تحلیلگر ارشد انتشارات OAO Prosveshchenie

روش شناسی چابک دارای چندین مزیت است که مهمترین آنها انعطاف پذیری و توانایی سازگاری، سازگاری با هر محیط و فرآیند سازمانی. روش شناسی چابک - بهترین گزینهبرای پروژه هایی که پایان آنها "باز" ​​است. این می تواند ایجاد یک بازی کامپیوتری باشد، سیستم عاملیا خدمات اینترنتی در عین حال، به دلیل انعطاف پذیری، در نهایت می توانید تمرکز خود را از دست بدهید و قابلیت پیش بینی را کاهش دهید.

تشخیص اشتباهات در استفاده از رویکرد چابک از کاستی های روش شناسی چابک بسیار مهم است. مدتی طول می کشد تا مزایای روش شناسی محقق شود. تطبیق رویکرد با وضعیت فعلی در یک تجارت خاص ضروری است و در این دوره ممکن است اشتباهات زیادی مرتکب شود. اما واقعیت همچنان باقی است: روش شناسی چابک در حال تبدیل شدن به یکی از محبوب ترین پارادایم ها هم در روسیه و هم در سراسر جهان است.

روش های چابک: چابک، ناب، اسکرام و دیگران

مانیفست چابک اصول خاصی را تعریف می کند. بر اساس آنها، یک متدولوژی توسعه چابک Agile شکل گرفته است.

• مدل سازی چابک (AM). رویه‌های مدل‌سازی (از جمله تأیید با کد مدل) و مستندسازی در طول توسعه نرم‌افزار در اینجا اعمال می‌شوند. توجه کمتری به رویه‌های طراحی و ساخت نمودارها در UML می‌شود. در مورد زمینه هایی مانند توسعه، آزمایش، مدیریت پروژه، استقرار و نگهداری چیزی نمی گوید.
• Agile Unified Process (AUP) یک نسخه یکپارچه از روش RUP (IBM Rational Unified Process) است که توسط اسکات آمبلر شکل گرفته است. AUP مدل توسعه نرم افزار را برای برنامه های کاربردی تجاری تعریف می کند.
• روش داده چابک (ADM) یک روش تکراری برای توسعه نرم افزار چابک در یک مجتمع است که بر توسعه راه حل ها و الزامات تاکید دارد. تیم های متقابل مختلف با یکدیگر همکاری می کنند.
• روش توسعه سیستم های پویا (DSDM) یک روش افزایشی و تکراری بر اساس توسعه سریع برنامه (RAD) است. تاکید بر به حداکثر رساندن مشارکت مصرف کننده نهایی در خلق محصولات است.
• فرآیند یکپارچه ضروری (EssUP). نویسنده رویکرد ایوار یاکوبسون است. این رویکرد دارای روش های توسعه نرم افزار تکراری است. تاکید بر معماری محصول و بهترین شیوه های تیم برگرفته از RUP، CMMI و Agile Development است. ماهیت این ایده استفاده از روش ها و تکنیک هایی است که در یک مورد خاص به کار می روند. این انتخاب آنهاست که مبنای تعیین فرآیند هدف است. این رویکرد با روش ها و شیوه های مرتبط با RUP متفاوت است. همچنین انعطاف پذیری و توانایی جداسازی عناصر ضروری از هر چیزی که در دسترس است وجود دارد.
• برنامه نویسی شدید (XP) یا برنامه نویسی شدید. ماهیت روش استفاده از بهترین تکنیک های موجود در زمینه توسعه نرم افزار و بهبود آنهاست. این رویکرد و رویه رایج با یکدیگر متفاوت است، به ویژه در این که در مورد دوم، برنامه نویس یک بررسی متوالی از کد نوشته شده توسط همکار خود را انجام می دهد. برنامه نویسی افراطی شامل آزمایش موازی است که منجر به انتشار سریع تر محصول می شود، اما خطرات را نیز افزایش می دهد.
• توسعه مبتنی بر ویژگی (FDD). به عنوان بخشی از استفاده از روش، وجود دارد ممنوعیت عمده، که شامل این واقعیت است که اجرای هر عملکرد باید در عرض دو هفته و نه بیشتر انجام شود. در حالت ایده آل، آن را در یک حرکت توسعه یافته است. اگر این امکان پذیر نباشد، تابع به چندین تقسیم شده و به آرامی اجرا می شود.
• دریافت واقعی (GR) - هنگام استفاده از روش، به رویه های مشخصات عملکردی مورد استفاده برای برنامه های وب متوسل نشوید. توسعه از پشت شروع می شود، یعنی ابتدا به طراحی و رابط و سپس به محتوای کاربردی فکر می کنند.
• OpenUP (OUP) - RUP اساس توسعه رویکرد است. این روش یک روش تکراری- افزایشی را برای ایجاد نرم افزار تعریف می کند. به عنوان بخشی از رویکرد، در مورد گفته شده است چرخه زندگیتوسعه (مراحل راه اندازی، پالایش، توسعه و انتقال به مشتری). این روش در چند مرحله با بررسی نقاط کنترلی خاص اجرا می شود که به افزایش کارایی کنترل و نظارت بر اجرای پروژه کمک می کند. تمام تصمیمات مربوط به پروژه به موقع گرفته می شود.
• توسعه نرم افزار ناب این رویکرد مبتنی بر مفهوم مدیریت شرکت تولید ناب (تولید ناب، تولید ناب) است.
• اسکرام یکی از پرطرفدارترین روش های توسعه نرم افزار است و قوانینی را برای مدیریت فرآیند تولید با استفاده از روش های شناخته شده تعریف می کند. تاکید در این مورد بر مشارکت مشتری در توسعه است (در صورت تکمیل مرحله بعدی، امکان تغییر یا شفاف سازی الزامات برای محصولات در حال ایجاد وجود دارد). این به شما امکان می دهد کاستی ها را شناسایی کرده و محصول را اصلاح کنید.

متدولوژی Agile Scrum یکی از فناوری های محبوب است

تقریباً رایج ترین روش چابک اسکرام ("Scrum") است. این نام از راگبی گرفته شده است. در حال حاضر این نام ساختارمندترین متدولوژی توسعه Agile است. "اسکرام" در زمین ورزشی یک اقدام تیمی شدید با هدف دستیابی به هدف - گرفتن توپ برای حمله بعدی حریف است.

دوره اسکرام کوتاه است. بهترین ورزشکاران با تمرینات عالی در این مرحله از راگبی شرکت می کنند، زیرا کاملاً آسیب زا است. اگر بازیکنان آموزش دیده و قوی وجود نداشته باشند، اسکرام به سادگی انجام نمی شود. روش اسکرام در روسیه روز به روز گسترده تر می شود. بیایید با جزئیات بیشتر در مورد آن صحبت کنیم.

اسکرام مبتنی بر اسپرینت است. این نام اقدامات ثابت کوتاه مدت برای ایجاد و ارائه یک محصول کارآمد با ویژگی های جدید به مصرف کننده است. قابلیت های آن در عین حال فراتر از توانایی های قبلی است. اصطلاح "اسپرینت" ثابت است و قابل پیش بینی بودن و انعطاف پذیری فرآیند ایجاد به آن بستگی دارد. اگر بازه زمانی کوتاه باشد، خوانش های انعطاف پذیری و قابل پیش بینی بیشتر می شود، اما هزینه نسبی هر تکرار و همچنین زمان صرف شده برای سازماندهی و ملاقات با مشتری و اعضای تیم نیز افزایش می یابد.

یک عنصر مهم روش شناسی عقب ماندگی محصول است. این لیستی از الزامات برای نتیجه نهایی است. الزامات در اینجا به وضوح بر اساس سطح اهمیت ساختار بندی شده اند. از این لیست است که وظایف برای اسپرینت های بعدی انجام می شود. این فهرست در راستای شفاف سازی مشخصات و فروش محصولات قابل اصلاح و تکمیل است.

یک مرحله برنامه ریزی وجود دارد که در آن کیفیت های عملکردی جدید محصول ایجاد شده برای سرعت بعدی مشخص می شود. پس از حل مشکل، یک بک لاگ اسپرینت (Sprint Backlog) کامپایل می شود. در طول مدت خود بدون تغییر باقی می ماند.

این روش همچنین نقش های ساختار یافته را در پروژه تعریف می کند:

• اسکرام مستر یک واسطه بین تیم و مشتری است.
• مالک محصول نماینده مشتری است، تشکیل می دهد، بک الگ محصول را اولویت بندی می کند و نتایج میانی کار را می پذیرد.
• تیم - یک تیم پروژه که در آن هیچ نقش جداگانه ای وجود ندارد. این یک سیستم خودسازماندهی است که شامل متخصصان با انگیزه متقابل است.

این متدولوژی تعدادی از مزیت ها را به سرمایه گذاران ارائه می دهد که عبارتند از:

• فرصتی برای صرفه جویی در هزینه با کار نکردن در اسناد پروژه برای مدت طولانی فراهم می کند.
• به شما امکان می دهد بودجه پروژه را به طور کامل کنترل کنید.
• امکان تعدیل بدون ضرر مالی قابل توجه برای شرکت را فراهم می کند.
• به شما این امکان را می دهد که محصولات را زودتر راه اندازی کنید و اولین درآمد را از آن بدست آورید.

مشکل اصلی در این مورد سوال است ثبت قانونیاین نوع فعالیت و تعامل با تیم توسعه خارجی است.

چرا به یک روش مدیریت چابک نیاز دارید؟

• این سیستم به شما امکان می دهد در یک دوره بحرانی و در شرایط نامشخص احساس خوبی داشته باشید، درآمد کسب کنید، از کسب و کار خود محافظت کنید، از منابع و فرصت های موجود به درستی استفاده کنید.
• روش‌های چابک به عنوان شرکت‌های بزرگی که چابک را پیاده‌سازی می‌کنند، مورد علاقه است روش های مدیریتیو همچنین شرکت های کوچک. برای آخرین متدولوژی Agile بهترین گزینه است. ما در مورد موسسات پذیرایی صحبت می کنیم. کلینیک های دندانپزشکیو دفاتر، نمایندگی های خودرو؛ علاوه بر این، روش چابک به شما امکان می دهد فرآیندهای تجاری را در زمینه هایی مانند سازمان تنظیم کنید فعالیت اقتصادی خارجی، سیستم های فروش ساختمان و مدیریت بحران.
• متدولوژی چابک در مدیریت، بازاریابی، صنعت مالی، مدیریت پرسنل کاربرد دارد. به لطف آن، می توانید به اجرای پروژه فوق سریع و نتایج عالی دست پیدا کنید.
• روش شناسی چابک اول از همه تفکر انعطاف پذیر و فقط ابزار است. برای استفاده موفقیت آمیز از آن، باید تغییرات خاصبه ذهنیت، فرهنگ کار با پروژه ها در شرکت.
• Agile روش های زیادی دارد. امروزه محبوب ترین ها اسکرام و کانبان هستند.
• روش چابک کمک می کند تا کسب و کار خود را با در نظر گرفتن قابلیت ها، منابع و مهارت های عملی کارمندان موجود به سطح جدیدی برسانید.
• متدولوژی چابک برای هر شرکتی مناسب است که بر ایجاد درآمد بیشتر و افزایش نفوذ در محیط بازار متمرکز باشد.
• روش شناسی چابک جستجو و معرفی فناوری های جدید مرتبط با پیشرفت، توسعه داخلی را فراهم می کند فعالیت کارآفرینی، رویکرد خلاقیت و تفکر در سازمان های بزرگ.

همه موارد فوق فقط شروع است. بسیاری از کارشناسان تجارت و رهبران شرکت های بزرگ مطمئن هستند: روش شناسی چابک آینده صنعت اقتصادی مدرن است.

نظر متخصص

اجرای متدولوژی چابک برای بهبود کارایی کارکنان

ماریا اونوچینا,

مدیر بخش مدیریت دارایی در گروه مدیریت دارایی Becar، مسکو

ما فضای اداری خود را برای حرکت به سمت مدیریت چابک تغییر داده ایم:

مرحله ی 1.سازماندهی محل کار.

در عرض یک ماه، محل کار پرسنل را مطالعه کردیم، بخش هایی را که در آن قرار داشتند را شناسایی کردیم عملیات کارآمدسکوت کامل مورد نیاز است (این، به عنوان مثال، حسابداری است)، توجه را به بخش هایی جلب کرد که متخصصان در آنها کار می کنند، که دائماً دور هستند و بیش از 3 ساعت در روز را در دفتر نمی گذرانند. ما برنامه ای دریافت کردیم که تعداد کارمندان و ویژگی های وظایف شغلی آنها را نشان می داد. بر اساس اطلاعات دریافتی، بازسازی دفتر را آغاز کردیم.

برای کارمندانی که فعالیت آنها مستلزم حضور دائمی در محل کار است، مکان های دائمی تجهیز شده است. به کارکنان سیار فضای موقتی در فضای باز ارائه شد. می توانید به آنجا بیایید، مکان مورد علاقه خود را انتخاب کنید و دسترسی از راه دور را روشن کنید. ما همچنین به مناطق غیررسمی توجه کردیم: اتاق های تفریحی، مذاکرات و کافه کاری.

ما سعی کردیم فضای دفتر را طوری سازماندهی کنیم که کارمندان این فرصت را داشته باشند که در هر زمان مکان را تغییر دهند:

• در صورت لزوم، تنها باشید.
• در مینی گروه ها دور هم جمع شوید.
• یک جلسه بین بخش ها در هر ترکیبی برگزار کنید.

تعداد چنین مناطقی در پروژه تحت تأثیر نسبتی از کسب و کار که این فرآیند به آن تعلق دارد، بود.

مرحله 2.سازگاری کارگران

علاوه بر این، ما به متخصصان در زمینه سازگاری کمک کردیم. بسیاری از تغییرات متدولوژی Agile هراس دارند، حتی اگر برای بهتر شدن باشند. بعد از گذشت چند هفته مشخص شد که کارگران از همه چیز خوششان آمده و از ادارات خارج شدند. در این مرحله، شایان ذکر است که کارکنان درک کنند که در صورت عدم تغییر در فرآیندهای تجاری، شرکت در معرض خطر ترک فضای بازار است.

مرحله 3.معرفی راه حل های غیر معمول

ما تعدادی ویژگی را معرفی کردیم: ما یک سینما را در منطقه مشترک سازماندهی کردیم که در آن ارائه ها در حین کار نمایش داده می شود، و فیلم ها در عصرها نمایش داده می شود، و همچنین یک دیوار با تصویر یک درخت که در آن ارزش های شرکت نوشته شده است.

دفتر جدید غیر معمول است، اما راحت است. ما آن را با مبلمان چند سطحی مجهز کردیم: چهارپایه های بار، کیسه های لوبیا، مبل های چرمی و پارچه ای، میزهای شیشه ای. مدیریت چابک با جزئیاتی مانند موارد زیر مشخص می شود:

• راه حل های مهندسی مدرن؛
• زیرساخت فناوری اطلاعات؛
• مبلمان راحت؛
• سطوح برای ثبت ایده ها در طول مذاکرات و غیره.

طراحی و تعمیر کاربه مدت دو ماه انجام شد. در این دوره، متخصصان شرکت وظایف کارگری را در قلمرو دفتر قدیمی انجام می دادند. مقدار هزینه های تعمیر تقریباً به اندازه هزینه بازسازی معمولی بود. قیمت فقط تحت تأثیر مبلمان و آخرین فناوری قرار گرفت.

نتیجه. چند ماه ماندن در دفتر بهبودیافته نشان داد که کار تیمی شده است و ارتباط بین متخصصان بخش های مختلف بهبود یافته است. موفق به صرفه جویی در اجاره. به طور متوسط، 12-40 متر مربع برای هر نفر در دفتر یک سازمان بزرگ وجود دارد. قبلاً 10 متر مربع داشتیم و این رقم به 6 متر مربع کاهش یافت و به طور مؤثر مشاغل را توزیع کرد. دوره بازپرداخت پروژه 1.5 سال بود.

ما تمام اتاق های جلسه را به Wi-Fi و تماس های کنفرانسی مجهز کرده ایم. بنابراین نیاز به اجاره اتاق های کنفرانس برای برگزاری جلسات خارجی در آنها را از بین بردیم. شرایط راحت کارمندان را به خود جذب می کند، به همین دلیل آنها زمان بیشتری را در محل کار می گذرانند و وظایف را با کارایی بیشتری انجام می دهند.

در صورت استفاده از متدولوژی Agile چه مشکلاتی ممکن است ایجاد شود

مشکل 1.عادت نقش.

متخصصان تیم پروژه در ابتدا، با تمایل کمی، به سمت انجام کارهایی می روند که برای آنها غیرعادی است، حتی متوجه می شوند که اینگونه بهتر خواهد بود. به عنوان مثال، تحلیلگران اغلب آزمایش یک سیستم را دوست ندارند، اگرچه چه کسی، اگر نه، همه چیز را در مورد ویژگی های عملکرد آن می داند؟ این نوع مشکلات در یک تیم به راحتی قابل تشخیص هستند و معمولاً به راحتی قابل رفع هستند.

مشکل 2عادت مستندسازی

ابتدا، توسعه دهندگان منتظر الزامات مشتری هستند - مستندات پروژه با توضیح همه مسائل. این روش انتقال اطلاعات کارآمدترین نیست و بنابراین بهتر است توسعه دهندگان به ارتباط مستقیم با مشتری عادت کنند. با گذشت زمان، پس از برقراری ارتباط با مشتری، برای توسعه‌دهندگان آسان‌تر می‌شود تا به پیچیدگی‌های کسب‌وکار بپردازند و مسائل بدیهی را حل کنند. حتی اگر اشتباهی مرتکب شوند، مشتری در پایان تکرار به سرعت متوجه آن می شود و به موقع می توان نقص را اصلاح کرد.

مشکل 3.تیم جدید

مدیر پروژه در معرض خطر مواجه شدن با مشکلات کار با یک تیم جدید است. شرکت کنندگان هنوز نمی توانند به درستی با یکدیگر ارتباط برقرار کنند، هیچ تماسی بین آنها وجود ندارد، آنها از درخواست کمک خجالت می کشند و می ترسند از کسی برای یک تصمیم اشتباه انتقاد کنند. مدیر پروژه مسئولیت دارد. او موظف است به اعضای تیم در برقراری روابط غیررسمی کمک کند که وجود آن در متدولوژی Agile دلالت دارد. ممکن است سازماندهی یک سفر مشترک به یک رستوران، یک رویداد تیم سازی یا یک مسابقه ورزشی مفید باشد.

مشکل 4.مشکلات ارتباطی

وظیفه مدیر پروژه در مرحله اولیه برگزاری تجمع با اعضای تیم برای دستیابی به فعالیت های سازنده و کارآمد است.

مشکل 5.فشار زمان

اغلب، مشتریان بر توسعه دهندگان فشار می آورند، آنها را عجله می کنند. مشتریان مایلند محصول مورد نظر خود را در کمترین زمان ممکن دریافت کنند. تیم باید الزامات را به دقت اجرا کند بدون اینکه کیفیت را قربانی کند. در غیر این صورت در درازمدت سرعت ایجاد کاهش می یابد، زیرا هزینه تغییرات ناشی از بی کیفیتی افزایش می یابد. علاوه بر این، عدم کیفیت تأثیر منفی بر انگیزه توسعه دهندگان دارد. مدیر پروژه باید مرتباً نیاز به حفظ کیفیت بالا را به مربیان یادآوری کند.

مشکل 6.خلاقیت.

وظایف در پروژه هم جالب هستند و هم نه خیلی. توسعه دهندگان اغلب از تصمیم گیری هایی که به پروژه آسیب می زند اما از نظر فنی جالب هستند، لذت می برند. در اینجا ارزش آن را دارد که اصول KISS (ساده، احمقانه نگه دارید) و YAGNI (به آن نیاز نخواهید داشت) را به خاطر بسپارید. بگذارید ویژگی اصلی تصمیمات طراحی سادگی باشد. شما نباید کاری را انجام دهید که در حال حاضر ضروری نیست.

برای اینکه تیم تصمیمات ساده بگیرد چه باید کرد؟ گاهی اوقات مفید است که به متخصصان اجازه دهید یک بار اشتباه کنند، تا بعداً بتوانند آن را به دقت تجزیه و تحلیل کنند و به توسعه دهندگان اجازه دهند بفهمند چه کاری باید انجام شود و چه کاری نباید انجام شود. تقریباً هر پروژه ای به نوعی با وظایف تحقیقاتی تکمیل می شود (فناوری های جدید و رشته های مهندسیدانش). اینجاست که باید تلاش کنید و آزمایش کنید.

مسئله 7.تخمین زمان

کارشناسان برای تعیین زمان برای حل مشکل فقط نوشتن کد را در نظر می گیرند. و در عین حال، این کار حداقل شامل ایجاد طراحی و آزمایش است. در همان ابتدای پروژه، توسعه دهندگان فکر می کنند که پروژه را زودتر از زمان ممکن به پایان خواهند رساند. در پایان فرآیند، کارشناسان اشتباهات را یادداشت می کنند و برای آینده نتیجه می گیرند. زمان می گذرد و تیم یاد می گیرد که وضعیت را به درستی ارزیابی کند. معمولاً پس از 3-4 تکرار، سطح دقت و عملکرد بهبود می یابد.

مسئله 8.مشکل مدیریت

انتظارات مدیریت در دسترس بودن قابلیت خاصی در زمان مشخص شده است. اما متدولوژی Agile اجرای برنامه ها را تا 100% تضمین نمی کند. منطقی است که منتظر بمانید تا کارهای اولویت دار حل شوند. هماهنگ کردن برنامه ها در سطح انتشار با مدیریت مفید است. سطح بالای برنامه انتشار به مدیر اجازه می دهد تا دامنه توسعه حتی ویژگی های فردی سیستم را در یک بازه زمانی نسبتاً بزرگ تغییر دهد. به عنوان مثال، وظیفه ایجاد یک زیر سیستم جستجو ممکن است شامل حسابداری مورفولوژی باشد. پس انداز در این مرحله امکان پذیر است.

مسئله 9.مشکلات رفتار غیر تیمی

در فرآیند اجرای متدولوژی Agile مستثنی نیست وضعیت بعدی. تجمعی برپا می شود و ناگهان یکی از شرکت کنندگان بلند می شود و شروع می کند به صحبت در مورد ایده های خود. او ایرادات را نمی پذیرد، اما پس از مدتی در مورد تصمیم گرفته شده صحبت می کند و پیشنهاد شروع بررسی موضوع دوم را می دهد. البته تیم تصمیمی نگرفت. در واقع این کار را کرد این عضوگرفتن حق از او

در اینجا چندین گزینه وجود دارد. این امکان وجود دارد که فرد به سادگی در حالت بیش از حد مشتاق بوده باشد که به زودی باید از بین برود. اما اغلب کسانی هستند که به دلیل ماهیت خود نمی توانند بخشی از تیم باشند.

روش شناسی چابک بدون اشتباه

اشتباه 1.مدیران ارشد نمی دانند متدولوژی Agile چیست و برای چه هدفی باید اجرا شود.

مستلزم درک دقیق این است که ما به چه نتیجه ای علاقه مندیم، چه مهلت و بودجه ای داریم. اهداف مبهم و جمله بندی زیبا، مانند «در رشته خود شماره یک شوید» یا «کارآمدتر شوید» مناسب نیستند. بگذارید وظایف به صورت اعداد بیان شوند. به عنوان مثال: "دستیابی به گردش مالی 3 میلیارد دلاری در سال 2018"، "کاهش زمان ایجاد یک محصول به 3 ماه" و غیره.

خطای 2.تشخیص اشتباه

اغلب، هنگام معرفی یک روش چابک، یک شرکت می خواهد تعدادی از مشکلات خاص مانند هزینه های بیش از حد یا کیفیت پایین کالاها را حل کند. اما باید با جزئیات مشخص کنید که در کجا شکاف وجود دارد. در غیر این صورت، مدیر منتظر خواهد ماند تا متدولوژی Agile همه چیز را تغییر دهد. با این حال، در اینجا او فقط خطر بدتر کردن وضعیت را دارد.

اشتباه 3.معرفی Agile فقط در یک منطقه جداگانه از فرآیندهای تجاری.

این ادامه منطقی خطای دوم است که در بالا توضیح داده شد. دلیل پذیرش او یکسان است: عدم درک مشکل و محل پنهان شدن آن. تمام شاخه های شرکت باید تغییر کند: قطعات تولید و بازاریابی، حسابداری و فروش. در غیر این صورت، هیچ چیز کار نخواهد کرد. اگر تغییراتی را فقط در بازاریابی ایجاد کنید و منتظر اثر مورد نظر نباشید، نظر قوی ای خواهید داشت که متدولوژی Agile ناکارآمد است.

اشتباه 4.کم اهمیت جلوه دادن اهمیت مشارکت همه کارکنان در شرکت.

شما باید با همکاران خود متحد باشید. اگر اینطور نیست، بهتر است در منابع، زمان صرفه جویی کنید و هیچ کاری انجام ندهید. روش شناسی چابک مستلزم ابتکار، بسیج و مسئولیت همه کسانی است که در این فرآیند شرکت می کنند، حداقل مدیران شرکت. اگر این افراد رهبرانی قوی و مقتدر باشند که بتوانند در حل مشکلات و وضع قوانین جدید در کار به نظم و انضباط خوبی دست یابند، آنگاه همه چیز درست خواهد شد. بر اساس آمار، 85 درصد از شرکت ها مدیران قوی با آموزش حرفه ای کافی ندارند.

اشتباه 5.این توهم که همه چیز فقط به لطف تلاش انسان امکان پذیر است.

البته شایستگی، انگیزه و سطح حرفه ای کارکنان در دستیابی به اهداف مهم است. اما باید به تجهیزات فنی مناسب شرکت، نرم افزاری نیز توجه شود که به کمک آن مدیریت و برنامه ریزی فعالیت ها کارآمدتر می شود. در این زمینه چه بخواهید و چه نخواهید باید برای خرید ماشین آلات، تجهیزات و نرم افزارها سرمایه گذاری کنید.

اشتباه 6.عدم تمایل به تغییر قاب

تقریبا 90 درصد موفقیت به تیم شرکت بستگی دارد. توجه مستمر باید به توسعه، آموزش و انگیزه درستکارمندان بسیاری از متخصصان آماده کار بر اساس متدولوژی Agile نیستند، آنها علاقه ای به دانش و فرصت های جدید و تسلط بر فرآیندهای تجاری ندارند. حدود 25 تا 30 درصد از کارکنان شرکت نمی خواهند تمام تلاش خود را انجام دهند و برای درآمد بالا تلاش می کنند. بهتر است چنین کارمندانی بگویند: «خداحافظ». شناسایی پیوندهای ضعیف می تواند بسیار دشوار باشد، بنابراین مدیران منابع انسانی اغلب این کار را انجام نمی دهند.

اشتباه 7.از دست دادن علاقه و مشارکت مدیران ارشد.

اجرای یک پروژه معمولاً 8 تا 16 ماه طول می کشد. در 70 درصد مواقع، پس از سه ماه، علاقه شرکت کنندگان کاهش می یابد. در نتیجه، اعضای تیم به سادگی نمی خواهند بخشی از پروژه باشند. اگر اینطور باشد، مطمئناً نمی توانید مشکل را حل کنید.

روش شناسی چابک: نمونه هایی از کاربرد ناموفق

متدولوژی چابک متخصصان زیادی را به خود جذب می کند و تا به امروز تعدادی از شرکت های معروف دنیا سعی در پیاده سازی آن داشته اند. اما تقریباً هیچ کس نتوانست به نتیجه مطلوب برسد.

مثال: در سال 2015 در بورس اوراق بهاداردر نیویورک حراج هایی برگزار شد که باید تا 4 ساعت متوقف می شد. در ابتدا با یک حمله سایبری توضیح داده شد. اما، همانطور که بعدا مشخص شد، مشکل یک اشکال در روند به روز رسانی بعدی بود. البته 4 ساعت توقف مرکز تجارت جهانی میلیاردها دلار ضرر به همراه داشت.

و این مثال تنها نیست. برای کارگزاران راحت تر است: آنها ضرر کردند و سپس دو برابر بیشتر درآمد داشتند. وضعیت برای خطوط هوایی پیچیده تر است. تقریباً همین وضعیت در مورد شرکت هواپیمایی دلتا پس از یک به روز رسانی ساده نرم افزار رخ داد. سیستم دیسپاچینگ دریافت اطلاعات را متوقف کرد که منجر به لغو اجباری پروازها شد. این شرکت نه تنها متحمل ضرر شد، بلکه شهرت خود را نیز پرداخت کرد.

برجسته ترین شکست روش چابک با راه اندازی سیستم بیمه درمانی اوباما در ایالات متحده مرتبط است. مفهوم برنامه به این صورت بود: به دسته های خاصی از شهروندان آمریکایی بیمه نامه رایگان ارائه شد. برای به دست آوردن چنین حقی، شخص باید پرسشنامه ای را در سایت پر می کرد و منتظر تصمیم برخی خدمات بود. البته میلیون ها نفر برای پر کردن پرسشنامه ها عجله کردند. اما مشکل این بود که آنها می توانستند پرسشنامه را پر کنند، اما نتوانستند آن را ارسال کنند، نوعی خرابی سرور وجود داشت. سیستم مراقبت اوباما تقریباً 6 ماه پس از راه اندازی به پایان رسید. برای انجام کار، ذینفعان متخصصی را از خارج وارد کردند که وضعیت را ارزیابی کرد. مشاور راه درازی را پیموده است، شروع از پایان - "تولید"، کنار هم قرار دادن قطعات و موفق به دستیابی به عملکرد صحیح سیستم.

نظر متخصص

نمونه ای از اجرای موفق آgil-کنترل

سرگئی بوچیک,

مدیر کل گروه NPM، نووسیبیرسک

این شرکت، شامل تمامی بخش‌ها، به مدت 1.5 سال است که به سمت متدولوژی Agile حرکت کرده است. پیش از این، بخش منابع انسانی متشکل از: یک متخصص منابع انسانی، یک مدیر آموزش و یک استخدام کننده بود. مدیریت بخش ها، انتخاب پرسنل جدید یا انجام آموزش، درخواست ها را به تعداد زیادی پر کرد. اکنون هر بخش از شرکت دارای منابع انسانی خاص خود است. در تیم های توسعه ای که روی متدولوژی اسکرام کار می کنند، این مکان برای اسکرام مستر محفوظ است. محصولات در اینجا خدمات پرسنلی هستند و اعضای تیم مصرف کنندگان داخلی هستند.

سبک جدید مدیریت بر اساس متدولوژی Agile در زمینه استخدام به خوبی ریشه دوانده است. مشتری می تواند فعالیت های خود را با در نظر گرفتن خروج نامزد دقیقا در زمان مشخص شده برنامه ریزی کند. طی 9 اسپرینت به مدت 2 هفته، موفق شدیم تعداد جای خالی عقب افتاده را 2 برابر کاهش دهیم. یک جای خالی ساده (مثلاً یک کاستور) اکنون در 20 روز بسته می شود، یک متوسط ​​(مهندس خدمات) - 32 روز، یک متخصص نادر (تکنولوژیست قالب گیری پلاستیک) - 51 روز. پس از اتمام اولین اسپرینت، برای استخدام کنندگان مشخص شد که مهمترین چیز برای مدیران بخش سرعت جستجو نیست، بلکه مهلت های شفاف برای بسته شدن مشاغل خالی و مدت زمانی است که می توانند برای انتخاب کارمند با آموزش های بعدی صرف کنند. . در حال حاضر مدیر زمان و مرحله جستجوی متقاضی را به مشتری می گوید. همچنین وظیفه استخدام‌کنندگان این است که شایستگی‌های فنی مورد نیاز برای استخدام مؤثر مشاغل تولیدی، مانند یادگیری خواندن نقشه‌ها را «پمپ» کنند.

بیایید مثالی بزنیم: مدیریت بخش متوجه نمی شود که به چه نوع کارمندی نیاز دارد یا این موضوع توسط متخصصان چندین بخش به طور همزمان تصمیم گیری می شود. فرض کنید یک شرکت به یک انباردار نیاز دارد که در انبار ابزار کار کند. در این مورد، بخش تولید و خدمات تدارکات یک جای خالی سفارش می دهند. در نظر گرفتن الزامات این بخش ها برای متقاضی، مسئولیت استخدام کننده است. تولید کنندگان به یک متخصص فنی که کاملا مدرن را بشناسد نیاز دارند ابزار برش فلز. تدارکات می خواهند هر حرفه ای با تجربه را ببینند که کاملاً می داند لجستیک انبار چیست. مشتریان هنوز تصمیم نگرفته اند و مخرج مشترکی را استنباط نکرده اند، اما استخدام کننده در حال حاضر با در نظر گرفتن متقاضیان به دنبال یک نامزد است. پس از انتخاب بهترین، از نظر خود متقاضی، با همه مشتریان گفتگو می کند. در صورتی که بعد از مصاحبه امکان توافق وجود نداشته باشد، استخدام کننده تغییراتی را در متن جای خالی ایجاد می کند.

در حال حاضر بخش ها به این نتیجه می رسند که گروه هدف باید شامل استادان فنی با دانش عالی از ابزار باشد. استخدام کننده دوباره جستجو می کند، متقاضیان مناسب را انتخاب می کند و با آنها ملاقات می کند. این کار تا زمان بسته شدن جای خالی ادامه دارد.

روش مدیریت پروژه چابک: 6 قانون برای اثربخشی

قانون 1 روی طرح پروژه کار کنید و به سوالات زیر پاسخ دهید: چه وظایفی در اولویت هستند، چه منابعی برای این کار مورد نیاز است، چارچوب زمانی برای دستیابی به نتیجه چیست؟

برنامه های بلند مدت دقت نسبتا کمی دارند، بنابراین در سه مرحله برنامه ریزی کنید:

• یک برنامه در دراز مدت که نشان دهنده تمام وظایف مورد نیاز برای تکمیل و برنامه ریزی عمده برای زمان بندی اجرای نقاط عطف کلیدی است.
• برنامه های هدف ماهانه، بر اساس برنامه کلی (اجرای آنها نباید کمتر از 90٪ باشد).
• در عرض یک ماه دقیق ترین اهداف را تعریف کنید و نتایج دستیابی به آنها را به وضوح توصیف کنید.

قانون 2تیم را در اجرای پروژه مشارکت دهید، کارکنان را در مورد آن آگاه کنید. همه متخصصان باید اهداف سازمان را درک کرده و به اشتراک بگذارند، بدانند که برای حل وظایف چه کاری باید انجام شود، حتی اگر این کارمندان آنها را در چارچوب پروژه انجام ندهند.

قانون 3هر از گاهی با تیم اجرا ملاقات کنید. تعداد جلسات 1-2 بار در ماه است. این برای تعیین راه حل وظایف و مشکلات، تنظیم به موقع طرح در صورت بروز مشکلات در اجرا مورد نیاز است. با این حال، برای تنظیم حاد موقعیت های درگیریدر طول جلسه، که در یک هفته برنامه ریزی شده است، دنبال نمی کند. مجوز باید واضح و سریع باشد.

قانون 4اگر دیدید پروژه نمی دهد، پروژه را متوقف نکنید اثر مثبت. مشکلات، به عنوان یک قاعده، به دلیل نارضایتی تیم به وجود می آیند، که اعضای آن باید منطقه راحتی را ترک کنند و به روشی خلاقانه هماهنگ شوند. به یاد داشته باشید که اولین نتایج معمولاً پس از تکمیل 80٪ از کل مسیر اندازه گیری می شوند.

قانون 5اگر می بینید که روش Agile به آنها نزدیک نیست، به کارکنانی که عملکرد ضعیفی دارند، «خداحافظ» کنید.

قانون 6خودتان را برای حل کامل مشکل در اولین بار آماده نکنید. حدود 95 درصد از ابزارها و ایده های مؤثر پس از تکرارهای زیاد و تعدیل ها پس از چندین بار تکرار به دست آمد.

1. اندرو استلمن، جنیفر گرین "درک چابک".

این کتاب در مورد چهار گزینه اصلی که در آنها روش شناسی چابک ارائه شده است صحبت می کند. توضیحات آنها بسیار جالب و مفصل است. به لطف راهنما، تسلط بر هنر به کارگیری تکنیک ها آسان و سرگرم کننده می شود.

این کتاب ماهیت محبوب ترین متدولوژی های Agile را نشان می دهد: Scrum، XP (برنامه نویسی شدید)، Lean (برنامه نویسی ناب) و Kanban (Kanban). به شما می گوید که چگونه از آنها برای ایجاد برنامه های با کیفیت و دستیابی به اهداف خود استفاده کنید. راهنما توضیح می دهد که چگونه روش چابک به تغییر تفکر شرکت کنندگان در پروژه، متحد کردن آنها و تلاش برای بهبود با هم کمک می کند. هدف این نشریه صحبت در مورد روش ها، ارزش ها و اصول Agile است که به لطف آنها تیم ها می توانند استراتژی کار بر روی پروژه ها را کاملاً تغییر دهند و به طور متفاوتی به آن نگاه کنند. این راهنما هم برای مدیران و هم برای مدیران پروژه و فقط برای کسانی که به متدولوژی توسعه انعطاف پذیر Agile علاقه دارند، جالب خواهد بود.

2. بوریس ولفسون "مدیریت پروژه و محصول انعطاف پذیر".

این کتاب تئوری و عمل را ترکیب می کند. جنبه های مختلف مفهوم روش شناسی چابک، توسعه محصول، مدیریت و تجزیه و تحلیل را توصیف می کند. بخش تئوری مدیریت پروژه و محصول حاوی اطلاعاتی در مورد وضعیت فعلی اسکرام و کانبان است. در بخش عملی، در مورد مدیریت نیازمندی‌ها، تیم‌ها، ریسک‌ها، مدل‌سازی کسب‌وکار، تجزیه و تحلیل نیازمندی‌ها، برآورد زمان، شیوه‌های مهندسی برای توسعه محصول (عمدتاً برنامه‌نویسی شدید)، کنترل و تضمین کیفیت، پیاده‌سازی و مقیاس‌بندی Scrum صحبت می‌کند.

3. جف ساترلند اسکرام روش انقلابیمدیریت پروژه".

جف ساترلند روش‌شناسی خاص خود را دارد که در تلاش برای غلبه بر کاستی‌های مدیریت پروژه کلاسیک آن را توسعه داده است. اغلب برای متخصصان در شرکت های مختلف دستیابی به کار کارآمد، سریع و به خوبی هماهنگ شده است. آنها به دلیل کمبود زمان و منابع، اکثر برنامه های خود را کامل نمی کنند، و بخش ها و تیم ها اغلب کارهایی را حل می کنند یا تکرار می کنند که از نظر معنی مخالف هستند.

اسکرام 20 سال است که وجود داشته است و در این مدت نه تنها توسعه دهندگان نرم افزار، بلکه سازندگان خودرو، داروسازان، FBI و مردم عادی که زمان و فرصت های خود را برنامه ریزی می کنند، با موفقیت از این تکنیک استفاده کرده اند.

با خواندن این کتاب، نگاه متفاوتی به مدیریت پروژه خواهید داشت و متوجه خواهید شد که چگونه کارهایی را که قبلاً دست نیافتنی به نظر می رسید، حل کنید. برنامه های شما مهم نیست: افتتاح یک استارتاپ، تغییر سیستم آموزشی، معرفی فناوری های جدید، یا مدیریت موثرتر تیم. به لطف Scrum، شما در مواقعی بهره وری خود را افزایش خواهید داد. این راهنما برای مدیران پروژه، مدیران و متخصصان فناوری اطلاعات مناسب است.

4. مدیریت محصول رومن پیخلر در اسکرام.

این راهنما برای همه کسانی که روش شناسی Agile را مطالعه می کنند، به ویژه کسانی که صاحب این فناوری هستند، جالب خواهد بود. این کتاب می گوید که صاحب محصول چه نقشی ایفا می کند، چگونه آن را به بهترین شکل مدیریت می کند، راه های اصلی برای انجام این کار چیست. ما در مورد تجسم محصول، ایجاد و بهبود بک لاگ، برنامه ریزی و ردیابی انتشارات و استفاده موثر از اسکرام صحبت می کنیم.

5. کنت اس روبین "مبانی اسکرام".

از این کتاب، همه چیز را در مورد اسکرام، شرایط این متدولوژی یاد خواهید گرفت و نحوه بهره مندی از کاربرد آن را خواهید فهمید. اگر به متدولوژی Agile علاقه مند هستید، راهنما به شما می گوید که برای دستیابی به نتایج عالی چه چیزی لازم است. این کتاب توسط یک متخصص برجسته آموزش اسکرام نوشته شده است. نویسنده اصول کلیدی، ارزش ها و هنجارهای تمرین را با دست زدن به رویکردهای انعطاف پذیر، که اثربخشی آن با گذشت زمان تأیید شده است، شرح می دهد.

اطلاعات در مورد کارشناسان

آندری کوچشکوف, تحلیلگر ارشد انتشارات OAO Prosveshchenie. "روشنگری" - انتشارات تخصصی ادبیات آموزشی و آموزشی شوروی و بعداً روسیه.

ماریا اونچینا،مدیر بخش مدیریت تسهیلات در گروه مدیریت دارایی Becar، مسکو. Becar-Exploitation LLC (گروه مدیریت دارایی Becar). زمینه فعالیت: یک راه حل سیستماتیک برای مشکلات مدیریت اشیاء (مدیریت اموال)، پروژه ها (مدیریت پروژه) و سرمایه گذاری ها (کارگزاری، ارزیابی). تعداد پرسنل: 5000. قلمرو: دفاتر جلویی - در مسکو و سنت پترزبورگ. سه دفتر و 55 زیرمجموعه های جداگانه- در شهرهای مختلف روسیه.

سرگئی بوچیک،مدیر عامل گروه NPM، نووسیبیرسک. NPM LLC (NPM Group). زمینه فعالیت: تولید تجهیزات برای صنعت نوشیدنی. توسعه راه حل های فناوری اطلاعات برای ادغام با تجهیزات، برنامه های موبایل. تعداد کارمندان: بیش از 300. سهم بازار: 95 درصد تجهیزات بطری آبجو و نوشابه های گازدار در روسیه. تعداد اختراعات برای محصولات خود: بیش از 80.

همه نمونه دستگاه کارخانه ای را می شناسند که در کتاب های درسی مدیریت کلاسیک گنجانده شده است، جایی که هر کارمند حق داشت نوار نقاله را متوقف کند تا نقصی را برطرف کند یا پیشنهاد منطقی ارائه دهد. این رویکرد است که اساس فلسفه چابک را تشکیل می دهد.

Agile که 10-15 سال پیش به عنوان یک روش توسعه نرم افزار در تیم های کوچک ظاهر شد، اکنون به فرهنگ جدید مدیریت شرکت های بزرگ تبدیل شده است. به لطف سخنرانی اخیر آلمانی گرف، اصطلاح چابک در فرهنگ واژگان تمام مدیران مدرن روسیه گنجانده شده است.

Agile چیست و چرا این روش تقریباً تنها روش صحیح نامیده می شود؟

یک رویکرد کلاسیک برای ایجاد محصولات و خدمات وجود دارد که در درجه اول مشخصه صنعت IT است. این رویکرد را روش توسعه آبشار یا تکراری می نامند. در اصطلاح انگلیسی، این رویکرد توسعه آبشار (از انگلیسی - waterfall) نامیده می شود. چرا به آن آبشار می گویند؟ زیرا با چنین طرح توسعه ای، پس از تایید طرح محصول نرم افزاری، نمی توانید این طرح را قبل از ایجاد آن متوقف یا تغییر دهید.

چابک رویکردی نوآورانه برای بازنگری در ایجاد یک محصول یا خدمات جدید است. بر اساس بسیار است ایده ساده: هر یک از شرکت کنندگان در فرآیند، هر یک از کارکنان این "مجمع نقاله" باید در روند بازاندیشی وظایف خود و علت مشترک مشارکت داشته باشند. همه می توانند نقاله را متوقف کنند و پیشنهادات منطقی خود را ارائه دهند.

در اکثر سازمان ها، هنگام ایجاد محصولات نرم افزاری، افراد مسئول مراحل خاصی از پروژه در بخش های مختلف، اغلب متضاد، مستقر می شوند. بر کسی پوشیده نیست که کارکنان عملیات، آزمایش کنندگان و توسعه دهندگان معمولاً با یکدیگر در تضاد هستند. و اگر محصول کار نکند و سودی برای کسب و کار به ارمغان نیاورد، همه تلاش می کنند دیگری را مقصر بدانند. اگرچه در واقع، در چنین مواردی، به عنوان یک قاعده، همه مقصر هستند.

روش چابک شامل مشارکت همه شرکت‌کنندگان در فرآیند توسعه محصول نرم‌افزاری است و شایستگی‌های آشنا را برای شرکت‌کنندگان به ارمغان می‌آورد. این رویکرد به وضوح نشان می دهد که همه آنها برای یک هدف نهایی کار می کنند - یک محصول با کیفیت برای مشتریان خود.

بنابراین تغییری در فرهنگ تجاری خود شرکت ایجاد می شود. به عنوان بخشی از برنامه های MBA، یک دوره کامل وجود دارد که به ساختار سازمانی شرکت می پردازد. مفهوم تعادل در آن وجود دارد، زمانی که همه هر کاری را در داخل شرکت های نوپا و استارت آپ انجام می دهند، به همین دلیل است که اغلب تیم دوستانه ای در آنجا متولد می شود که به طور موثر در بازار عمل می کند. و از نظر کارایی و ارائه ایده های جدید به بازار، این ساختار سازمانی ایده آل است.

البته سازمان هایی هستند که اصلا نیازی به Agile ندارند. مثلاً ادارات دولتی. فعالیت آنها بر اساس قانون است. اگر قوانین بازی هر روز تغییر کند، نمی‌توانیم با دولت تعامل کنیم.

بنابراین، ما دو نقطه مقابل رادیکال زیرساخت سازمانی داریم. از یک طرف، سختگیرترین سازمان رسمی بوروکراتیک وجود دارد که در موارد خاص استفاده می شود و در شرایط خاص به خوبی کار می کند. و کاملاً متضاد آن، استارتاپ‌های جوان است، تیم‌هایی از افراد همفکر که واقعاً چیز جدیدی خلق می‌کنند، و Agile بسیار نزدیک‌تر به وضعیت یک تیم احساسی است که برای هدف نهایی کار می‌کند، یک نرم‌افزار با کیفیت بالا و قابل اجرا. تولید - محصول. و بنابراین، مشکلاتی که در هر مرحله ای ایجاد می شود، مشکلات همه مردم است و هرکسی که بتواند آنها را حل کند، درگیر این روند است.

انتقال یک کسب و کار بزرگ کلاسیک (Enterprise) به Agile

این یک سوال بسیار مهم است و بسیار جالب است. تمام دنیا در این مورد صحبت می کنند، گرف آلمانی هم همین را گفت. او گفت: بچه ها، ما یک بانک هستیم، رقبای ما بانک نیستند، رقبای ما شرکت های جوانی هستند که دیجیتال را به جامعه می آورند.

یک تجارت پیشرفته بر سه پایه استوار است: تجربه و دانش در صنعت (که در آن کسب و کار در حال فعالیت است)، توسعه محصولات و خدمات با استفاده از متدولوژی Agile و مهمتر از همه، فرهنگ نوآورانه.

شرکت های پیشرو فناوری اطلاعات که به راحتی محصولات و خدمات بانکی را کپی کرده اند، شروع به تکمیل (یا تبدیل) آنها به سطحی می کنند که بانک نمی تواند آنها را به آن برساند. موسسه مالیفرهنگ نوآوری به اندازه کافی توسعه یافته ندارد.

یک مثال بسیار ساده، سازمان های تامین مالی خرد است. اینها شرکت هایی هستند که به معنای واقعی کلمه با یک ضربه انگشتان خود یک سرویس ایجاد می کنند. امروز این شرکت ظاهر شد، وام با نرخ بهره فوق العاده بالا صادر کرد - فردا سودآوری آن چندین برابر بیشتر از یک بانک خواهد بود. چنین سازمان هایی می توانند فورا خدمات و محصولات خود را بازسازی کنند، به سرعت وارد بازارهای جدید شوند و بانک های کلاسیک را جایگزین کنند.

اتفاقات مشابهی نه تنها در صنعت بانکداری در حال وقوع است، بلکه در همه صنایع و حوزه های تجاری نیز اتفاق می افتد. اپراتورهای تلفن همراه شروع به پرداختن به سیستم های پرداخت کرده اند. اوبر رویکرد خود را تغییر داده است ترافیک مسافریدر سراسر جهان در چند سال، و Airbnb همین کار را با بخش هتل‌داری در تجارت مسافرتی انجام داد.

برنامه ریزی انعطاف پذیر

با توسعه آبشار، باید یک سال آینده برنامه ریزی کنید. اما اگر چیزی تغییر کند - به عنوان مثال، سرورهای بیشتری یا اجزای دیگر مورد نیاز است، پس از توقف پروژه چنین سناریویی امکان پذیر است - از این گذشته، انجام مناقصه جدید، خرید زیرساخت های جدید و غیره ضروری است.

یعنی Agile نه تنها به یک روش برای ایجاد نرم افزار جدید، بلکه به یک سیستم برنامه ریزی انعطاف پذیر برای توسعه کل شرکت تبدیل می شود. چنین زیرساختی باید ساخته شود که همچنین به طور انعطاف پذیر به درخواست های مشتریان و نیازهایی که در طول توسعه یک محصول نرم افزاری و عملکرد آن تغییر می کند پاسخ دهد (به هر حال، این به معنای انتقال کامل به فناوری های ابری است).

برنامه ریزی چابک مستلزم درک و تجزیه و تحلیل هر فرآیند تجاری است. و این مرحله بعدی در توسعه شرکت است - دیجیتالی شدن آن.

مطالب را بخوانید

یک روز یک مدیر ارشد در کارخانه مونتاژ خودرو شرکت معروف تویوتا وارد روسیه شد.

سفر او آموزشی بود. او قرار بود اصول تولید ناب، خلق کردن را به تیم مدیریت آموزش دهد تیم موثرو البته مونتاژ صحیح خودروهای مدرن و باحال.

روش شناسی چابک در قلب همه چیز قرار داشت. اما آنچه در جلسه دید او را شوکه کرد ...

به شکل زیر اتفاق افتاد. مدیر کل به گزارش روسای ادارات گوش داد و برای خود یادداشت کرد.

وقتی نوبت به بحث در مورد برنامه های توسعه آتی و رفع مشکلات رسید، مدیر از روسای ادارات دعوت کرد تا نظرات خود را بیان کنند.

سروصدا، بحث و جدل به پا شد. مدیر بازاریابی با مدیر فروش شروع به بحث کرد.

بنابراین 15 دقیقه گذشت و سپس کارگردان فریاد زد: "دموکراسی تمام شد، حالا دوباره دیکتاتوری!" شروع به دادن دستوراتی کردند که زیردستان با پشتکار شروع به نوشتن آنها در دفتر خاطرات خود کردند.

میهمان ژاپنی توانست تنها یک عبارت از آنچه دیده بود به زبان بیاورد: «اما این مدیریت پروژه چابک نیست.

از این گذشته ، در کارخانه ما ، هر کارگری می تواند نوار نقاله را در حین کار متوقف کند و تنظیماتی را در کار آن انجام دهد.

در جلسات برنامه ریزی در مورد ایده ها صحبت نمی کنم…». ژنرال پاسخ داد: «بله، اینها اصول چابکی نیستند! چنین روش های انعطاف پذیری در روسیه کار نمی کند!».

خب کار نمیکنن...

به احتمال زیاد، اکنون این سؤال در ذهن شما می چرخد: "این چه نوع عبارت مرموز است؟".

بنابراین، در این مقاله، بیایید بفهمیم که چگونه اصول مدیریت چابک در روسیه، برای مشاغل کوچک قابل اجرا است و چگونه به شما در افزایش فروش کمک می کند.

برنامه نویسان مقصر هستند

آیا می دانید قبلاً هر محصول نرم افزاری چگونه ساخته شده است؟ کل البته الان هم آن را ایجاد می کنند، اما نه شرکت های پیشرفته.

یعنی قبلاً ساختار خاصی وجود داشت که پس از عبور از آن محصول نرم افزاری نهایی متولد شد. او به این شکل بود:

1. اندیشه؛
2. وظیفه فنی؛
3. ایجاد طراحی؛
4. برنامه نويسي؛
5. آزمایش کردن؛
6. راه اندازی نسخه نهایی.

با این حال، شکاف های قابل توجهی در این 6 مرحله وجود داشت. همه مشکلات به دلیل توالی سفت و سخت این ساختار و عدم امکان ارائه ایده های جدید در هر یک از مراحل به وجود آمد.

در نتیجه، هنگام طراحی یا برنامه نویسی، ایده های جدید به سادگی نادیده گرفته می شدند.

در غیر این صورت، لازم است که کل کار فنی دوباره انجام شود، که به طور قابل توجهی شرایط کار را طولانی تر کرد، یا هزینه فرآیند را به میزان قابل توجهی افزایش داد.

و سپس برنامه نویسان شروع به تغییر رویکرد به کار کردند: آنها شروع به انجام آزمایش های کوچک برای دریافت بازخورد در هر مرحله کردند تا فوراً تغییرات را حتی در یک محصول هنوز ناتمام ایجاد کنند.

آنها همچنین شروع به درخواست بازخورد از مشتری حتی قبل از تحویل محصول نهایی به او کردند.

آزمایش ها نتایج عالی نشان دادند و به عنوان بسیار موفق شناخته شدند (کیفیت محصولات بسیار بهتر شد، مشتریان راضی بودند و برنامه نویسان شروع به ملاقات زودتر از موعد کردند).

این رویکرد به کار "انعطاف پذیر" نامیده شد زیرا در هر مرحله از کار امکان ایجاد تغییراتی در ایجاد محصول برای به دست آوردن راه حل ایده آل وجود داشت.

برای آوردن تمام رویکردهای مدیریت پروژه (و در آن زمان بیش از ده ها مورد از آنها وجود داشت) به یک مخرج مشترک، کل تیم موسس (17 نفر) که "روش های چابک" مختلف را توسعه و اجرا کردند دور هم جمع شدند.

آنها دریافتند که اگرچه روند توسعه محصول را به روش های مختلف می بینند، اما این ایده که باید انعطاف پذیر باشد برای همه قابل مشاهده است.

این ملاقات در دهکده کوهستانی اسنوبرد در فوریه 2001 بود که تولد روش شناسی چابک (حتی برخی آن را فلسفه می نامند) تلقی می شود.

از آنجایی که بیشتر این افراد برنامه نویس بودند، نتیجه جلسه انتشار مانیفست چابک و اصول چابک بود.

زمانی که برنامه نویسان با استفاده از این فلسفه و اصول به نتایج بسیار خوبی دست یافتند، بسیاری از سازمان ها شروع به استفاده از این رویکردها کردند.

مختصر و مفید

مانند هر فلسفه دیگری، روش شناسی چابک ارزش های خاص خود را دارد. در واقعیت، همه با آنها موافق نیستند، اما اگر یک شرکت رویایی ایجاد کنید، قطعاً به این فلسفه پایبند خواهد بود:

1. افراد و تعامل مهمتر از فرآیندها و ابزارها هستند.
2. یک محصول کارآمد مهمتر از مستندات جامع است.
3. همکاری با مشتری مهمتر از توافق بر سر شرایط قرارداد است.
4. آماده بودن برای تغییر مهمتر از پایبندی به برنامه اولیه است.

اصول ذکر شده در مانیفست چابک. فقط بخوانید، کمی بیشتر متوجه شوید.

• رضایت مشتری از طریق تحویل زودهنگام و بدون وقفه نرم افزارهای ارزشمند؛
• تحویل مکرر نرم افزار کار (هر ماه یا هفته یا حتی بیشتر).
• و بسیاری دیگر مانند آن.

"چه لعنتی خوندم؟ یک کلمه هم نفهمیدم!" من فکر می کنم این همان چیزی است که شما در حال حاضر فکر می کنید.

راستش را بخواهید، Agile به عنوان یک متدولوژی چیست (و همچنین آنچه در مانیفست نوشته شده است) من خودم بلافاصله متوجه نشدم، کتاب ها و مقالات توصیفی سطحی دادند تا زمانی که همه اینها را در عمل دیدم.

بنابراین، من مقدار زیادی در زمان شما صرفه جویی می کنم و به طور مختصر و دقیق به شما می گویم.

چابکنام روشی است که در آن پروژه بزرگبه چندین قسمت کوچک تقسیم می شود که هر کدام تاریخ تکمیل خود را تعیین می کنند.

این رویکرد به جز یک چیز خیلی چیزها را به من یادآوری می کند. تجزیه، مشارکت کل تیم را در نظر نمی گیرد.

مثال واضح است

برای اینکه درک همه چیز را برای شما آسانتر کنم، با استفاده از مثال نانوایی، تفاوت را نشان می دهم.

برای این کار ابتدا در مورد کارخانه ای صحبت می کنم که متدولوژی ندارد و سپس در مورد کارخانه ای که این روش مدیریتی را اجرا کرده است. بیایید به یک مثال برویم.

نانوایی معمولی در روسیه

مدیر عامل به تکنسین دستور می دهد تا نوع جدیدی از نان را توسعه دهد. در بهترین حالت، تکنسین برای انجام تحقیقات به آنها مراجعه می کند.

اما، به عنوان یک قاعده، چنین ایده هایی نه از تمایل مصرف کنندگان بر اساس تحقیقات بازاریابی، بلکه از تمایل خود کارگردان ناشی می شود.

پس از انجام تحقیقات، تکنسین نان را به سلیقه خود توسعه می دهد و به کارگردان می آورد.

او محصول جدیدی را امتحان می‌کند و تصمیم می‌گیرد به فن‌آور با عبارت «آفرین. شیرینی را نگه دارید» یا بگویید «نه. بازسازی کنید."

پس از تایید، نمودارهای جریان به نانواها داده می شود تا محصول را وارد مرحله تولید کنند. بعد، فروشندگان برای فروش - نان پخته شده.

این رویکرد معمول در روسیه است، کارکنان به سادگی دستورالعمل ها را دریافت می کنند و یک نفر (گاهی چند نفر) ارزیابی می کنند.

نانوایی چابک در روسیه

مدیرعامل ایده توسعه نوع جدیدی از نان را مطرح کرد. و اینجاست که معجزات شروع می شود.

نه تنها یک فناور و بازاریابی در ایجاد یک محصول نقش دارند، بلکه فروشندگان، تدارکات، سرآشپزها / قنادی ها و ... حتی خریداران واقعی نیز مشارکت خواهند داشت.

در این دستور، هیچ سلسله مراتبی وجود نخواهد داشت (به جز مدیر عامل) و نتیجه کار پاداش یک کارمند خاص نخواهد بود، بلکه دریافت نوع جدیدی از نان خواهد بود که توسط خریداران خریداری می شود.

علاوه بر این، در طول کل فرآیند، همه کارکنان نتیجه را ارزیابی کرده و برای بهبود آن بازخورد می دهند.

پیاده سازی یا ارسال کنید

به طور خلاصه، مزیت اصلی این است که این رویکرد به شرکت کمک می کند تا به سرعت یک محصول رقابتی را بازسازی و ایجاد کند که مشتریان به آن نیاز دارند و دوست دارند.

در نتیجه تاثیر خوبی در فروش خواهد داشت، در زمان بسیار صرفه جویی می کند و اشتباهات را از بین می برد.

با این حال، پس از خواندن نیمه اول مقاله، می توان نتیجه گرفت که روش چابک فقط برای شرکت های فناوری اطلاعات مناسب است.

اما این اساساً درست نیست. در روسیه، این روش به طور فعال توسط:

• بانک "آلفا بانک"؛
• شبکه پیتزا فروشی "Dodo Pizza";
• خدمات حسابداری "دکمه".

و اگر همه چیز با آلفا بانک، یک شرکت بزرگ روشن باشد، آنها منابع و افرادی را دارند که نوآوری ها را به سیستم خود وارد کنند.

سپس با "Dodo Pizza" و "Button" همه چیز بسیار جالب تر است، زیرا شرکت ها کوچک هستند. و به نظر من این رویکرد یکی از عوامل موفقیت آنها شده است.

در نتیجه اجرای چابک، می توانید امتیازات مثبت زیادی (در ادامه در مورد معایب بیشتر) به دست آورید که به شما کمک می کند رهبر بازار شوید. در اینجا برخی از این امتیازات وجود دارد:

1. به لطف استفاده از رویکردهای "انعطاف پذیر"، کیفیت نتایج به دست آمده افزایش می یابد.
2. نتایج بسیار سریعتر و کارآمدتر به دست می آیند، در نتیجه در زمان و هزینه صرفه جویی می شود.
3. شرکت با تغییرات (حتی پیش بینی نشده) و رقابت بهتر سازگار است.
4. ایجاد پروژه ها بیشتر برنامه ریزی شده و کنترل شده است.
5. یک شرکت می تواند محصولاتی ایجاد کند که مصرف کنندگان منتظر بمانند و بخرند.

کار درونی

تنها سوالی که مدتهاست به دنبال پاسخ آن هستم این است که کار در یک شرکت چابک چگونه کار می کند.

واضح است که هر کارمند برای نتیجه کار می کند و پیشنهادات خود را ارائه می دهد. اما همه چیز از درون چگونه به نظر می رسد؟ شما نمی توانید این را از روی کتاب ها درک کنید.

بیایید به نانوایی مورد علاقه خود برگردیم. و به وظیفه قدیمی خود - انتشار نوع جدیدی از نان. برای انجام این کار، آنها دنباله زیر را داشتند:

1. داده های ورودی.کارگردان می گوید چه نوع نانی را در حالت ایده آل می بیند و همچنین محاسبه آن را می گوید که از نظر اقتصادی برای شرکت مفید است.
2. بحث ایده.تیمی متشکل از یک تکنسین، آشپز، تدارکات، بازاریابان و فروشندگان شروع به بحث در مورد این پروژه می کنند.

   سرآشپزها، فناوران و تدارکات محصولات سودآوری را ارائه می دهند، بازاریابان در مورد رقبا صحبت می کنند، و فروشندگان می گویند که خریداران معمولاً خواسته های خود را بیان می کنند.

3. آزمایش کردن.تمام ایده ها و دانش در یک دستور العمل آزمایشی خلاصه می شود. این دستور غذا در یک دسته آزمایشی کوچک پخته می شود تا بازخورد آن را در یک مزه بسته در بین خریداران عادی دریافت کند (!!!).
4. جمع آوری بازخوردمشتریان نان می خورند و خواسته های خود را بیان می کنند. بر این اساس، تغییرات و بهبودهایی در دستور العمل آزمایش ایجاد می شود. آخرین.

این مراحل را می توان بارها و بارها ادامه داد تا یک نوع نان کامل به دست آید که همه از آن راضی باشند: بازاریابان، سرآشپزها، تدارکات، فناوران، فروشندگان، خریداران و البته خود مدیر کارخانه.

بله، الان همه چیز خوب است

من خودم را می خواهم

شاید پس از خواندن مقاله تمایل داشته باشید (به خصوص اگر در زمینه تولید مشغول هستید) متدولوژی های مدیریت پروژه انعطاف پذیر را در کسب و کار خود معرفی کنید.

و شما فکر می کنید که چابک چیزی است که به آن نیاز دارید. پس از همه، به این ترتیب شما می توانید چیزی جدید، یک محصول واقعا نوآورانه ایجاد کنید.

سپس بلافاصله به شما هشدار می دهم و به چند سوالی که دارید پاسخ می دهم.

اینها 5 سوال اصلی است که همه مالکان با دیدن این روش از خود می پرسند.

برای مشاغل کوچک مناسب است؟اگر دائماً محصولات جدید را منتشر نمی کنید یا دائماً پروژه های جدیدی را اجرا نمی کنید، اما روی "قدیمی" کار می کنید، به احتمال زیاد خیر.

آیا اجرای آن آسان است؟من به این سوال با یک سوال پاسخ خواهم داد: آیا یادگیری آسان است؟ زبان خارجی? فلسفه را نمی توان به سرعت وارد یک شرکت کرد. باید گام به گام و در یک دوره زمانی نسبتاً طولانی اجرا شود.

فرآیندهای کسب و کار در شرکت تغییر خواهد کرد؟بله کاملا و شدید. بخش ها و افراد در آنها تغییر خواهند کرد، جلسات برنامه ریزی شخصیت معمول آنها را تغییر می دهد، مسئولیت های شغلی کاملاً متفاوت می شود.

مردم چگونه کار خواهند کرد؟کاملا متفاوت. اگر قبلاً فقط روی یک کار کار می کردند، اکنون باید کار کنند و در کل پروسه تا چندین پروژه شرکت کنند.

و این به معنای کار تیمی منحصراً و دیدگاه گسترده تر است.

چه کسی باید رئیس باشد؟هر چقدر هم که عجیب به نظر برسد، شرکت های چابک رئیسی ندارند.

اول از همه، اینها دستیاران متصدی هستند که افراد را در تیم های مشترک برای کار موثرتر سازماندهی می کنند.

به سوال شما پاسخ ندادید؟ در این مورد، نظرات زیر وجود دارد، آن را در آنجا بنویسید و من به شما توصیه رایگان می کنم. برای ما مهم است که شما 100% راضی باشید.

ما در حال حاضر بیش از 29000 نفر هستیم.
روشن کن

سنگ های زیر آب

مانند هر ابزار بهبود کسب و کار، مشکلاتی وجود دارد. و در نگاه اول، آنها چندان قابل توجه نیستند.

آنها تنها پس از اجرا توسط شرکت ها محقق می شوند. بنابراین، پیشاپیش، "لطفا" برای صرفه جویی در هزینه و زمان شما.

چابک ابزار نیست

چابک حتی یک متدولوژی نیست، اگرچه من اغلب آن را در متن نامیده ام. این فلسفه ای است که شرکت با آن موافقت می کند زندگی کند.

و برای اجرای فلسفه در زندگی به قوانین و الگوها و ابزارهایی نیاز است. به آنها چارچوب گفته می شود.

این شامل یا Scrum (ابزارهای مدیریت) است. البته در آینده در مورد هر ابزاری مقاله خواهیم نوشت، اما باید بدانید که چابکی قبل از هر چیز، فلسفه ای است که در شرکت اتخاذ شده است.

تیم

برای اکثر مردم کشور ما (من در مورد تجارت معمول روسیه صحبت می کنم)، کار تیمی غیرعادی خواهد بود.

آنها عادت کرده اند دستورالعمل های فردی را دریافت کنند و در قبال اجرای آنها پاسخگو باشند. بر این اساس، KPI هر متخصص خاص با معرفی چابک باید لغو شود.

و این تیم است که سهم هر متخصص خاص را در پروژه ارزیابی خواهد کرد. و این بسیار دشوار است اگر شما متخصصان برتر در زمینه خود نداشته باشید.

بینی شخص دیگری

دیگر فضای شخصی در شرکت وجود ندارد. از سریال - من به تو صعود نمی کنم و تو به من صعود نمی کنی. این دیگر نیست.

اگر کار گروهی وجود داشته باشد، فروشندگان نان ممکن است سؤال کنند که چرا او این یا آن افزودنی را به انواع اضافه کرده است، زیرا خریداران آن را دوست ندارند.

این هم بد (غیر معمول) و هم خوب است، زیرا اغلب چشمان شما تار می شود.

پرداخت

جذابترین. در چابک، مرسوم نیست که به افراد حقوق ثابت پرداخت شود، زیرا موفقیت شرکت به میزان مشارکت هر یک از کارکنان بستگی دارد.

دستمزد اگر هم باشد بیشتر از سریال است که آدم از گرسنگی نمیرد. همه چیز دیگر نتیجه است.

حجم معاملات

قابل توجه خواهد بود. در جامعه ما مرسوم نیست که به صورت تیمی کار کنیم و برای نتایج خاص دستمزد بگیریم (اگرچه اخیراً این موضوع تغییر کرده است).

بنابراین، شما باید سعی کنید متخصصانی را بیابید که فلسفه پیاده سازی شده در شرکت شما را به اشتراک بگذارند.

به طور خلاصه در مورد اصلی

مدیریت پروژه چابک برای چه کسانی مناسب است؟ برای شرکت های بزرگ یا کوچک؟ در واقع، برای آنها و برای دیگران.

شرکت‌های بزرگ از آنها «جوان‌تر» می‌شوند، متحرک‌تر و کمتر بوروکراتیک می‌شوند، در حالی که به شرکت‌های کوچک پیشرفت قدرتمندی می‌دهند.

به هر حال، شما به روش قدیمی کار نمی کنید و کارمندان شما مانند اکثر رقبای شما از فکر کردن (و کار کردن) باز می مانند.

Agile همچنین مستلزم مشارکت کارکنان است. و حتی به شرطی که همه در کار مشارکت داشته باشند، با پروژه های بزرگ در پایان باز هم صرفه جویی در زمان و افزایش کیفیت محصول خواهید داشت.

اما بازم میگم به شرطی که مدام در حال اجرای محصولات یا پروژه های جدید باشید.

به نظر می رسد که ارتباط در صورت. من به شما پیشنهاد می کنم از راه دیگری بروید. از شانه شلیک نکنید

به تدریج شروع به اجرای اصول چابک مانند ما کنید. شروع به مشارکت دادن متخصصان مختلف در اجرای پروژه های مختلف کنید. و ما می توانیم از تجربه خودمان بگوییم که کارایی ما به طور قابل توجهی افزایش یافته است.

صفحه 2 از 2

روش مدیریت پروژه چابک (Agile)

برای پروژه هایی که شامل یک جزء نرم افزاری قابل توجه است، روش سنتی مدیریت پروژه ممکن است به اندازه ای که الزامات مبهم و قابل تغییر باشد، موثر نباشد. روش دیگر، می‌توانید از روش مدیریت پروژه چابک (APM) استفاده کنید، که چندی پیش در بازار محبوبیت پیدا کرده است. این روش یک فرآیند نسبتاً تکراری و دوره‌ای است که طی آن توسعه‌دهندگان و شرکت‌کنندگان پروژه به طور فعال با هم کار می‌کنند تا دامنه را درک کنند، همچنین نیازهایی را که باید اجرا شوند و عملکردها را اولویت‌بندی می‌کنند.

زمانی که شرایط زیر وجود داشته باشد از روش های انعطاف پذیر استفاده می شود:

• معنای پروژه به وضوح نشان داده شده است،
• مشتری به طور فعال در طول پروژه درگیر است،
• مشتری، طراح و توسعه دهندگان در این نزدیکی هستند
• ممکن است توسعه گام به گام، بر اساس توابع
• اسناد بصری قابل قبول است (کارت پستال روی دیوار برخلاف اسناد رسمی). شکل 3

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

محیط کاربردی مدیریت پروژه چابک

توسعه چابک با همکاری یک تیم کوچک واقع در همان ساختمان انجام می شود. تیم اصلی معمولاً از دو توسعه‌دهنده تشکیل می‌شود که کد را به صورت جفت (مدیریت کیفیت کامل) مشتری/کاربر، معمار فناوری اطلاعات، تحلیلگر تجاری - و مدیر پروژه می‌نویسند. کار در یک سری از جلسات انجام می شود که در آن تیم کد را می نویسد، سپس ماژول های کار سیستم را آزمایش می کند و سپس فرآیند تکرار می شود. در عین حال، سطح مستندات به حداقل می رسد، زیرا تیم عمدتاً تنها بر ارتباطات غیررسمی درون تیم متکی است.

باز هم، این با رویکرد سنتی متفاوت است، که در آن زمان قابل توجهی به برنامه ریزی اختصاص داده می شود و مستندات گسترده نیازها و نیازمندی ها حفظ می شود. تیم چابک ویژگی‌های در حال توسعه را بر اساس ارزش آن‌ها برای کسب‌وکار شناسایی و اولویت‌بندی می‌کند، و هنگامی که اجزای سیستم حیاتی در جای خود قرار گرفتند، روی آن‌هایی کار می‌کنند که بالاترین اولویت را دارند. این رویکرد در صورتی مناسب است که محصول پیشنهادی بتوان گام به گام به مشتری تحویل داد. در صورتی که این امکان پذیر نباشد، عملکردها و ویژگی ها همچنان می توانند توسعه داده شوند و سپس در نسخه اصلی سیستم ادغام شوند.

اجزای روش فلکس

چند وجود دارد عناصر کلیدی، که اساس روش مدیریت انعطاف پذیر هستند. این تکنیک ها همچنین می توانند در روش سنتی برای بهبود عملکرد مورد استفاده قرار گیرند:

1. کنترل بصریاین روش برنامه ریزی بر اساس کارت های روی دیوار است که به تیم کمک می کند تا گردش کار را سازماندهی کند. به عنوان مثال، یک تیم موفق کارت هایی با رنگ ها و طرح های مختلف را روی دیوار قرار داد تا عناصر محصول نهایی را نشان دهد. آن عناصری که برنامه ریزی شده، توسعه یافته، آزمایش شده و قبلاً منتشر شده بودند، یک رنگ بودند، و آنهایی که برنامه ریزی شده، توسعه داده شده بودند، آزمایش شده بودند، اما هنوز منتشر نشده بودند (در عین حال، از قبل آماده انتشار) رنگ دیگری داشتند. تیم توانست به راحتی وضعیت هر مجموعه از عناصر را بررسی کند. کنترل بصری چشم انداز یکسان پروژه را توسط هر یک از شرکت کنندگان تضمین می کند.
2. تیم های با عملکرد بالا در کنار همروش توسعه چابک به این معنی است که همه اعضای تیم، از جمله مشتری / کاربر، ترجیحاً در یک اتاق کار در همان نزدیکی قرار دارند. این رویکرد کیفیت هماهنگی و ارتباطات را تا حد زیادی بهبود می بخشد. با این حال، این ممکن است تغییرات فرهنگی را برای توسعه دهندگان ایجاد کند، زیرا از آنجایی که رهبران پروژه مسئول جمع آوری یک تیم با عملکرد بالا هستند، اعضا باید بتوانند به طور مشترک کار کنند.
3. توسعه آزمایش محوردر مواردی که تعیین نیازها و نیازهای مشتری برای مشتری دشوار است، تیم توسعه اغلب از روشی مبتنی بر آزمایش محصول استفاده می کند. این نیاز به مراحل زیادی بین تعریف نیاز، برنامه ریزی، توسعه و آزمایش دارد. تیم تقریباً همیشه برنامه آزمایش را توسعه می‌دهد در حالی که الزامات را به طور موازی تعریف می‌کند - اگر یک نیاز قابل آزمایش نباشد، توسعه نیافته است. این رویکرد می تواند در روش توسعه سنتی مورد استفاده قرار گیرد و الزامات را کامل، دقیق و قابل آزمایش کند.
4. مدیریت سازگارهمه اعضای تیم به طور مداوم با شرایط وفق می دهند. با توجه به محیط پویا، مدیر پروژه باید یک رهبر باشد نه فردی که دستور بدهد. او باید به جای درخواست‌های سفت و سخت از گروه، یک رابطه کاری تیمی را با وضع قوانین و دستورالعمل‌های اساسی برای همکاری ایجاد کند. اعضای تیم در طول پروژه با یکدیگر سازگار خواهند شد و در عین حال دانش کسب شده در چرخه قبلی را به کار می گیرند و در نتیجه روش ها را بهبود می بخشند که مطمئناً تأثیر مثبتی بر پروژه خواهد داشت.
5. توسعه مشترکمتدولوژی توسعه چابک مبتنی بر همکاری بین همه اعضای تیم برای به دست آوردن نتایج خوب، نظرات عینی و اجرای تمام دانش کسب شده در مرحله بعدی توسعه است. این یکی از فواید است این روش- نظرات و پیشرفت های عینی ثابت مدیر پروژه برنامه ریزی اولیه را تکمیل می کند و تحلیلگر تجاری عناصر محصول در دست توسعه را به همراه مشتری و متخصصان شناسایی و اولویت بندی می کند. در مرحله بعد، تیم های پروژه برای طراحی، توسعه، آزمایش و اصلاح نسخه هر مرحله قبلی با یکدیگر همکاری می کنند. چنین همکاری با مشتری منجر به یک پروژه موفق می شود.
6. توسعه بر اساس عناصر محصول در حال توسعه.این سیستم توسعه پیچیدگی پروژه را تا حد زیادی کاهش می دهد و به تیم ها اجازه می دهد تا روی هر عنصر به طور جداگانه تمرکز کنند. به عنوان مثال، یک تیم از کارمندان روی عنصر شماره 4 کار می کنند - و این تمام چیزی است که آنها به آن اهمیت می دهند. آنها به موارد شماره 1-3 اهمیت نمی دهند. این نگرانی تحلیلگر کسب و کار و مدیر پروژه است که اطمینان حاصل می کند که مورد بعدی در لیست بر اساس ارزش تجاری و سطح ریسک آن دارای بالاترین اولویت است. اغلب، اجزای پرخطر یا قطعات کلیدی زیرساخت ابتدا توسعه می‌یابند، و سپس همه چیز بر اساس ارزش تجاری اولویت‌بندی می‌شود. هدف ساخت کامپوننت ها بر اساس کارکرد اما داشتن وابستگی یک طرفه به سیستم اصلی است، بنابراین اجزای تخصصی مستقل از یکدیگر بوده و می توانند به هر ترتیب و یا به صورت موازی ساخته شوند.
7. رهبری و همکاری در مقابل فرماندهی و کنترل.اصل توسعه چابک مستقل از زمان است و ارتباط نزدیکی با رهبری دارد. نسبت به روش سنتی مدیریت، گام های بیشتری برای ایجاد رهبری ارائه می دهد. مدیر پروژه با مشتریان، متخصصان و شرکت کنندگان پروژه کار می کند تا اطمینان حاصل کند که آنها از وضعیت پروژه آگاه هستند. علاوه بر این، مدیر پروژه تمام موانع بین تیم ها را در پروژه از بین می برد.
8. انتقال تمرکز از هزینه ها به سود.عناصر بر اساس اهمیت کسب و کار در اولویت قرار می گیرند، به عنوان مثال، سطح بالادرآمد و سهم بازار این وظیفه تحلیلگر کسب و کار است که اطمینان حاصل کند که تیم توسعه پروژه در توسعه یک محصول جدید خیلی عمیق نمی شود. اگر این اتفاق بیفتد، آنگاه ممکن است پروژه از هزینه های برنامه ریزی شده فراتر رود و بیش از ارزش آن هزینه داشته باشد. در حالی که مدیر پروژه به هزینه‌ها اهمیت می‌دهد، تحلیلگر تجاری بر هزینه کل مالکیت کل محصول تمرکز می‌کند، که نه تنها هزینه خود محصول یا نصب آن را شامل می‌شود، بلکه شامل استفاده بعدی از سیستم پس از نصب نیز می‌شود.
9. آموختن درس های آموخته شده.پس از هر چرخه، تیم باید تمام مهارت ها و دانش کسب شده را به منظور بهبود روند چرخه بعدی جذب کند. همانطور که آنها یاد می گیرند، اعضا با کار سایر همکاران سازگار می شوند و برای بهبود عملکرد تیم با یکدیگر همکاری می کنند.

مزایای پیشنهادی مدیریت پروژه چابک

رویکرد سنتی به مدیریت پروژه خطی است، جایی که همه چیز در یک چرخه انجام می شود. شما همه چیز را با جزئیات برنامه ریزی می کنید و به محض اینکه همه چیز آماده و توسعه یافت، کل پروژه را تحویل می دهید. این طرز تفکر از توسعه نرم افزار به پروژه های دیگر نیز سرایت کرده است - و این تفاوت بین رویکرد سنتی و چابک است.

در مورد مدیریت پروژه چابک، شما فقط به اندازه نیاز برنامه ریزی می کنید. در حالی که هر بخش از سیستم در حال توسعه است، تیم تمام تجربیات به دست آمده و همچنین بازخورد مشتریان را جمع آوری می کند. از آنجایی که مشتری یک نمونه اولیه کار را می بیند و/یا تجربه می کند، تعریف یا بازتعریف الزامات برای او آسان تر خواهد بود و آنچه را که سازمان واقعاً به آن نیاز دارد برای تیم توسعه توصیف می کند. این روش شامل تغییراتی است که از طریق توسعه تکراری، ارزش به ارمغان می آورد و هزینه ها را کاهش می دهد. تغییرات در یک ماژول کوچک ارزان تر از تغییرات در یک سیستم بزرگ توسعه یافته است.

آیا می توان از روش مدیریت پروژه منعطف استفاده کرد؟

در هسته خود، مدیریت پروژه، چه سنتی و چه چابک، تمرکز اولیه بر رضایت مشتری دارد. نکته این است که تیم را مدیریت کنید تا نتایج قابل اندازه گیری را ارائه دهید. بسیاری از مهارت های عملی را می توان در اکثر ساختارهای سازمانی از نوع فرماندهی به کار برد. با این حال، برخی از متخصصان در محیط مدیریت پروژه ممکن است این اصول مدیریت پروژه چابک را نادیده بگیرند، در صورتی که نتوانند همه مهارت‌ها و مؤلفه‌ها را به کار گیرند - اما این یک اشتباه نخواهد بود. برای مثال، اگر نتوانند کاربر را مجبور کنند همیشه در اتاق کار با تیم توسعه باشد، چه اتفاقی می‌افتد؟ این بدان معنا نیست که آنها نمی توانند از سایر اصول چابک مانند بازرسی بصری و توسعه پیش بینی شده استفاده کنند. علاوه بر این، حتی اگر کاربر به طور کامل درگیر نباشد، بسیاری از کاربران مایل به شرکت در تیم هستند، به خصوص در طول فرآیند تست و اولویت بندی آیتم ها. بقیه زمان ها، تحلیلگر کسب و کار می تواند منافع کاربر را نمایندگی کند، در حالی که تیم کاملاً در اختیار است کار مشترک.

پیاده سازی تکنیک های مدیریت چابک در پروژه ها، تمرکز بر مزایای هر عنصر را فراهم می کند. در رویکرد سنتی، تیم ها باید پروژه را به موقع و با بودجه تکمیل کنند، در حالی که مسیر سود سازمانی را که پروژه در نظر گرفته شده برای دستیابی به آن از دست می دهد. لازم به یادآوری است که استراتژی بهبود پروژه با توجه به افزایش هزینه کل محصول و استفاده بیشتر از آن است و نه صرفاً هزینه پروژه - در این صورت، مزایای پروژه به وضوح مشخص خواهد شد. بیان می شود، صرف نظر از اینکه تیم محصولی را ایجاد می کند یا محصول جدیدی را توسعه می دهد.

هر کسی که تا به حال با مدیریت پروژه سر و کار داشته باشد می داند که سازماندهی یک کار تیمی به خوبی هماهنگ شده چقدر دشوار است و در مواجهه با الزامات دائمی در حال تغییر برای نتیجه یک پروژه، تمام تلاش های انجام شده ممکن است بیهوده شود. روش مدیریت پروژه چابک برای کار با چنین پروژه هایی ایده آل است.

روش مدیریت پروژه چابک مجموعه‌ای از مراحل کاری است که با ضرب‌الاجل‌های سخت تعریف می‌شوند - اسپرینت‌ها، به تیم اجازه می‌دهد تا به طور مداوم نتایج کار انجام شده را ارزیابی کند و از مشتری و سایر شرکت‌کنندگان پروژه بازخورد دریافت کند. این رویکرد به شما این امکان را می دهد که در صورت رسیدن نیازهای جدید، تغییرات فوری در محصول ایجاد کنید.

تاریخچه چابک

مدیریت پروژه تکاملی و توسعه نرم افزار تطبیقی ​​در اوایل دهه 1970 پدیدار شد. در سال 1970، دکتر وینستون رویس مقاله ای با عنوان "مدیریت توسعه بزرگ" ارائه کرد. سیستم های نرم افزاری"، که توسعه متوالی را مورد انتقاد قرار داد. او استدلال می‌کرد که نرم‌افزار نباید مانند یک خودرو در خط مونتاژ که هر قسمت در فازهای متوالی اضافه می‌شود، توسعه یابد. در چنین فازهای متوالی، هر مرحله از پروژه باید قبل از شروع فاز بعدی تکمیل شود. دکتر رویس استفاده از رویکرد مرحله‌ای را توصیه می‌کند که در آن توسعه‌دهندگان ابتدا تمام الزامات پروژه را جمع‌آوری می‌کنند و سپس کل معماری و طراحی خود را تکمیل می‌کنند، سپس همه کدها را می‌نویسند و غیره.

در دهه 1990، تعدادی از روش‌های توسعه نرم‌افزار چابک در پاسخ به روش‌های سنگین‌وزن رایج توسعه یافتند. این موارد عبارتند از: از سال 1991 - RAD (توسعه سریع برنامه). از سال 1994 - روش توسعه سیستم های پویا (DSDM); از سال 1995 - اسکرام؛ از سال 1996، برنامه نویسی Crystal Clear and Extreme (XP); و از سال 1997 - توسعه مبتنی بر ویژگی (FDD). اگرچه آنها قبل از انتشار مانیفست توسعه نرم افزار چابک ایجاد شدند، اما در مجموع به عنوان توسعه نرم افزار چابک شناخته می شوند.

در فوریه 2001، هفده توسعه‌دهنده نرم‌افزار در Snowbird Resort در یوتا گرد هم آمدند تا درباره تکنیک‌های توسعه سبک‌وزن بحث کنند. آنها با هم مانیفست چابک را منتشر کردند.

مانیفست چابک

مانیفست چابک شامل 4 ایده اصلی و 12 اصل است. هر متدولوژی Agile این ایده ها را به طور متفاوتی به کار می گیرد، اما همه آنها برای مدیریت پروژه ها به بهترین نحو ممکن بر آنها تکیه می کنند.

4 ایده چابک

1. افراد و تعامل مهمتر از فرآیندها و ابزارها هستند.
2. نرم افزار کار مهمتر از مستندسازی است.
3. همکاری با مشتریان مهمتر از مذاکره در مورد شرایط قرارداد است.
4. تمایل به ایجاد تغییرات در اولویت به جای پایبندی به برنامه اولیه.

12 اصل چابک

1. رضایت مشتری از طریق تحویل زودهنگام و مستمر نرم افزار. مشتریان زمانی که نرم افزار کار را در فواصل زمانی منظم دریافت می کنند، خوشحال تر می شوند.
2. در طول فرآیند توسعه، نیازهای محصول را تغییر دهید.
3. تحویل مکرر نرم افزارهای کاری (هر ماه، دو هفته یکبار، هفتگی و غیره).
4. همکاری بین ذینفعان (مشتری و توسعه دهندگان) در طول پروژه.
5. حمایت، اعتماد و انگیزه افراد درگیر. تیم‌های با انگیزه بیشتر به نتایج خود عمل می‌کنند بهترین شغلنسبت به کارکنان ناراضی از شرایط کار.
6. تعامل چهره به چهره. ارتباطات زمانی موفق تر است که تیم های توسعه قادر به برقراری ارتباط مستقیم باشند.
7. نرم افزار کار معیار اصلی پیشرفت است. ارائه نرم افزار کاربردی به مشتری عامل نهایی است که پیشرفت را می سنجد.
8. حفظ سرعت کار ثابت. تیم‌ها یک نرخ عملیاتی تکرارپذیر و پایدار ایجاد می‌کنند که در آن می‌توانند نرم‌افزار کارآمد را ارائه دهند.
9. توجه به جزئیات فنی و طراحی. مهارت های مناسب و طراحی خوببه تیم اجازه دهید حرکت خود را حفظ کند، محصول را به طور مداوم بهبود بخشد و روی تغییر کار کند.
10. سادگی.
11. تیم های خودسازمانده معماری، الزامات و طرح های عالی را تشویق می کنند. اعضای تیم واجد شرایط و با انگیزه که صلاحیت تصمیم گیری را دارند به طور منظم با سایر اعضای تیم ارتباط برقرار می کنند و ایده هایی را مبادله می کنند که ایجاد یک محصول با کیفیت را تضمین می کند.
12. سازگاری مداوم با شرایط در حال تغییر، که به رقابتی تر شدن محصول در بازار کمک می کند.

اساس روش چابک

اساس روش مدیریت پروژه چابک تعدادی از عناصر کلیدی است:

1. کنترل بصری شرکت کنندگان پروژه در طول کار روی پروژه از کارت هایی با رنگ ها و انواع مختلف استفاده می کنند که نشان می دهد کدام عنصر محصول نهایی قبلاً توسعه یافته، برنامه ریزی شده، تکمیل شده است و غیره. بنابراین، تیم یک نمایش تصویری از وضعیت فعلی دارد. کنترل بصری چشم انداز یکسان پروژه را توسط هر یک از شرکت کنندگان تضمین می کند.
2. همه شرکت کنندگان پروژه در کنار هم کار می کنند، از جمله مشتری. این رویکرد نه تنها بسیاری از فرآیندهای مرتبط با اطلاع رسانی به شرکت کنندگان را سرعت می بخشد گروه کاریبلکه فضای مساعدی را برای همکاری و کار موثر ایجاد می کند.
3. مدیریت سازگار مدیر پروژه فردی نیست که دستور بدهد، بلکه رهبری است که قوانین اساسی کار و همکاری را تعیین می کند.
4. همکاری. تیم، مدیر پروژه و مشتری با هم کار می کنند که احتمال از بین رفتن اطلاعات و درک نادرست اهداف را از بین می برد. همچنین شفافیت تمامی فرآیندها به شما این امکان را می دهد که فوراً مشکلات نوظهور را از بین ببرید و راه حل ها و پیشرفت های موفقی پیدا کنید.
5. کار بر اساس تقسیم کل محدوده پروژه به اجزای سازنده آن. این سیستم کار پیچیدگی پروژه را به میزان قابل توجهی کاهش می دهد و به تیم ها اجازه می دهد تا روی هر قسمت به صورت جداگانه تمرکز کنند.
6. روی اشکالات کار کنید در طول کار یک چرخه، تیم مهارت های جدیدی را یاد می گیرد و خطاهای رخ داده را تجزیه و تحلیل می کند، که وقوع آنها در چرخه بعدی را حذف می کند.
7. دوی سرعت و جلسات روزانه. اسپرینت - دوره‌هایی از زمانی که تیم‌ها یک سری وظایف را انجام می‌دهند - به شما این امکان را می‌دهد که نتایج کار را به وضوح ببینید. با تقسیم زمان کار روی پروژه به دوی سرعت، به عنوان مثال، 10 اسپرینت، هر کدام برای دو هفته، دریافت می کنیم. و جلسات روزانه بیش از 15 دقیقه به هر یک از اعضای تیم کمک می کند تا به سه سؤال برای خود پاسخ دهند: دیروز چه کار کردم، امروز چه خواهم کرد، چه چیزی مانع از انجام کار می شود؟

بنابراین، معرفی یک روش چابک تحت شرایط زیر امکان پذیر است:

• معنای پروژه به وضوح نشان داده شده است،
• مشتری به طور فعال در طول پروژه درگیر است،
• امکان اجرای گام به گام کل محدوده پروژه،
• نتیجه کار مهمتر از مستندات است،
• گروه کاری بیش از 7-9 نفر نیست.

در حال حاضر، متدولوژی Agile در زمینه فناوری اطلاعات گسترده شده است و شروع به تسلط بر حوزه تجاری، به ویژه بازاریابی، مدیریت، آموزش و غیره کرده است. روش مدیریت پروژه چابک توسط بسیاری از شرکت ها و سازمان های دولتی استفاده می شود، به عنوان مثال، دولت های نروژ و نیوزلند از Agile استفاده می کنند. در روسیه، Sberbank در حال تسلط بر Agile برای بخش تجاری است.

سیستم های مدیریت پروژه مبتنی بر Agile

روش های زیادی بر اساس ایده Agile وجود دارد که محبوب ترین آنها Scrum و Kanban هستند.

SCRUM

اسکرام یک روش مدیریت پروژه است که بر کنترل کیفیت فرآیند کار تمرکز دارد. هیروتاکا تاکوچی و ایکوجیرو نوناکا، اولین کسانی که رویکرد اسکرام را توصیف کردند، آن را به عنوان «رویکرد راگبی» توضیح دادند که در آن اسکرام برای توپ می‌جنگد. این روش خود یک فرآیند توسعه است که به تکرارهای کوچک تقسیم می شود - اسپرینت ها، که در پایان آن کاربران نسخه بهبود یافته نرم افزار را دریافت می کنند. اسپرینت به طور سفت و سخت در زمان ثابت است و مدت آن از 2 تا 4 هفته است. کار در یک اسپرینت شامل چند مرحله است:

1. برنامه ریزی محدوده کار برای یک سرعت.
2. جلسات روزانه به مدت 15 دقیقه برای اصلاح کار تیم و جمع بندی نتایج میانی.
3. نمایش نتایج کار.
4. یک بازنگری دوی سرعتی که موفقیت ها و شکست های آخرین سرعت را بررسی می کند.

اسکرام بیشتر برای مدیریت نرم افزارهای پیچیده و توسعه محصول با استفاده از روش های تکراری و افزایشی استفاده می شود.

اسکرام بهره وری را تا حد زیادی افزایش می دهد و زمان را نسبت به فرآیندهای کلاسیک "آبشار" کاهش می دهد. فرآیندهای اسکرام به سازمان ها این امکان را می دهد که به طور یکپارچه با نیازهای در حال تغییر سریع سازگار شوند و محصولی را ایجاد کنند که اهداف تجاری در حال تغییر را برآورده کند. اسکرام به شما اجازه می دهد:

• بهبود کیفیت نتایج؛
• بهتر است با تغییرات کنار بیایید.
• تخمین های دقیق تری ارائه دهید و زمان کمتری برای ایجاد آنها صرف کنید.
• بهتر است سناریو پروژه و مراحل کار را کنترل کنید.

کانبان

کانبان فرآیندی است که برای کمک به تیم ها برای همکاری موثرتر با یکدیگر طراحی شده است. ترجمه شده از ژاپنی، kanban به معنای "بلورد، تابلو" است و خود این روش از سیستم تولید تویوتا گرفته شده و اقتباس شده است. ماهیت Kanban این است که فرآیند توسعه را تا حد امکان شفاف کند و بار را به طور مساوی بین اعضای تیم توزیع کند. کانبان همکاری مستمر را ترویج می کند و یادگیری و بهبود فعال و مستمر را تشویق می کند.

کانبان بر سه اصل استوار است:

1. تجسم وظایف: قابل مشاهده بودن تمام اطلاعات مربوط به پروژه به مشاهده کاستی ها، خطاها و همپوشانی ها کمک می کند.
2. کنترل و محدودیت WIP (کار در حال انجام): این به متعادل کردن رویکرد threading کمک می‌کند تا تیم‌ها یک‌باره کار زیادی را شروع نکنند و انجام ندهند.
3. زمان تکمیل کار را کنترل کنید و کار را برای صرفه جویی در زمان بهینه کنید.

مزایا و معایب Agile

هر روشی دارای مزایا و معایبی است. جوانب مثبت و منفی Agile را در نظر بگیرید.

مزایای

1. انعطاف پذیری بیشتر در مقایسه با روش Waterfall.

روش سنتی آبشار به وضوح مراحل کار را دیکته می کند. با متدولوژی Agile، برنامه زمان بندی و هزینه تعیین کننده اصلی هستند و این حوزه ای است که برای برآورده کردن نیازهای مشتریان و مصرف کنندگان محصول تغییر می کند.

2. نقص کمتر در محصول نهایی.

این نتیجه بررسی کیفیت انجام شده در هر مرحله از کار است. فرآیند مستمر "توسعه، ساخت و آزمایش" نیز با ادامه چرخه های تکرار، نقص ها را کاهش می دهد.

معایب

1. دریافت مداوم بازخورد منجر به به تعویق افتادن دائمی تاریخ اتمام پروژه می شود.

با توجه به بازخورد فوری که Agile ارائه می دهد، خطر کار طولانی وجود دارد. کاربران نهایی که می بینند این الزامات را می توان "به راحتی" برآورده کرد (آنها فقط نتیجه را می بینند، نه تلاش) ویژگی های اضافی را درخواست می کنند. اگر مدیر پروژه و توسعه دهندگان نتوانند انتظارات را مدیریت کنند، کاربران نهایی درخواست بیشتری خواهند کرد تا زمانی که کل تیم غرق در کار اضافی شوند.

2. مستندات

با توجه به ماهیت انعطاف پذیر Agile، اسناد باید از شرایط پروژه پیروی کنند. درخواست تغییر یا ویژگی می‌تواند با جزئیات مورد بحث قرار گیرد و با کاربران نهایی، توسعه‌دهندگان و آزمایش‌کنندگان مورد توافق قرار گیرد، اما اگر تیم مطلع نمی‌شد، یک سند مهم مانند راهنمای کاربر، سند معماری، یا سند الزامات عملکردی منسوخ می‌شد.

3. جلسات مکرر

در حالی که Agile توصیه می کند که این جلسات روزانه برگزار شود تا همه از پیشرفت یکدیگر مطلع شوند، پایداری این روش بر پیشرفت تکرار تأثیر می گذارد. توسعه دهندگان روی کاری که انجام می دهند متمرکز هستند. بیرون کشیدن آنها برای جلسه ای که ممکن است حواس آنها را از انجام کار واقعی منحرف کند، چیزی نیست که با خوشحالی قبول کنند.

پیاده سازی چابک

1. انتخاب روش.روش‌شناسی‌های انعطاف‌پذیر مختلفی وجود دارد که تحت شرایط خاصی توسعه می‌یابند. اولین گام در کار با Agile این است که اهداف کار، ضرب الاجل ها، تعداد کارمندان و موارد دیگر را تعیین کنید و چنین روش مدیریت پروژه انعطاف پذیری را انتخاب کنید که تمام الزامات را برآورده کند.
2. آموزش.آموزش لازم است تا کارکنان اصول اولیه Agile را درک کنند و بدانند چگونه با آنها کار کنند. در این مرحله است که تله هایی که می توانند اثربخشی Agile را کاهش دهند شناسایی می شوند. آیا تیم آماده تغییر است؟ آیا پروژه های این شرکت برای تمرینات چابک مناسب است؟ این و بسیاری از سوالات دیگر معمولا توسط مربیان تجاری Agile پاسخ داده می شود. از جمله لیستی از آموزش ها و برنامه ای نیز تهیه می شود که بر اساس آن اجرای Agile در شرکت انجام می شود.
3. دمو چابکنوعی تست درایو چابک که زیر نظر یک متخصص انجام می شود و تمام مراحل کار را نشان می دهد، عملکرد نقش ها، تعامل درون تیمی و بین تیم ها و غیره را توضیح می دهد.
4. ایجاد یک تیم.ایجاد یک تیم علاوه بر انتخاب کارکنان، شامل تعریف مسئولیت ها، توزیع وظایف، ایجاد برنامه جلسات و غیره نیز می شود. هر یک از روش ها برای تعداد معینی از افراد تیم طراحی شده است.
5. انتخاب ابزاربرای توزیع وظایف، گزارش، تجزیه و تحلیل و موارد دیگر ضروری است.
6. اولین پروژه با Agile.در پروژه اول، خطاها، ناهماهنگی ها، رد برخی ابزارها و انتخاب برخی دیگر وجود خواهد داشت. هر تکنیکی مستلزم نوعی انطباق با ویژگی های شرکتی است که در آن اجرا می شود.

اگر خطایی پیدا کردید، لطفاً قسمتی از متن را برجسته کرده و کلیک کنید Ctrl+Enter.