• คุม Spec ให้นิ่ง Requirement ไม่เปลี่ยน (เป็นไปไม่ได้)
• กำหนดระยะเวลาเสร็จที่แน่นอนให้ได้ เพื่อจะได้เอาไปบอกลูกค้าได้ถูก (อันนี้ไม่ว่าจะ plan แบบไหนก็คือการเดาด้วยกันทั้งสิ้น)
• ถ้า Requirement เปลี่ยน ต้องแก้ให้ทันตามที่ลูกค้าต้องการ (ถ้ารับเละ ไม่ดูแรงของทีมงานก็ตายสถานเดียวครับ)

เป็นต้น ซึ่งถ้าทีมงานหรือบริษัทของคุณไม่ได้เป็นบริษัทขนาดใหญ่ (ทีม Programmer 1 ทีมใหญ่กว่า 3 คน) ก็คงไม่ค่อยเห็นภาพอะไรนัก เนื่องจากคนน้อย การบริหารจัดการก็คือการคุยกันเรื่อยๆ เป็นระยะๆ จะดีที่สุดนั่นเอง แต่แม้คนจะน้อย Agile ก็จะช่วยจัดการจัดสรรปันส่วนงานต่างๆ ให้เป็นระเบียบขึ้น ง่ายต่อการเห็นภาพรวมของ project มากขึ้น เรามาดูขั้นตอนการทำงานแบบ Agile กันดีกว่า โดยทีมงานจะแบ่งเป็นสองตำแหน่งหลักคือ Product Owner (คนที่คุยกับลูกค้า รู้ว่าลูกค้าต้องการอะไร) และ Programmer มีขั้นตอนทำงานดังนี้ (ผมจะเขียนเน้นไปทาง Practice ของ Scrum นะครับ แต่ขั้นตอนการสร้าง card จะคล้ายๆ กันหมด)

