Agile,Scrum

Certified ScrumMaster Day 1/3 : Part 2/3

หลังจาก ที่เราคุยกันเรื่อง CSM Class ในวันแรก ซึ่งส่วนแรกเป็นส่วนของ Introduction to Scrum/Agile พูดถึงประวัติความเป็นมาเล็กน้อย พูดถึง Iterative, Incremental Development และ Timebox รวมไปถึงจุดสำคัญของ Agile Manifesto ไปแล้ว Part 2 เราจะเริ่มที่ Self-Managed ซึ่งเป็นหัวใจหลักอันนึงใน Scrum เลย

#ผมขออนุญาตออกตัวก่อนว่าตัวเองมีความสามารถด้านภาษาอังกฤษน้อยมาก …สิ่งที่เขียนคือสิ่งที่เข้าใจจากการฟังและแปลแบบงู ๆ ปลา ๆ แบบ real time ซึ่งอาจจะมี error ไปบ้าง แต่ก็อยากทบทวนสิ่งที่เข้าใจแล้ว Share กับท่านอื่น ๆ รวมถึงเก็บไว้อ่านทีหลังด้วย จงอย่าเชื่อ#

Self-Managed Team 

เพื่อให้อธิบายความหมายง่าย ๆ ของ Self-Managed Bas เริ่มกิจกรรม เพื่อให้เห็นถึงภาพของ Command & Control โดย ให้ทุกคนจับคู่ มีคนนึงคอยสั่ง อีกคนนึงคอยทำตามคำสั่ง (คนรับคำสั่งห้ามคิดเอง) โดยทุก ๆ คู่มีจุดมุ่งหมายเดียวกัน คือให้ทุกคู่เดินในบริเวณที่กำหนด เวลาที่จำกัดไว้ และมีชุดคำสั่งไม่มากนักที่สามารถสั่งได้ แน่นอนว่าพอสัญญาณเริ่ม ความวุ่นวายก็เกิดขึ้น ปรากฏว่าจนจบ ไม่มีใครสามารถทำจบเป้าหมายได้ เลย … คำถามคือทำไม … ไม่รอช้าปรับกฏใหม่ คราวนี้ไม่ต้องจับคู่ ให้ทุกคนเคลื่อนไหวได้ตามอิสระ บนเป้าหมายเดิม … กลายเป็นทุกคนสามารถทำตามเป้าหมายได้ทั้งหมด (ก่อนเวลาที่กำหนดด้วยสิ) แถมสิ่งที่ได้มามันน่าอัศจรรย์ไม่ใช่มันได้ตามเป้าหมาย แต่มัน … (ทิ้งไว้ให้อยาก) คำถามคือทำไม … ทุกอย่างเหมือนกันหมดมีส่วนแตกต่างกันเรื่อง Managed by another one or Managed by themselves.

Bas บอกเล่าถึงประวัติศาสตร์ของการเกิด Role และการแยก Role เป็น Manager กับ Worker จากยุคปฏิวัติอุตสาหกรรม ซึ่งต้องการขยายการผลิตออกไปมาก ๆ ในต้นทุนที่ถูกที่สุด จึงต้องย้ายฐานการผลิต ไปยังที่ ๆ ค่าแรงต่ำ แต่ก็มีจุดเสียคือการศึกษาน้อย เพราะฉะนั้นการจ้างคนเหล่านี้ (Worker) ให้ทำงานให้จึงเน้นไปที่การมอบหมายงานที่เป็นงานใช้แรงไม่ใช้สมอง และสร้างกลุ่มคนที่ทำหน้าที่คิดวิธีการทำงานให้กับ Worker โดยมองว่าต้องกำหนดวิธีการแบบให้คนที่ไม่รู้อะไรมากก็สามารถเข้ามาทำงานได้ (ช่วงนี้เบลอ ๆ แล้วไม่มันใจว่าแปลถูกไหม แต่พยายามเอาสิ่งที่ฟังมา Mix กับสิ่งที่เข้าใจ)  เพราะฉะนั้น Worker จึงต้องทำงานแบบใช้แรงงานเต็มเวลา โดยให้คนที่เป็น Manager เป็นคนควบคุมการทำงานทั้งหมด รวมถึงให้ Manager เป็นคนคิดว่า “เขาเหล่านั้นต้องการอะไร หรือมีอะไรที่พอช่วยเขาได้ไหม … หรือ Worker ต้อง Improve อะไร”

