natty

Day2: Scrum Master course 2012

In scrum on November 11, 2012 at 4:51 pm

มี day2 ของปีที่แล้วด้วยค่ะ Day 2: My short note from Scrum Master Course

หาสมุดไม่เจอ..​ถ้าเจอจะเอามาเติมอีก ตอนนี้เอาไปก่อน ม้นก็เป็น potentially shippable product แล้ว ฮาๆ

เริ่มด้วยการถามตอบ

Product อะไร ควรใช้ Scrum?

  • ใช้กับ product อะไรก็ได้ แต่เน้นว่า ต้องเป็นสิ่งที่สามารถสร้างได้แบบ incrementally และเปลี่ยนแปลงได้ ไม่จำเป็นต้องเป็น software ก็ได้ ใช้กับอะไรก็ได้
  • ยกตัวอย่าง การเอา scrum  มาใช้กับงานการจัดงานแต่งงาน อันนี้ดูเป็นสิ่งที่ไม่ค่อยถูกต้อง เพราะมันแปลว่า คุณต้องไปโบสถ์ทุก 2 สัปดาห์เหรอ? มันไม่่ใช่ มันไม่สามารถทำให้เกิด potentially shippable product ได้ ดังนั้น งานแต่งงาน ควรใช้ kanban มากกว่า scrum
  • การจะเป็น scrum ได้ มันต้องเป็น combination ของหลายๆ practice เน้นๆ เลยคือ ต้องทำให้เกิด potentially shippable product ต้องเป็น process ที่เกิดซ้ำๆ เพราะเราต้องการ improve การทำงานของเรา (จะ improve ได้ ก็ต้องเกิดซ้ำๆ) การทำ 1 อย่าง แล้วจบไป แล้วก็ทำสิ่งใหม่ (เช่น ไปโบสถ์ แล้วก็ไปซื้อของขำร่วย) ไม่ได้เรียกว่าเป็นการทำซ้ำ ถ้าเป็นแบบแปลว่าเราแค่ใช้ scrum practice มาช่วยให้เราทำงานง่าย แต่ไม่ได้หมายความว่า นี่คือ scrum combination ที่ถูกต้อง
  • การผลิตเก้าอี้ ก็ใช้ scrum ได้ เราก็กำหนดการผลิตเก้าอี้ทุก 2 สัปดาห์ แล้วเก็บ feedback จากลูกค้า ถ้าลูกค้าไม่ชอบ ก็ไม่ได้หมายความว่าเราต้องเอาเก้าอี้ตัวเดิมมาแก้จึงจะเรียกว่า scrum แต่การทำเก้าอี้ใหม่ให้ดีกว่าเดิมเป็น new model ก็ถือเป็นการทำซ้ำจากการเก็บ feedback จากลูกค้าเหมือนกัน

ถ้ามีคนถามว่า Project นี้ เสร็จเมื่อไหร่ เราจะตอบยังงัย เพราะจากที่ Bas แนะนำ เราจะรู้ velocity ของทีมได้เมื่อผ่านไป 3 iterations? แต่ลูกค้าอยากรู้ตอนนี้อ่ะ

  • ให้เราบอกไปว่า ณ บัดนาวเนี่ย สามารถเสร็จได้ภายใน 3 ปี (scrum ไม่ได้วางแผนเรื่อง bug ไว้) แต่อีก 2 สัปดาห์ ข้างหน้า จะมาอัพเดทให้ฟังใหม่นะ (คือระยะเวลามันนานขนาดนั้น เราจะพูดอะไรไปก่อนก็ได้ แต่ให้ใช้การอัพเดททุกๆ 2 สัปดาห์ หลังจากนั้นแทน)

———- จบ session ถามตอบ

Potentially shippable product

การ deliver potentially shippable product ทำให้องค์กรเกิด Agility และ flexibility เพราะเราพร้อมจะ deploy เมื่อไหร่ก็ได้ จะเปลี่ยน direction ไปเป็นอย่างไรก็ได้ เพราะของมันพร้อมตลอดเวลา

