تصمیم گرفتم مواردی که جهت بهبود فرآیند documentation در چابک/لین تجربه کردم رو در اینجا ذکر کنم امیدوارم مفید باشه. خوشحال میشم اگر نظر یا تجربه ای در جهت تکمیل/اصلاح این موارد دارید کامنت کنید تا سایر دوستانِ مشتاق هم بتونن استفاده کنند.
1. آنچه که در مستندسازی حائز اهمیت است موضوع just-enough بودنش هست، در واقع تمام انتقاداتی که به شیوه های قبلی مستندسازی میشه برای more than enough بودنشون هست و اینکه دیگه از "راهنما" خارج و تبدیل به رُمان میشن.
2. تا جایی که دیدم دو تایپ اصلی برای مستندسازی در Agile مرسوم هست یکی سندی هست که تیم در آینده برای تغییر و نگهداری محصول ممکن هست بهش refer کنه که میتونه در برگیرنده کد استایل، استوری ها، criteria های مهم، بزنس رول ها، مپ ها، flow ها، دیاگرام ها، موارد مهم بزنس محصول، کامنت های کد، اسامی و شرح یک خطی تست ها، خلاصه API ها، سند خلاصه معماری، تصمیمات طراحی، باگ ها، توضیحات بدهی فنی، موارد Deploy و سایر مواردی که برای تیم ها یا محصولات مختلف مورد نیاز است. سند دوم برای onboarding نیروی جدید مورد استفاده قرار میگیره و هدفش افزایش سرعت در پروسه آنبوردینگ فرد جدید هست در واقع میشه گفت بیشتر در Knowledge Management سازمان جای می گیره. تیم میتونه brainstorm کنه و سرفصل های هر دو سند رو تهیه کنه و تصمیم میگیره چه مواردی در کدوم سند و در چه سر فصلی باید قرار بگیره یا اشتراکات رو تعیین می کنه.
3. سندها باید از لحاظ ادبیات و شیوه نگارش طوری نوشته بشن که از misunderstanding جلوگیری کنه و کاملاً Clear باشه. توصیه اکید میشه هر مستندی دارای یک goal باشه تا خواننده با خواندن اون goal بفهمه که کلیات چی هست و تصمیم به خواندن یا نخواندن رو سریع بتونه بگیره. از مثال، جدول و نمودار برای افزایش Clarity میشه استفاده کرد. ترجیحاً سندها in tandem نوشته یا review بشن یعنی دو یا سه نفر انجام بدن نه یک نفر. همچنین قابلیت سرچ، نظم و طبقه بندی خیلی مهم است در واقع UX خوبی باید براش ایجاد شود.
4. سندها باید به طور مداوم در چارچوب continuous improvement قرار بگیرند و به روزرسانی (افزودن، تغییر و حتی حذف) بشن. داکیومنت ها وقتی استفاده میشن در واقع در حال تست هستن و استفاده کننده ها باید فیدبک بدن و این فیدبک منتج به اصلاح بشه.
5. لازم نیست همه چی text باشه می تونید از عکس استفاده کنید مثلاً بعد از یک جلسه مهم از وایت بورد عکس بگیرید یا آن چیزی که روی کاغذ کشیدید رو استفاده کنید یا یک audio باشه ولی براش باید tag بزنید که در سرچ بتونید پیداش کنید.
6. دقت کنید که داکیومنت کردن خودش یک کار جاری در اسپرینت هست و جزئی از زمانی که تیم در اسپرینت صرف می کنه باید وقفش بشه. جهت الزام به انجام، داکیومنت میتونه در قالب criteria آورده شه. اگر در حالت enough بهش نگاه کنید هیچ cost ای برای تیم نداره و جلوتر قطعاً چندین برابر این زمان و انرژی که براش صرف شده به تیم باز خواهد گشت. نکته مهم این است که روش های قبلی مستندسازی عموماً به صورت Document Late Strategy انجام میشد به این معنی که آخر کار سراغ داکیومنت کردن میرفتن در حالیکه در Agile به این صورت نیست و اصطلاحاً باید به صورت Document Continuously Strategy و پیوسته انجام بشه.
7. اگر documentation فراموش بشه و یا value کمی بهش داده شه قطعاً تیم در آینده از چابکی خارج خواهد شد. این مورد به دفعات در استارتاپ هایی که درscale هستن به وضوح تجربه شده و زمان و انرژی زیادی میبره تا تیم به state قبلی برای حل مشکل یا اعمال تغییر برگرده. با این حرف که در داکیومنت کردن در تیم های سریع قابل انجام نیست، موافق نیستم چون به همون سرعت هم میشه enough ها رو نوشت. البته seniority تیم هم نقش پر رنگی در اینجا ایفا می کنه.
8. نکته پایانی نگرش تیم به documentation هست اگر تمرکز روی why مفهوم مستندسازی گذاشته شه در اولویت قرار می گیره به طوریکه در culture سازمان نهادینه میشه. نظر شخصی م این هست که تیمی که میتونه موارد بالا را بخوبی هندل کنه تیم invaluable ای هست و البته قبول دارم که کم پیدا میشه ولی هست.
موفق باشید.
