วันจันทร์ที่ 22 พฤศจิกายน พ.ศ. 2553

กรอบงานของกระบวนการ (A Process Framework)

 - กรอบงานของกระบวนการ เป็นพื้นฐานสาคัญของกระบวนการทาง
ซอฟต์แวร์ กรอบงานจะแยกออกได้เป็น กิจกรรมกรอบงาน (Framework
Activity)
- กรอบงานของกระบวนการยังครอบคลุม กิจกรรมที่ใช้ได้กับกระบวนการทาง
ซอฟต์แวร์ เรียกว่า ชุดกิจกรรมร่วม (Umbrella Activities)

 ขอขอบคุณ www.chanin.utc.ac.th ที่ให้ความรู้ใน chapter2

วันพฤหัสบดีที่ 4 พฤศจิกายน พ.ศ. 2553

SCRUM MODEL


 

                     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 ยาวๆ แต่พักสั้นๆ

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 ส่วนหลักๆ ได้แก่
              
1 Backlogเป็นรายการของ feature ที่ต้องทำ คำว่า feature นี้รวมถึง request จากลูกค้า bug fix และ specification ของตัว product โดยคนทำคือ product owner ซึ่งจะจัดลำดับ feature ตามความสำคัญ จัด list เพื่อนำเข้า sprint และจัดการกับรายละเอียดต่างๆของ feature เช่นต้องจัดทำ user story สำหรับแต่ละ feature เป็นต้น

               2 Sprint phase
คือช่วง iteration นั่นเอง โดยมีกำหนดไม่เกิน 30 วัน ซึ่งก่อนเริ่ม sprint ก็จะมีการนำ product backlog มาจัดลำดับความสำคัญเพื่อเลือกมาเป็น sprint backlog จากนั้น scrum team จะดู backlog และแตกเป็น task ย่อยๆออกมาและทำการ estimate เวลาที่ใช้ในแต่ละ task หลังจากได้เวลาและต่อรองกันระหว่างทีมงานแล้ว ก็จะได้ list ของ task และ list ของ backlog ที่จะทำภายใน sprint ขึ้นมา

               3 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 ได้ดี
ขอขอบคุณ
http://www.rephoenix.net

ที่แบ่งปันความรู้ครับ