เจาะลึกขั้นตอนการ login ของ yahoo (Archive)
Posted by Bomber, Apr 25 2008, 08:30 PM
ขออนุญาติเอาบทความเก่ามาลงนะครับ พอดี thaidev เปลี่ยนแปลงไปมากกลัวหาย เลย copy มาลงตรงนี้แทน
---------------------------------------------------------------------------------------------------------------
พอดีผมต้องทำ project ตัวหนึ่งที่ต้องไป export contact list ใน address book ของ yahoo ช่วงแรกผมพยายามหา web services ของ yahoo ที่จะสามารถติดต่อขอเอา contact list แต่ปรากฏว่าหายังไงก็ไม่เจอเลย สุดท้ายเลยจำใจติดต่อ yahoo เองโดยจำลองการกรอก username/password ของ user และการ export contact list
เมื่อตกลงใจดังนี้ผมเลยเริ่มต้นด้วยการ ศึกษาและวิเคราะห์หลักการของการ login เข้าใช้ระบบของ yahoo
เครื่องมือที่ใช้วิเคราะห์ไม่มีอะไรมากครับ มีแค่ Browser และ HTTPLook เท่านั้นเอง
หลังจากทำการทดสอบ login เข้าระบบใน yahoo โดยเปิด http source code ทิ้งไว้ในหน้าต่างๆที่เข้าๆไป ระหว่างนั้นก็เปิด HTTPLook ทิ้งไว้ด้วยเพื่อตรวจสอบข้อมูลที่รับส่งกัน ปรากฏว่าผมประทับใจกับ concept ของ yahoo มากๆ
ผมพบว่าในหน้า login ของ yahoo ก่อนที่จะทำการส่ง data ออกไป จะทำการ encrypt password ของเราก่อนจะส่งทุกๆครั้ง โดยการ encrypt จะใช้ concept ของ MD5 เป็นหลัก ส่วน key ในการ encrypt ก็ทำการ generate ใหม่ทุกครั้งที่เข้าสู่หน้า login ที่สำคัญหาก key เคยถูกใช้แล้วจะไม่สามารถใช้ได้อีกเลย
การ encrypt password ทาง yahoo ใช้ javascript ซึ่งเขียนโดย Paul Johnston เป็น argorithm ของ MD5 โดยหลักของการ encrypt จะใช้หลักดังนี้
md5(md5(password)+key)
นอกจาก key แล้ว yahoo ยังมี parameter อีกตัวชื่อ ".u" ซึ่งผมไม่แน่ใจเหมือนกันว่ามันใช้ทำอะไร แต่จะถูก generate ใหม่ทุกครั้งและใช้คู่กับ key ที่ generate มาพร้อมๆกันเท่านั้น
หลังจากทำการ login แล้ว yahoo จะส่ง cookie กลับมาให้ โดยข้อมูลใน cookie จะถูก encrypt แล้วทั้งหมดอ่านไม่ออกเลย แต่ไม่เป็นไรแค่เรา repeat ข้อมูล cookie อันนี้เราก็จะสามารถใช้ service ใดๆก็ได้ใน yahoo ซึ่งผมก็เพียงแค่ request ขอ contact list เป็น CSV fil ตรงๆพร้อมทั้งส่ง cookie ที่ได้จากการ login มาด้วย ก็จะได้ file contact list กลับมาทันที
เมื่อวิเคราะห์สำเร็จดีแล้ว ผมก็จัดการลงมือเขียน code โดยใช้ common httpclient เป็น library หลักในการเขียน โดยมี process ดังนี้
1. เรียกขอหน้า login จาก yahoo เพื่อขอ ".challenge" key และ ".u"
2. ถาม user/pass จาก user
3. ทำการ encrypt pass ด้วย ".challenge" key
4. login เข้า yahoo และ รอรับ cookie ที่จะได้
5. นำ cookie ที่ได้ไปร้องขอ csv file โดยตรง
แค่นี้ก็เสร็จสิ้นกระบวนการครับผม
TrueVisions PVR
Posted by Bomber, Apr 22 2008, 03:52 PM
TrueVisions PVR
สวัสดีครับ ไม่ได้เขียน blog ตั้งนาน วันนี้ขออนุญาติมาอวดผลงานตัวเองหน่อยนะครับ 
ความเป็นมา
อย่างที่หลายๆท่านพอรู้กันบ้างแล้วว่าตอนนี้ผมทำงานอยู่ที่ TrueVisions ในส่วนของการพัฒนา product PVR ซึ่งตอนนี้ได้เปิดตัวไปแล้ว เมื่อวันที่ 17 มีนาคม ที่ผ่านมา ได้เสียงตอบรับพอควรทั้งดีๆและที่ไม่ดี (โดนบ่นเรื่อง bug 
) สินค้าตัวนี้ต้องบอกว่าเป็น Project ที่ผมภูมิใจมาก project หนึ่งในชีวิตการทำงานของผม... ผมเคยมีความฝันไว้ตั้งแต่ได้เห็น TiVo ครั้งแรกใน web site ของ CNET ว่าเป็น product of the year ในปี 2004 ตอนนั้นผมรู้สึกตื่นเต้นมาก การย้อนดูซ้ำ Live TV ได้ การเลือกอัดรายการที่อยากจะดู แล้วมันจะตามอัดให้ มันเป็นเทคโนโลยีที่จะช่วยอำนวยความสะดวกใน Life Style ของเราเป็นอย่างมาก และที่แน่ๆมันแทบจะเปลี่ยนพฤติกรรมการดูทีวีของเราไปเลย... ตอนนั้นผมรู้สึกอยากทำ product ในลักษณะนี้มากๆ เพราะอยากให้คนไทยได้ใช้ จริงๆแล้วอยากทำ เองใช้เองมากกว่า (ฮา) ผมเลยไปเสนอ idea กับผู้บริหารในบริษัทที่ผมทำงานอยู่ตอนนั้น ซึ่งก็ไม่ได้มี feedback อะไรมากนักเพราะบริษัทที่ผมอยู่ตอนนั้นเป็นบริษัทเครือข่ายมือถือ จนในที่สุดผมได้มีโอกาศมาทำงานที่บริษัท True ก็ยังเสนอ idea นี้กับผู้บริหารของผมอีก ซึ่งคร่าวนี้โอกาสเลยเปิดครับ เพราะพอดีกับที่ True พึ่งซื้อหุ้นของ UBC ทั้งหมดเพื่อนำมาบริหารเอง และนั้นทำให้ผมได้มีโอกาสได้มาทำ project นี้
ผมเริ่มจากการศึกษาหาความรู้ใหม่ในเทคโนโลยีของการถ่ายทอดทีวีแบบ digital หรือที่เรียกว่า DVB โดยเรียกได้ว่าเริ่มจาก 0 เลยละ ความรู้เรื่อง network บนโลกของ internet แทบจะใช้อะไรไม่ได้เลยในโลกของ DVB ความรู้เล็กๆน้อยตอน ศึกษาเรื่อง Multimedia พวกเรื่อง MPEG กลับช่วยได้มากกว่า เพราะ DVB จะอยู่บนมาตรฐาน MPEG เป็นสำคัญ
หลังจากศึกษาหาความรู้ได้พอควรแล้ว ก็เริ่มคิดหาเทคโนโลยีที่จะมาใช้ทำ ตอนนั้นคิดว่าจะใช้ Linux หรือ WindowsCE มาใช้ แต่ปรากฏว่า OS ของคอมพิวเตอร์ในตอนนั้นยังไม่เหมาะกับการนำมา implement จริงๆจังๆกับ DVB (ตอนนี้ LinuxTV เริ่มใช้ได้ดีขึ้นแล้ว) เลยต้องมาหาแนวทางใหม่ สุดท้ายเลยรู้ว่ามันมี OS อีกประเภทที่เรียกว่า RealTime OS ซึ่งจะเป็น OS สำหรับ run software บนอุปกรณ์พวกนี้ แต่ OS พวกนี้ส่วนใหญ่จะเป็น proprietary หากเราเลือก Set-Top box คนละ vendor ก็จะได้ OS คนละเจ้า ตายละจะทำอย่างไรดี?? ก็เลยมาพบว่ามันมี solution ที่เรียกว่า Middleware ที่จะมา run บน os พวกนี้ให้ แล้วเราเขียน software ในแบบเดียวก็ run ได้ทุก vendor
ผมพบว่า Middleware ในตอนนั้นหลักๆมี 2 ลักษณะคือเป็น proprietary และ open standard โดยส่วนใหญ่แล้ว operator ทั่วโลกจะใช้เป็นแบบ proprietary ส่วน open standard พอมีใช้บ้างในประเทศที่เขาบังคับว่าต้องใช้เช่น เกาหลีใต้ และอิตาลี
proprietary เจ้าใหญ่ๆก็คือ OpenTV และ NDS ส่วน open standard ก็จะมี MHP และ MHEG ตอนนี้เองที่น้อง iWat เริ่มเข้ามามีบทบาท มาทำงานวิจัยให้ผม 
หลักๆแล้วคือให้ trial ตัว product ทั้งหลายนั้นเอง จนสุดท้ายมาเลือกมาได้ 2 ตัวเลือกคือ OpenTV และ MHP
ใจผมนะโอนไปทาง MHP ครับ เพราะตัวเองชอบพวก open standard อยู่แล้ว แต่ผู้บริหารทั้งหลายกลับไม่คิดแบบนั้น สุดท้ายเลยต้องเลือก OpenTV ด้วยเหตุผลหลายๆประการณ์ซึ่งไม่สามารถเปิดเผยได้ อย่างไรก็ดี OpenTV ก็ถือว่าเป็น middleware ที่ดีตัวหนึ่งครับ โดยหลักการณ์แล้ว ดีกว่า MHP ด้วยซ้ำเพราะมันเป็น C ทำให้ control ระดับ hardware ได้ดีกว่า MHP ที่เป็น Java เยอะ แต่ก็ต้องแลกมากับความยากในการพัฒนานั่นเอง
พอเลือก technology ที่จะใช้ได้แล้ว ผมก็ set-up ทีมงานขึ้นมาซึ่งมี developer ทั้งหมด 10 กว่าคน โดยใช้ Agile เป็น development process หลักๆ ตอนแรกเลือกใช้ XP เป็น process หลัก แต่หลังจากทำๆไปได้ 4 เดือนพบว่ามันไม่สมบูรณ์ มันขาดหลายอย่างเลยประยุกต์ใช้ Scrum เข้ามาด้วย จนสุดท้ายกลายเป็น Scrum 80% และ XP 20% เท่านั้น และดูเหมือนจะเป็น process ที่ลงตัวที่สุดเท่าที่เคยใช้มา
PVR คืออะไร? 
PVR มาจากคำว่า Personal Video Recorder จริงๆแล้วมันมาจากคำว่า DVR หรือ Digital Video Recorder อีกที แต่ทำไมต้องเป็น PVR ด้วยล่ะ? ... ประเด็นคือต้องการแยกความแตกต่างให้ออกจาก DVR ทั่วๆ ซึ่งมันจะทำได้แค่บันทึกสัญญาณ ภาพ ทีวีให้อยู่ในรูปแบบ digital เท่านั้น แต่ PVR จะทำได้มากกว่านั้นมากครับ
PVR โดยหลักๆแล้วทำหน้าที่เหมือนกับ DVR คือสามารถอัดรายการทีวีลงบนสื่อที่เป็น digital ซึ่งในกรณีนี้คือ Harddisk เพื่อเอามาดูทีหลังได้ แต่สิ่งที่เหนือกว่าคือ PVR จะมี EPG หรือ Electronic Program Guide มาให้ด้วย
TV Guide (EPG)
EPG คือ ตารางออกอากาศครับ โดยในกล่อง PVR ที่ทีมงานผมช่วยกันพัฒนาขึ้นมา จะมีตารางออกอากาศทั้งหมด 8 วันล่วงหน้า เราสามารถกดปุ่ม record บน remote control ที่รายการที่เราอยากชมในอนาคต แล้วเดียวกล่องจะตามอัดให้เอง 
ไม่ว่ารายการจะเลื่อน ออกอากาศมันก็จะตามอัดให้ นอกจากนี้มันยังมี Feature Series Recording ให้เราได้ใช้สะดวกสบายอีกด้วย โดยหากรายการที่เราจะตั้งอัดเป็นรายการในรูปแบบ Series คือเป็นตอนๆ ตัวกล่องก็จะตามอัดให้ทุกๆรายการ ไม่ต้องคอยมาตั้งอัดเองอีก ทำให้เราแน่ใจได้ว่าเราจะไม่พลาดตอนไหนๆเลย
หลายๆคนอาจจะเริ่มสงสัยว่าแล้วไอ้ข้อมูล EPG มันมาจากไหนๆกันละ มาจาก internet? หรือมาจากการ load เข้าไปเอง?
ไหนๆก็เป็นคนสาย Technology จะให้โฆษณาอย่างเดียวก็ใช่ที่ ผมจะไขปริศนาให้ครับ 
แล้ว EPG มันมาจากไหนละ?
มันมาพร้อมๆกับสัญญาณทีวีนี่แหละครับ โดยสัญญาณทีวีที่ทาง TrueVisions ส่งอยู่นี้ ปัจจุบันในเทคโนโลยีที่ชื่อ DVB (Digital Video Broadcast) ซึ่งเป็นการแพร่สัญญาณภาพวิดีโอแบบ digital ซึ่งอยู่บนพื้นฐานของ MPEG Stream
สัญญาณ DVB นอกจากภาพและเสียงแล้ว มันมีสัญญาณที่เป็น Data ส่งมาได้ด้วยครับ แต่ data ที่ส่งก็จะมีลักษณะเป็น 1 way communication เท่านั้น... ถึงตรงนี้จะมีคนสงสัยบ้างไหมหนอ ว่าหากเป็น 1 way communication แล้วจะไปรู้ได้ไงว่า user เปิดเครื่องเมื่อไหร แล้วมันจะรู้ได้ไงว่าจะเริ่มต้นส่ง data เมื่อไร ประเด็นคือมันจะไปรู้ว่าเริ่มตรงไหนได้อย่างไร หากเปิดเครื่องแล้วมาอยู่ตรงกลางๆของข้อมูลแล้ว
ตอนนั้นผมสงสัยครับ... งงจริงๆ 1 way communication ไม่มี request ไม่มี reply แถมเป็น broacasting technology อีก มันจะไปรู้ได้ไงว่า user ต้องการข้อมูลเมื่อไร? จริงๆแล้วมันง่ายๆมากๆครับการแก้ปัญหานี้ เทคนิคที่เขาใช้คือใช้ การส่งข้อมูลในรูปแบบ carrousel ครับ
carrousel เป็นการส่งข้อมูลแบบม้าหมุน!!!! ตรงตัวครับมันม้าหมุนจริงๆ คือมันจะส่งข้อมูลวนๆกันไปเป็นรอบๆ หาก user เปิดเครืองมาตรงกลางของชุดข้อมูลก็ไม่ต้องสนใจข้อมูลชุดที่เจอ ให้ไปรอรอบใหม่ได้เลย ง่ายๆแต่มีประสิทธิภาพ
Control Live TV
Control Live TV เป็น feature highlight ตัวหนึ่งของ PVR ด้วย function นี้ user สามารถควบคุมการรับชม Live TV ที่ฉายสดๆได้ ไม่ว่าจะเป็นหยุดภาพไว้ก่อน หรือจะ Rewind ภาพกลับ หรือทำเป็น Replay เพื่อดูภาพซ้ำก็ได้ เทคนิคไม่ยากเลยครับ คืออัดภาพที่ user รับชมอยู่ลง Harddisk ไปด้วย ที่ยากคือต้องทำ circular video record คือพออัดได้ file size ที่กำหนดแล้วต้องกลับมาใช้หัว file ใหม่ ไม่งั้น file vdo มันจะใหญ่ขึ้นเรื่อยๆ
แต่เอาเข้าจริงๆที่ยากกว่าคือ UI ครับ... การ design UI ให้แสดง status bar บอกสถานะของการ control Live TV นั้นยากมาก กว่าจะได้ UI ที่ทางทีมคิดว่าลงตัวที่สุดนี้รื้อไปไม่รู้กี่ครั้ง ต้องทำ brainstrom กันหัวแตกกันหลายวันกว่าจะได้ออกมา ถือได้ว่าเป็น user story ที่ respawn บ่อยที่สุดเลยครับ
My Programs
My Programs เป็น feature มาตรฐานของ PVR ครับ เป็นแหล่งเก็บ VDO ที่ user ตั้งอัดเอาไว้ และเป็นส่วนที่มี bugs มากที่สุดอีกด้วย (ฮา) ความยากของมันอยู่ที่ระบบ Security ครับ File VDO ทุกๆ file ในกล่องจะถูก encrypted ด้วย key ซึ่งจะผูกติดกับ smart card กับ chip บนกล่อง ซึ่ง key จะเปลี่ยนไปในทุกๆ x นาที เป็นส่วนที่ปวดหัวที่สุดในการตามล่าหา bug ต้องยอมรับว่าปัจจุบันก็ยังมี bug อยู่ ซึ่งผลที่ได้คือ VDO ที่อัดมาจะ decrypted ไม่ได้ในบางช่วง ซึ่งก็คือจะดูไม่ได้ในช่วงๆที่ decrypted ไม่ได้นั่นเอง ตอนนี้ software ล่าสุดที่จะ release ออกมาในสัปดาห์หน้าจะช่วยลดโอกาสการเกิด bug นี้จนตอนนี้ต่ำกว่า 1% แล้ว (ทีมงานกำลังทำงานหนักเพื่อแก้ไขปัญหานี้ให้หมดไป)
My Schedules
My Schedules เป็นอีกหนึ่ง feature มาตรฐานที่ผู้ใช้มักมองข้าม ด้วยความสะดวกของการตั้งอัดรายการผ่าน EPG ทำให้คุณค่าของ My Schedules นั้นน้อยลงไป หลักๆแล้วมันทำหน้าที่ใช้ตั้งอัดครับ feature นี้ดูเหมือนง่ายๆไม่มีอะไรก็แค่ตั้งอัด แต่จริงๆแล้วเป็นอีก feature ที่ไม่ง่ายเลย ความยากของมันคือการตามอัดรายการเลื่อน ตามอัดรายการ series และการ manage conflict (เวลารายการที่จะอัดชนกัน ปัจจุบันอัดได้แต่ทีละรายการครับ) สิ่งที่ปวดหัวที่สุดคือต้อง manage tasks background ให้ดี ต้องกิน cpu น้อยไม่ให้กระทบการรับชมปกติ และยิ่งยากเข้าไปใหญ่คือ conflict ยากตรงการคิด case ครับ โดยปัจจุบัน PVR ยังทำได้แค่ basic conflict คือต้องเลือกว่าจะอัดเรื่องใดเอาเอง ยังไม่สามารถเรียนรู้และเลือกแทน user ได้ว่าควรจะอัดเรื่องใดมากกว่ากันหากตั้งอัดชนกัน ซึ่งในอนาคตทางทีมงานจะเพิ่ม intelligent conflict management ลงไปครับ แต่มันยากจริงๆปวดหัว
Interactive TV
Feature นี้คือการส่ง application ฝั่งมากับรายการที่ถ่ายทอดอยู่ครับ ปัจจุบันมีแค่ Football Live Score แต่ในอนาคตจะมีเพิ่มเติมแน่นอน ความยากยังไม่บังเกิดสำหรับ feature นี้แต่หากอนาคตมีการระบุว่า scene นี้ต้องขึ้น menu นี้ scene โน้นต้องมี logo นี้ละก็เหนื่อยหนักแน่ๆครับ สิ่งที่หนักจะอยู่ฝั่ง server ที่จะต้อง play-out application และ data ของมันให้ sync กับรายการที่ออกตอนนี้ยัง no-idea ว่าจะทำยังไงครับ แต่ requirement มาจ่อๆอยู่แล้วเหมือนกัน
ตอนนี้สิ่งที่ทำคือ รับ feed ที่ได้จากต่างประเทศ ซึ่งเขาจะ feed ตรงมาจากสนามแข่งเลย ได้มาเป็น XML เข้ามาทาง FTP ซึ่งทางทีมก็ไป research ได้เทคนิคการทำ FTP trigger ขึ้นมา ซึ่งจะมี event เกิดขึ้นเมื่อมี file upload เข้ามาจึงสามารถทำงานได้ทันทีไม่ต้องเสียเวลา pull อีก จาก XML ที่ได้เอามาสร้างเป็น application แล้ว compile แบบสดๆยิ่งขึ้นไปพร้อมๆกับสัญญา vdo แบบ realtime ทั้งหมดนี้เป็นระบบ automate ไม่มีคน operate เลยครับ ทีมงานพัฒนาเองทุกส่วน น่าภูมิใจจริงๆ
สุดท้ายคือ OTA Upgrade
OTA หรือ Over the Air ถือเป็นหัวใจหลักของ software บนกล่องที่ลูกค้าจะซื้อไปตั้งที่บ้านตัวเอง หากปราศจาก feature นี้เราจะไม่สามารถ upgrade software บนกล่องได้เลยครับ หลักแล้วไม่ยากอะไร แค่ต้อง test หนักเท่านั้นเอง ต้อง test ทุกรูปแบบ ไม่ว่าจะตอนฝนตก แดดออก เมฆครึม ต้องแน่ใจว่า software ที่ OTA ไปหากไม่สำเร็จจะไม่ทำให้กล่องเสียหายเด็ดขาด ซึ่งตอนนี้ทีมงานมั่นใจมากว่าไม่มีวันที่จะทำให้กล่องเสียหายหาก OTA ไม่สำเร็จ
สรุป
Project นี้ใช้เวลาเตรียมตัวก่อน kick-off ทั้งหมด 2-3 เดือน ไม่ว่าจะเป็นการทำ prototype เพื่อไปขออนุมัติจากผู้บริหารของ True และ TrueVisions การเลือกเทคโนโลยีที่จะนำมาใช้ และการ set-up ทีมงานเข้ามาทำงาน หลังจาก kick-off ก็ใช้เวลาพัฒนาทั้งหมด 1 ปีเต็มๆ test อีก 3 เดือนเต็มๆ ถือได้ว่าเป็น project ที่ทุ่มเทแรงกายแรงใจมากที่สุดเลยก็ว่าได้ เป็น project ที่ทำให้ผมหายหน้าหายตาไปจาก narisa พักใหญ่ๆ เพราะไม่มีเวลาเข้ามาตอบ และอีกอย่างเริ่มห่างไกลเทคโนโลยีที่เป็น topic ที่คุยกันใน forum มากขึ้นทุกที
ยังไงๆ ก็ขอฝาก product ตัวนี้ไว้ด้วยนะครับ ช่วยกันอุดหนุนกันหน่อย ผลงานของคนไทย ทีมงานไทย หัวคิดคนไทยล้วนๆครับ เป็น OTOP ตัวหนึ่งของจังหวัดกรุงเทพครับ 
สนใจอ่านรายละเอิียดเพิ่มเติมได้ที่ http://pvr.truevisionstv.com
Scrum เพื่อเสริม XP
Posted by Bomber, Oct 4 2007, 10:17 AM
SCRUM
Scrum เป็นหนึ่งใน implementation หลายๆวิธีที่อยู่ในค่าย Agile Software Development ในเมืองไทยตอนนี้กระแส Agile เริ่มมาแรงมากขึ้นเรื่อยๆ หน่วยงาน หรือบริษัทต่างๆก็เริ่มประยุคต์ใช้กันมากขึ้น หรือไม่ก็มีแนวโน้มว่าอยากจะทดลองใช้ดู ซึ่งเป็นแนวโน้มที่ดีมาก เพราะ Agile เน้นที่การทำให้ทุกฝ่ายมีความสุข
ลูกค้ามีความสุข เพราะได้เห็นผลงาน ได้เห็นความคืบหน้าชัดเจน ได้เปลี่ยน requirement บ่อยๆอย่างที่อยากได้
คนทำงานก็มีความสุข เพราะทำงานไม่หนักเกินไป มี balance ของชีวิต เห็นอนาคตชัดเจนว่าวันนี้จะทำอะไร มีอะไรให้ทำหรือเปล่า แล้วอนาคตอันใกล้มีอะไรรออยู่
Project Manager ก็มีความสุขเพราะ track งานง่าย คุยกับลูกค้าได้ง่ายขึ้น ไม่ต้องมาปวดหัวกับความเอาแต่ใจของลูกค้ากับคนทำงาน ที่มักไม่ตรงกันอยู่เลย ลูกค้าอยากให้ทำแต่คนทำงานไม่อยากทำไม่เห็นจะ make sense เลย
พอใช้ Agile มันตอบโจทย์ทุกอย่าง มีความสุขกันทุกคน งานเสร็จ ทำงาน happy เงินก็ได้ project จบเร็วไม่ยืดเยื่อ
กลับมาที่เรื่อง Scrum ปกติแล้ว พอพูดถึง Agile มีแต่คนนึกถึง XP จนเดี๋ยวนี้คนทั่วไปคิดว่า Agile=XP ไปแล้ว ซึ่งจริงๆแล้วไม่ใช่ XP เป็นแค่น implement หนึ่งของ Agile เมื่อก่อนหน่วยงานผมเริ่มต้นก็ใช้ XP เช่นกัน แต่ XP เองก็มีข้อเสียหลายๆข้อที่ไม่ค่อยจะเหมาะกับลักษณะงานและสังคมของความเป็นไทย ปรับไปปรับมาหลังๆมันก็เลยกลายเป็น Scrum ไปแบบไม่รู้ตัว แล้ว Scrum มันต่างจาก XP อย่างไรล่ะ?
เวลาผมถามใครๆว่าถ้าพูดถึง XP จะนึกถึงอะไรบ้าง คำตอบแรกที่ได้คือ Pair Programing ใช่หรือไม่ แล้วสิ่งต่อไปละ? Unit Test First ใช่หรือไม่? มีอะไรอีกไหมครับ? User story ไง? มีอีกไหมครับ?.............................ถึงตอนนี้จะเริ่มเงียบ เพราะเริ่มนึกไม่ออก
คุณจะตอบเหมือนคำตอบด้านบนไหมครับ? ผมเดาว่าไม่ใช่ก็ใกล้เคียงล่ะ นั่นแปลว่า XP นั้นเน้นเรื่อง Development เป็นสำคัญใช่ไหมครับ? ส่วนตัวผมคิดว่าใช่ เพราะชื่อมันบอกอยู่แล้วว่าเป็น eXtreme Programming
แล้วนั่นคือปัญหาของผมครับ XP เน้นเรื่อง development มากๆ จนอ่อนเรื่อง Project Management คือมันมีเนื้อหาหรือรูปแบบที่กว้างเกินไป ทำให้ implement ลำบาก และต้องใช่การตีความค่อนข้างมาก การ track งานเลยมีประสิทธิภาพไม่เต็มที่ จุดนี้ Scrum ช่วยได้มากครับ
Scrum คืออะไร?
Scrum เป็น development process ที่อยู่บนพื้นฐานของ Sprint ให้นึกถึงเวลาวิ่งแข่งระยะไกล เวลาวิ่งเราจะวิ่งเต็มแรงไม่ได้ใช่ไหมครับ เพราะหากวิ่งเต็มแรงเราจะเหนื่อยเสียก่อน อย่าว่าแต่จะชนะหรือเปล่าเลย อาจจะไม่ถึงเส้นชัยเสียด้วยซ้ำ วิธีการเราคือจะวิ่งแบบออมแรงไว้ก่อน แล้ว sprint เป็นช่วงๆไปตามช่วง check point ต่างๆ เช่นกันครับ Scrum ก็จะ sprint เป็นช่วงๆ ตามหลักการแล้วคือช่วงละ 2-4 สัปดาห์ โดยจะเป็นช่วงที่เราจะวิ่งกันอย่างเต็มที่เต็มขีดจำกัด หลังจบ sprint ก็จะพักบ้างสัก 3-5 วันให้เบาๆหน่อยก่อนที่จะ sprint กันต่อ (อันนี้จะผิดกับวิ่งแข่งหน่อย เพราะปกติเราจะ sprint สั้นๆ แต่ออมแรงยาวๆ แต่ scrum จะ sprint ยาวๆ แต่พักสั้นๆ 55555555)
Concept ของ Scrum
ประกอบไปด้วย 3 หัวข้อหลักคือ
1. ว่าด้วยเรื่องของทีมงาน (Role)
2. ว่าด้วยเรื่องของวิธีการทำงาน (Process)
3. ว่าด้วยเรื่องของการประเมินและติดตามงาน (Demonstration and Evaluation)
แค่ 3 หัวข้อหลักบนก็แทบจะเสริมส่วนที่ XP ขาดไปได้ครบสมบูรณ์แบบ เห็นด้วยไหมครับ
ว่าด้วยเรื่องของทีมงาน (Role)
ในทีมงานจะประกอบไปด้ย 3 Roles หลักๆได้แก่
Scrum Team คือคนทำงานจริงๆ มีประมาณ 5-9 คน แต่ละคนไม่ได้กำหนดงานตายตัว สามารถทดแทนกันได้เสมอ โดยคนในทีมงานมีหน้าที่ประเมินเวลาของ task ที่จะต้องทำ แจกจ่ายงานและ assign งานกันเอง ส่วนวิธีการทำงานไม่ได้กล่าวถึงไว้มากนัก จุดนี้ผมใช้ XP ผสมเข้าเต็มที่คือทำงานเป็น pair, การทำ unit test (แม้จะไม่เอื้อนัก) และอื่นๆตามแบบฉบับของ XP
Product Owner เป็นตัวแทนของลูกค้า ทำหน้าที่จัดการเรื่อง product backlog ทั้งคิด ทั้งรวบร่วม พร้อมทั้งต้องเป็นคนเผยแพร่ product backlog ให้ทุกคนได้รับรู้ ได้เห็นกันง่ายๆ เพื่อให้คนในทีมเห็นอนาคตว่าจะมีอะไรรออยู่ข้างหน้า คนนี้เป็นคนเขียน User Story ด้วยครับ
Scrum Master ทำหน้าที่ดูแลทีมงาน เป็นโค้ชของทีมงาน และเป็นคนรับผิดชอบคุณภาพของผลงาน จัดลำดับความสำคัญของงาน แตก task ของ user story ออกมา lead การประชุม daily scrum ตัดสินใจในเรื่องต่างๆตามความเหมาะสมไม่ว่าจะเป็นเรื่องของ design หรือ architecture ของระบบ (ย้ำว่าตัดสินใจไม่ใช่คนออกแบบ คนออกแบบคือ scrum team)
ว่าด้วยเรื่องของวิธีการทำงาน (Process)
โดยเนื้อหามี 3 ส่วนหลักๆ ได้แก่
Backlog เป็นรายการของ feature ที่ต้องทำ คำว่า feature นี้รวมถึง request จากลูกค้า bug fix และ specification ของตัว product โดยคนทำคือ product owner ซึ่งจะจัดลำดับ feature ตามความสำคัญ จัด list เพื่อนำเข้า sprint และจัดการกับรายละเอียดต่างๆของ feature เช่นต้องจัดทำ user story สำหรับแต่ละ feature เป็นต้น
Sprint phase คือช่วง iteration นั่นเอง โดยมีกำหนดไม่เกิน 30 วัน ซึ่งก่อนเริ่ม sprint ก็จะมีการนำ product backlog มาจัดลำดับความสำคัญเพื่อเลือกมาเป็น sprint backlog จากนั้น scrum team จะดู backlog และแตกเป็น task ย่อยๆออกมาและทำการ estimate เวลาที่ใช้ในแต่ละ task หลังจากได้เวลาและต่อรองกันระหว่างทีมงานแล้ว ก็จะได้ list ของ task และ list ของ backlog ที่จะทำภายใน sprint ขึ้นมา
Daily scrum คล้ายกับ standup meeting โดยทุกๆวัน scrum master และ scrum team จะมีการประชุมกันเพื่อจัดว่าเมื่อวานทำอะไรไปบ้าง และวันนี้จะทำอะไรบ้าง มีการถกกันเพื่อแก้ไขปัญหาที่เจอเมื่อวาน และจัดการ assign task ให้กับทีมงาน
จาก 3 หัวข้อด้านบน จะเห็นว่ามันดูหลวมๆอยู่ดีไม่ใช่หรือ? จริงแล้วก็ใช่ แต่มันไม่ได้หมดแค่นั้น มันมี tool ที่นำมาช่วยเรื่องพวกนี้อยู่พอควร ไม่ว่าจะเป็น index card, planning poker , scrum checklist , Niko-niko calendars ซึ่ง tool แต่ละตัวใช้ได้ดีมีประโยชน์มากในการช่วยขับเคลื่อน process ซึ่งลองไปค้นหาข้อมูลศึกษาดูนะครับ ไว้ผมมีเวลาจะลองเขียนแต่ละตัวให้อ่านกัน
ว่าด้วยเรื่องของการประเมินและติดตามงาน (Demonstration and Evaluation)
จุดเด่นของ scrum คือเราสามารถวัดผลของการทำงานได้ และได้ดีมากๆด้วย ด้วย burn-down chart ที่เรียบง่าย และธรรมดา แต่มันทำให้เห็นสภาพของ sprint ได้อย่างชัดเจน โดยหลักการแล้วก็คือ graph ของงาน โดยแกน y เป็น จำนวน task ที่เหลือ และ แกน x เป็นวันแต่ละวันของ sprint โดยในแต่ละ dairy scrum เราจะมีการ update graph กัน เพื่อให้เห็นภาพความคืบหน้าของงาน และหลังจากจบ sprint เราก็จะเอา graph นี้แหละมาประเมินผลงานของทีมงาน โดยมาดูในแต่ละจุดว่าเหตุใดบางช่วง graph จึงเป็นแนวนอนไม่ดิ่งลงมา burn-down chart จะมีประสิทธิภาพมากเมื่อใช้คู่กับ index card เพราะจะทำให้ plot graph ได้ง่าย และรู้สถานการณ์ภายใน sprint ได้ดี
สรุป
และนี่คือทั้งหมดของ scrum ดูหลวมๆ แต่จริงๆแล้วยังมี detail อีกพอควรในแต่ละ tool ที่ใช้งาน ซึ่ง tool ต่างๆก็จะพุดขึ้นมาเรื่อยๆตาม idea ของคนในโลก อย่างเรื่องของ index card นี่ก็ไม่ได้เป็นหัวข้อหลักใน scrum แต่มีคนคิดขึ้นมาเพื่อทำให้ burn-down chart มีประสิทธิภาพมากขึ้น
หากคุณทดลองใช้ XP แล้วพบปัญหาเรื่องการ manage งานอย่างผม ลองประยุกต์ใช้ scrum เข้าไปเสริมสิครับ จะช่วยได้มากทีเดียว
reference: wikipedia, infoQ, softhouse
Useful acronym
Posted by Bomber, Jul 17 2007, 09:42 AM
DRY = Don't Repeat Yourself
KISS = Keep It Simple, Stupid
YAGNI = You Ain't Gonna Need It
PHB = Pointy-Haired Boss
WTF = What The F*ck
FUBAR = F*ck Up Beyond All Repair, F*cked Up But All Right
Agile Testing
Posted by Bomber, Jan 22 2007, 05:47 PM
Agile Testing
"QA (Quality Assurance) เป็นกระบวนการที่ทำหลังจากพัฒนา Software เสร็จสิ้นแล้ว เพื่อเป็นการควบคุมคุณภาพของ Software ก่อนจะถึงมือลูกค้า"
จากข้อความข้างต้น QA เปรียบเสมือนกำแพงหน้าด่านเพื่อป้องกัน Software ไม่ได้คุณภาพให้ไกลจากมือลูกค้า ดูเหมือนมันจะห่างไกลจาก Agile Development Process เป็นอย่างมาก ที่ว่ากันว่าต้อง Speed up development process ให้เร็วถึงที่สุด มี release ทุกๆเดือนหรือมากกว่านั้น แล้วเราจะไปมีกำแพงทุกๆเดือนได้อย่างไร
ปัญหาอีกอย่างที่ Tester เริ่มตกใจกลัวเมื่อมีองค์กรหลายๆแห่งเริ่มประยุกต์ใช้ XP มาเป็น Development Process หลัก "แบบนี้เราไม่ตกงานเหรอ? ในเมื่อมันมี Automate Unit Test อยู่แล้ว? แบบนี้ Tester จะมีประโยชน์อะไร"
ไม่ต้องตกใจกลัวครับ Tester ทั้งหลาย Agile ก็มี concept ของการทำ QA เช่นกัน และเข้มข้นมากๆด้วย
Concept ของ QA ใน Agile คือ "ต้องช่วย support Developer เพื่อให้ได้ Software คุณภาพดีเยี่ยมไปถึงมือลูกค้า" ดูดีไหมครับ เรามาตีความกันว่า Tester จะต้องทำอะไรบ้างเพื่อจะ support developer ให้พัฒนา Software คุณภาพดีได้
แนวคิดหลักๆก็คือ Tester ต้องยอมรับความเปลี่ยนแปลงอย่างน่าชื่นตาบาน!!! Change Request Control Board นะเหรอ ลืมมันซะ!!! เราไม่ต้องการมัน ความเปลี่ยนแปลงเกิดขึ้นได้ทุกๆ Release ใน XP เราพร้อมจะโยนโค๊ดเก่าทิ้งแล้วเขียนใหม่อยู่ตลอดเวลา
จากการเปลี่ยนแปลงที่เกิดขึ้นตลอดเวลาดังนั้น คุณต้อง Plan as you go คุณไม่สามารถวางแผนล่วงหน้าได้มากๆ จะวางแผนได้ในแต่ละ release เท่านั้น ดังนั้นคุณต้องมีความยืดหยุ่นสูงในเรื่องการวางแผนการ test สามารถปรับเปลี่ยนแผนงานได้ตามความเหมาะสม
ทำเอกสารเท่าที่จำเป็นเท่านั้น ซึ่งตามปกติแล้ว Tester ต้องทำ Step by step Test Case จำนวนมาก พร้อมทั้งทำ Test Scenario มหาศาล ถามจริงๆเถอะ ว่ามีใครอ่านบ้างหรือเปล่า จงยอมรับความจริงเถอะว่ามันคือ "ขยะ" คำนี้อาจจะแรงแต่มันเป็นความจริง ไม่มีใครอ่าน Test Script ของคุณหรอก แม้แต่คุณเองก็เถอะเวลาทำ Test คุณทำตาม Test Script ที่เขียนมากแค่ไหนกันเชียว ยิ่งถ้าเราจ้าง Outsource มาทำ Test ให้ด้วยแล้วละก็ ฮา ฮา ฮา ลองไปแอบถามดูสิครับว่าเขาใช้กันบ้างหรือเปล่า (ระวังคำตอบสะเทือนใจนะครับ)
แนะนำให้ทำแค่ Check List ก็พอแล้ว แล้วมันทำอย่างไรละ? Check List เป็นผลผลิตจากการทำ User Story ครับ ตามปกติแล้ว User Story จะมีลักษณะคล้ายกับ User Manual มากๆ ซึ่งมันจะมีผลลัพธ์ของสิ่งที่ User อยากจะได้อยู่ นั่นแหละครับ สิ่งที่นำมาทำเป็น Check List แล้วใช้ Check List ในการ Test และเพียงจด note สำหรับ test ที่ fail คร่าวนี้แหละที่ Step by step เป็นสิ่งต้องการของ developer เพราะเขาต้องการรู้ว่า step แบบไหนที่ทำให้เกิด error ขึ้น ซึ่ง Tester จะต้อง repeat error นั้นให้ได้พร้อมทั้งเขียน step เอาไว้
จาก Check List คุณต้องทำ Sequence Test สำหรับแต่ละ List แล้วมันคืออะไรละ? มันคือวิธีการทุกๆวิธีที่สามารถทำให้เกิดผลที่ต้องการได้ อธิบายให้เป็นภาษามนุษย์อีกนิดคือ การที่จะให้ได้ผลลัพธ์ A เราสามารถทำ 1,2,3 หรือทำ 2,1,3 หรือ 1,4,3 ก็ได้ เราต้อง Test ให้มากที่สุดเท่าที่ทำได้ ตรงนี้ไม่จำเป็นต้อง document แต่คุณต้องจำให้ได้นะว่ามันคุณทำอะไรไปบ้าง หาก fail ค่อย note
ต้องทำ Evil Case หากคุณรู้ว่าถ้าทำแบบนี้แล้วระบบน่าจะพัง ลองเลยครับ ลองให้หมด ทำทุกอย่างที่จะทำให้ระบบพัง เพื่อจะได้ช่วยเหลือ developer ให้ ensure ว่าคุณภาพของ software จะดีจริงๆ
แล้วเมื่อไรละถึงจะ Test?
ใน Agile เราจะทำ Test ทุกๆ week โดยต้องทำงานร่วมกับ developer ซึ่งจะใช้เวลาสั้นๆ ไม่เกิน 1 ชม. ให้ Developer ทำ demo ระบบให้ดู แล้ว test คอยตรวจสอบว่ามันทำงานได้หรือไม่ ถ้าไม่ได้จด note เอาไว้ แต่ไม่ต้องคิดอะไรมาก ค่อยคิดมากตอนจบ release โดยนำ note ที่จดไว้นั่นแหละเข้า check list เพื่อนำมาทดสอบซ้ำว่า bug ที่เคยเห็นยังอยู่หรือไม่ นอกจากนี้ระหว่างที่ developer ทำ demo ให้ดู tester ควรจะสอบถามให้ลอง test ต่างๆด้วย (แต่อย่าให้มากเกินไป พอเป็นน้ำจิ้ม) และให้ลองทดสอบ case เก่าๆที่เคยทำจบใน release เก่าๆด้วยว่ามันยังอยู่ดีหรือเปล่า การทำ test ทุกๆ week จะช่วยให้ developer ต้องใส่ใจในคุณภาพอยู่ตลอดเวลา ไม่ใช่คอยมาดูเอาตอนจะจบ release ซึ่งปกติแล้วจะไม่ทันการณ์
End to end test หลังจากจบ release แล้ว จะมีการ integration code ครั้งใหญ่ (ปกติควรทำทุกๆวัน) และให้ developer ทำ demo ให้ดู concept เหมือนการทำ testing ทุกๆ week เพียงแต่คร่าวนี้จะให้ทุกๆคนในทีมงานเป็นสักขีพยานความชั่วร้ายของ bug ที่จะเกิดขึ้น พูดเล่นนะครับ ถึงจุดนี้ bug น่าจะน้อยแล้ว โดยมาก demo จะราบลื่น แต่ก็มีบ่อยๆที่มักจะมี bug เกิดขึ้นแบบไม่คาดคิด tester อย่าลืม note นะครับ และหลังจาก demo จบแล้ว จะถึงคร่าว tester ออกโรงทำการ test แบบละเอียดตาม check list ที่ทำไว้ และอย่าลืมนะครับ ต้องยอมรับความเปลี่ยนแปลงที่จะเกิด ดังนั้น code ที่คุณ test รับรองว่าไม่เหมือนเก่าแน่นอน ดังนั้นต้อง test ใหม่ในทุกๆ check list คุณโชคดีนิดหนึ่งที่ developer ทุกคนจะมี automate unit test อยู่แล้ว ซึ่งเป็นการ ensure ในคุณภาพระดับหนึ่ง แต่ในบาง project (อย่างของผมเอง T_T) ไม่สามารถทำ Unit Test ได้เนื่องจากข้อจำกัดของเทคโนโลยี ดังนั้น Tester ก็จะเหนื่อยหน่อย
สรุปแล้ว tester ใน agile จะมีส่วนร่วมในการ development ค่อนข้างมาก เพราะต้องเข้าร่วมตั้งแต่การทำ user story เพื่อจะได้เห็นภาพรวมทั้งหมดว่าระบบจะทำอะไรได้บ้าง ต้องศึกษา user story เพื่อนำมาทำ check list ต้องทำงานร่วมกับ developer เพื่อให้ลอง test case แปลกๆในทุกๆ week และต้องจด note ไว้ตลอดเวลา สุดท้ายก็ต้องทำ end to end test เพื่อ ensure คุณภาพตอนจบ release อีกครั้ง อีกอย่างที่ tester ควรจะทำคือการให้ feedback ขณะทดสอบระบบ หากพบว่าบาง case ขาดไป แสดงว่า user story ยังไม่ครอบคลุม ดังนั้น case เหล่านั้นจะกลายเป็น user story ใหม่ และนำไปจัด release ใหม่เพื่อนำไป develop เพิ่มเติม
หวังว่าคงมีประโยชน์นะครับ
Reference:
Agile Testing
Problem Solving Tip
Posted by Bomber, Jan 16 2007, 05:45 PM in General
Problem Solving Tip
พอดีได้มีโอกาสต้อง fix bug กับทีมงาน โดยช่วงแรกผมไม่ได้ยุ่งอะไรด้วยเลย เพียงแต่สังเกตุการเฉยๆ แต่ยิ่งปล่อยไปก็ยิ่งเลยเทอดเริ่มไปไกลจากปัญหาเรื่อยๆ จนทนไม่ได้ต้องเข้าไปช่วยเหลือ จึงพบว่า Skill ด้าน Problem Solving เป็นสิ่งสำคัญมากสำหรับนักพัฒนาซอฟแวร์ เพราะมันจะทำให้เราหา Bug ได้เร็วขึ้นดีขึ้น และทำอย่างมีทิศทางไม่ใช่เป็นคลำมั่วไปหมด
เทคนิคที่ผมจะเสนอต่อไปนี้สามารถใช้ได้ในทุกๆกรณีที่เกี่ยวกับการแก้ไขปัญหา และใช้ได้ดีมากๆในการค้นหา Bug ใน Software ทั้งที่เราเขียนและไม่ได้เขียน ทั้งนี้ทั้งนั้นต้องมี Source Code นะครับ ไม่งั้นคงได้แต่เดา
สิ่งสำคัญที่สุดและยากที่สุดของการแก้ไขปัญหาคือ การค้นหาปัญหา เท่าที่ผมสังเกตุการณ์ดูทีมงานขณะพยายามแก้ไขปัญหา ส่วนใหญ่จะมุ่งประเด็นไปที่ Solution ทันทีโดยไม่ได้คิดว่าจริงๆแล้วปัญหามันคืออะไรกันแน่ หรือบางคนก็จะใช้วิธีการตั้งสมมุติฐานขึ้นมาต่างๆนาๆ แล้วลองทดสอบดูว่าเป็นจริงหรือไม่ ซึ่งเป็นวิธีการที่ไม่ถูกต้องนัก การตั้งสมมุติฐานจะสามารถทำได้ดีก็ต่อเมื่อเรารู้ถึงตัวปัญหาจริงๆเสียก่อน แล้วจึงตั้งสมมุติฐานในการแก้ไขปัญหานั้น แล้วจึงทดสอบมัน หากเราใช้การตั้งสมมุติฐานเป็นหลักโดยยังไม่เข้าใจปัญหาเราจะหลงทางได้ง่ายๆ และจะไปไกลจากปัญหามากขึ้นเรื่อยๆ
การค้นหาปัญหา เป็นเหมือนการสืบสวน ต้องมีพยานหลักฐานที่ชัดเจน ไม่ใช่การเดาสุ่ม วิธีการที่ผมใช้ค้นหาปัญหานั้นง่ายๆ คือ
ผมจะตั้งคำถามโดยใช้ Who What Where When ในการตั้งประโยคคำถามเพื่อใช้ในการตรวจสอบ แล้ว Why กับ How ละ? ถ้าคุณตอบ Why กับ How ได้แสดงว่าคุณรู้ปัญหาและวิธีการแก้ไขแล้วดังนั้นจึงไม่จำเป็นครับ
Questions
ปัญหานี้จะเกิดขึ้นในหรือที่เหตุการไหนบ้าง (where) ทุกๆจุด? บางที่?
ปัญหานี้เกิดขึ้นเมื่อใด (when) สามารถหาจุดเริ่มต้นและสิ้นสุดของปัญหาได้หรือไม่? เกิดทุกครั้งๆ เกิดบางครั้ง? มี Pattern หรือไม่?
ปัญหานี้มีอะไรที่เข้ามาเกี่ยวข้องบ้าง? (what) ไม่ว่าจะเป็นสิ่งของ หรือ object หรือ class หรือ function หรือ อะไรก็ตามที่เกี่ยวข้องกับปัญหาทั้งหมดเช่น ชนิดของ client หรือ input device
ปัญหานี้มีใครเกี่ยวข้องบ้าง? (Who) คำถามนี้จะใกล้เคียงกับ What เพียงแต่ว่าจะเน้นไปที่ผู้เกี่ยวข้องกับปัญหา เพราะเราสามารถสอบถามคนเพื่อหาข้อมูลเพิ่มเติมได้ แต่สิ่งของที่ได้จาก What พูดกับเราไม่ได้
Case Study
อย่างเช่นหากเราพบ Bug ใน Software ในส่วนของการแชร์ข้อมูลระหว่าง Application โดยที่ App A ต้องเขียนข้อมูลเก็บไว้ใน Memory แล้วพอไปเปิด App B ก็ต้องอ่านข้อมูลนั้นขึ้นมาแสดงผล แต่ปัญหาที่เกิดคือ เมื่อใส่ข้อมูลผ่าน App A แล้ว ไปเรียก App B โดยตรง จะทำให้ App B เกิด Memory Violation ขึ้น
วิธีการที่ผมใช้หาปัญหาคือ
- หากเปิด App B ขึ้นมาเฉยๆ โดยไม่ได้เปิด App A ก่อนเกิดปัญหานี้ขึ้นหรือไม่? คำตอบคือไม่เกิด
- หาก insert ข้อมูลใน App A แล้ว ลองใช้ App A ไปเรื่อยๆ ข้อมูลหายไปหรือไม่? คำตอบคือไม่หาย
- หาก update ข้อมูลที่ App B แล้วไปที่ App A จะแสดงผลถูกต้องหรือไม่? คำตอบคือถูกต้อง
- หากเปิด App A แล้วปิด จากนั้นไปเปิด App B จะเกิดปัญหานี้หรือไม่? คำตอบคือไม่เกิด แต่ข้อมูลที่ insert จาก App A กลับไม่เข้า App B
- หากเปิด App A แล้ว Insert ข้อมูล จากนั้นปิด App A แล้วเปิดขึ้นมาใหม่ ข้อมูลที่ Insert ยังอยู่หรือไม่? คำตอบคือไม่อยู่
จาก case ที่ 4 และจากปัญหาเริ่มต้นคือ "เมื่อใส่ข้อมูลผ่าน App A แล้ว ไปเรียก App B โดยตรง จะทำให้ App B เกิด Memory Violation ขึ้น" ผมตั้งสมมุติฐานว่า การปิด App A และการเรียก App B โดยตรงจาก App A มีสิ่งที่หนึ่งที่ทำหน้าที่เหมือนกัน คือทำให้ข้อมูลหายไปจาก Memory ซึ่งเมื่อไปดู code ปรากฏว่ามีการเรียก function งานเดียวกันอยู่คือการ clean up resource แต่ทีมงานยืนยันว่า clean up resource ไม่ได้เป็นการ clean up memory ที่สร้าง เพียงแต่เป็นการ clean up พวก i/o ที่ใช้งาน แต่ผมยังไม่ปักใจเชื่อว่าทำแค่นั้น ผมถามต่อไปเพื่อทดสอบสมมุติฐานของผม
- นอกจาก App A แล้วยังมี App ตัวไหนอีกบ้างที่ต้องใช้ memory ส่วนนี้? คำตอบคือมีแต่ App B
- แต่ App B ไม่เสียหายนี่? ใครทำ App B? จริงๆผมรู้อยู่แล้วแค่ยกตัวอย่างคำถาม
- ผมถาม App B ว่าต้องออกจาก App มีการ clean up resource หรือไม่? คำตอบคือมี
- มีอะไรบ้าง? ก็รายยาว x, y, z
- ผมถาม App A ว่าตกลงเรา clean up resource อะไรบ้าง? มี w, x, y, z
อะ!!!! มีสิ่งที่เหมือนและแตกต่าง นั่นคือการ clean up resource "w"
- ทำไม่ต้อง clean up resource "w"? จำเป็นต้องทำไหม? คำตอบคือไม่จำเป็นเท่าไร แต่ clean up แล้วน่าจะทำให้ระบบดีขึ้น (ระวังนี่คือ ASSUMPTION!!!! เป็นสิ่งควรระวังในการทำงานทุกแขนง)
พยานหลักฐานชัดเจนมาก ผมจึงให้ลบบรรทัดที่ทำการ clean up "w" เสีย ปรากฏว่าปัญหาได้รับการแก้ไขทันที!!!
ตัวอย่างข้างบนเป็นตัวอย่างเหตุการณ์จริงแต่ผมปรับแต่งให้เข้าใจง่ายขึ้น เพราะระบบจริงๆซับซ้อนกว่านี้ และคำถามที่ผมถามก็มีมากกว่านี้ แต่แนวทางคือประมาณนี้นั่นแหละครับ
จะเห็นได้ว่าหากเราสามารถหาต้นต่อของปัญหาได้แล้ว การแก้ปัญหามักจะทำได้ง่ายมากๆ ดังนั้นก่อนที่จะแก้ปัญหาใดๆ ผมแนะนำว่าให้หาตัวปัญหาให้เจอเสียก่อน โดยสามารถใช้แนวทางข้างต้น แล้วจึงค่อยหา Solution ที่ใช้การแก้ไขปัญหา โดยใช้สมมุติฐานเข้าช่วย
--จบ---
Usability and Information Architect
Posted by , Oct 30 2006, 10:24 AM in General
Usability and Information Architect
เนื่องจากช่วงนี้งานของผมจะเน้นที่ต้องพัฒนา Product ที่เป็น Software ที่จะถูกใช้โดยลูกค้าที่มีฐานที่กว้างไม่จำกัดเฉพาะคนใช้คอมพิวเตอร์ ดังนั้น Software ที่พัฒนาขึ้นมานั้นแน่นอนนอกจากต้องมีคุณภาพที่ดีแล้ว ยังต้องมี Usability ที่ดีมากๆด้วย และนั่นเป็นศาสตร์ชนิดใหม่ที่ผมพยายามศึกษาอยู่ในช่วงนี้
Usability หมายถึงอะไร?
หากไปเปิดพจนานุกรมดูจะได้ความว่า
Usability มาจากคำว่า Us-a-ble ซึ่งหมายถึง การใช้งานได้โดยสะดวก, สามารถใช้งานได้
ในทางคอมพิวเตอร์แล้ว Usability หมายถึง ความมีประสิทธิภาพ, ประสิทธิผล และความพึ่งพอใจ ในการใช้งานระบบ โดยสามารถใช้ได้ง่าย เรียนรู้ได้ง่าย จำได้ง่าย สนุกที่จะใช้ และสามารถแก้ไขปัญหาได้โดยง่าย
Usability สำคัญอย่างไร?
Usability ถือว่าเป็นหัวข้อแรกใน เรื่องของคุณภาพของ Software เลยทีเดียว ในความคิดของเราก็แค่พัฒนาซอฟแวร์ให้ใช้ได้ง่ายก็น่าจะจบ แต่จริงๆมันไม่ใช่แค่นั้นครับ ทุกวันนี้ศาสตร์ของ Usability นั่นก้าวไปไกล
แนวคิดเรื่องนี้จะเน้นที่ความง่ายในการใช้งานเพื่อให้บรรลุวัตถุประสงค์ แทนที่จะเป็นการเพิ่ม Feature & Function เข้าไปให้มาก (ซึ่งเป็นแนวคิดเก่าๆ) จะเห็นได้จาก Google เปิดหน้า web ขึ้นมาเจอแต่ box ให้ search เท่านั้น ไม่ต้องคิด ไม่ต้องศึกษา เห็นทีเดียวก็รู้ได้ว่าต้องกรอกข้อความที่อยาก search ลงไปแล้วกดปุ่ม search แม้ Google Search เองจะมี Feature มากมาย แต่ก็มีไว้ให้กับ Advance User เท่านั้น ซึ่งเป็นแนวคิดที่ว่าคนส่วนใหญ่ที่ใช้คือ User ระดับธรรมดา ดังนั้นวิธีการที่ซับซ้อนขึ้นไม่จำเป็นต้องให้เห็นง่ายๆก็ได้ ให้อยู่ในที่ๆ Advance User จะสามารถเข้าถึงได้ก็พอ เช่น การเข้าไปอ่าน Help และ Tips ในการ Search เป็นต้น
แนวทางการออกแบบสินค้านั้น จะถูกคิดทุกๆสัดส่วน ไม่ใช่คิดว่าแค่สวยดี แต่ได้รับการคิดเป็นอย่างดีว่าตำแหน่งปุ่มอยู่ตรงนี้เพราะอะไร ตำแหน่งของเมนูอยู่ตรงนี้เพื่ออะไร จะมีคนใช้งานหรือไม่ ไม่ใช่แค่คิดว่าสวยดี เจ๋งดี เท่ห์ดีก็พอ แต่ต้องคิดถึงการใช้งานที่เข้าใจได้ง่าย ใช้ได้ง่าย เป็นหลัก
Information Architect
ปัจจุบันตำแหน่งงาน Information Architect (IA) เริ่มมีความสำคัญมากขึ้น ในต่างประเทศเองตำแหน่งนี้มีความสำคัญมากๆ และเป็นเบื้องหลังของความสำเร็จของสินค้ายอดนิยมในปัจจุบันอย่าง iPod, Google, YouTube, Digg, etc.
IA มีหน้าที่ดูแลเรื่องคิดหาวิธีการที่จะทำให้ User Interface นั้นใช้การได้ง่าย เข้าใจได้ง่าย มีโครงสร้างที่ดี จะต้องคิดหาวิธีการที่ง่ายที่สุดที่จะใช้งาน
ตำแหน่งงาน IA สามารถมาจาก Programmer หรือ Communication Art ก็ได้ ปัจจุบันในไทยมีมหาลัยที่เปิดสอนด้านนี้โดยเฉพาะอยู่เช่นกัน ซึ่งที่เมืองนอกตำแหน่งนี้ได้รับความสำคัญมาก รวมถึงที่ประเทศไทยที่เริ่มให้ความสำคัญขึ้น ลองศึกษาดูนะครับ เป็นทางเลือกให้ตัวเองมากขึ้น
Web site แนะนำ
http://www.informationarchitects.jp/
http://www.usabilityprofessionals.org/
http://my.opera.com/usability/blog/
http://en.wikipedia.org/wiki/Usability
ใครว่า LAMP ทำ app ระดับ enterprise ไม่ได้
Posted by , Jul 24 2006, 11:10 AM in Technology
เมื่อวันศุกร์ที่แล้ว (21 july 06) ผมเข้า digg.com ตามปกติเพื่อติดตามข่าวสาร พบว่า digg.com ปิด site เพื่อ upgrade ระบบอยู่ โดยหน้าที่ปิด digg.com ก็แนะนำ website ที่น่าสนใจ 5-6 web sites เพื่อฆ่าเวลาระหว่างที่ digg.com ปิด และด้านท้ายของหน้าก็มี technology ที่ digg ใช้ อันได้แก่ PHP และ MySQL ทำให้ผมค่อนข้างสนใจว่า web site ที่มี load มากขนาดนี้ใช้ PHP และ MySQL เลยลองไปศึกษาดูว่าเขามี configuration อย่างไร และทำอย่างไรให้ลองรับ load มากๆได้
หลังจากทำ research อยู่ วันสองวัน ยิ่งทำให้แปลกใจว่า web ขนาดใหญ่ปัจจุบัน ไม่ว่าจะเป็น Flickr, Digg, Yahoo, Wikipedia, delicious, Technorati ใช้ LAMP(Linux, Apache, Mysql, Php) กันหมด น่าสนใจจริงๆ และพอรู้จำนวนเครื่องที่ digg ใช้ ยิ่งน่าสนใจหนักเข้าไปใหญ่คือ digg มี webserver front end เพียงแค่ 3 ตัว และ database อีกเครื่องเล็กๆ 8 ตัว เป็น architecture ที่น่าสนใจจริงๆ
เท่าที่ศึกษาเข้าใจได้ว่า PHP เองนั้น มี performance ที่สูงมากหาก configuration ดีๆ ที่มีปัญหาจริงๆคือ database คือ MySQL ต่างหาก ซึ่งจุดนี้ digg จะใช้ MCache และ APC PHP accelerator platform ช่วย นอกจากนั้นผมได้รู้จัก PHP Framework ที่น่าสนใจคือ WASP ซึ่งเป็น PHP MVC Framework ต้องลองศึกษาเสียหน่อยแล้ว
เท่าที่ดูเป็น configuration ที่น่าสนใจจริงๆ ไว้ศึกษาได้อะไรเพิ่มเติมจะมา share อีกทีครับ
site references:
http://www.oreillynet.com/onlamp/blog/2006...y_and_perf.html
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
วิธีการ develop software แบบ Extreme Programming
Posted by , Jun 20 2006, 01:03 PM
Extreme Programming Rule & Practices
หลังจากได้ศึกษา Google Development Process มานิดหน่อย ได้รู้ว่าหัวใจหลักของ Google ใช้ XP เป็น process การทำงาน เลยคิดว่าน่าจะศึกษา XP development process แบบจริงๆจังๆสักที ก็เลยลองศึกษาหาข้อมูลดู ซึ่งปกติผมจะทำ short note เอาไว้ด้วย เลยคิดว่าน่าจะเอามาแชร์ซะเลย จะได้มาช่วยกันทำความเข้าใจ แล้วเอามาถกกันนะครับ
หัวใจหลักของ XP มีอยู่ 4 องค์ประกอบได้แก่
Planning
- เขียน User Stories
- ทำ Release Planning เพื่อให้ได้ Schedule
- มี Small Release บ่อยๆ
- แบ่ง project ออกเป็น iterations
- ทำ Iteration Planning ตอนเริ่มทุก iteration
- Move people around
- stand-up meeting ทุกๆวัน
- Fix XP กล้าเปลี่ยน process หากมีปัญหาหรือไม่เข้ากับงาน
- Simplicity พยายามออกแบบระบบที่ง่ายที่สุดที่ทำงานได้
- ใช้ชื่อที่สื่อและง่ายต่อการเข้าใจ System Metaphor
- ใช้ CRC cards สำหรับการ design
- สร้าง spike solution เพื่อลด risk - ทดลองทำ POC เพื่อดูว่าทำได้จริง
- ไม่ใส่ function ที่ยังไม่ต้องการ (added early) - มีเพียง 10% ของสิ่งที่ทำเพิ่มเท่านั้นที่จะถูกใช้จริง ดังนั้นอย่าเสียเวลาไปกับ 90% ที่ไม่ได้ใช้ ให้ concentrate ที่ feature function ปัจจุบันเท่านั้น
- Refactor ทุกๆครั้งเมื่อมีโอกาส
- ต้องมี user อยู่ตลอดเพื่อถามปัญหาได้ทันที always available
- มี standard ที่ตกลงกันในการเขียน code
- เขียน unit test ก่อน
- ใช้ pair programmed ในการเขียน code
- ให้ integrate code ทีละคู่ อย่ารวมทีเดียวหมด และให้ทำบ่อยๆ ให้มากกว่าสัปดาห์ละครั้ง
- Integrate บ่อยๆ - ให้ release code ขึ้น repository ให้บ่อยที่สุด ทุกๆ 2-3 ชม.
- ใช้ Collective Code Ownership ทุกคนใช้ code ร่วมกัน สามารถแก้ code คนอื่นเพื่อแก้ bug และ refactor ได้
- ปล่อย optimization ไว้สุดท้าย - Make it work, Make it right, then make it fast
- ไม่ทำ overtime - ให้ใช้ release planning meeting แก้ project scope หรือ timing แทน การเพิ่มคนก็ไม่ช่วยให้ดีขึ้นหากเมื่อ project เริ่ม late แล้ว
- ทุกๆ code ต้องมี unit test
- ทุกๆ code ต้องผ่าน unit test ก่อนจะ release
- เมื่อเจอ bug ให้สร้าง test case สำหรับ case นี้ทันที
- ทำ Acceptance Test บ่อยๆ และมีการ publish ผลที่ได้
User Strories
- จุดประสงค์คล้ายกับ Use case
- เขียนโดยลูกค้า ว่าระบบต้องทำอะไรให้แก่เขาได้บ้าง (output ของระบบโดยรวม)
- คล้ายกับ Usage Scenarios แต่ไม่ได้จำกัดแค่เรื่อง UI
- อยู่ใน format ของ three sentences โดยไม่มี technology เข้ามาเกี่ยวข้อง
- User stories จะช่วยในการสร้าง Acceptance Test
- User stories ต่างจาก requirements specification ตรงที่มันมีรายละเอียดน้อยกว่า โดยให้รายละเอียดเพียงพอที่จะ estimate ได้ว่าเรื่องราวทั้งหมดจะใช้เวลาทำเท่าไร
- หลังจากได้วันแล้วก็จะไปคุยกับลูกค้า หน้าต่อหน้า เพื่อให้ได้ข้อมูลรายละเอียดเพิ่มเติม
- Developers จะทำการกะระยะเวลาพัฒนาในแต่ละเรื่อง (Story) โดยแต่ละเรื่องอาจจะใช้เวลา 1, 2 หรือ 3 สัปดาห์ เป็น "Ideal development time"
- หาก story ใดใช้เวลามากกว่า 3 weeks ควรจะแตกออกเป็น story ย่อยๆ ให้ได้
- หากใช้เวลาน้อยกว่า 1 week แสดงว่าลง detail มากเกินไป
- User stories ประมาณ 80 story +-20 เป็นเลขที่ดีที่สุดสำหรับทำเป็น release plan
- สิ่งที่แตกต่างระหว่าง stories และ requirement doc. อีกอย่างคือ จะ focus ที่ความต้องการของ user เป็นหลัก และต้องพยายามหลีกเลี่ยงการระบุถึง technology, database, algorithms และ Focus ตรงที่ความต้องการ user มากกว่าจะเป็น UI layout
- มี meeting เพื่อทำ release plan ซึ่งกำหนดภาพรวมของ project และจะนำมาใช้ทำ iteration plan
- กำหนดวันที่ทุกคนสามารถ commit ได้ ต้องได้รับการตัดสินใจจากทั้งฝั่ง techical และ business
- ทำการประเมิณ user story แต่ละเรื่อง เพื่อกำหนดเป็น ideal programming weeks โดยแต่ละ ideal programming week หมายถึงทำงานนั้นงานเดียวไม่มีเรื่องอื่นมากวน แต่ต้องรวม testing แล้วด้วย แล้ว business ทำการตัดสินใจว่า story ไหนสำคัญกว่า story ไหน
- business และ developer ร่วมกันกำหนด release แรกว่าจะมี story ใดบ้าง
- ให้ทำการ deliver ระบบที่ใช้งานได้หรือ test ได้ตรงตาม business อยู่เรื่อยๆเพื่อรับ requirement ใหม่และปรับปรุงระบบให้ดีตลอดเวลา
- ห้ามลดเวลาการทำงานเด็ดขาด หาก plan ไม่ได้ตามที่ management ต้องการ แต่ให้ทำการ negotiate ตัว release plan แทน
- release plan ที่ดีขึ้นอยู่กับ Scope, Resource, Time, Quality ฝ่ายบริหารสามารถเลือกได้แค่ 3 ตัวจาก 4 เท่านั้น
- scope คือจำนวนงานที่จะเสร็จ
- resource คือคนที่จะทำ
- time คือเวลาที่ใช้ release
- quality คือคุณภาพของ software ที่ได้รับการ test อย่างดี
- release plan คือการกำหนดว่าแต่ละ user stories ที่จะถูก implement จะ release วันไหนและ release ไหน
- Stories จะถูกทำเป็น acceptance test ในแต่ละ iteration เพื่อให้แน่ใจว่าแต่ละ iteration ทำงานได้ถูกต้อง
- project velocity คือวิธีการตรวจวัดความคืบหน้าของ project
- โดยทำการประเมิณ user stories ที่จะเสร็จในแต่ละ iteration
- รวมผลการประเมิณ task ที่เสร็จในแต่ละ iteration plan
- ในแต่ละ iteration planning ลูกค้าสามารถเลือก user stories จำนวนเท่ากับ iteration ที่แล้วก่อน แล้วหลังจากประเมิณ task ของ iteration แล้วหากเกินค่อยปรับเปลี่ยน
- ให้ทำการ re-estimate และ re-negotiate ใน release plan หาก project velocity มีการเปลี่ยนแปลง
- ไม่ต้องเสียเวลาหาร project velocity ด้วยระยะเวลาของ iteration หรือจำนวนของคน เพราะแต่ละ project มีคุณลักษณะไม่เหมือนกัน แต่ให้ดูที่จำนวนของงานที่เสร็จในแต่ละ iteration เป็นสำคัญ
- การรวบรวมข้อมูลให้มากที่สุดตั้งแต่ต้นไม่ช่วยอะไร เพราะมันเป็นแค่การเดา ให้ทำการ estimate overall project ดีกว่า
- Iterative Development ช่วยเพิ่มความเร็วในการพัฒนาระบบ
- โดยแบ่งเวลาการพัฒนาเป็น 1-3 week โดยต้องพยายามให้ไม่เกินเด็ดขาด เพราะเป็นการ measuring progress ของ plan ของระบบในxp
- ห้าม schedule ตัว programming task ก่อนเด็ดขาด ให้ทำ iteration plan ก่อนเริ่ม iteration นั่นๆเสมอ (Just-in-time planing)
- ห้าม implement อะไรก็ตามที่อยู่นอกเหนือ iteration เด็ดขาด ไม่ต้องเผื่ออนาคต เพราะมันอาจจะไม่เคยได้ใช้ ถ้าต้องใช้ค่อยทำ หากต้องทำการ redesign ก็ต้องทำ ไม่ต้องทำเผื่อก่อน
- กำหนด deadline ของ iteration seriously! พยายาม track งานภายใน iteration และหากมีแนวโน้มว่าจะไม่เสร็จ ให้ทำการเรียกประชุม iteration planning ใหม่ กำหนดเวลาใหม่ หรือทำการย้าย task ไปก่อน
- เน้นไปที่ task ที่มี priority สูงที่ได้จาก user ก่อนเป็นหลัก
- Iteration Planning เป็น meeting ที่มีทุกครั้งก่อนเริ่มแต่ละ iteration
- เลือก user stories ที่จะนำมาทำ จาก release plan โดย customer เอง โดยดูจากความสำคัญเป็นหลัก
- Feature ที่ Fail จากการทำ acceptance tests ให้นำมาเลือก fix ในคร่าวนี้ด้วย
- user stories และ failed test จะถูกมาแตกย่อยเป็น programming task
- user stories เป็นภาษาของ user แต่ programming task เป็นภาษาของ developer
- Developer สมัครใจทำ task และ estimate เวลาที่จะใช้ทำ
- แต่ละ task ควรกำหนดเป็น 1,2, หรือ 3 ideal programming days (ไม่มีอะไรมาแทรก)
- Task ที่เกิน 3 วันควรแตกเป็น task ย่อย
- ให้นำวันที่ได้มารวม หากวันที่ได้มากกว่า iteration ที่แล้ว customer จะต้องเลือก user stories ที่จะเอาออกไป (snow plowing) แต่หากได้วันน้อยกว่า iteration ที่แล้ว สามารถเพิ่ม story ได้
- ห้ามเพิ่มหรือ design เผื่อเด็ดขาก ให้ใช้วิธีก refactoring
- ห้ามต่อเวลา task หรือ story estimate เด็ดขาด
- Class, Responsibilities, and Collaboration
- ทุกๆคนในทีมมีส่วนร่วมในการ design
- แต่ละ CRC card แสดงถึง Object
- Class ของ object เขียนบนหัวของ card
- Responsibilities ของ class ให้ list ลงมาด้านซ้าย
- Collaborating classes ให้ list ลงมาด้านขวา ข้างๆ Responsibilities
- แต่ทางปฏิบัติอาจจะเขียนแค่ชื่อ Class เท่านั้น
- CRC session เริ่มจากมีคนต้องการจำลองการทำงานของระบบ โดยดูจากการส่ง message หากันระหว่าง object
- หากมีจำนวนคนพูดมากเกินหรือมีคนพยายามย้าย card ตลอดเวลา ให้จำกัดคนที่จะขึ้นพูดหรือย้าย card
- เป็น POC เพื่อทดสอบแนวคิดการแก้ปัญหา และปัญหาด้านการ design
- เป็นเพียงโปรแกรมง่ายๆที่ใช้ทดสอบ expect ว่าจะทิ้งไปไม่ได้ใช้ แค่ทดลอง
- ใช้เพื่อ estimate user story ได้แม่นยำขึ้น
- ปรับโครงสร้าง ลบสิ่งที่ไม่จำเป็น แก้ไขตัวแปร รวมสิ่งต่างๆเข้าด้วยกัน
- keep design simple as you can
- พยายามทำ code ให้สะอาด เข้าใจง่าย แก้ไขง่าย และต่อเติมได้ง่าย
- ยากที่จะปฏิบัติช่วงแรก เนื่องจากเริ่มต้นเรามักมี design ในใจที่ดีอยู่แล้ว แต่ต้องปล่อยมันไป ให้ทำเท่าที่จะสามารถทำให้ระบบทำงานได้ตอนนี้ แล้วค่อยมา refactor ที่หลังเพราะการ refactor ที่หลังจะดีกว่าที่คิดไว้ตอนแรกแน่นอน (เข้าหลักอย่าเผื่อไว้ก่อน เพราะจะไม่ได้ใช้ หรือไม่ก็อนาคตจะมีสิ่งที่ดีกว่า)
quantity
- Code ที่ถูกเขียนควรเกิดจากคน 2 คนช่วยกันเขียนขึ้นมา
- คน 2 คนใช้ คอมพิวเตอร์เครื่องเดียวกัน จะได้ปริมาณเท่ากับแยกกันทำ แต่ได้คุณภาพที่ดีกว่าเสมอ ท้าพิสูจน์ เหตุผลเพราะ code ที่คุณภาพดีจะทำให้งานทำได้เร็วขึ้นนั่นเอง
- คน 2 คนช่วยกันทำ สามารถแลกเปลี่ยน keyboard และ mouse กันได้ โดยคนนึ่งคิดและพิมพ์ อีกคนจะคิดถึง design ว่าอะไรควรอยู่ตรงไหน ควรจะปรับอย่างไรให้เข้าใจง่าย
- ส่งเสริมให้ทุกๆคนมีส่วนร่วมกับ idea ใหม่ๆในทุกๆส่วนของ project
- ทุกคนใช้ code ร่วมกัน สามารถแก้ code คนอื่นเพื่อแก้ bug และ refactor ได้
- ทุกๆ developer สร้าง unit test สำหรับ code ตัวเอง
- source code เวลาขึ้น repository ต้องมี unit test
- code ที่จะขึ้น repository ต้องผ่าน unit test 100% เท่านั้น
http://www.extremeprogramming.org
http://www.xprogramming.com
http://www.methodsandtools.com
ผมกำลังคิดที่จะนำ XP development Process มาใช้กับการทำงานจริงในโครงการใหม่ที่จะถึงนี้ และนี่เป็นแค่ Part I ยังอีกยาวครับ ลองติดตามกันดูนะครับ
กระบวนการพัฒนาระบบของ Google
Posted by , Jun 2 2006, 02:57 PM
Idea กว้างๆ
1. มีแค่ 1 code base ทุกๆคนมีสิทธิที่จะเข้ามาแก้ไข code เพียงแค่ register เข้าระบบ ใครสร้าง library อะไรก็เอาขึ้นไป อยากได้ library อะไรก็ search หาดูใน code base บนนั้นจะมีทั้ง source code และ document พร้อม
2. เปลี่ยนทีมได้ง่าย ตามความสนใจของตน หากเบื่องานนี้ก็สามารถไป lookup หา project ที่สนใจ แล้วขอร่วม join ได้ แต่ต้องผ่านการสัมภาษณ์และ HR ก่อน ใช้วิธีการประกาศหางานใน Internal ก่อน
3. ทีมจะแชร์ totally share ข้อมูลของ project ของตนที่ดูอยู่ภายในบริษัท ทั้ง tech talks, design docs, lunch table conversation เพื่อแชร์ความรู้และข้อมูลให้แก่กัน หากมี project 2 projects ใกล้เคียงกันเกิดขึ้นจะไม่มีการ push ให้รวมทีม แต่จะให้แข่งกัน เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด There isn't only one solution for each problem
4. 20% ของเวลางานจะใช้เพื่อวิจัย project ส่วนตัว
5. ไม่มีการปิดกั้น idea หากมี idea ใหม่ๆ ทุกๆคนจะตื่นเต้นกับมันและช่วยกัน brainstrom ไม่มีการหวงว่าเป็น area ของใคร แต่ยินดีรับ idea ใหม่ๆ จากคนอื่นๆเสมอ
วิธีการทำงาน
องกรค์เป็นแบบ Flat มากๆ โดย engineer แต่ละคนต้องดูแลและรับผิดชอบตัวเอง ตั้ง goal ของตัวเอง
มีมาตรฐานของสไตล์การเขียน code ทุกๆคนต้องผ่านการ train ตรงนี้ก่อน code จะต้องผ่านการ review ว่าเขียนถูกต้องตามสไตล์กลาง ก่อนจะเข้า code base จะต้องมี design document เสมอ ไม่ว่าจะเป็น project เล็กแค่ไหน และจะมีคนคอยตรวจดู format ของ document ว่าถูกต้องหรือไม่ งานทุกชิ้นที่ขึ้น codebase กลางต้องมีคุณภาพตามมาตรฐาน process เหล่านี้ทำให้ช้าอยู่บ้าง แต่แลกกับคุณภาพที่ดีของงานแล้วคุ้มค่ามาก
Google ใช้ XP ในการพัฒนา Software แต่ไม่ได้บังคับว่าต้องเป็น XP แต่แนวโน้มแล้วส่วนใหญ่ project ต่างๆจะใช้ XP
มี Fix-it week เพื่อทำการ fix bug ที่ได้จากการ test มีทำ functional test ทำ unit test ในระดับที่ลองแกล้งใส่ข้อมูลผิดๆใน DB ระบบต้องรองรับได้ในทุกๆกรณี
ระบบของ Google จะเขียน Log เป็นจำนวนมาก แล้วใช้ Tool นำ log ไปประมวลผล มีการใช้ Rule Base และมีการแยก Exception ออกจาก log ปกติ หากพบ Exception จะถูก Report ไปที่ Engineer ที่ดูแลทันทีเพื่อวิเคราะห์ปัญหา
Philosophy ของ Google
- Google believes that great code comes from happy engineers.
- Smart people + creative environment + outlet for ideas = innovation
- User-centered design means building products that people really want and start with users’ needs and desires for designing products and services.
- Accept Ideas From Everywhere -> Prioritization into Top 100 List
- Small, Agile Engineering Teams
- Self-organization and Visibility
- Good quality by itself improves usag
- If we have a good idea, try it
ตัวอย่างการเกิด product ของ Google
- Google News was result of watching engineering email (one employee wrote the demo after being frustrated trying to read news after Sept 11 event.
- Started as a demo created by one engineer on a weekend
- Googlers started to use it to read their news
- Then assigned 3 people (one was UI designer) and one PM to work on it
- Iteration example
- Original: all news on one screen
- Pre-release:
- break into sections with a “google” look and feel
- lots of mock-ups of the layout
- User interface testing (user studies); Asked “Go to Entertainment Page” but users couldn’t find their way around – poor navigation
- Next iteration: Didn’t make it to user studies because Googlers hated it
- Next iteration: Finally got to put something on the public site, but
found users not using the navigation bar at all - Next iteration: simplified navigation and moved it
- They use “test marketing” techniques where they try two styles when they
http://www.eightypercent.net/Archive/2005/03/24.html
http://www.geekswithblogs.net/srkprasad/ar...2/03/16712.aspx
http://evelynrodriguez.typepad.com/crossro...tDevProcess.pdf
on เจาะลึกขั้นตอนการ login ของ yahoo (Archive)