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

  • یوسف مهرداد بی‌بالان

پیش‌گفتار

متن زیر ترجمه‌ای است از یکی از نوشته‌های آقای مایک کوهن درباره‌ی اسکرام روزانه. امیدوارم برای شما خوانندگان گرامی مفید باشد.

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

در سال 1975، فرد بروکس (Fred Brooks) مدیر پروژه‌ی IBM OS/360 بود. این پروژه جزء اولین پروژه‌های نرم‌افزاری بود که تأخیرش شهره‌ی خاص و عام شد. در واقع، پروژه یک سال تأخیر داشت. … از بروکس پرسیده بودند که «چه طور یک پروژه می‌تواند یک سال تأخیر داشته باشد؟». بروکس در پاسخ، جمله‌ی بسیار معروف خود را گفت: «یک روز، یک روز» (one day at a time یا هر بار، یک روز).

اعتقاد دارم که اسکرام روزانه به ما کمک می‌کند تا پروژه‌های ما دچار چنین سرنوشتی نشوند. با برگزاری جلسه‌ی روزانه، مشکلات زودتر از هر روش شناخته‌شده‌ی دیگری مطرح می‌شوند. این کار باعث می‌شود که اشتباه «هر بار، یک روز تأخیر» را مرتکب نشویم که باعث شد پروژه‌ی بروکس یک سال تأخیر داشته باشد.

بگذریم!

آیا اسکرام روزانه باید هر روز برگزار شود؟

بله! اکثر تیم‌ها باید هر روز این جلسه را برگزار کنند.

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

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

این دو کار اصلاً شبیه به هم نیستند. در چنین تیم‌هایی، اسکرام روزانه احتمالاً تنها زمانی در طول یک روز کاری است که «همه‌»ی افراد در بحث و گفتگو «مشارکت» می‌کنند. در حالی که در سایر گفتگوها و بحث‌ها، فقط بخشی از اعضای تیم مشارکت دارند.

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

اما چه زمانی برگزاری اسکرام روزانه در یک تیم ضرورت ندارد؟

الف) در تیم‌هایی که در یک جا مستقر نیستند (تیم‌های توزیع‌شده)، اسکرام روزانه می‌تواند در روز جمعه برگزار نشود. [جمعه، آخرین روز کاری تیم‌ است و شنبه، یکشنبه تعطیل است]. تیمی را در نظر بگیرید که چند تن از اعضایش از راه دور کار می‌کنند و دارای اختلاف زمانی زیادی هستند و 8 شب افراد دورکار، 8 صبح به وقت محل استقرار تیم است [فرض کنید تیم دورکار در هند و تیم اصلی در آمریکاست]. حضور در جلسه‌ی اسکرام روزانه از دوشنبه شب تا پنج‌شنبه شب برای تیم دورکار قابل قبول و ضروری است. اما کسی دوست ندارد شب تعطیلات آخر هفته‌اش را یعنی جمعه‌شب را هم در جلسه باشد.

ب) روزهایی که برنامه‌ریزی اسپرینت برگزار می‌شود، بسیاری از تیم‌ها برگزاری اسکرام روزانه را بی‌فایده می‌دانند. معمولاً برنامه‌ریزی اسپرینت با بحث‌هایی تمام می‌شود که همان بحث‌های اسکرام روزانه است….

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

گزیده:

daily scrum

تابلوی کانبان و واکنش مدیران

  • یوسف مهرداد بی‌بالان

به نقل از مایک بوروس:

اگر تابلوی کانبان نشان ‌دهد که شرایط مطابق انتظار شما نیست، چه واکنشی نسبت به آن خواهید داشت؟ برخی از واکنش‌های متداول مدیران یا مربیان به شرح زیر است:

  1. اهمیت ندهید، مثل همیشه خودش درست می‌شود.
  2. تا زمانی که این شرایط تغییر نکند باید دخالت کنم و کارها را دقیق‌تر مدیریت کنم.
  3. باید دخالت کنم و سیستم را تغییر بدهم .
  4. آیا آنها می‌دانند که چه‌طور کار به اینجا رسیده؟ آیا می‌خواهند تغییراتی در سیستم ایجاد کنند؟ چگونه می‌توانم به آنها کمک کنم؟
  5. به توانمندی آنها برای ایجاد تغییرات مناسب برای چنین شرایطی باور دارم.

 