1. Product Owner ไปคุยกับลูกค้า แล้วมาขายฝันให้ทีมว่าจะมีโปรเจคนี้ๆ ลูกค้าอยากได้อะไรบ้าง โดยสมมติว่าลูกค้าอยากให้เราเขียนระบบ Forum ของเว็บไซต์ของเขา
2. Product Owner เขียนสรุป Requirement ออกมาเป็น User Story ในรูปแบบ Card 1 Story ต่อ 1 Card ซึ่งมี template ของ Story คือ ”As a <role>, I want <goal/desire>” เช่น “ในฐานะ guest ต้องดู forum ได้”, “ในฐานะ member ต้องตั้งกระทู้ใหม่ได้” ซึ่งการสร้างแต่ละ Story ควรจะรู้ด้วยว่าทำไปเพื่ออะไร (ไม่งั้นก็ทำฟรี ไม่มีประโยชน์) ตรงนี้ต้องระวังว่าห้ามเขียนเป็นรูปของ Task เช่น setup database, เขียน function a() ต้องเป็น story ที่ลูกค้าอ่านเข้าใจ และถ้าเสร็จออกมาให้ทดลองใช้แล้วลูกค้าจะได้ประโยชน์อย่างชัดเจน (เช่นเขียนว่าระบบค้นหากระทู้ ไม่ใช่ function search)
3. เมื่อสรุปเสร็จทั้งหมด Product Owner ก็จะเรียงลำดับความสำคัญของ Feature ที่ลูกค้าอยากเห็นก่อน-หลัง ซึ่ง story ไหนที่เป็นฐานในการทำ Story ถัดไปควรจะมาก่อน Story ที่ต้องต่อยอดจาก story นั้นๆ รวมไปถึง Feature ที่มีโอกาสเปลี่ยนแปลงสูงก็ควรจะอยู่หลังๆ ด้วย (เผื่อลูกค้าเปลี่ยนใจจะได้เสียหายน้อยที่สุด)
4. แต่ละ Story Product Owner จะต้องเขียน Exit Criteria เพื่อสรุปว่าจากหน้าจอของผู้ใช้ที่เกี่ยวข้องกับ story นี้ เช่น คลิกปุ่มที่หนึ่งจะต้องไปหน้าไหน search ชื่อได้, search topic ได้, ถ้าไม่พิมพ์เลยต้องแสดง error เป็นต้น ทั้งหมดนี้แยกมาเป็นข้อๆ ซึ่งสำหรับโปรแกรมเมอร์แล้วจะเหมือนได้ Test Case มาโดยอัตโนมัติเอาไปทำ TDD ต่อได้ง่ายขึ้นมากเลยทีเดียว (มีคนคิดมาให้แล้วนั่นเอง) แต่ถ้า story ไหนยังไม่แน่นอน เผื่อเปลี่ยนทีหลังก็ยังไม่ต้องเขียน Exit Criteria (ในที่นี่สมมติว่า Product Owner คือ Tester ในคนเดียวกันนะครับ)
5. นำ Story Card ที่พร้อมแล้วมาวางเรียงบนโต๊ะ ประชุมร่วมกับทีม Programmer ว่าแต่ละหัวข้อควรจะให้คะแนนความยาก (Story Point) เท่าไหร่ดี โดยมีคะแนนตั้งแต่ 1,2,3,5,8,13,… เป็น Fibbonanci ซึ่งทุกคนจะโหวตแต่ละ Card พร้อมกันว่าได้เท่าไหร่ โดยอาศัยการเปรียบเทียบกันเองระหว่าง story ที่วางอยู่ด้วยกัน ซึ่งจะทำได้ง่ายกว่าประมาณด้วยเวลามาก (แต่ละคนไม่มีทางประมาณเวลาที่ใช้ทำออกมาได้ตรงกันหรอก จริงไหม? แต่ถ้าเป็นการเทียบความยากกันเอง จะได้ข้อสรุปง่ายกว่ามาก) แล้วมาดูกันว่าคะแนนต่างกันมากไหม หากแต่ละคนให้คะแนนต่างกันมากก็ต้องคุยกันว่าทำไมจึงให้แบบนั้น (เป็นสัญญาณว่าเกิดความเข้าใจไม่ตรงกันของคนในทีม รีบทำความเข้าใจให้ตรงกันซะ!) แล้วโหวตใหม่ จนกว่าจะได้คะแนนเท่ากันหมด ขั้นตอนนี้เรียกว่า Planning Poker ครับ ตรงนี้ Story Point ไม่ใช่เวลาที่จะทำเสร็จนะครับ มันคือค่าความยาก(หรือความเสี่ยง) ของงานแต่ละอย่าง ยิ่งเลขมาก จะยิ่งยากขึ้นมากตาม ซึ่งถ้าเลขเยอะมากๆ ควรจะแตก Story ออกให้เล็กลงเป็น Card 2 ใบครับ และแน่นอนว่าควรแตกเฉพาะอันที่ Requirement ไม่เปลี่ยนแน่ๆ แล้ว
6. นำ Story Point ของ Card ทั้งหมดมาบวกรวมกันก็จะได้ค่าความยากของ Project นี้ ทีนี้ละครับเราก็จะได้ Estimate ของเวลาการทำงานออกมาแล้ว โดยเทียบกับ project เก่าๆ เอาเช่น project a มี story point 30, project b มี story point 50 project b น่าจะใช้เวลาทำนานกว่าแน่ๆ และจากค่าเฉลี่ยของการทำงานที่ผ่านมา ทีมของเราทำงานได้ 5 point ต่อ 1 สัปดาห์ ดังนั้นน่าจะใช้เวลาใน project b ทั้งสิ้น 10 สัปดาห์ (ต้องไม่ลืมว่าทั้งหมดนี้คือการเดาครับ 55 แต่เป็นการเดาแบบมีหลักการมากขึ้น) ซึ่งเวลานี้ต้องไม่ลืมว่ามันคือ Speed ของทีมที่ทำทีมเดียว ไม่สามารถสรุปได้ว่าอีกทีมเข้ามาทำจะใช้เวลาในการทำเท่ากัน
7. เริ่มแบ่งงานออกเป็นรอบๆ ซึ่งถ้าเป็น Scrum จะเรียกว่า Sprint ส่วนใหญ่จะอยู่ที่ 1-2 อาทิตย์ต่อ Sprint ถ้าเป็น Agile Practice อื่นก็จะแตกต่างกันไปว่าจะแบ่งรอบการทำงานเป็นอย่างไร โดย Story ที่ลูกค้ายังเอาแน่กับชีวิตไม่ได้ เราก็ทิ้งไว้ก่อนถูกไหมครับ(แต่เราขึ้น Story ไว้แล้ว ให้คะแนนเยอะเวอร์ๆ ไปก่อน) ซึ่งเราจะแตก Story ที่มี Story Point เยอะๆ ในงานรอบแรกๆ ก่อน ยังไม่ต้องทำทุก Story เพราะ เดี๋ยว Story หลังๆ ทำไปเดี๋ยวมันก็เปลี่ยน จะทำค่อยแตก Story ทีเดียวดีกว่า
8. ทีม Programmer ลงมือทำตาม Story Card โดยใครอยากหยิบอันไหนใน Sprint นั้นๆ มาทำก่อนก็ตามใจ หรือจะคุยกันเองว่าให้ Senior ทำอันยาก Junior ทำอันง่ายก็ว่ากันไป ย้าย Card จากช่อง Backlog ไปช่อง Doing พอทำเสร็จก็ย้าย Card จากช่อง Doing ไป Done เป็นต้น
9. สำคัญมากคือต้องคุยกันในทีมว่าก่อนจะย้ายเข้า Done นั้นคือต้องทำ อะไรเสร็จแล้ว (Definition of Done) เช่น ต้อง Test เสร็จก่อนถึงจะย้ายเข้า Done ถ้ายังไม่ Test ถือว่างานยังไม่เสร็จ ห้ามย้ายเข้า Done เด็ดขาด เป็นต้น
10. เมื่อทำจบหนึ่ง Sprint ก็มาลองวิเคราะห์กันดูในทีมว่าทำได้ตามเป้าไหม เกิด Bug ที่ไม่คาดคิดหรือไม่ แล้วจะ Weight อย่างไรระหว่าง Bug ที่เกิดกับงาน Story ในรอบถัดไปที่จ่อคิวอยู่ ตรงนี้ขึ้นกับการตัดสินใจของทีมแล้วครับ ถ้าเกิด Bug นั้นต้องแก้แน่ๆ และสำคัญมาก ทำให้ต้องเลื่อนเวลาการทำงานออกไป ทีมปั่นกันไม่ไหวแน่ๆ ก็ต้องบอกลูกค้าแต่เนิ่นๆ แต่ประชุมหาทางแก้ไขกับลูกค้าเจรจาขอตัด feature หรืออะไรก็ว่าไป ไม่ใช่วันสุดท้ายพึ่งมาบอก แบบนี้ลูกค้าจะเครียดได้ครับ 55
11. วนทำข้อ 8 ไปเรื่อยๆ จนงานเสร็จครับ