แต่ในงานที่เป็น Software Development มันต่างกับ Context ที่ถูก Set ไว้มาก เพราะ Worker ในงาน Software Development คือ Developer เป็นคนระดับมันสมอง ใช้สมองในการคิด ใช้สมองในการทำงานอยู่ตลอดเวลา “เขามีสมองเขาคิดเองได้ ว่าอะไรควร Improve เพราะฉะนั้นให้เขาได้คิดเอง” (จำได้แค่นี้ : ส่วนตัวแล้วรู้สึกว่า Developer มีความหมายตรงตัวของมันอยู่แล้ว เขาคือ นักพัฒนา เขารู้ว่าอะไรควรพัฒนาอะไรควรปล่อยไป เพราะมันคืออาชีพของเขา เพราะฉะนั้นปล่อยให้เขาทำในสิ่งที่เขาถนัดไปเหอะ)

การจะให้ Team เป็น Self-Managed ได้ มีสิ่งที่ขาดไม่ได้ 3 อย่างคือ

  • Boundary : ใน Scrum ตัว Scrum Framework เองเป็น Boundary คือเป็นกรอบให้กับทีม
  • Shared Goal : ทุกคนในทีมต้องมีเป้าหมายร่วมกัน เห็นจุดหมายปลายทางเดียวกัน
  • Fixed Team : จากที่ฟังเรื่องนี้สำคัญมากใน ในปัจจุบัน บริษัท ใหญ่ ๆ จะทำงานในลักษณะ Project Based ซึ่งเมื่อเริ่ม Project จะเริ่มตั้ง Development Team ขึ้นมา และ Team จะถูกยุบ (Destroy The Team) เมื่อ Project จบ ( Bas พูดด้วยน้ำเสียงที่เสียดายมาก | ผู้เขียนเข้าใจว่า : ที่เขาเสียดายเพราะกว่าจะสร้างทีมที่สามารถทำงานร่วมกันได้เข้าขากันได้นั้นไม่ใช่เรื่องง่าย ๆ สิ่งสำคัญที่สุดควรจะเป็น คงความเป็นทีมไว้มากกว่า สร้ัาง ๆ ยุบ ๆ)

มีคำถามเรื่อง Fixed Team กันต่อพอสมควร เช่น

  • บางทีมที่อยู่ ๆ ก็มี Project ฟ้าประทานมาทำให้ต้อง Split Team ออกเป็นหลาย ๆ ทีมต้องทำยังไง …
  • บางคนก็ถามเกี่ยวกับ การที่ต้องมีคนเข้าคนออก มันมีเสมอคุมไม่ได้ … อันนี้ผมเข้าใจว่า Fixed Team แต่มีคนเข้าออกซึ่ง มุมมองผมก็เป็นเรื่องไม่ดี แต่บางครั้งมันก็เป็นเรื่องส่วนบุคคลด้วย ซึ่งต่างกับ ยุบ ๆ สร้าง ๆ

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

Categorization of Complexity in dev project