همه‌ی این واکنش‌ها درست است اما به نظر می‌رسد برخی از آنها پخته‌تر از بقیه هستند. کانبان با تشویق به اقدام و پشتیبانی از تصمیم‌گیری درست، افراد را به سمت واکنش‌های پخته‌تر مانند 4 و 5 هدایت می‌کند. سازمان‌هایی که آگاهانه از این‌گونه موضوعات و شیوه‌هایی از رهبری که مشوق این‌گونه موضوعات‌اند استقبال می‌کنند، در مسیر بلوغ پیش می‌روند.

واکنش‌ 5 (و کمی کم‌تر، واکنش 4) شامل عنصر جذاب دیگری به نام خودسازماندهی است. خودسازماندهی پدیده‌ی زیبایی است و فقط به این معنا نیست که افراد برای کارهای خود دارای استقلال هستند، هرچند این امر برای موفقیت آنها ضروری است. معنای دیگر خودسازماندهی این است که سیستم برای روبه‌رو شدن اثربخش‌تر با چالش‌های خود می‌تواند خود را بازپیکربندی کند. خودسازماندهی با این تعریف درست و کامل خود، موجب تطبیق‌پذیری و انعطاف‌پذیری می‌شود و چون بدون مداخله‌ی بیرونی رخ می‌دهد، به‌خوبی مقیاس‌پذیر است. خودسازماندهی هم برای عملیات سیستم و هم برای تغییر سیستم، موضوعی اثربخش و انسانی است.

گزیده:
شما چه واکنشی به تابلوی کانبان خواهید داشت؟

یادگیری کانبان (7)

  • یوسف مهرداد بی‌بالان

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

یوآخیم با صدای بلند به گروهی که جلوی تابلو جمع شده ­بودند، گفت: «خب بچه‌ها! بیایید از همین اول، کار رو ساده کنیم و برگه‌ها رو به­‌ترتیب اولویت از بالا به پایین مرتب کنیم. این کار، برای بعد مفیده چون مي­تونيد به سادگی مهم­ترین کار هر ستون رو ببینید.»

مارکوس پرسید: «کار روی هر قلم را چه‌­طوری شروع می‌­کنید؟ اولین کاری که باید انجام بدید چیه؟» فرانک گفت: «معمولاً با یک جلسه طراحی شروع می‌­کنیم. که چه‌­طوری کار رو پیاده‌سازی کنیم؟ برای چه کاری می­‌تونیم از سکوی نرم‌­افزاری (Platform) موجود استفاده کنیم؟ آیا برای راهکار نرم‌­افزاری جدید باید از مؤلفه‌های پیاده‌سازی شده در سایر تیم‌ها استفاده کنیم؟ معمولاً این جور کارها رو انجام می‌دیم.»

بِث گفت: «البته مستنداتی هم برای پاسخ این پرسش‌ها تهیه می‌کنیم.»

یوآخیم پرسید: «شما به این کار چی می‌گید؟»

سزار گفت: «با کلمه‌ی «طراحی» موافقید؟»

فرانک گفت: « آها…، نه، درست نیست. در این مرحله باید کارهای زیادی انجام بشه. شاید «تحلیل» (Analyze) کلمه‌ی مناسب­تری باشه.» و از مارکوس پرسید: «نظر شما چیه؟»

1002.png

مارکوس رو به روی گروه ایستاد و گفت: «من نظری ندارم. این گردش‌ِکار تیم شماست. به جای من، از تیم بپرسید. نظر شماها چیه؟»

دافنه گفت: «بله. تحلیل کلمه‌ی مناسب­تری‌ یه.» بقیه هم به­‌نشانه‌ی موافقت سر تکان دادند.

مارکوس پرسید: «کاری هست که الآن مشغول تحلیل اون باشید؟»

اعضای گروه موافقت کردند تا دو تا از برگه‌ها را در ستون تحلیل قرار دهند.

یوآخیم گفت: «گردش کار رو تا مرحله‌ی «عملیاتی شدن» ( In production) دنبال کنید.» یوآخیم با خودش فکر ‌کرد که بعضی اوقات یکسری واژه‌های ناب (Lean) پشت سر هم تبدیل به شعر می‌شوند. نگاه سریعی به اطراف انداخت و متوجه شد که بقیه هنوز منظورش را نفهمیده‌اند. سرفه‌ای کرد و گفت: «خب! بعد از تحلیل چی‌کار می‌­کنید؟»

