پیچ Tighten به هر مشتری بالقوه یک جمله است: مهم‌ترین هفتهٔ کاری ممکن را برمی‌داریم، تا جایی که بلدی‌ایم خوب انجامش می‌دهیم، تحویل می‌دهیم، وقتی آماده‌ای شیپ می‌کنیم، و همین را تکرار می‌کنیم تا از نتیجه راضی باشی. متدولوژی‌شان همین است — نه اسپرینت، نه پوکر تخمین.
متدهای دیگر ارزش بررسی دارند. Tighten برای بعضی مشتری‌ها **Shape Up** بیس‌کمپ را استفاده کرده و خوشش آمده؛ احترام می‌گذارد. به بقیهٔ متدها احترام نمی‌گذارد. بیشتر چیزهایی که دیده به باور او به احتمال انجام کار واقعی ضربه می‌زنند چون رهبری را سیر می‌کنند نه توسعه را. از همهٔ سیستم‌های تسک که امتحان کرده، این ریتم هفتگی هیچ‌وقت ناامیدش نکرده.
ریتم: یک جلسهٔ هفتگی با مشتری — تمام
خیلی از سیستم‌ها دور اسپرینت و retrospective و planning ساخته شده‌اند. Tighten هفته‌ای یک‌بار با مشتری می‌نشیند:
- هفتهٔ قبل چه کردیم؛ یادداشت و بازخورد
- هفتهٔ بعد چه می‌کنیم؛ سؤال‌های تیم و نکته‌های مشتری تا با هدفش جور درآید
- تمام
بین جلسات، داخلی فقط اگر لازم باشد: گاهی نمایش سریع به PM، معمولاً pair programming. **استندآپ روزانه ندارند. sprint retro و planning ندارند.** همان چک‌این هفتگی همهٔ آن نقش‌ها را پر می‌کند و برایشان کار می‌کند.
بعضی مشتری‌ها آخر هر روز چند بولت کتبی می‌خواهند: امروز چه کار شد. بعضی مشتری‌های فنی‌تر pairing با دولوپر یا جلسهٔ برنامه‌ریزی با PM می‌خواهند. این‌ها اختیاری است. هسته همان یک جلسهٔ هفتگی است: همه در یک جا، مرور هفتهٔ قبل، برنامهٔ هفتهٔ بعد.
lowercase-a agile در برابر صنعت Agile
سال‌هاست مت در اینترنت از چیزی می‌گوید که اسمش را **lowercase-a agile** گذاشته: چابک بودن به‌عنوان صفت — تند حرکت کردن، آسان تغییر جهت دادن — در برابر Agile به‌عنوان ساختار رسمی.
Agile Manifesto سندی کوتاه است دربارهٔ کار کردن با agility. بعدش یک اکوسیستم مشاوره‌ای زبان و بعضی ایده‌ها را مصادره کرد و اسمش را Agile گذاشت. مت به Agile رسمی و به Scrum باور ندارد. کل «مجتمع صنعتی Agile» را اسکَم می‌داند. در تمام عمرش ندیده تیمی با سوییچ به Agile در تعریف و تحویل تسک و نرم‌افزار بهتر شود. دیده برعکس شود: چون کار خراب بوده سوییچ کرده‌اند، خراب‌تر شده، و پول در جیب مشاور رفته.
خود Manifesto و ایدهٔ چابکی را درخشان‌ترین اتفاق تعریف فیچر و تحویل می‌داند. دوازده اصل است؛ بخوان. برای نسخهٔ تندتر، کار مدرن **Allen Holub** را ببین.
در این درس دو اصل اول حیاتی‌اند — با واژه‌های مت، نه لزوماً نقل قول کلمه به کلمه:
1. تحویل زودهنگام و پیوستهٔ نرم‌افزار باارزش 2. خوشامد به تغییر نیازمندی‌ها
هر گوشهٔ سیستم تسک ایده‌آل او باید همین دو را ممکن کند.
Kanban: کار را ببین
Kanban روش دیداری‌کردن کار است؛ تویوتا در دههٔ ۶۰، با الهام از نحوهٔ پر کردن قفسه در سوپرمارکت — از جمله **Piggly Wiggly** در آمریکا. هدف: دیدن کاری که باید بشود و ردگیری حرکتش در مرحله‌ها. برای خیلی چیزها به درد می‌خورد؛ برای نرم‌افزار به‌خصوص.
ابزار: اگر به چیزی قفل نیستی، با **Trello** شروع کن — ساده و آزموده. **Jira** به‌شکل وحشتناکی سخت است. **Linear** جدید و جذاب است. بعد از انتخاب ابزار هم می‌شود Kanban را رویش سوار کرد؛ مهم ستون‌هاست نه لوگو.
ایدئولوژیک با چهار ستون شروع کن؛ پروژه می‌تواند عوضشان کند:
| To do | Doing | Ready for review | Done |
|---|---|---|---|
| Allow users to log in with GitHub | Add rate column to dashboard | Preview staging mail in Mailtrap | Invoice PDF export |
| Handle GitHub users without email | Fix tax rounding | ||
| Place social-auth buttons on login |
کارت‌ها از چپ شروع می‌کنند و راست می‌روند تا تمام شوند. داخل هر ستون، بالا به پایین معمولاً **اولویت** است (گاهی زمان).
در جلسهٔ هفتگی با مشتری:
- ستون To do حدود **یک هفته کار قابل‌پیاده‌سازی همین الان** داشته باشد — بدون جلسهٔ اضافه با مشتری
- اولویت مشتری بالای لیست باشد
- بکش تا تمام شود
برخلاف Scrum و سیستم‌های اسپرینتی، Kanban **هیچ‌وقت قفل نیست**. وسط هفته اولویت عوض شد؟ عوض کن. کار تمام شد؟ کارت بعدی را بکش. هفته تمام شد و کارت هنوز Done نیست؟ تمامش نکن؛ مهم نیست. چیزی دور انتظار اسپرینت ساخته نشده.
سیستم باید برای تو خم شود تا مولد بمانی. این فرایند تسک — مثل فرایند کد — وجود دارد تا دولوپر کد خوب بنویسد و بفرستد؛ نه تا velocity با تعداد کامیت و تخمین t-shirt planning poker دو هفته پیش هم‌خط شود، وقتی آن موقع اصلاً تسک را نفهمیده بودند.
کارت: تا جای ممکن کم
حداقل یک پاره‌جمله. آن‌قدر که کسی که تسک را نمی‌شناسد بفهمد باید چه بسازد. «Add user login» ممکن است بدفهمیده شود. «Allow users to log in with GitHub» در بعضی زمینه‌ها کارت کاملی است و در بعضی نه.
کارت خوب یعنی دولوپر باید هنوز تصمیم بگیرد: دکمهٔ GitHub کجا باشد، اگر ایمیل GitHub قبلاً به‌عنوان کاربر عادی در دیتابیس است چه، اگر Laravel نیست کدام ابزار. اگر دولوپرهای مستقل داری — محبوب مت — و مشتری یا صاحب محصول به آن‌ها اعتماد دارد — باز هم محبوب مت — همان یک جمله کافی است.
اگر مشتری وسواس جزئیات دارد، یا همه‌چیز باید اول از طراح بگذرد، یا این دولوپر هنوز نمی‌تواند وسط راه این تصمیم‌ها را بگیرد، must-have را روی کارت بگذار: اگر باید این‌شکلی دیده شود، بنویس؛ اگر ورک‌فلو خاصی اجباری است، بنویس. باز هم حداقل ممکن.
مت کارت ساده به‌اضافهٔ آزادی «آنچه منطقی‌تر است» را به مشخصات چهارصفحه‌ای ترجیح می‌دهد. همیشه ممکن نیست؛ هرچه می‌توانی کم کن.
| کارت درست‌اندازه | کارت بادکرده | |
|---|---|---|
| عنوان | Allow users to log in with GitHub | Epic: Social auth platform v2 |
| محتوا | یک جمله. اگر must-have داری (مثلاً دکمه فقط روی `/login`) همان یک خط. | چهار صفحه: پیکسل دکمه، کتابخانهٔ اجباری، همهٔ edge-caseها با «چگونه» — و تقریباً هیچ «چرا». |
| عمر | ساعت تا چند روز | هفته‌ها تا ماه؛ کسی جرئت اسپیلیت ندارد |
| تصمیم | دولوپر همدل + دسترسی به محصول | از قبل در سند قفل شده؛ هر انحراف جلسه می‌خواهد |
فیچر بزرگ می‌آید؛ کارت کوچک می‌ماند
بیشتر کار از مشتری یا صاحب محصول می‌آید به‌شکل فیچر بزرگ و بدتعریف، با نسخهٔ بی‌فایده از **چگونه** حل شود — که حوزهٔ توست — و اطلاعات ناکافی از **چرا** و به چه هدف — که حوزهٔ آن‌هاست.
کار PM یا مسئول فرایند: با بیزنس بخش غیر فنی را گوشت بدهد؛ روشن کند چگونه باید کار کند و چرا. بعد با لید فنی از منظر فنی بشکند — چون برش فیچری همیشه با برش فنی یکی نیست. دو تا با هم بهترین شکل را پیدا می‌کنند.
نتیجه: یک فیچر روی **چند کارت** پخش می‌شود. کارت یک تکه از فیچر بزرگ‌تر است. مثال مت: فیچر «Add social auth» می‌شود:
- جایی برای دکمه‌های social auth
- یک کارت برای هر provider (GitHub، بعدی‌ها)
- بعداً شاید: GitHub اجازه می‌دهد بدون ایمیل وارد شوی؛ منطق auth را برای این حالت اضافه کن
واحد را تا **کوچک‌ترین تغییر مفید** بشکن: مشتری اگر فیچر است بتواند تأیید کند؛ دولوپر دیگر اگر کار فنی خالص است. اگر مرددی، کوچک‌تر. هزینهٔ تمام کردن چهار تسک در یک روز کم است؛ هزینهٔ یک تسک در دو هفته زیاد است.
کارت ایده‌آل روی بورد Kanban در **ساعت یا روز** تمام می‌شود نه هفته و ماه. اگر بیش از یک هفته طول می‌کشد، بیش از یک کارت است. اولش غلط می‌فهمی؛ طبیعی است. زیبایی Kanban این است که لازم نیست اولش کامل باشد. یک‌دو روز که کار کردی، وسط پرواز اسپیلیت کن. گاهی بزرگ‌تر می‌شود. آن‌وقت با تیم حرف بزن:
- بعضی زیرتسک‌ها را ببریم؟
- به فاز بعد پرت کنیم؟
- بگوییم دیرتر از انتظار تحویل می‌دهیم؟
هر سه معقول است. برای دیدن گزینه‌ها اول باید روی کارت‌های جدا باشد.
آدم همدل استخدام کن؛ مثل Ender فرمان بده
مت تسک ساده‌تعریف را ترجیح می‌دهد چون آدم بدون تجربهٔ واقعی استخدام نمی‌کند. دنبال آدم همدل و دقیق است که بخواهد مشتری را بفهمد و همان را بسازد که واقعاً برایش معنی دارد. این آدم برنامه‌نویسی — حل مسئله — را با فهم نیاز قاطی می‌کند و نتیجه‌ای می‌سازد که کس دیگری نمی‌تواند.
پس: تسک به‌اندازهٔ معقول گوشت‌دار، دسترسی فوری به بیزنس / مشتری / صاحب محصول برای رفع ابهام، و آزادی بهترین انتخاب. دولوپرهای دیگر و PMها کار را می‌بینند؛ کسی بی‌سر و صدا چیزی به مشتری تحویل نمی‌دهد که تیم به آن باور ندارد. امن است.
اگر *Ender's Game* را خوانده‌ای: در مدرسهٔ نبرد، رهبری کلاسیک به همه می‌گوید دقیقاً چه کنند؛ جنگ که شروع می‌شود همه منتظر دستور می‌مانند، غرق می‌شوند، بی‌فایده‌اند. راه Ender: گروه‌های کوچک با رهبران توانمند که هدف کلی را می‌فهمند، گاه‌به‌گاه چک می‌کنند، و در لحظه اختیار دارند آنچه منطقی است بکنند. مت از مدیر توسعه می‌خواهد **مثل Ender** باشد — نه فرمان هر حرکت.
pair programming داخل سیستم تسک
در دوره چند بار به pair programming اشاره شد؛ جزئیاتش کم است چون پیچیده‌اش نمی‌کند. افراطی‌های Extreme Programming نسخهٔ درست و غلط دارند. برای مت: **دو نفر روی یک کد، روی یک صفحه** — لازم نیست صفحهٔ فیزیکی یکی باشد؛ pairing ریموت جا افتاده.
معمولاً یکی **driver** است (کیبورد و ماوس) و دیگری نگاه سطح‌بالاتر: ریویو، سینتکس و نیاز، برنامهٔ بلندتر. نقش وسط جلسه عوض می‌شود. در Tighten برای pairing همان **Zoom** را می‌گذارند چون برای کار مشتری هم همان است. ابزار مخصوص pairing به نام **Tuple** هم محبوب است.
این بخش در درس تسک است چون «دو نفر روی یک تسک» از نظر تسک‌دهی ترسناک به نظر می‌رسد: یعنی نصف سرعت؟ در pairing سالم، کدنویسی و code review و حتی کمی برنامه‌ریزی در یک قدم جمع می‌شوند. دو مغز تجربه روی یک کار. تیم معمولاً نمی‌خواهد روی همهٔ تسک‌ها pair کند؛ روی همان‌هایی که خودش معیار دارد — معمولاً همان کارهایی که وسطش گیر می‌کنند، بیشتر باید پلن کنند، یا ریویوی سنگین می‌خواهند و در هر حال کمک می‌طلبند.
تا وقتی دولوپر مسئول داری، pair programming تسک‌دهی و سرعت را خراب نمی‌کند.
ساده شروع کن؛ پیچیدگی را با دلیل اضافه کن
سیستم و ابزار پیچیده‌تر فراوان است: Jira، در گذشته Pivotal Tracker، Scrum، Shape Up. باید بفهمی برای تیمت چه می‌ماند؛ چیزی انتخاب کن و مدتی به آن بچسب. وسوسهٔ رهبری تقریباً همیشه **زیادی ساخت‌یافته، زیادی رسمی، زیادی میکرو** است — نه خلافش.
ساده شروع کن. پیچیدگی را فقط وقتی اضافه کن که شاهد داری به تیم سود می‌رساند، نه چون «همه همین کار را می‌کنند». مت می‌گوید اگر یک شرکت دیگر در غیاب دانستنِ چطور تیم توسعه را اداره کند، برود سراغ Scrum تمام‌عیار و Jira، فشار خونش را نجات بده. ساده نگه دار.
به زبان ساده
مهم‌ترین هفته را بردار، خوب انجام بده، تحویل بده، تکرار کن. یک جلسهٔ هفتگی با مشتری؛ کانبان قفل نیست.
مثال واقعی
کارت «Allow users to log in with GitHub» کافی است اگر دولوپر مستقل و مشتری قابل‌اعتماد باشند. اسپرینت و استندآپ روزانه در Tighten وجود ندارد. جفت‌برنامه‌نویسی با Zoom یا Tuple.