คน adopt agile ใหม่ๆ ผ่านกับดัก level 0 มา เริ่มที่จะเขียน test แล้ว ผลปรากฏว่า ใช้เวลาทำงานมากกว่าเดิม (เวลาเขียน test + เวลาเขียน code// ปล. แอบเอา test ขึ้นก่อน code ด้วย ;P) แล้วก็ทำงานได้ช้าลง… สาเหตุเพราะติดกับดัก agile level ถัดมาครับ มาดูกันว่ากับดัก agile level 1 ในความคิดผมคืออะไร?
*อ่านถึงตรงนี้ ใครที่เคยได้ยิน, ได้อ่าน, ได้เห็นว่า “ไม่เขียน test: บาป” แต่ยังไม่เคยสัมผัสประสบการณ์จริง กลับไปอ่าน level 0 ซ้ำ 3 รอบ ลองเขียน test แล้วค่อยกลับมาอ่านใหม่ครับ พูดจริงๆนะครับ ข้อความข้างล่างนี้ใครๆก็อ่านได้ แต่ผู้ไร้มลทินเท่านั้นถึงจะเห็นครับ
คุณ Benjamin Scherrey เล่าให้ฟังใน annual conference ครั้งหนึ่งของ Software Park ว่า
การแก้บั๊กสิ่งๆหนึ่งนั้น ยากกว่าการ design มันขึ้นมาเป็นเท่าตัว ฉะนั้นถ้าเรา design อะไรก็ตามที่ยากเกินครึ่งหนึ่งของความสามารถเรา นั่นแปลว่า เราไม่มีปัญญาจะ maintain สิ่งนั้น
NoTE แน่นอนว่าคุณ Benjamin พูดเป็นภาษาอังกฤษที่สละสลวยสวยงามกว่านี้ครับ แต่ด้วยความ “66″ ทำให้มันโผล่มาภาษาไทย (ตามสไตล์ผม) แทน ( >.< )
ทุกคนเคยได้ยิน “simple is beautiful” ครับ แต่มันทำได้ยากเหลือเกิน คำถามคือทำไมถึงยาก? คำตอบเพราะเราไม่กล้า refactor ครับ คนที่มี test กางคลุม code จะมี 2 ความมั่นใจคือ ความมั่นใจที่จะ refactor ติดตัว และความมั่นใจในคุณภาพของ code ติดงานครับ ด้วย 2 ความมั่นใจนี้ เราเลยกล้าที่จะใช้ simple design และ refactor as needed
ความศักดิ์สิทธิ์อยู่ที่ พอเวลาผ่านไป จากความมั่นใจที่จะ refactor จะกลายเป็นความมั่นใจในการ refactor เพราะชั่วโมงบินในการ refactor เพิ่มขึ้น project ที่ไม่มี test case คลุม refactor architecture ซัก 10 ครั้ง cost พุ่งทะลุ budget จนต้องกัดก้อนเกลือกินครึ่งบริษัทแล้วครับ project ที่มี test case คลุม refactor กันอยู่ทุกวันตาม requirement ที่เปลี่ยนไป
กับดัก level 1 คือ การ over design ครับ
พวกเรารู้ซึ้งดีว่าการต้องลาก design ใหญ่ๆ ไปตลอด 2 ปีที่ทำ project มันทรมาณอย่างไร? แต่จะไม่*เผื่อ* ก็กลัวมันจะ*ขาด* กลัวอยู่อย่างนั้น เฝ้ารอวันที่ความเปลี่ยนแปลงมันจะมาถึงตรงนี้ที่เราเตรียมรับมือไว้ และแล้ว… มันก็ไม่มา…. (และยังโผล่มาตรงอื่นที่ไม่ได้ดักไว้ด้วยนะ T-T)
สรุปแล้ว หลังจากท่านลงทุนทำ test ท่านสามารถเอาทุนคืนโดยการใช้ simple design ได้ทันที เพราะ architecture ท่านสุขภาพดี มีความยืดหยุ่นสูง (เพราะเราเลือกที่จะ refactor เมื่อไหร่ก็ได้ ด้วยเหตุว่าค่า refactor มันไม่แพงจนเกินไป) ฉะนั้นการทำ test จะคืนทุนเร็วมากๆครับ ถ้าท่านเริ่มลืมเลือนช่วงเวลาเลวร้ายที่ต้องนั่งไล่บั๊ก เริ่ม refactor บ่อยขึ้น เริ่ม design อะไรง่ายๆ แล้วคิดว่าถ้าจำเป็นค่อยขยายมันทีหลัง ก้มลงดูหน้าอกตัวเองจะเห็นตรา agileness level 1 ครับ! 
ฮ่าๆ หัวหน้าเรานี่จะโดนพูดถึงบ่อยไปแล้วนะ
ไปเรียกแกเข้ามาดูแล้วนะคะ แต่แกคงอ่านออกเป็นจุดๆ
ชอบ article ค่ะ
ถึงแม้มี test case ก็ต้องระวังอยู่ดีนะครับ (ไม่รู้มันคือกับดัก level 1 หรือเปล่า)
นั่นคือเขียน test case ใหญ่และยากเกินไป พยายาม test หลาย domain และไม่ mock dependency ทิ้ง หรือ mock ทิ้งไม่หมด หรือ mock ทิ้งไม่ได้
ซึ่งมันจะเชื่อมมาจากอีกเรื่องคือ refactoring กันไม่เป็น ไม่เป็นในที่นี้หมายถึง ไม่รู้จะ refactoring ไปท่าไหนที่สวยกว่าเดิม
คือสัญชาตญาณความรู้สึกบอกแล้วว่ามัน “ไม่ใช่ไม่ถูก” แต่ก็ไม่รู้จะแก้ยังไงให้สวยกว่านี้ สาเหตจากชั่วโมงบินไม่พอ
เรื่องนี้ผมพูดไว้ในงาน bugday ถ้าไปแล้วยังจำกันได้ เป็นกับดักสำคัญตอนพยายามทำ TDD
พี่ deans4j อ่านเกมขาด! เล็งไว้ว่ากับดัก Agile level 2 จะเฉียดเรื่องแถวๆนี้ครับ 555+
อ่านแล้วไม่เข้าใจว่า Over Design เป็นกับดักของ Agile ได้อย่างไร?
จริงๆแล้วน่าจะเป็น กับดักของคำว่า Simple is beautiful มากกว่าหรือเปล่า? เพราะคนมักเข้าใจว่า simple คือไม่ต้องทำอะไร กลับกันการจะทำให้มัน simple ได้ต้องใช้ความรู้และเทคนิคชั้นสูงมาก จึงจะทำให้มัน simple ได้
บางคนมักเข้าใจผิดว่า technical excellence and good design นั้นไ แปลว่าต้อง design ให้ซับซ้อนและเผื่ออนาคตไว้จะได้มาเพิ่มได้ง่ายๆ กลับกันแบบนี้เรียกว่า Over Design การ design ที่ดีคือ design เพื่อแก้ไขปัญหาปัจจุบันโดยใช้วิธีเรียบง่าย ซึ่งการจะทำให้เรียบง่ายได้ต้องใช้เทคนิคขั้นสูง
การ Over Refactoring หรือการ Over TDD เป็นกับดักได้หรือเปล่าครับ? เช่น บ้า Refactoring จนงานไม่คืบหน้า? หรือพอ refactoring แล้วจาก 100 line of code กลายเป็น 200 line of code เพราะแตก class แตก function จนมากเกินความจำเป็น เป็นต้น
ไม่ได้มาตอบแทนคุณ juacompe นะคะ แต่คิดว่า series ที่คุณ juacompe เขียนอาจจะ เพื่อให้ฉุกคิดว่าเรากำลังไปถูกทางรึเปล่า เพราะหลายๆที่ ต้องการ adopt agile แต่ยังติดอะไรในแบบเดิมๆอยู่ ทำให้มันรู้สึกลำบาก แล้วท้ายที่สุด ก็บอกว่า agile ยากไปไม่ใช้ หรือ agile ไม่เห็นดีเลย (ทั้งที่จริงๆแล้ว agile ก็ไม่ได้ถึงสิ่งของสิ่งเดียวอ่ะนะคะ)
แป๋มมองว่า over design ก็เป็นสิ่งนึงที่ต้องพยายาม let go หรือมองให้ออก เพราะ agile มองว่า เราควร design เท่าที่จำเป็นกับ requirement ที่เข้ามานะปัจจุบัน แต่ design ให้ maintain ได้ง่าย เพื่อรองรับกับการเปลี่ยนแปลงในอนาคต และมี test คอยรองรับ เพื่อให้เราสบายใจที่จะเปลี่ยนแปลง
ยากมั๊ย ก็อาจจะยาก ต้องใช้ชั่วโมงบินมั๊ย ก็มีบ้าง แต่ควรจะมีการเรียนรู้อยู่เสมอ developer ที่รู้แล้วก็ช่วยๆ กัน share กับน้องๆ
จำได้ว่าตอนตัวเองแปลงร่างจาก coder เป็น software engineer ได้เนี่ย เพราะมี mentor ที่ดีมากหนึ่งคน สอนให้รู้ว่า ความแตกต่างของ copy paste coder ต่างกับ software engineer อย่างไร
555+ ยังไม่เข้าใจอยู่ดี
แต่ juacompe เขียนดีไม่ต้องสงสัยครับ โดยเฉพาะ level 0 เพียงแต่งงว่า level 1 overdesign มันเป็น pitfall ยังไง อืมมม หมายถึงปัจจุบันทำ Over Design แล้วใช้ agile มาจับเพื่อแก้ปัญหาใช่ไหมเอย…
ยกตัวอย่างนะคะ ทำงานเป็น story และวิธีการ estimate ใช้ story point (ไม่ใช่ man-day หรือ ideal day จึงไม่สามารถ reference เป็นจำนวนวันได้โดยตรง)
สิ่งที่เจอ story ทำไม่เสร็จซะที เพราะ developer คิดไปเผื่อว่าอนาคตต้องมีอย่างนี้แน่ๆเลย ก็นั่ง design ไป design ไป เขียน code เผื่อไว้
ผลคือ story เสร็จช้าลง ไม่ได้ออกไปให้ user ดูและลองใช้ซะที และสิ่งที่ design “เผื่อ”มา สุดท้าย ไม่ได้ใช้
ช่วยมากขึ้นมั๊ยอ่ะคะ ^ ^’
agile ไม่ได้แก้ Over Design แต่ Over Design อาจะทำให้การ adopt agile เป็นไปได้ยาก…. อย่างนี้ละกัน
งึมๆ เข้าใจล่ะ สงสัยบทความนี้ของ Juacompe ต้องขัดใหม่แล้วละครับ ขนาด roofimon ก็ยังมึน 555+ “จะ” กับ “ในการ”
นี่คือคำตอบของบทความนี้ค่ะ โดนมาก!
ถึงคุณ sinapam จะไม่ได้ตั้งใจ แต่ตอบอย่างที่ผมคิดเปี๊ยบครับ ^ ^
เนื้อหาหลักที่อยากจะสื่อคือ คนที่เพิ่งปรับมาใช้ agile ใหม่ๆ ยังติดนิสัยการ design แบบ preventive แบบเดิมๆอยู่ (ซึ่งถือว่าดี ในยุคที่เรายังไม่รู้จัก testcase) ทำให้ไม่ได้ประโยชน์จาก effort ที่ adopt agile เท่าที่ควรครับ
ถ้าเพิ่งเริ่มปรับมาโดยเริ่มจากการ introduce การเขียน test ตอน level 0 ตอนนี้ ณ level 1 น่าจะเริ่มรู้สึกแล้วว่าเราต้องปรับการ design ใหม่ ให้กระชับกว่าเดิม ตรงประเด็นมากขึ้นครับ
ถ้าถามว่า agile ใช้ตอบโจทย์ over design ไหม? ใช่ แต่ไม่ใช่การตอบตรงๆครับ คนที่ agile แล้ว จะรู้สึกว่าเด๋วนี้เรามองโลกในแง่ดีมากขึ้น เราไม่นั่งเครียดกันทุกข้อต่อเหมือนเมื่อก่อน แต่สำหรับคนที่เพิ่งจะ adopt agile จะรู้สึกว่าเดิมที่เราเผื่อแค่พอสมควร ก็ไม่สมควรอีกต่อไปแล้วครับ ต้องกระชับกว่าเดิมอีก ถ้ายังติดนิสัยเผื่อ ก็จะไม่ได้กลยุทธ์*ตรง*มาใช้ซะที แล้วความเร็วก็จะไม่เกิดครับ
สรุปแล้ว มันเป็นกับดักเพราะขอบเขตความกระชับมันเปลี่ยน ถ้าไม่รู้ตัว ก็จะไม่ได้รับประโยชน์อย่างเต็มที่ครับ
“ความศักดิ์สิทธิ์อยู่ที่ พอเวลาผ่านไป จากความมั่นใจที่จะ refactor จะกลายเป็นความมั่นใจในการ refactor”
ต้องเป็น ไม่มั่นใจ แล้ว มั่นใจหรือป่าวครับ
งึมๆ หมายถึง “จะ” กับ “ในการ” ซึ่งคงอยากสื่อว่ามั่นใจเต็มที่หรือเปล่า
มั่นใจที่จะ refactor หมายถึงพอจะต้อง refactor จากที่กลัวอะไรจะพังไปบ้างก็ไม่รู้ สุดท้ายก็ไม่กล้าทำ จะกล้าทำมากขึ้นถ้ามี testcase คลุม code ไว้ให้เราอุ่นใจครับ
มั่นใจในการ refactor เกิดหลังจาก refactor ไปเยอะๆ ของที่เคย refactor ไม่ได้ ก็จะทำได้ เริ่ม refactor ของที่ใหญ่ขึ้นได้ (แท้จริงแล้วคือ design เก่งขึ้นนั่นเอง) สุดท้าย ด้วย capabilities ที่มากขึ้น ทำให้ทำงานได้เร็วยิ่งขึ้นไปอีกครับ
อ๋อจะสื่อแบบนี้ใช่ไหมครับ “ความศักดิ์สิทธิ์คือระดับความกล้าในการทำ Refactor จะเพิ่มขึ้นเรื่อยๆเพราะเรามี Test Case เป็นหลัก……”
ขอบคุณสำหรับทุกๆ feedback นะครับ จะพยายามปรับปรุงให้ดียิ่งๆขึ้นไปครับ
คำถามครับ…
1. สมมตุในระบบงานหนึ่ง ใน phase แรกจะมี concurrent user ที่ 50 คน แต่พอ phase ที่ 2 จะมี concurrent user ที่ 500 คน (ตาม plan นะ) ถ้าเป็น case แบบนี้ แล้วเรา design โดยตั้งเป้าให้ระบบสามารถรองรับที่ 500 คนใน phase แรก จะเรียกว่า over design ไหมครับ หรือถ้าไม่ design ตั้งแต่ต้น มันมีความเสี่ยงที่จะต้อง refactoring กันตั้งแต่รากหญ้าเลยรึเปล่า คือคุ้นๆ ว่าเคอ่านที่พี่ minimalist พูดถึงเรื่องนี้จากมุมมองของ architect แต่หากระทู้ไม่เจอ (เอ… หรือจะใช้คาถาอัญเชิญพี่แกมาดี 555 … ผมแซวเล่นคับพี่ ^/|\^)
2. ตัวอย่างระบบ inventory ที่เคยทำ ตอนแรกไม่ support สาขา (เจ้านายจะเอาแบบไม่มีสาขาก่อน เสร็จแล้วค่อยทำเพิ่ม) พอจะทำให้ support สาขา … ถึงขั้นจับไข้กันเลยทีเดียว มัน effect ทุกเรื่องเลย ตั้งแต่หน้า input ยัน report… แบบนี้มีแนวทางยังไงครับ
ทั้งสองระบบมี test case คลุม code ไหมครับ? (เดาว่าไม่มี) ถ้ามีเมื่อไหร่ คำตอบคือ
1. รองรับ 50 คนครับ ถึง iteration ที่จะ support 500 คน ก็ refactor ธรรมดาครับ
2. ก็ refactor ธรรมดาอีกเช่นกันครับ
เพิ่มเติมนิด คำตอบฟังดูง่ายมากเลยใช่ไหมครับ? เพราะส่วนที่ยากมันอยู่ก่อนหน้านั้นครับ ออกแบบระบบให้ test ได้ นั่นแหละยากที่สุดครับ
ลองนึกภาพว่า ถ้าระบบ inventory มันมีแค่ 2-3 tables ถ้าต้องขยายให้ support สาขามันยากไหมครับ? ไม่ยากใช่ไหมครับ สาเหตุเพราะระบบที่มี 2-3 tables ที่เราเห็นๆกัน ส่วนใหญ่จะมี quality สูงครับ จะปรับจะแก้อะไรก็ไม่ยาก ความซับซ้อนของระบบเป็นปัจจัยเล็กๆที่ทำให้การต่อยอดทำได้ยาก แต่ปัจจัยที่สำคัญจริงๆที่เราเผชิญเวลาต้องต่อยอดอะไรยากๆ คือ ระบบที่มี quality ต่ำครับ
บ่อยครั้งที่เราเห็นระบบซับซ้อนมักจะมี quality ต่ำตามมาด้วยกัน เราเลยจำติดตากันมาว่าระบบใหญ่ๆมันต่อยอดยากครับ
ปล.
- คำถามของคุณ olarn.u บอกให้ผมรู้ว่าคุณ olarn.u ยังไม่เคยผ่านโปรเจคที่พัฒนาแบบ TDD และไม่คุ้นเคยกับการออกแบบ test ด้วย ผมเข้าใจถูกไหมครับ?
ใช่ครับ เป็น project เก่าๆ ที่เคยทำมาก่อนหน้านี้ แฮ่ๆ
เมื่อก่อนผมเขียนโปรแกรมด้วย tool ที่เน้นลากปะ พอจะ refactoring ทีนึงก็ปวดตับเลย งานในช่วง 3 ปีหลังมานี้ก็ไม่ได้ทำงานที่ต้องเขียนโปรแกรมเต็มๆ เหมือนเมื่อก่อน ก็เลยไม่ได้จริงจังกับ TDD ซะที แต่จะเป็น topic ที่ตั้งใจจะลงไปจับอย่างจริงจังหลังจากนี้ครับ
ขอบคุณสำหรับคำตอบครับ จะรอติด(อ่าน)กับดักใน level ต่อไป ^^
ขอบคุณสำหรับ feedback เช่นกันครับ ที่เดาไว้อย่างนั้นเพราะมันเกี่ยวกับ post นี้พอดี ถ้าถึง level 1 แล้วจะคุ้นเคยกับการ refactor ครับ วิธีทำมันเหมือนที่เราเคย refactor กันอยู่ทุกวันนี้แหละครับ ที่แตกต่างคือชีวิตมันจะสบายขึ้นเท่านั้น
อันต่อไปไม่น่าจะเป็น level 2 ครับ เป็น level 1 นี่แหละ แต่จะ rewrite ใหม่ ^ ^”
จาก feedback ของทุกๆท่าน ทำให้ความคิดตกตะกอนขึ้นเยอะ อยากเขียนใหม่แล้ว กำลังคิดไม่ตกว่าเขียนใหม่อีกอันดี หรือว่าแก้อันนี้ดี?
รบกวนแก้อันนี้เป็นภาษาไทยก่อนค่ะ 555+
คนที่เริ่มทำ agile ใหม่ๆ จะท้อแท้ที่ขั้นตอนนี้ค่ะ เพราะคนที่ไม่เคยเห็นผลที่แท้จริงของ test case บวกกับประสบการณ์การทำพวก test หรือ TDD มีน้อย จะทำให้รู้สึกเหมือนมีงานเพิ่มแทนที่จะลดงาน เพราะในขั้นตอนนี้ test case มันยังไม่ใช่ product ที่แท้จริงของโปรเจค
สิ่งหนึ่งที่เกิดกับ เลเวล 1 นี้ ผลเสีย “อย่างหนึ่ง” ที่เกิดขึ้นของคนที่ผ่านมันไปไม่ได้ คือ คนทำนั่นแหละ คิดว่าตัวเอง กำลัง over design มากไปหรือเปล่า์? เพราะจับทุกอย่างมา test มากกว่าปกติ เพราะปกติไม่เคยเขียน test และไม่เคยเสียเวลาใส่ใจมันมากเท่านี้ พอรู้สึกว่างานคืบไปได้ช้า ก็เริ่มคิดว่า agile ไม่เห็นจะดีเลย เหมือนที่พี่แป๋มว่า โดยที่ยังไม่เคยเห็นประโยชน์เทพๆ ของการเขียน test เพราะประสบการณ์ยังน้อย
แต่คำว่า over design ในความหมายของท่านอื่นๆ ที่อ่านบทความนี้แล้วงง น่าจะเป็น over design ในส่วนของตัว product มากกว่าค่ะ เลยทำให้ งง กันไปใหญ่ ซึ่งแน่นอน อันนี้ก็เป็นเหตุผลหนึ่งของกับดักเลเวล 1 ด้วย เพราะถ้าเราดีไซน์ในส่วนของ product เผื่อไว้มากเกินจำเป็น ก็ต้องทำ test มากขึ้นด้วย ก็ทำให้ story นึงจบไม่ลงเพราะการ over design
แต่เอาจริงๆ เก๋อ่านก็งงเหมือนกันนะคะ ต้องกลับไปอ่าน เลเวล 0 ใหม่ด้วยกว่าจะได้คอมเมนต์ – -*
เพิ่งจะได้ฤกษ์มาอ่านบทความยอดนิยม อ่านแล้วมีความสุขอย่างประหลาด คุณ juacompe เขียนได้ดีมาก ส่วน reply ก็สนุกไม่แพ้กัน
ผมคิดว่าสิ่งหนึ่งที่จะช่วยทำให้เลี่ยงกับดัก over design ได้คือการมี exit criteria ของ user story ที่ชัดเจน
(ค่าว่า exit criteria เนี่ยจริงๆผมก็เอามาจาก Ben (Benjamin Scherrey) เข้าใจว่าในหนังสือ Mike Cohn จะใช้คำ่ว่า acceptance criteria)
วิธีง่ายๆก็คืออย่าทำอะไรเกิน exit criteria เพราะมันถ้ามันไม่ได้เขียนไว้ แปลว่ามัีนยังไม่จำเป็นสำหรับลูกค้า ทำอยางพอเพียงและทำสิ่งที่สำคัญที่สุดก่อน test case ในที่นี่ก็ยึด exit criteria เป็นหลัก จริงอยู่ phase แรกรับ 50 และ phase สองกะว่า 500 แต่เราแน่ใจแล้วเหรอว่าจบ phase แรกแล้วจะไม่กลายเป็น 50,000 หรือว่าโปรเจคล่ม?
ถ้ามี test coverage เป็นเกราะป้องกันกับดัก มาไม้ไหนก็ไม่กลัว เราพร้อมจะ embrace change เสมอ ผมว่าความยากอยู่ที่การเตรียมความพร้อมนี่แหละ
เห็นด้วยนะครับ ว่าการตั้งที่ acceptance criteria เป็นคีย์หลัก
แต่สำคัญมากๆๆๆๆๆๆ คือต้องมี automated acceptance test case รับด้วยนะครับ ขาดไม่ได้
ไม่งั้นตายลูกเดียว บางที่เขียนไว้ง่ายๆ โง่ๆ มากจริงๆ เพราะไม่ต้องการ over design
บางทีโค้ดมันไม่สวยที่สุด ไม่ได้เป็น design pattern ที่ดีพอ แต่มันก็พอดีผ่านแล้ว ก็ทิ้งไว้อย่างนั้น
พอมันไม่ได้เป็นอะไรที่ดีเลิศเลอ test case เลยจำเป็นมากเพื่อจะช่วยตอนขยายงานต่อไปเมื่อ “จังหวะจำเป็น” มาถึง
เรื่องนี้ต้องย้ำกันชัดๆ ว่าที่ option นี้เป็นไปได้เพราะเรามี test case ที่พร้อมจะรับการเปลี่ยนแปลงในอนาคต
พี่เคอะ… แต่ถึงแม้จะมี exit criteria ที่ clear แล้ว ก็ยังมีส่วนที่ต้องใช้ความสามารถของ developer ในการแยกแยะ ว่าอันนี้ “เผื่อ” หรือ อันนี้เป็นการ “เตรียมพร้อม” ที่ดีสำหรับการเปลี่ยนแปลงนะเคอะ… น้องว่า….
อันนี้ก็แน่นอนอยู่แล้วจ๊ะ
เส้นแบ่งระหว่าง “เผื่อ” กับ “เตรียมพร้อม” มันอยู่ที่ตรงไหน? จริงๆ มันคือเรื่องเดียวกันหรือเปล่า?
เป็นคำถามที่น่าสนใจนะครับ
ผมมองว่า test coverage ของ automated acceptance test ก็น่าจะเป็นตัวช่วยชี้วัดที่ดีว่า “เผื่อ” หรือ “ไม่เผื่อ”
ส่วน “พร้อม” หรือ “ไม่พร้อม” น่าจะดูที่ความสะอาดของ code มากกว่า
ถ้ามันอ่านง่าย สื่อ intension เข้าใจด้วยการกวาดสายตาทีเดียว ก็ถือว่า maintain ได้แล้วในระดับหนึ่ง ผมก็ถือว่า “เก็บงาน” เรียบร้อยแล้วละครับ
ว่าแล้ว เรื่อง coding technique น่าจะไปคุยกันต่อที่ http://www.code-66.com เนอะ
ปล. ดูจาก linkedin คุณ sinapam ผมน่าจะเป็นรุ่นน้องอยู่หลายปีครับ
กรี๊ด…รู้อายุหมดเลย – -” คือ “พี่เคอะ” นี่ใช้กับพี่ kluak110 น่ะค่ะ (พี่ยังเป็นรุ่นน้องพี่เค้าอีกหลายปีค่ะ
)
คือพี่(ใช้สรรพนามให้ถูกต้อง)แค่อยากจะบอกว่า อุปสรรคอาจจะไม่ได้จบแค่ define exit criteria น่ะค่ะ แต่ก็ไม่ใช่ว่าเป็นไปไม่ได้… ไว้จะไปรอตามอ่าน http://www.code-66.com นะคะ เผื่อจะได้ไอเดียอะไรไปแชร์กับน้องๆบ้าง
[...] level 1 อันที่แล้ว ยิ่งอ่านยิ่งขัดใจ มัน abstract ไปหน่อย [...]
[...] Agile ที่ level 1 (ทั้งเก่าและใหม่) ผมพยายามดันให้ลดการเผื่อ [...]