در ادامه، اعضای تیم ستون­های توسعه (Development) و آزمون (Testing) را به تابلو اضافه کردند و برگه‌­های کارهاي موجود را روی این ستون‌­ها چسباندند. سپس خیلی کوتاه در مورد معنی کار «انجام ‌شده» (Done) با هم بحث کردند. آنها تصمیم گرفتند در گردش‌کار مرحله­‌ای برای پذیرش(Accept) اضافه کنند و نام «پذیرش» را روی ستون آن قرار دادند. وقتی این کار تمام شد، آدام متوجه شد که سه تا از برگه‌های ستون «آزمون» قبلاً آزمون شده‌اند و منتظر تأیید سزار هستند. بنابراین تصمیم گرفتند سه برگه را به ستون «پذیرش» در کنار برگه‌ی دیگری که در آن ستون قرار داشت منتقل کنند.

آدام پای تابلو رفت و برگه­‌ها را از ستون آزمون به ستون پذیرش منتقل کرد.

1001.png

یوآخیم گفت: «بعدش چی؟ کارها رو تحلیل مي­‌كنيد، پیاده‌سازی مي­‌کنید، آزمون می‌کنید و می‌پذیرید. چه کارهای دیگه‌ای لازمه تا کار تموم شه؟»

اریک گفت: «خوش‌تیپ! خب ما باید کارها را روی سرویس‌دهنده‌های عملیاتی تحویل بدیم.»

دافنه بی‌معطلی گفت: «و منظورت از «ما» چیه؟»

اریک با حسرت آهی کشید و گفت: «عملیات» (Ops)

مارکوس گفت: «اون دیگه چیه؟»

فرانک مؤدبانه توضیح داد: «خب منظورش بخش عملیاته.»

دافنه زیر لب گفت: «بخش عملیاتِ شرکت به شرکت دیگری برون­سپاری (Outsourcing) شده ­است. و این مسأله، زمان استقرار محصول نهایی رو افزایش می‌ده.»

«اولین کاری که اونها کردند این بود که دسترسی ما رو به سرورهای عملیاتی قطع کردند.»

یوآخیم پرسید: «فکر می‌کنم مجبورید منتظر بمونید تا نسخه به تیم عملیات تحویل بشه. بعدش چی؟»

اریک با ناامیدی گفت: «خب! اون­ها استقرار محصول رو شش بار در سال انجام میدن. و فعلاً هم تصمیم ندارن این رویه­ رو تغییر ِبدن.»

آدام گفت: «بنویسید «در انتظار عمليات» (Waiting for Ops) یا چیزی شبیه به این»

فرانک گفت: «آره، فعلاً همین کلمه خوبه. ادامه بدیم.»

1000.png

فرانک گفت: «اما اگر دوست داشته باشید، می‌­تونیم به اون «انجام شده» یا «خارج از دسترس» بگیم.»

مارکوس پرسید: «چرا؟»

دافنه گفت: «چون تنها کاری که باقی مونده، عملیاتی کردنه که دست ما نیست.»

فرانک ادامه داد: «آره، ما بعد از این مرحله، کار زیادی نداریم.»

یوآخیم و مارکوس نگاهی به هم کردند و بدون گفتن کلامی این سوال را بین خودشان رد و بدل کردند که «نوبت کیه؟ من یا تو؟». ظاهراً نوبت یوآخیم بود.

یوآخیم پرسید: «مشتری شما کیه؟»

فرانک پرسید: «منظورت از «مشتری» چیه؟»

یوآخیم توضیح داد: «خب، چه کسی به کارها و ویژگی­‌های انجام‌شده‌ی شما علاقه‌­منده.»

فرانک هم توضیح داد: «خب، ذی­نفعانی (Stakeholders) که نیازمندی­های سیستم رو نوشتند.»

یوآخیم موذیانه گفت: «واقعاً؟»

بِث متفکرانه گفت: «آها…، لطفاً دوباره «مشتری» رو برای من تعریف کنید.»

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

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

یوآخیم با پرسش خود، آنها را تحت فشار قرار داد: «پس ستون «در انتظار عمليات» چی؟ آیا این کار (در انتظار عملیات)، کاربر نهایی شما رو خوشحال‌تر می‌­کنه؟»

بِث گفت: «البته که نه. اما فرایند ما این شکلیه. چه کاری از دست ما برمی‌آد؟»