การกำหนด Definition of Done ทำให้เกิด potentially shippable product

อะไรบ้างที่จะทำให้ product ของเรามันเป็น potentially shippable

  • code/design
  • unit test
  • functional test
  • compatibility test
  • integration test
  • bla bla..

สิ่งเหล่านี้ เรากำหนดเป็น definition of done ของ project ได้
definition of done จะโดน apply ไปในทุก story ที่เราทำงาน …. สงสัยใช่ไหมว่าจะทำทั้งหมดนี้ได้ยังงัยกับทุก story ไม่เสียเวลาแย่?????

ก็ทำให้มัน automate งัยยยยยยยยย automate ทุกสิ่งทุกอย่าง

แล้ว.. เราจะทำได้ทุกอย่างตั้งแต story แรก จริงเหรอ????? คำตอบคือ แรกๆ เราอาจจะทำได้แค่ 2-3 อย่าง เช่น ทำได้แค่ unit test / functional test และก็ยังทำ capacity test ไม่ได้ เพราะมันต้องเตรียมมาเยอะๆ นั่นก็แปลว่า เรายังไม่ได้ potentially shippable product ตามที่กำหนดได้ แปลว่า เราก็ต้อง improve ในทุก sprint ให้มันทำครบทุกข้อให้ได้ พวก capacity test หรือ test อื่นๆ ที่เราจะเตรียมให้มัน automate มันก็ต้องเสียเวลาเตรียม ใช้ effort เยอะ ในตอนแรก สิ่งเหล่านี้เราสามารถสร้างเป็น item หนึ่งใน product backlog ได้

definition of done จะลงความเห็นร่วมกันจากทีม และ product owner โดย definition of done จะถูกตั้งขึ้นตอนเริ่ม project และจะถูก apply ใช้กับทุกๆ story ใน project
เราสามารถปรับปรุง definition of done ของ sprint ถัดๆ ไปให้ดีขึ้นได้ (มันจะไม่เคยน้อยลง มันจะต้องมีแต่เท่าเดิม กับ ดีขึ้น)

Potentially shippable product = item + definition of done

Definition of done = potentially shippable product with no delay and no risk

if definition of done is not equal to potentially shippable product -> undone -> can’t ship -> lack of transparency

definition of done ทำให้ undone work มีน้อยลง ทำให้เรามีโอกาสจะ release ทันที ได้มากขึ้น ทำให้เราไม่ต้องทำ release sprint ซึ่งเป็น bad idea มากๆ เพราะการที่เราเก็บ undone work ไว้เยอะๆ พอจะ release เราก็ต้องมาทำ undone work ตามหลัง ทำให้มี risk และ delay ได้

บางที่ ก็ไม่ได้ใช้ release sprint แต่จะส่ง undone work ไปให้ undone department แทน (พวกแผนก QA อะไรแบบนี้)

Product owner
เป็นผู้รับผิดชอบ ROI เป็นคนที่เลือกจัดลำดับความสำคัญของงานได้ และจะเปลี่ยนเมื่อไหร่ก็ได้ที่ต้องการ เป็นคนมีสิทธิ์เลือกของเข้า sprint

Product backlog
เป็นแบบ customer centric คือ เขียนในมุมมองลูกค้า ไม่มี technical ไปเกี่ยว
product backlog = customer centric item + additional work to make them visible for team (พวก capacity test หรืออะไรที่กล่าวถึงด้านบน)
product backlog จะไม่มี task (มีแต่ item) และไม่มี ชื่อ component อยู่ (เพราะมันไม่ technical)
product backlog มี item และสามารถแตก item ให้ย่อยลงมาได้อีก เพื่อให้มัน fit ใน sprint ได้ แต่ split แล้ว ก็ยังต้องเป็นแบบ customer centric
1 iteration ทำงานกัน 5 คน ควรมีอย่างน้อย 10 items ใน sprint

