شاید افراد فکر کنند که با زیاد و گاهی بیش از حد کار کردن میتوانیم به روند رو به رشد پروژه ها کمک کنیم، اما آیا این نظر درست است؟
مستند سازی:
یکی از دلایل مهمی که بر رویWorking Software بیش تر از تولید مستندات جامع تمرکز میشود این است که مستند سازی زمان بر است و این زمان ارزشمند از وقت افراد تیم توسعه صرف خواهد شد. ما به این ضد الگو (View-graph Engineering) میگوییم و همانند Gold Plating نتیجه آن، تمرکز نکردن روی موارد با ارزش و صرف وقت برای کارهایی ست که ارزش کمتری ایجاد می کنند.
در این شرایط توسعه دهنده به جای اینکه آزادانه بر روی کد نویسی و حل مشکلات تکنیکی تمرکز کند، وقت خود را به مستند سازی، ساختن گزارش ها و ارائه ها می گذراند. در سازمان‌هایی که دچار مشکل ساختار هرمی یا طبقاتی هستند این موضوع بیشتر رخ می دهد. زیرا در این شرایط، یک توسعه دهنده برای کار روی محصول درگیر فرآیند های دست و پاگیر و توضیح و ارائه به سلسله مراتب بالاتر از خود می شود.
راهکار معمول، اصلاح ساختار تیم توسعه محصولات نرم افزاری است، هر چه ساختار به مسطح تر شدن میل کند، این مشکل کمتر بروز خواهد کرد. همچنین این موضوع قابل اندازه گیری و توجیه است. زیرا زمانی که توسعه دهنگان صرف مستند سازی، ساخت ارائه ها و گزارش ها می کنند به اندازه زمان ساخت یکMVP از آنها وقت خواهد گرفت.
همواره در نظر داشته باشید، ارزشی که محصول ایجاد شده اولیه (MVP) ارزش وقتی که توسعه دهنگان شما روی آن صرف کرده اند را داشته باشد.
خروج اضطراری Fire Drill:
این درست زمانی است که ما بهlunch محصول خود نزدیک می شویم. اگر خیلی از مراحل اصلی برنامه ریزی و تحلیل را به درستی انجام نداده باشیم، فشار کاری روی توسعه دهندگان بالا می رود و آنها زمان هایی بیش از وقت کاری خود را صرف توسعه محصول و پیشبرد آن خواهند کرد. بخشی از این موضوع به اولویت بندی کارها مربوط است. در صورتی که در طول زمان آماده سازی محصول، میزان کار انجام شده توسط تیم توسعه در هر Sprint کم تر از میزانی باشد که لازم است، بیشتر فشار به آخرین روز ها منتقل خواهد شد.
در این شرایط Scrum Master وPO کسانی هستند که باید کارهای برنامه ریزی شده را به خوبی مدیریت کنند. مالک محصول بیشتر در قسمت Business که نیاز ها به صورت صحیح و شفاف توسط ذینفعان تعریف شوند وScrum Master بعنوان تسهیلگر در کنار تیم ها.
در صورتی که با این شرایط مواجه شویم، باید بدانیم که رسیدن به زمان هایی که برای تحویل محصول به آن تعهد کرده ایم باعث فدا شدن کیفیت کار توسعه دهندگان نرم افزار می شود و در اصلاح برای ما "بدهی فنی" ایجاد می کند.
ابر قهرمانان Super Heroes:
ضد الگوی خروج اضطراری عموما منجر به بوجود آمد ضد الگوی دیگری میشود و آن اتکای توسعه محصول بر ابرقهرمانان است. افرادی با توانایی بسیار بالا در زمینه توسعه محصول نرم افزاری که ناگهان از راه می رسند و کار های ناتمام را به سرانجام می رسانند و در آخر مورد تقدیر همگان واقع می شوند.
دقت داشته باشید افراد تیم توسعه نیازمند داشتن روحیه و حس اعتماد هستند. و شما بعنوان تسهیلگر و مدیر میبایست این حس را در آنها ایجاد کنید. بوجود آمدن چنین شرایطی که "ما همواره به ابرقهرمان ها نیاز داریم" آنها را به این نتیجه می رساند که کاری که در طول فرآیند توسعه محصول انجام می دهند مورد توجه قرار نخواهد گرفت بلکه تمامی تقدیر ها شامل ابرقهرمانی می شود که قرار است "محصول را نجات دهد."
بعنوان مدیران یا مالکان محصول در کنار تیم توسعه وظیفه ما این است که علاوه بر ایجاد اعتماد سازی با اعضای تیم توسعه، ارزش کار آنها را ذکر کرده و همچنین به آنها در بهبود سرعت توسعه و برداشتن موانع از سر راه آنها کمک کنیم.
فراموش نکنیم اگر افرادی که محصول را تولید می کنند (تیم توسعه) به آن "باور نداشته باشند" یا روحیه خود را از دست بدهند عملا این محصول محکوم به شکست است حتی اگر به مشتری تحویل داده شود.
پایان قسمت سوم