یوآخیم رو به گروه کرد و پرسید: «اگر از شما بخواهیم که همه‌ی برگه‌های «در انتظار عمليات» رو روی تابلو بچسبونید، چند تا برگه می‌شه؟»

قبل از اینکه کسی فرصت صحبت کردن پیدا کند، اریک جواب داد: «یک کامیون!»

فرانک گفت: «خب. تعداد اون­ها خیلی زیاده. آخرین انتشار…..» سکوت کرد وبعد از کمی فکر کردن گفت: «فکر می‌کنم چهارشنبه‌ی این هفته یک نسخه بالا می‌آد. حدس می­‌زنم حدود 25 تا 40 تا قلم توش باشه.»

مارکوس رو به سزار کرد و پرسید: «پروژه‌هایی که «در انتظار عمليات» هستند چه فایده‌ای برای مشتریان شما دارند؟» و به ستون آن اشاره کرد.

سزار گفت: «عملاً هیچی! ما هم دوست داریم این رویه متوقف بشه. ولی همون­طور که بِث گفت، این موضوع اصلاً دست ما نیست.»

یوآخیم پرسید: «می­‌تونید اون رو تغییر بدید؟»

سزار آهی کشید و گفت: «آسون نیست. بودجه‌ی اون‌ها جداست، مدیریت اون‌ها جداست و حتی ساختمان اون‌ها هم جداست.»

بخش بعدی
بخش قبلی

گزارش یک Meetup

  • یوسف مهرداد بی‌بالان

پیش‌گفتار:

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

از ایشان سپاسگزارم که زحمت کشیدند و گزارشی در این زمینه نوشتند تا بتوانم آن را در اینجا منتشر نمایم. برای ایشان بهترین‌ها را آرزومندم.

گزارش یک Meetup:

اگر نخوام زیاد کشش بدم و از خلقت آدم و حوا شروع کنم! باید بگم که با استفاده از نرم افزار Meetup برای شرکت در نشست Software Craftsmanship (مهارت در نرم افزار) که توسط آقای Mark Seemann در شرکت NNIT برگزار میشد، اعلام آمادگی کردم و روز Meetup اونجا حاضر شدم.

Meetup سر ساعت 5 شروع شد و من بخاطر ناآشنا بودن مسیر و اینکه یه جاهایی مجبور بودم دوچرخه رو هم کول بگیرم و یه جاهایی هم گوگل مپ میگفت بپیچ منم زود می‌پیچیدم و نگو منظورش 50 متر جلوتر بوده، ده دقیقه ای با تاخیر رسیدم.

در مورد مسیریابی تو شهر کپنهاگ تنها این نکته رو ذکر میکنم که با وجود یک نرم افزار کامل که تمام اطلاعات لحظه ای قطارها، اتوبوس ها و مترو و همین طور مختصات، مشخصات و نقشه مسیر پیاده روی و دوچرخه سواری رو به شما میده؛ اما شما باید به دروس ساختمان داده ها و طراحی الگوریتم اشراف کامل داشته باشید که ضمن محاسبه مسیر بهینه بتونید وزن (قیمت) مسیر رو هم با توجه به زونی [ناحیه‌ای] که در اون هستید در هر لحظه محاسبه کنید تا دچار جریمه 750 کرونی نشید! من که یه خرده تو این دروس ضعیف هستم ترجیح دادم یه قسمتی از مسیر رو رکاب بزنم!

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

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

بگذریم. برسیم به اهم سخنان مارک سیمن متخصص معماری نرم افزار و برنامه نویس.
1- نقل قولی از آقای مارتین فاولر به این مضمون:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
2- فرضیه خوانایی کد رو مطرح شد. ” Code is read much more than written ” پس یه جوری بنویسید که راحت قابل خوانده شدن باشه. توصیه اکید بر کامنت گذاشتن در کدها داشتن!
3- از نوشتن کدهای طولانی خودداری کنید. کدهای شما تا حد ممکن باید کوتاه باشند. برنامه‌های بلند را به کلاس ها، متدها و کدهای دیگر بگنجانید!
4- از بازی تنیس بخاطر خاصیت رفت و برگشتی سریع به عتوان مدلی مناسب برای برنامه‌نویسی نام برد
5- کدهایی بنویسید که مهربان و زیبا باشند!!
6- از کدهای بد یا کثیف دوری کنید.
7- عدم استفاده بیش از حد از حلقه‌ها و دستورات کنترلی و …
8- لزوم رعایت اصول شی‌گرایی در برنامه‌نویسی مثل: تجرید، چسبندگی، وارونگی وابستگی، وارونگی کنترل، خودت را تکرار نکن و ….
9- لزوم Refactoring و اصلاح مجدد کدها
10- حتما برای کدهای خود تست بنویسید! (خنده ی حضار!!)
11- لزوم استفاده از Source Code Control System
12- حتما به زبان مورد علاقه خودتون برنامه نویسی کنید، با این حال از یادگرفتن زبان های دیگر غافل نشوید!