อันนี้จริงๆ แล้วถ้าเป็นการวางแผนทั่วๆ ไป คนมักจะวางแผนง่ายๆ ด้วยการ “เผื่อเวลาความไม่แน่นอน” เอาไว้ถูกไหมครับ ซึ่งมักจะเผื่อไว้ครั้งแรกครั้งเดียว แล้วก็มารู้ตัวอีกทีตอนใกล้จะปิดโปรเจคแล้วก็ปั่นไฟลนก้นกันสุดๆ ถ้าทำตามขั้นตอน Agile พวกนี้จะช่วยให้เราประเมินสถานการณ์บนพื้นฐานของความจริงอยู่ตลอดครับ หากเห็นว่าสถานการณ์กำลังแย่ ทำไม่ทันแน่ๆ เราก็จะได้หาทางวางแผนแก้ไขให้ทันท่วงที และเนื่องจากเราทำงานไล่ทำเป็น Story อยู่แล้ว หาก Story ท้ายๆ ไม่มีปัญญาปั่นให้เสร็จจริงๆ อย่างน้อยมันก็คือ Story ที่สำคัญน้อยที่สุดแล้ว ถูกไหมครับ (เราเรียงลำดับความสำคัญไว้แล้วนี่) ความเสียหายที่เกิดจะน้อยที่สุดครับ ดีกว่าทำไอนู่นเสร็จนิด ไอ้นี่เสร็จหน่อย แล้วประกอบออกมาเป็นโปรแกรมไม่สมประกอบ ใช้งานไม่ได้ซักอย่าง นั่นคือหายนะของ Project ที่ไม่ได้วางแผนครับ โชคดีกับการวางแผนการทำงานนะครับทุกคน

แถมท้ายเว็บดีๆ ที่ช่วยในการทำ Story Card ได้อย่างดีเยี่ยมครับ

http://www.trello.com

ที่ชอบอีกอย่างนึงคือ ในสัปดาห์นึงจะมีวันประชุมรวม แล้วให้แต่ละแผนกสลับกันขึ้นมาพูดในที่ประชุม สัปดาห์ละแผนกตรงนี้ส่วนใหญ่จะเป็นให้ความรู้ การแก้ข้อสงสัย หรือนำเสนอแนวคิด ปัญหาที่พบ และทางแก้ต่างๆ ของ IT ก็ไปบอกว่าปัญหาที่เกิดขึ้นทำไมมันเยอะนัก ฝีมือข้าำพเจ้าเองแหละ 55+

ก็หวังว่าจะปิดงานได้ภายใน 3 สัปดาห์นี้ คงไม่มีปัญหาอะไรนะเออ

ปล. แอร์หนาวมาก