มาถึงจุดนี้ Bas พูดถึงประเภทของ Dev Project ตามความซับซ้อน ซึ่งแบ่งเป็นระดับโดยมี Req กับ Technology เป็นแกน ถ้าทั้ง 2 อันไม่มีปัญหามาก Dev Project นั้นก็จะอยู่ในกลุ่ม Simple Project ซึ่งไม่มีอยู่จริงในโลกนี้ 555+ ส่วนมากจะไม่ด้านใดด้านหนึ่งยากส์ ก็จะเป็น ยากส์ทั้ง Req & Tech ซึ่งก็เริ่มเป็น Complicate และ Complex ในที่สุด ซึ่งการคิดแผนงานแบบละเอียด โดยคนที่ไม่ได้ลงมือทำจริง ๆ ตั้งแต่ก่อนเริ่มมันเป็นไปไม่ได้เลย งั้นใน Agile หรือ Scrum เราวางแผนรับมือกับ Project เหล่านี้ยังไง (ใครบอกว่า Agile ไม่ต้องทำ Plan ถ้าสนิทหน่อยก็ตบกระโหลกมันสักทีก่อน) เขาจึงยกตัวอย่างการเดินทางของ ห่านป่า เพื่อหนีหนาวไปยังที่ ๆ อบอุ่นกว่า ซึ่งเป็น Project ที่ใหญ่มาก ๆ แถมมีตัวแปลที่อาจจะเกิดขึ้น หรือเปล่าแปลงระหว่างทางอยู่ตลอดเวลาแล้วมันทำงานยังไงหล่ะ ? (ช่วงนี้ฟังสบาย ๆ หน่อยเพราะเคยอ่านมาแล้วจาก -> http://korn4d.wordpress.com/2011/05/17/agile-%E0%B8%88%E0%B8%B2%E0%B8%81%E0%B8%AB%E0%B9%88%E0%B8%B2%E0%B8%99%E0%B8%9B%E0%B9%88%E0%B8%B2/ อ่านเพิ่มเติมเอาเองแล้วกัน) จากการทำงานของฝูงห่านป่าที่เป็น Self-Managed มาก เพราะมัน Set  3 สิ่งขึ้นมา

  • Boundary
  • Shared Goal : แน่นอนว่ามันมี Goal เล็ก ๆ ที่ชัดเจนมาก และตรวจสอบ Goal นั้นอยู่ตลอดเวลา
    1. Warm Place
    2. Safety Place
    3. Have a Food
  • Fixed Team : อาจจะมีคนเข้าคนออกบ้างระหว่างทางก็ยังไปได้

และสิ่งสำคัญที่ทำให้ห่านป่าสามารถทำตามเป้าหมายได้ คือ Inspect & Adapt เพราะมันบีนไปยังที่ต่าง ๆ ตรวจสอบ Goal แล้วจึง Adapt เพื่อปรับปรุงวิธีการให้ เข้าใกล้เป้าหมายมากขึ้น

การทำ Software Dev Project เราไม่สามารถ Define หรือ Predictive ทุกสิ่งอย่างได้ทั้งหมด (Comfortable is not Realized) และถึงแม้ว่ามันจะทำได้ แต่ในการทำ Project เราไม่มีปุ่ม Pause ที่จะสามารถหยุด ทุกอย่าง หยุดทุก ตัวแปรที่เกี่ยวข้องกับ Project เพื่อให้มันสามารถดำเนินการได้ตามแผนงานที่วางไว้อย่างสวยหรู

ตัวอย่างจากร้าน BURGER (เหมือนเคยได้ยินมาก่อนอีกแล้วแต่จำไม่ได้ว่าที่ไหน)

มีชายคนนึงเดินเข้ามาในร้านสั่ง Double Burger with Cheese , Coke size Big และ French fried size Big พนักงานรับ Order แล้วเดินไปคิดเงิน พร้อมกลับมาบอกลูกค้าว่าราคา 5.5$ ชายคนนั้นก็เอามือควักเข้าไปในกระเป๋ากางเกงพร้อมหยิบเงินมาวางไว้บนโต๊ะ 1.5$ แล้วบอกว่าจะเอาที่สั่งแต่ในราคานี้ … ถ้าคุณเป็นพนักงานขายจะทำยังไง … ซึ่งใน Class แต่ละกลุ่มก็พยายามจะหาคำตอบเช่น ทำ Size เล็กลง, คุณภาพไม่มีให้ไป … มีถึงขนาดให้ไปซื้อที่ร้านอื่น ๆ (ไล่ลูกค้าไปให้คู่แข่งซะงั้น)

ฺBas บอกว่าในเหตุการณ์จริงที่เกิดขึ้น (คิดว่าแปลถูกนะ 555+) พนักงานพยายามหาทางออกในปัญหาดังกล่าว เหลือบไปเห็นซาก ??? (ฟังชื่อสัตว์ไม่ออกประกาศตัวแปรรับไปแล้วกัน) พึ่งตายอยู่หน้าร้าน เลยเดินอุ้มเอาเข้ามาในร้าน จัดการขน เอาขึ้นเตาย่าง แล้วเอาเนื้อที่ย่างเนี่ย ทำ Burger ให้ลูกค้า (ซะอย่างงั้น)

ฺBas ถามต่อว่ามองเห็นปัญหาไหม ปัญหาคืออะไร ให้แต่ละทีม Discuss กันว่าการทำแบบนี้ (ให้ลูกค้ากิน ??? Burger ) มันมีปัญหาอะไรไหม เริ่มมีคนตอบหลากหลายยิ่งขึ้น เช่น ลูกค้าอาจจะติดใจในราคา แล้วช่วนเพื่อน ๆ มาซื้อแต่เราไม่มีของขาย ,บางคนก็บอกว่าคุณภาพสินค้ามันจะไม่ดีหน่ะสิ … สุดท้าย Bas จึงถาม “คุณไม่คิดเหรอว่า ถ้าลูกค้าที่กิน ??? Burger เกิดล้มป่วยหรือว่าตายเพราะกิน ???”

 “เรากำลังเอาความเสี่ยงของลูกค้ามาตัดสินใจอยู่หรือเปล่า … จริง ๆ หน้าที่เราคือการให้ Info เพื่อให้เขาตัดสินใจสิ ….”

ไม่ไหวแล้วสงสัยแค่ First Day อาจจะต้อง Split เป็น 4 – 6 Part ได้เลยนะเนี่ย เพราะยังเหลือเนื่อหาเยอะมาก … วันนี้ไม่ไหวแล้วไปนอนดีกว่า -/\-

Reference 

Advertisements

3 thoughts on “Certified ScrumMaster Day 1/3 : Part 2/3

ใส่ความเห็น

Fill in your details below or click an icon to log in:

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