Software_Craftsmanship_with_Mark_Seemann

گزیده:
ندارد.

یادگیری کانبان (6)

  • یوسف مهرداد بی‌بالان

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

دافنه دستهایش را باز کرد و گفت: «ما که گفتیم یه عالمه کار داریم.»

سزار سرش را خاراند و گفت: «می­‌دونستم زیاد کار داریم ولی فکرش رو هم نمی­‌کردم این‌قدر زیاد باشه… شما (هم‌تیمی‌ها) زمان‌های پر استرس و ناخوشایندی داشتید.»

بث در حالی که داشت برگه‌‌ها را می‌شمرد گفت: «ولی تعداد اینها بیش‌تر از کار «واقعیِ» (Actual) ثبت‌شده توی جیراست.» اریک برای اولین بار لحن صدایش را تغییر داد و گفت: «این همون چیزیه که ما تمام مدت سعی داشتیم بگیم.»

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

مارکوس گفت: «آن‌جا اطلاعاتی وجود دارد که از یک ابزار الکترونیک به نام جیرا یا به قول یوآخیم از «یخچال اطلاعات» (Information Fridge) در آورده شده.» سپس به یوآخیم نگاه کرد و سکوت کرد تا او این استعاره (Metaphor) را توضيح دهد.

111

یوآخیم متوجه‌ی اشاره او شد و شروع به توضیح دادن کرد: «تصویرسازی‌ روی یک تابلوی بزرگ را «رادیاتور اطلاعات» (Information Radiator) یا انعکاس‌دهنده‌ی اطلاعات می‌نامند. اطلاعات تابلو برای افرادی که از جلوی تابلو رد می‌شوند، روشن و قابل‌فهم است. من فکر می‌کنم ابزارهای الکترونیکی گاهی شبیه یخچال می‌شوند، زیرا برای پیدا کردن چیزی که دنبالش هستید، باید درش را باز کنید و داخلش را بگردید». او خیلی مطمئن نبود کسی به حرفش گوش داده باشد زیرا اعضای تیم به تَل برگه‌های یادداشت‌ که جلوی یوآخیم بودند زل زده بودند و حواسشان آنجا بود.

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

  • ما معمولاً کارها را دیر انجام می‌دهیم
  • بیشتر اوقات برآوردها غلط هستند
  • تیم در باتلاقی از کارها گیر کرده است
  • اولویت­ها مشخص نیستند
  • از هرجایی کار به تیم سپرده می‌­شود
  • معلوم نیست که کی چه كار می‌کند

بث نگاهی به اطرافش کرد و يادداشت‌هایش را برداشت و جلوي تابلو رفت. پس از لحظاتی گفت: «با این کوه یادداشت‌ها چه­‌کار باید کرد؟»

دافنه ادامه داد: «خب! مرتب‌سازی یادداشت‌های روی دیوار توی اینکه بتونیم کار بیشتری رو انجام بدیم و مشتری‌ها را راضی نگه داریم، کمکی به ما نمی‌­کنه! کمکی می‌کنه؟»

تصویرسازی کارها ‌

كارهاي مخفی را آشكار مي‌کند

  • به راحتی قابل انجام است مثلاً داشتن یک برگه‌ی یادداشت برای هر قلم کاری

به شما كمك مي­‌كند که ببینید:

  • هر یک از افرد چه كاري انجام می‌دهند؟
  • خود شما مشغول انجام چه كاري هستید؟
  • در کل، چقدر کار در حال انجام است؟

تصویر کارها اطلاعات را در اختیار افرادي قرار می‌دهد كه آن را مشاهده مي‌­كنند (رادیاتور اطلاعات)

نگاشت گردش کار