review, approval doc ไม่ควรเป็น item หนึ่งใน backlog แต่มันควรเป็นส่วนหนึ่งของ definition of done

แล้ว item ออกมาให้เล็กลง ก็ relation หาย หมด ภาพรวมหายหมด?

  • วัตถุประสงค์ของการแตก item คือเพื่อทำให้เกิด simplicity
  • สุดท้ายแล้ว relationship ไม่สำคัญหรอก

ใน product backlog เราแตก item แต่ใน sprint เราแตก task (task จะเริ่มลง detail แบบ technical มีวิธีการ implement เราแตกตอนที่เป็น sprint เป็นสิ่งที่ทีมแตกกันเอง ไม่เกี่ยวกับ Product owner ในช่วงของการแตก task ทำให้เกิด design decision การ clarify ทางด้าน technical กันในทีม)!!!

ใน Agile สิ่งที่เราพยายามทำทั้งหมดคือ การแตกปัญหา (item) ออกมาให้เล็กลง โดยยังไม่ต้องคิดถึง solution หรือการ implement (สำหรับ engineer มันยากมากที่จะคิดอะไรให้มัน without solution ฮ่าๆ) ตอนที่เราจะแตกของแล้วคิดถึง solution คือตอนที่แตก task ใน sprint ไม่ใช่ตอนแตก item ใน product backlog ให้เล็กลง

Product backlog refinement
ทำกลาง sprint เลย โดยจะทำกับ items ของ sprint ถัดไป “ไม่ใช่ของ sprint ปัจจุบัน”

  • split item จาก corse grained ให้เป็น fine grained
  • clarify item
  • estimate item
  • acceptance test / criteria

การทำ product backlog refinement ใช้เวลาประมาณ 5-10% ของ sprint แปลว่าจะประมาณ ครึ่งวัน – 1 วัน สำหรับ sprint ที่มี 2 สัปดาห์

โดยปกติ product backlog refinement จะทำทุกวันศุกร์ กลาง sprint และศุกร์ถัดไปก็จะเป็น retrospective ตอนจบ sprint แปลว่า product backlog refinement กับ retrospective จะเกิดขึ้นสลับๆ กันไปทุกศุกร์ (เจ๋งเนาะ)

ถ้าอยากทำ scrum อยากให้เกิดสิ่งที่เรียกว่า partial allocation เพราะการเป็น scrum เราอยากให้ทุกคน share responsibility, take ownership ถ้าอยู่ project แบบครึ่งๆ กลางๆ มันจะไม่เกิดประโยชน์

keep team together “forever”

Scrum Master
โยนคำถามไปให้ทีมประมาณว่า

  • Is this useful?
  • What have you decided?
  • What should I do?

จะเห็นได้ว่า ไม่ตัดสินใจอะไรเลย แต่จะโยนคำถามให้ทีมตัดสินใจเอง

Obstacles ของการทำ scrum

  • command and control จะทำให้เกิดการเสพติด ของการหาคนมาช่วยแก้ปัญหา แบบไม่มีปัญญาแก้เอง
  • การเปลีี่ยนแปลงจากสิ่งที่เป็นอยู่ทุกวัน (status-quo) มันยาก การทำ scrum ก็ทำให้คนต้องเปลี่ยนแปลง
  • การเป็น scrumbut ทำให้เกิด status-quo ใหม่
  • belief in magic ว่างานมันจะเสร็จอย่างดีของมันเอง ขอแค่เชื่อ #ห๊ะ
  • The era of opacity
  • การมีความคิดฝังหัวเกี่ยวกับ waterfall (และคิดว่าการทำ scrum คือ mini waterfall)
Advertisements
  1. […] อ้างอิงจาก Natty’s blog -> Day2: Scrum Master course 2012 […]

Leave a Reply

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 / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: