Spike กับ เทคนิคการวางแผนแบบ Agile

เมื่อเช้านี้ตอนที่กำลังขับรถไปทำงานกับคุณภรรยานั้นก็คุยกันสรรพเพเหระ ผมจะรายละเอียดไม่ได้ แต่เธอถามขึ้นมาว่า “แล้วจะวางแผนอย่างไรล่ะ” ผมก็ตอบไปตรงๆ แบบไม่ได้คิดมากว่า “อะไรที่วางแผนได้ก็จงวางแผน อะไรที่วางแผนไม่ได้ก็ไม่ต้องวางแผน” พอได้ยินตัวเองก็สว่างวูบขึ้นมาว่า โอ้ มันช่าง Agile เสียนี่กระไร

อะไรที่วางแผนได้ก็จงวางแผน อะไรที่วางแผนไม่ได้ก็ไม่ต้องวางแผน

ฟังดูอาจจะประมาณว่า มันง่ายไปปล่าวเพ่ แต่นี่ก็เป็นแก่นของ Agile จริง ลองคิดดูว่าสำหรับ คนที่ต้องมีส่วนในการวางแผนโปรเจ็ค กี่ครั้งที่เราเดาว่า มันจะเป็นอย่างนั้นอย่างนี้ หรือถ้าคุณเป็น Developer แล้วหัวหน้ามาถามว่าเสร็จเมื่อไหร่ ขอ estimate หรือขอแผน จริงๆ คุณไม่รู้ อาจจะยังไม่รู้ หรือเรื่องนี้มันเกินกว่าที่จะรู้ล่วงหน้าได้ ต้องเริ่มทำก่อนจึงจะรู้ได้ แต่คุณก็ต้องตอบหรือทำแผนไปก่อน ด้วยการเดาว่า มันคงใช้ 3 วันเสร็จกระมัง ใน methodology แบบอื่นนั้น เค้าจะถือว่าการเดานั้น เป็น commitment ทันที และเมื่อคุณไม่สามารถทำเสร็จได้ตามกำหนดนั้น ก็จะถือว่าสาย ซึ่งมันไม่ยุติธรรมเอาเสียเลย และใครเล่าจะบอกได้ว่า เจ้าเรื่องที่เราไม่รู้และจำเป็นต้องเดานั้น มันต้องใช้เวลาจริงๆ เท่าไหร่

แล้ว Agile แก้ปัญหานี้อย่างไร Agile กำหนดไว้แบบซื่อๆ และตรงตัวมากๆ ว่า เมื่อไม่รู้ ก็คือไม่รู้ การเดาไม่ทำให้รู้ขึ้นมาได้ การทำต่างหากที่จะทำให้เรารู้มากขึ้นจนกระทั่งสามารถเรียกว่ารู้ได้ Agile กำหนดการลองทำดูเพื่อให้รู้เพิ่มขึ้นพอที่จะวางแผนได้ว่า “Spike

A spike is an experiment that allows developers to learn just enough about something unknown in a user story, e.g. a new technology, to be able to estimate that user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike .

William McKnight of 3M once said “Give it a try – and quick”. Apply this advice when using a spike.

สรุปความได้ว่า Spike คือการทดลองทำดูของ developer เพื่อให้ได้ความรู้เพิ่มเกี่ยวกับ story เพียงพอที่จะ estimate โดยจะต้องมีการกำหนดเวลาที่จะใช้ไว้แน่นอนล่วงหน้า (timeboxed)

สิ่งที่ต้องระวังสำหรับการทำ Spike คือ เราทำมันเพื่อให้สามารถ vote ได้ ไม่ใช่ทำให้เสร็จ หลายครั้งที่ผมพบว่า พวกเรามักจะใช้เวลามาก ทั้งเกินที่ timebox ไว้ ไม่ก็ให้ timebox ไว้มากเกินไป แล้วแทนที่จะศึกษาเพียงพอที่จะ vote ดันกลายเป็นว่า ทำ story นั้นเสร็จไปเลย

ข้อเสียของการทำ story เสร็จไปเลยในการทำ spike คือ Solution ที่เลือกใช้นั้นไม่ได้ผ่านการพิจารณาร่วมกันของทีม ทำให้อาจจะขาดตกบกพร่องไม่เห็นผลข้างเคียงของมันอย่างรอบด้าน หรือบางครั้งก็ไปกระทบกับวิธีการทดสอบ ทำให้ test ยากหรือบางครั้งถึงขั้น test ไม่ได้เลยก็เป็นได้ เพราะฉะนั้น เมื่อเรานำ Spike มาใช้ใน Agile project ห้ามทำจนเสร็จอย่างเด็ดขาด ทำแค่พอ vote ได้ แล้วกลับมา vote story ก่อน จึงค่อยกลับไปทำจนเสร็จ

Links
http://www.energizedwork.com/weblog/2006/01/spike.html

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s