یوآخیم گفت: «خب! اين برگه‌ها نشون می­ده که شما کارِ در جریان زیادی دارید. شما می‌تونید از تصویرسازی کارها استفاده‌ی بیشتری کنید، مثلاً بگذارید همه پیشرفت کارها و اولویت­های اون‌ها رو ببینند. این روش باعث افزایش شفافیت (Transparency) می‌شه و کمک ‌می‌کنه تا کارهایی که به شما می‌رسه رو اولویت‌بندی کنید.» و درحالی­که به فهرست چالش­‌ها اشاره می­‌کرد، گفت: «بیایید سعی کنیم تا گردشِ کار رو روی تابلو بنویسیم و برگه‌ها رو سمت راست تابلو بذاریم.» یوآخیم درِ ماژیک را درآورد و آماده‌ی کار شد.»

بِث پرسید: «چی رو بنویسیم؟»

یوآخیم گفت: «خب، اقلامی که مربوط به گردش كارِ سیستم شما هستند، از ایده­ یا درخواست­ مشتری گرفته، تا ویژگی­‌های تمام‌شده‌ای که انتشار یافته‌اند و برای مشتری ارزش­‌ ایجاد می‌­کنند، موافقید؟»

«آره… فکر ­کنم.». هم‌همه‌ای شد.

یوآخیم پرسید: «کار از کجا شروع می­شه؟»

فرانک گفت: « آها…، گفتنش سخته. به این بستگی داره ­که خط رو از کجا بکشی. وقتی‌که ایده‌ای برای اولین بار مطرح می‌شه؟ یا وقتی­که تصمیم می‌گیریم ایده رو عملی کنیم، یا مجوز انجامش رو می‌گیریم؟ ولی به­‌نظرم اون­ چیزی که مشخصه اینه که ما تمام کارها رو تو جیرا، سیستم ردگیری اقلام، ثبت می‌­کنیم.»

6

«ولی بِث»، سزار صحبت بِث را قطع کرد و گفت: «قبل از اون، من و تو کارهای زیادی انجام می‌­دیم، مگه نه؟»

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

اعضای تیم توافق کردند که گردشِ کار، از زمانی­ که کار در جیرا ثبت می‌شود شروع می‌شود و زمانی­ که کار انتشار یافت به پایان می‌رسد.

دافنه گفت: «نمی­‌فهمم چرا کار رو نباید در تمام مسیرها دنبال کنیم؟»

یوآخیم گفت: «خب! بیایید گام‌های گردشِ کار رو به­‌صورت ستون­هایی ترسیم کنیم». سپس شروع کرد به کشیدن ستون­ها روی تابلو ولی یک‌د‌فعه ایستاد و کشیدن ستون‌ها را ادامه نداد. او قبلاً بارها سعی کرده ­بود برای تیم‌ها این کار انجام بدهد و می‌دانست که چنین کاری باعث می‌­شود که تابلو به جای تیم، به او تعلق داشته باشد. خوش­بختانه این مسأله یک راه­ حل ساده دارد. یوآخیم ماژیک را به طرف بِث پرتاب کرد و گفت: «بهتره که شما ستون­ها را بکشید.»

مارکوس توضیح داد: «برای این­که نشان بدیم هر کاري در چه مرحله­اي قرار داره، برگه‌ رو توی ستون متناظر اون مرحله قرار می‌­دیم.»

112

بِث گيج شده بود چون يوآخيم هيچ نامي روی ستون‌ها ننوشته بود. بنابراين پرسيد: «این نام‌ها یا مرحله‌ها چه هستند؟»

یوآخیم با پوزخندی گفت: «خب، اینجا همون­‌جاییِ که شما بچه‌ها وارد عمل می‌­شید. ما که نمی­‌تونیم همه کارها را برای شما انجام بدیم. به کارهایی که توی جیرا هنوز تمام نشده‌­اند چی می‌­گید؟»

فرانک گفت: «خب!… نمی‌­دونم. انجام‌نشده؟» صدای قهقهه توی اتاق پیچید.

سزار پیشنهاد کرد: «نظرتون در موردِ صندوق ورودی (Inbox) چیه؟»

اریک گفت: «نمی دونم. این کلمه من رو یاد صندوق پستی و ایمیل می‌­اندازه. منم از ایمیل متنفرم. نمی­شه از کلمه‌ی دیگه‌ای استفاده کنیم؟»

دافنه پیشنهاد کرد: ««آماده‌ی انجام» (To do) چه ­طوره؟ خیلی ساده­ است؟»

