เวลาที่คนพูดถึง Agile Process เราคงจะนึกถึง SCRUM/XP กันเป็นหลัก วันนี้เราจะลองมาดู Process อีกตัวนึงที่คนเขียนบอกว่าเป็น Agile (แต่บางคนอาจจะบอกว่ามันไม่ค่อยจะ Agile ซักเท่าไหร่) นั่นก็คือ OpenUP ครับ ซึ่งคิดง่ายๆ ก็คือเป็นการเอาพวกหลักการของ Agile ทั้งหลายมาใส่ไว้ใน Framework ของ Unified Process ครับ สำหรับข้อมูลเพิ่มเติมลองดูได้ที่ ไฟล์นี้ คนเขียนก็ได้อธิบายไว้ด้วยว่าทำไมเขาถึงคิดว่ามันเป็น Agile โดยอ้างอิงจาก Agile manifesto
March, 2010:
กึ๋นของการ refactor
จากกับดัก Agile ที่ level 1 (ทั้งเก่าและใหม่) ผมพยายามดันให้ลดการเผื่อ แล้วค่อยมา refactor architecture ทีหลัง ซึ่งหลายๆท่านก็เป็นห่วงว่า “ความพอดี” ของแต่ละคนไม่เท่ากัน จะรู้ได้อย่างไรว่าเมื่อไหร่เรา”เผื่อ”มากเกินไป?
ในบางกรณี โทษจากการไม่เผื่อ (ขาด) มันรุนแรงมาก เช่น ออกแบบ field address ไว้เป็น text area อันเดียว แล้วต้องมาแยกที่หลังว่าใครอยู่จังหวัดอะไร ถนนไหน แก้ structure ไม่เท่าไหร่ แต่แก้ข้อมูลที่ลงไปแล้วนี่จุกครับ (ใครเคยทำจะซึ้งว่ามันทรมาณขนาดไหน T-T) ถึงอย่างนั้นก็ตาม วันนี้ผมยังกลับมาอีกครั้ง พร้อมกับเชียร์ดังๆว่า อย่าไปเผื่อครับ ค่อย refactor เอา สำหรับท่านที่เคย design แล้ว”ขาด”มาแล้ว จะฝังใจมากๆว่า”เหลือดีกว่าขาด” แต่นั่นมันไม่ Agile ครับ
พี่ Bomber พูดไว้ว่า process เหมือนรถแข่ง ถ้า scope คำว่า process ลงมาเป็น personal process แล้ว คน หรือ person ก็คือคนขับนั่นเอง ถ้าไม่กล้าเหยียบคันเร่งพุ่งใส่โค้ง ก็ไม่มีวันจะได้สัมผัสความรู้สึกของดริฟท์หรอกครับ (-__-+) หลายท่านที่เคย design ขาดมาแล้ว ต้องคิดว่าหมอนี่มันบ้าแน่ๆ แต่เพราะประสบการณ์ตามล้างตามเช็ดผลที่เราตัดสินใจพลาดมา ทำให้วันนี้เราเร็วขึ้น ท่านว่าจริงไหมครับ?
ขอบเขตของพอดีนั้นบางเหมือนปลายมีด นิดนึงมากกว่านั้นคือเผื่อ นิดนึงน้อยกว่านั้นคือขาด ขาดก็เจ็บ เผื่อก็ช้า
แต่ถ้าอยาก maximize agility ก็ต้องหาขอบนั้นให้เจอ ประสบการณ์กว่าจะถึงตรงนั้นมันทรมาณ แต่ความทรมาณนี้แหละที่ทำให้ผมเร็วขึ้นครับ
ถ้ามีคนลองทำตามผมจริงๆ (พวกบ้าพนัน 
) ณ วันนี้ ท่านจะเริ่มรู้สึกว่า refactoring == rotation (more…)
หนี้ทางเทคนิค Technical Debt
ศัพท์คำนี้ Ward Cunningham ตั้งเป็นอุปมาอุปมัยเพื่อสะท้อนถึงผลกระทบที่เกิดขึ้นเมื่อ software developer/business stakeholder ตัดสินใจเลือกจะติดหนี้ระบบเพื่อแลกกับการส่งงานทันกำหนด deadline หลังจากส่งไปแล้วหนี้ส่วนนี้ไม่ได้หายไปไหน หากแต่อนาคตไม่ได้รับการแก้ไขโดยเร็ว ความซับซ้อนจะพอกพูนจนถ่วงความเปลี่ยนแปลงให้แย่ลง เมื่อต้องปรับปรุงหรือเพิ่มฟีเจอร์ใหม่จะทำได้ยาก กินเวลานาน และบั๊กเกิดได้ง่ายกว่าปกติ ผมเชื่อว่า developer ที่ทำงานแข่งกับความกดดันและความคาดหวังย่อมรู้ดีว่าผมหมายถึงอะไร
การที่เราตัดสินใจแก้ปัญหาโดยเลือก solution ประเภท quick & dirty ย่อมเป็นการเชื้อเชิญให้เกิด technical debt ขึ้นมาอยู่แล้ว แต่คำถามคือว่า “มันเป็นเรื่องที่เราควรแลกหรือไม่” ต่างหาก?
Planning Poker มาโหวตกัน !!
Prerequisite: ก่อนอ่าน post นี้ ผู้อ่านควรทำความเข้าใจกับคำว่า user story ก่อนนะคะ ตามอ่านได้ที่นี่นะคะ กดเลย มองหน้าหาเรื่อง
ขั้นตอนหนึ่งของการสร้าง user story คือการให้ point หรือ คะแนน กับ story นั้น ว่าจะต้องใช้ effort กับมันมากแค่ไหน
คำถามที่ถูกถามบ่อย: แล้วเค้าทำกันยังงัย? รู้ได้งัยว่าเป็นคะแนนที่เหมาะสมแล้ว? แล้วใครเป็นคนทำ? บลาๆๆๆ
Planning poker เป็นวิธีการของการให้คะแนนกับ story เหมือนกับเล่นไพ่ โดยที่แต่จะคนจะได้รับแจก card ชุดหนึ่ง ถือไว้กับตัว โดยการ์ดนี้จะเรียงเลขไปตาม Fibonacci (0,1/2,1,2,3,5…) โดยเราจะนำแต่ละ story มาโหวตกัน ว่าคุณคิดว่า ควรจะให้คะแนนกับ story นี้เท่าไหร่
คำถาม: แล้วเราจะให้เท่าไหร่ดีล่ะ แนวคิดเป็นอย่างไร
คำตอบ:
โดยปกติแล้วนั้น ความหมายของตัวเลขคร่าวๆ คือ
0 = story ที่สร้างขึ้นเพราะกลัวจะลืมทำ แต่ไม่สำคัญเท่าไหร่
1 = story ที่สร้างขึ้นเพื่อ confirm ว่าเราจะทำอันนี้เสร็จแน่นอน เช่น เอา google calendar API มาแปะในหน้า page (ง่ายมาก แต่ต้องทำ)
2 = คะแนนเริ่มต้นของ story ที่เริ่มจะมีเรื่องมีราว แต่อาจจะไม่ซับซ้อนมาก
…
…
ยิ่งเลขเยอะ ก็เป็นสัญญาณว่า ต้อง split ออกมาให้ย่อยลง
ถ้าเป็นการ์ดเครื่องหมายคำถาม ? คือ คิดไม่ออกว่าจะเสร็จตอนไหน
การ์ดรูปถ้วยกาแฟ คือ พักเหอะว่ะ – -”
จริงๆ แล้ว มันไม่มีมาตรฐานที่แน่นอนของการให้คะแนน ส่วนใหญ่เราจะให้คะแนนโดยการเปรียบเทียบกับงานอื่นๆ แทนที่จะมานั่งคิดว่าสิ่งนี้ทำนานแค่ไหนจึงจะเสร็จ เพราะมันยากที่จะคิดมากกว่า เช่น งาน A ยากกว่า B ก็ ให้คะแนน A สัก 3 และ B สัก 2 ละกัน เป็นต้น (สำหรับเรื่องนี้ พี่แป๋มยกตัวอย่างการมองตึก ถ้ามองว่าตึกนี้สูงกี่ชั้น มันยากกว่าการมองกว่า ตึกนี้ สูงกว่าตึกข้างๆ เท่าไหร่ ครึ่งนึง หรือสองในสาม เป็นต้น)
คำถาม: แล้วทำไมต้องเรียงไปตาม fibonacci???
คำตอบ: เพราะไม่อยากมานั่งเถียงกันว่า story นี้ ควรได้คะแนน 7 หรือ 8 เพราะเลขที่ใกล้กันเกินไป ก็ทำให้มองไม่เห็นความต่าง
เตรียมพร้อมก่อนโหวต
อ่ะ คราวนี้ ตอนจะโหวต ทุกคนก็ต้องเข้าใจก่อนว่า story นี้ทำงานอย่างไร และมีคำถามอะไรที่สงสัยก็ถามไป ก่อนจะโหวตกัน เป็นช่วงเวลาที่ตื่นเต้นพอสมควร เพราะเราจะสงสัยตัวเองว่า เราจะโหวตเหมือนคนอื่นหรือเปล่าหนอ?? กลัวคิดบ้าๆ ไปคนเดียว 555
พร้อมจะโหวตแล้ว!!!
โชว์การ์ดของท่านขึ้นมาซิ ให้คะแนนกันเท่าไหร่บ้าง ????????
แต่ละคนจะโชว์การ์ดที่เลือกขึ้นมา (ด้วยความตื่นเต้น) เราก็จะได้ตัวเลขที่แต่ละคนคิด ซึ่งก็จะแตกต่างกันออกไป เราจะดูเสียงข้างมากเอา และคราวนี้ก็จะมาคุยกันค่ะ ว่าคนที่คิดต่างจากคนอื่น คิดอย่างไร ด้วยเหตุผลใดบ้าง และก็มาคุยให้จบที่ตัวเลขเดียวกัน
แล้วเราก็จะได้คะแนนสำหรับ story นั้น ไปอย่างเอกฉันท์ อย่างเป็นประชาธิปไตย ไม่มีเสื้อสีใดเลย!!
ประโยชน์ที่ได้คือ
1. ได้การ estimate ที่แม่นยำ เพราะมาจากคนหลายคนช่วยกันคิด
2. ทุกคนได้เข้าใจงานใน story นั้นอย่างแท้จริง และอาจจะทำให้เกิดการ split งานไป story อื่น หรือแก้ไขรายละเอียด ในขั้นตอนนี้
3. ตอนโหวตเสร็จ ก็จะได้รู้ว่า แต่ละคนเข้าใจตรงกันจริงหรือไม่ เพราะหากโหวตคะแนนแตกต่างกันมาก แสดงว่าอาจจะมีอะไรเข้าใจผิดก็ได้
4….. ใครคิดออกอีก ช่วยบอกด้วยได้ไหมคะ???
คราวนี้ การให้คะแนน story ก็ไม่อยากอย่างที่คิดแล้ว จริงไหมคะ? ^^
หากมีข้อสงสัย ติชม หรือมีอะไรเพิ่มเติม ก็รบกวนเลยนะคะ
มีภาพเหตุการณ์จริงมาฝาก เกิดขึ้นวันนี้เอง (18 March 2010)
Planning poker session ที่ Proteus ทำความเข้าใจก่อน vote
Pokers ของจริง ใช้จริง ที่ Proteus!!!
vote 2 points ให้กับ story เกี่ยวกับการส่งอีเมลล์อัตโนมัติไปยังผู้ใช้
“มองหน้าหาเรื่อง”
มีน้องทักว่าทำไมพี่ไม่เอาอันนี้ไป post ล่ะคะ ไหนๆเดี๋ยวนี้เค้าก็รณรงค์ Reduce Reuse Recycle ก็เลยซะหน่อย เอามาจากตรงนี้
ลักษณะเฉพาะตัวของความเป็น agile software development อย่างหนึ่งก็คือ การเขียน requirements ในลักษณะ user story… อ้ะ แล้ว user story หน้าตาเป็นยังไง?
User story เริ่มมาจากคำอธิบายสั้นๆถึงความต้องการ ในมุมมองของผู้ที่จะได้ประโยชน์จาก story
As a <stakeholder>, I want to <goal>, so that <reason>.
stakeholder ก็คือ ผู้ที่จะได้ประโยชน์จากการทำ story นี้ เราจะทำ story นี้ไปทำไม ถ้ามันไม่มีประโยชน์กับใครเลย
goal คือ เป้าหมายของ story เมื่อทำเสร็จนี่แหละคือสิ่งที่เราอยากได้
reason คือ เหตุผลที่อยากได้สิ่งนี้ การบอกเหตุผลจะช่วยให้คนทำ story มองเห็นภาพรวมของการนำไปใช้มากขึ้น
ส่วนถัดไปของ user story ก็คือ exit criteria ตัวนี้จะเป็นเหมือนกับ checklist ว่าต้องทำสิ่งเหล่านี้ให้เสร็จนะ story ถึงจะเสร็จได้
จริงๆ ก่อนจะนำ user story ไปทำงานได้ จะต้องมีการนำ story มา discuss แล้วก็ estimate กันก่อน แต่ในวันนี้ อยากจะพูดถึงส่วนนึงของการเขียน story ให้ดีจะดีกว่า เพราะเห็นว่าดูจะเป็นปัญหาที่ผู้ใช้ agile มือใหม่เจอกันเป็นประจำ
สิ่งที่อยากจะพูดก็คือ เราจะต้องไม่ตกไปใน หลุมพราง ต่อไปนี้
(more…)