บทความนี้เหมาะกับ : บุคคลที่ต้องการกระตุ้นตัวเองในการทำงาน เช่น นิสิตที่ปั่นโปรเจคจบ , Freelance , กิจการส่วนตัว หรือ พนักงานบริษัทที่ต้องการความก้าวหน้าในงาน

คุณเคยประสบปัญหาอย่างนี้ใช่หรือไม่!

- ทำงานไปอู้ไป วัดผลอะไรไม่ได้!

- ไม่รู้ว่าเราใช้เวลาไปเท่าไรกับการทำงานแต่ละประเภท! กะเวลาไม่ถูกว่างานจะเสร็จเมื่อไหร!

- ขาดแรงกระตุ้นในการทำงาน! ขาดตัววัดผลว่าเราขยันแค่ไหน!

- รวมทั้ง คุณหัวหน้าที่อยากรู้ว่าลูกน้องของคุณวันๆทำอะไรกันบ้าง!

วันนี้เราขอเสนอเครื่องมือที่จะช่วยให้ท่านสามารถวัดผลการทำงานของคุณเองได้อย่างไม่ยากเย็น ซึ่งเชื่อว่าจะส่งผลให้คุณสามารถปิดงานของคุณได้อย่างมีประสิทธิภาพมากขึ้น

Rescue Time

https://www.rescuetime.com

แล้วมันทำงานยังไง?

หลักการง่ายๆของ Rescue Time คือ โปรแกรมนี้จะจับเวลาการทำงานของคุณ และคอยติดตามดูว่าคุณทำงานได้ตามที่ตั้งเป้าหมายแล้วหรือยัง? โดยนอกจากนี้ Rescue Time ยังมี Feature ที่ช่วยให้เรามีสมาธิในการทำงานมากขึ้นด้วย!

Focus!!

ระบบจะปิดกั้นการเข้าเวปที่ถูกมองว่ารบกวนการทำงานของคุณ! เหมาะกับเวลาที่ต้องการปั่นงาน มากๆ โดยสามารถเลือกว่าจะยอมแพ้ (สั่งปิด Focus mode ได้) หรือห้ามยอมจนกว่าจะถึงเวลา  โอ้ววว สู้เค้านะทาเคชิ!

Tracking!

ตามติดการทำงานของคุณ! โดยสามารถตรวจสอบเวลาการใช้โปรแกรมต่างๆบนเครื่องของคุณอย่างแม่นยำ เช่นตัวอย่างด้านบน จะบันทึกว่าเข้าเวป Google Analytic แต่ไม่บันทึกว่ากำลังทำ Draft proposal อยู่ ! เลิกหลอกตัวเองได้เลย!

Powerful Report!

เมื่อตามเก็บข้อมูลมาแล้ว ไม่ว่าจะเป็นการเข้าเว็ปต่างๆ และการเปิดโปรแกรมทำงาน ก็สามารถกลับมาดูได้ว่า แต่ละช่วงเวลาเรา (ลูกน้อง) ทำงานกันเป็นยังไงบ้าง แอบเล่นเกม เข้าเวปอะไรช่วงไหนกันบ้าง หึหึหึ ทีนี้เราก็รู้สาเหตุแล้วว่าทำไมงานมันไม่เดินซักที!!

Powerful Group Tools for Business Time Management, Business Intelligence & More!

ประโยชน์ที่จะได้รับจากการใช้ Rescue Time

• ระบบมีความยืดหยุ่นทำให้สามารถปรับเข้ากับวัฒนธรรมการทำงานของทีมได้เป็ฯอย่างดี
• สรุปข้อมูลการทำงาน เพื่อนำมาวิเคราะห์หาทางการปรับปรุงการทำงานได้มากขึ้น
• สามารถเชื่อมต่อกับระบบการทำงานปัจจุบันที่มีอยู่แล้วได้ดี (เข้าบอกว่า API เค้าเจ๋ง)
• ประสิทธิภาพการทำงานเพิ่มขึ้นประมาณ 9% โดยไม่ต้องเพิ่มเวลาการทำงาน (แต่สำหรับคนขี้เกียจนี่อาจจะได้หลายเท่า )

ปัจจุบันมี Plan ต่างๆ ทั้ง Free (ตัด Feature Focus + ดูข้อมูลย้อนหลังออก) / Pro (เดือนละ 3-8$) / Bussiness / School

สามารถเข้าไปดูรายละเอียดเพิ่มเติมได้ที่ http://www.rescuetime.com/tour ครับ ที่สำคัญมันมีทั้ง version Windows/Mac นี่แหละ เยี่ยม!

Happy working :-D!!