کسی چیزی نگفت. یوآخیم گفت: «شروع خیلی خوبیه! یادمون باشه که می­خواهیم کلمات ساده و آسان باشند. اگر بعداً نیاز شد بتونید تغییرش بدید.»

مارکوس دستش را بالا برد و گفت: «پیشنهاد می­‌کنیم که با ماژیک تابلو را ستون‌بندی کنیم. این ستون‌ها دائمی نیستند، از نوار و سایر وسایل برای کشیدن سریع‌تر ستون­ها استفاده کنید زیرا اگر وقت زیادی برای آن بگذارید ممکنه انگیزه‌ی شما برای تغییر دادنش کم­ بشه. شما باید هم‌زمان با یادگیری، ستون‌بندی رو تغییر بدید.»

group_ws_accessories

همزمان با صحبت‌ مارکوس، بِث ستونی در سمت چپ تابلو کشید و عبارت «آماد‌ه‌ی انجام» را بالای آن نوشت.

یوآخیم گفت: «خب، همه‌ی برگه‌هایی که کار روی آنها را هنوز شروع نکردید، توی این ستون بذارید.»

اعضای تیم پای تابلو رفتند و برگه‌­ها را جابه‌جا کردند. بحث­ها و سوالاتی درمورد معنای واقعی برگه‌­ها مطرح شد و خیلی زود سه برگه در ستون «آماده‌ی انجام» قرار گرفت.

113

بخش بعدی
بخش قبلی

 

جلد دوم کتاب «اصول و روش کاربردی اسکرام»

  • یوسف مهرداد بی‌بالان

هفته‌ی گذشته، جلد دوم کتاب اسکرام («اصول و روش کاربردی اسکرام» / Essential Scrum)به انتشارات تحویل شد. بخش کوچکی از کتاب (مقدمه، واژه‌نامه و دو فصل آخر) نیز روز شنبه در اختیار انتشارات قرار خواهد گرفت.

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

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

فهرست مطالب جلد دوم کتاب:

بخش سوم: برنامه‌ریزی
فصل 14: اصول برنامه ریزی اسکرام
فصل 15: برنامه‌ریزی چندسطحی
فصل 16: برنامه‌ریزی سبد محصول
فصل 17: ترسیم چشمانداز (برنامه‌ریزی محصول)
فصل 18: برنامه‌ریزی انتشار (برنامه‌ریزی بلندمدت)

بخش چهارم: اسپرینت
فصل 19: برنامه‌ریزی اسپرینت
فصل 20: اجرای اسپرینت
فصل 21: بازنگری اسپرینت
فصل 22: بازاندیشی اسپرینت

فصل 23: مسیر پیش رو

پانوشت:

جلد اول کتاب اصول و روش کاربردی اسکرام را می‌توانید از فروشگاه‌های زیر تهیه فرمایید:

گزیده:
ندارد.

تحلیل فوتبال!

  • یوسف مهرداد بی‌بالان

پیش‌گفتار:

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

 

گفتار: مصاحبه با جاناتان ویلسون

جاناتان ویلسون یکی از شناخته شده ترین فوتبال نویس های حال حاضر دنیاست که بسیاری او را با کتاب ‏معروفش، “واژگونی هرم” که به سیر تحول تاکتیک های فوتبال اختصاص دارد، می شناسند.‏

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

 

خود شما چه نوع فوتبالی را می‌پسندید و فلسفه و کار کدام مربیان روی شما تاثیر بیشتری داشته؟

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

فکر می کنم این یکی از جذاب ترین جنبه های فوتبال مدرن، این ایده “شیوه صحیح بازی کردن“ است. ‏فکر می کنم در فوتبال به یک شکل بازی کردن بسیار خسته کننده است. فکر می کنم یکی از نقاط قوت ‏فوتبال این است که قابلیت سازگاری زیادی دارد.

فکر می کنم اینکه چه نگرشی داشته باشید، کلیدی است.

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

 

نظرتان در مورد تیم ایتالیا چیست؟ چرا ایتالیا، علی رغم افت کیفیت سری ‏A، همیشه به مراحل ‏پایانی ‏تورنمنت های بزرگ راه پیدا می کند؟

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

گزیده:

یک سال برای من به دو فصل تقسیم می‌شود: فصل فوتبال و فصل انتظار برای شروع فصل فوتبال. داریوس راکر

برای خروج از جستجو کلید ESC را بفشارید