เรามามองที่ฝั่งเนื้อย่างก่อน ตอนที่เราเข้ามาในร้านทุกคนจะเลือกตำแหน่งที่จะนั่ง ที่ตัวเองจะกินได้สบายที่สุด บางคนเลือกที่จะนั่งตรงข้ามคนที่กินเก่งที่สุดเพราะ ถ้าอิ่มเมื่อไรมันจะได้กินแทนเรา ในกรณีนีนี้ผมไปกันห้าคน แบ่งกันเป็น 2 เตา ซึ่งน่าจะเดาไม่ยากว่าเตาหนึ่งก็จะมี 2 คนรับผิดชอบเป็นหลัก และมีน้องคนหนึ่งเป็นตัวเสริมอยู่ระหว่าง 2 เตานี้ พอเลือกที่นั่งได้แล้วพนักงานก็จะมารับออเดอร์ซึ่งการกินแบบบุฟเฟ่เราก็สั่งในสิ่งที่เราอยากกิน มากน้อยแล้วแต่ศรัทธา พนักงานก็รับออเดอร์ไป แล้วหลังจากนั้นเราก็รอ ระหว่างนี้เราจะตัดกลับมาที่โปรเจ็คซอฟท์แวร์กันก่อน
ในโปรเจ็คซอฟท์แวร์ทีมๆ หนึ่งจะประกอบไปด้วยคนที่เชี่ยวชาญในแต่ละสาขาที่แตกต่างกัน จริงอยู่ที่ Agile มักจะบอกไว้ว่า Role ในทีมมันเป็นแค่สิ่งสมมติ แต่ถ้าเรามองในความสามารถจริงๆ ก็จะมีคนที่เชี่ยวชาญแต่ละสาขาอยู่นอกจากนั้นยังมีเรื่องของ Senior กับ Junior อีกซึ่งก็คล้ายๆ กับการที่เราเลือกนั่งตรงข้ามกับคนที่กินเก่งกว่าในเตาเดียวกัน เมื่อเราฟอร์มทีมขึ้นมาได้แล้วสิ่งต่อไปคือรับงานจากลูกค้า ในกรณีนี้มันจะกลับกันเลยขอข้ามกลับไปที่ฝั่งกินเนื้อย่างกันต่อ

พอเนื้อที่สั่งมาถึง ซึ่งมันก็มักจะมากันในปริมาณมากๆ พร้อมๆ กันหลายอย่าง ตามที่แต่ละคนสั่งไป ซึ่ง ก็ขึ้นอยู่กับสไตล์ในการกินของแต่ละคนว่าชอบกินอะไรก่อน กินอะไรหลัง หรือบางคน กินอย่างละนิดอย่างละหน่อย ให้รสชาติเปลี่ยนไปเปลี่ยนมาในปาก ก็แล้วแต่สไตล์ ทุกคนจะรับผิดชอบในสิ่งที่ตัวเองสั่งมาในกรณีที่อิ่มแล้ว และเลือกที่จะช่วยกันกินในสิ่งที่คนอื่นกินไม่ไหวแล้ว ถ้ายังไหวอยู่นะ (ซึ่งก็อุดมคติมาก เพราะถ้าอิ่มจริงๆ ก็มักจะเกี่ยงกันหรือในกรณีที่เห็นวันนี้ย่างให้แล้วส่งให้ถึงจานเลย)
เวลาเราเก็บ Requirement จากลูกค้ามา ซึ่งก็สารภาพตามตรงว่าผมก็ไม่เคยเก็บจากลูกค้าจริงๆ เพราะทำแค่โปรเจ็คของปีสี่ แต่สิ่งที่เกิดขึ้นและคล้ายกันคือสไตล์การทำงานมันไม่ต่างอะไรกับสไตล์การกินเลย เราเลือกในสิ่งที่เราชอบทำก่อน (หรือในบางกรณี ทำในสิ่งที่ง่ายกว่าก่อน) ในกรณีเวลาเราทำ Scrum เราต้องทำ Sprint Planning ซึ่งมักจะเลือก Requirement ที่สำคัญที่สุดมาทำก่อนคนเลือกคือใคร คือลูกค้า แต่ในกรณีนี้ลูกค้าคือตัวเองถามว่าจะเลือกอะไร แว็บนี้แหละที่แนวคิดแบบ Scrum มันโผล่เข้ามาและเห้ย มันจริง เราทำมันอยู่ทุกวันแหะ เราเลือกสิ่งที่เราอยากกิน (หรืออยากทำ) มาทีละนิดใส่ลงไปในเตาแต่ละรอบ ไม่ต่างจากการเลือกงานมาทำในแต่ละ Sprint เลย ซึ่งในเตาแรกเนี่ย จะคล้ายๆ เป็นการประเมินว่าในเตาหนึ่งมันวางเนื้อได้สูงสุดกี่ชิ้น รอบต่อไปเราจะกะได้โดยประมาณว่าจะวางได้เท่าไร ไม่ว่าเนื้อนั้นจะมาแบบลูกเต๋า เป็นแผ่น หรือเป็นเนื้อคนละชนิดก็ตาม

สิ่งที่ผมสังเกตุเห็นอีกอย่างคือในแต่ละรอบของเตารอบที่ 2-3 เป็นรอบที่เรากินได้มีความสุขที่สุดและมี Momentum มากที่สุด (รวมถึงเนื้ออร่อยสุดด้วย) ไม่ต่างอะไรกับการทำ Scrum ที่ Sprint แรกมักจะยังงงๆอยู่แต่พอ Sprint 2-3 จะเริ่มจับจังหวะและเริ่มคล่องตัวได้แต่ปัญหาของเนื้อย่างก็ไม่ต่างจากการเขียนโปรแกรมอีกพอเราทำไปจนถึง Sprint ที่ 4 หรือรอบเตาที่ 4 เนื้อในกระเพาะก็เริ่มเยอะขึ้นไม่ต่างจากการที่เรามี Code base มากขึ้นเมื่อเราทำโปรเจ็คไปซักระยะซึ่งจะทำให้การเพิ่มอะไรเข้ามาใน Sprint หลังๆมันยากลำบากยิ่งขึ้น (ในกรณีกินเนื้อย่างคืออิ่ม)

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

ปล.ที่เขียนมาทั้งหมดในข้างต้นมาจากอารมณ์ล้วนๆอิ่มมากครับ

Original post at: https://yothinix.blogspot.com/2014/01/blog-post_17.html

ระหว่างที่กลุ่มอื่นก็จัดงานสัมมนาไปในช่วง 2 เดือนที่ผ่านมานับว่าผมโชคดีมากที่มีงานสัมมนาเกี่ยวกับ Software จัดขึ้นมาตลอดทุกเดือนไม่ว่าจะเป็นThailand Practical Software Engineering ConferenceและAgile Tour Bangkok 2013ซึ่งนอกจากจะไปหาความรู้มาประดับตัวจากงานแล้วทั้งสองงานยังมีจุดประสงค์แฝงคือการไปทาบทามวิทยากรซึ่งก็คือพี่ปอมทั้งสองงานซึ่งก็น่ายินดีที่พี่ปอมตอบตกลงตั้งแต่ครั้งแรกที่เจอกันเลยซึ่งหลังจากติดต่อกันหลังจากนั้นไม่กี่ครั้งก็ถึงวันงานซึ่งก็คือวันนี้

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

โดยส่วนตัวแล้วตั้งแต่เลิกผมเลิกทำกิจกรรมก็แทบจะไม่ได้พูดต่อหน้าคนมากๆอีกเลยวันนี้เป็นอีกหนึ่งวันที่พิสูจน์ว่า “ถึงจะซ้อมมาแค่ไหนก็สั่นได้” ถึงแม้คนที่มาร่วมจะเป็นเพื่อนร่วมภาคเดียวกันแต่ก็ยังมีน้องๆจากภาควิชาอื่นและก็ยังมีนศ. มาจากคณะอื่นด้วยไม่สั่นก็ไม่รู้จะพูดยังไงแล้วครับพอแนะนำวิทยากรเสร็จก็ปล่อยให้เป็นหน้าที่ของพี่ปอมแล้วครับ

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

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

พอกลับมาจากคุยกับอาจารย์พี่ปอมก็พาเล่น Ball Point Game โดยตอนแรกว่าจะเล่นข้างหน้าหอประชุมแต่เสียงดังมากเลยย้ายกลับมากระจายกันเล่นอยู่ทั่วพื้นสโลป โดยเกมส์นี้จะแบ่งกลุ่มออกเป็นกลุ่มละ 10 คนในที่นี้และเกมนี้มีกฏอยู่ 3 ข้อคือ

• ต้องทำการส่งบอลผ่านทุกคนในทีมถึงจะนับเป็น 1 แต้ม ถ้าตกไม่นับ
• บอลต้องมีการผ่านอากาศคือส่งต่อๆ มือต่อมือไม่ได้
• ห้ามส่งให้คนที่นั่งติดกัน

โดยจะให้เวลา 2 นาทีแรกในการวางแผนแล้วก็ Estimate ว่าคิดว่ากลุ่มจะทำได้กี่แต้มหลังจากผ่าน 2 นาทีแล้วก็จะเล่นจริง 2 นาทีซึ่งจุดนี้เป็นอะไรที่สนุกมาก (แต่เป็นคนจัดงานก็ไม่ได้เล่นด้วย T^T) ที่เห็นเพื่อนตอนแรกๆงงๆเริ่มที่จะคุยกันเล่นแล้วยิ้มกันหัวเราะกันออกมาเห็นการ Estimation ผิดเห็นแนวคิดการ Retro แบบต่างๆกันแต่ละกลุ่มพัฒนาการและเทคนิคที่ซับซ้อนของแต่ละกลุ่มผมไม่รู้ว่าเพื่อนที่เล่นอยู่สนุกมั้ยแต่ผมรู้สึกดีมากที่ได้เห็นกิจกรรมแบบนี้รู้สึกดีจริงๆบรรยายไม่ถูกเลย

พอจบเกมพี่ปอมบอกว่าสิ่งที่สังเกตุเห็นที่นี่จริงๆคือ Natural Velocity หมายถึงทีมพอทำงานเต็มที่แล้วเนี่ยนั่งทำอยู่ที่เดิมแต่เปลี่ยนวิธีไปเรื่อยๆพอถึงจัดๆหนึ่งก็จะเป็นจุดที่ทีมทำได้เร็วสุดล่ะ (และจุดนั้นจะ Estimate ได้ใกล้เคียงมากๆด้วย) ซึ่งจากประสบการณ์การทำ Agile มาทีมผมทำได้น้อยถึงน้อยมากเลยในจุดนี้ต้องกลับไปทบทวนจริงๆว่าทีม Inspect & Adapt มากแค่ไหน (ถึงแม้เราจะทำ Retrospective ด้วยแล้วก็ตาม)

หลังจากนั้นแล้วพี่ปอมก็ได้พูดถึงศัพท์ต่างๆที่พอเราศึกษา Agile น่าจะผ่านหูผ่านตามาบ้างอย่างเช่น Continuous Improvement, Value Driven, Early Feedback (อันนี้ผมชอบมากกับการเปรียบที่ว่าการเขียนโปรแกรมก็เหมือนการดีดกีตาร์ถ้าเราดีดไปแล้วต้องรอ 3 ชม. กว่าเสียงมันจะดังกลับมาคิดว่าเราต้องใช้เวลาเท่าไรในการเรียนดีดกีตาร์), Transparency ที่พูดถึงเรื่อง Trust และพูดถึงเรื่อง Code อีก 2 เรื่องคือ “Good code is its own best documentation.” และประโยคเด็ดของลุงบ็อบผู้แต่ง Clean Code ที่แปลไทยได้ว่า “ถ้าเขียน Comment เมื่อไรรู้ไว้ซะว่า Code แกมันกาก” หลังจากนั้นก็ทวน Agile Manifesto อีกรอบแล้วแนะนำผู้ที่จะศึกษาเกี่ยวกับอไจล์ว่าควรจะทำไง (ง่ายก็คืออ่าน) โดยหนังสือที่แนะนำคือ Agile Samurai ซึ่งก็คือเล่มเดียวกับที่ผมชอบแนะนำน้องเวลามาถามเกี่ยวกับ Agile ว่าคืออะไรเพราะมันอ่านง่ายจริงๆโดยเฉพาะฉบับแปลเถื่อนจากเกรียนเพรสที่อุตส่าห์ไปขุดมาจนเจอ

สุดท้ายนะครับต้องขอบคุณวิทยากรคุณกุลวัฒน์และทีมงานมากๆ นะครับที่สละเวลามาให้ความรู้แก่พวกเรา ขอบคุณเพื่อนๆ ปี 4 ทุกคนนะครับที่มาเข้าสัมมนาในวันนี้, ช่วยกันตอบแบบสอบถามและร่วมกันทำกิจกรรมกันขอบคุณวิทย์ ที่จัดการหาของที่ระลึกให้ รวมถึงเรื่องดูแลวิทยากรด้วยขอบคุณพัด ที่อุตส่าห์หากล้อง ตั้งกล้อง รวมถึงเดินถ่ายรูปทั้งงานขอบคุณฟอร์ซที่คุยกับฝ่ายสถานที่ให้ ตอนที่เราไม่ว่างขอบคุณบอลที่ช่วยติดต่อกับอาจารย์ตี๋ให้ตั้งแต่วันแรกยันวันงานของคุณชาลี ที่ช่วยกันออกแบบโลโก้ให้ออกมาได้สวยขนาดนี้ขอบคุณเฮน โอม บูมที่อุตส่าห์มาแต่เช้ากว่าปกติ แล้วก็ดูแลโต๊ะลงทะเบียนให้ขอบคุณซ้ง ที่ช่วยเดินดูแลกลุ่มที่อยู่ข้างบน แล้วก็ช่วยกันแบกลำโพงไปไว้ข้างนอกด้วย ขอบคุณบิว ที่ช่วยกำกับตอนถ่ายคลิป และช่วยออกไอเดียแปลกๆ
ขอบคุณเพื่อนๆ พี่ๆ น้องๆ ที่ช่วยกันแชร์ประชาสัมพันธ์งานไปในสาขาต่างๆ นะครับ
ขอบคุณเพื่อนๆ พี่ๆ ในทวิตเตอร์ที่ช่วยกันรีทวีตประชาสัมพันธ์ เป็นทวีตที่โดนรีมากที่สุดตั้งแต่เล่นมาเลยสุดท้ายขอบคุณกิจกรรมนี้นะครับ ที่ทำให้ฝันของผมในการเผยแพร่อไจล์ไปสู่คนหมู่มากในลาดกระบังเป็นจริง

ขอบคุณทุกคนอีกครั้งครับขอบคุณจริงๆ

Original post at: https://yothinix.blogspot.com/2014/01/blog-post_7.html

Software must build for CHANGE not build for LAST

เหตุผลที่ผมเข้า Session นี้สารภาพตามตรงว่าเพราะคนพูดครับแฮร่จะว่าเป็นแฟนคลับก็ไม่เชิงซะทีเดียวแต่ผมรู้สึกทุกครั้งหลังจากเข้า Session ของพี่รูฟ+Twin Panichsombatผมมักจะได้ของเล่นและพลังอะไรบางอย่างกลับมาซึ่งทำให้การทำอไจล์นั้นไม่เคยน่าเบื่อเลยครั้งนี้ก็เช่นกันครับของเล่นใหม่ที่ผมได้มามันเรียกว่า Fishbowl ครับ

Fishbowl คือรูปแบบการประชุมที่แหวกจากขนบการประชุมแบบดั้งเดิมโดยจะให้คนที่อยู่ในที่ประชุมทุกคนสามารถเขียนคำถาม/หัวข้อที่ต้องการสนทนาลงในการ์ดซึ่งคนที่ทำหน้าที่เป็นคนจัดก็จะเก็บลงใน Fishbowl จากนั้นเราก็จะทำการสุ่มคำถาม/หัวข้อที่จะสนทนาขึ้นมาพูดกันเป็นเวลา 5 นาทีซึ่งเมื่อหมดก็จะให้ผู้เข้าร่วมทั้งหมดตัดสินว่าเราจะคุยกันต่อ (Like) หรือเราจะไปคุยเรื่องอื่น (Dislike) แต่ส่วนสำคัญอีกส่วนหนึ่งของ Fishbowl ก็คือทุกคนมีสิทธิที่จะพูดหรือตอบในหัวข้อที่เลือกมาได้โดยจะจัดเก้าอี้ไว้ 4-5 ตัวซึ่งจะต้องมีคนที่ร่วมการประชุมใครก็ได้นั่งอยู่แต่เหลือไว้ 1 ที่เพื่อที่จะเปิดโอกาสให้คนที่ไม่ได้อยู่ในวงสนธนา (คนฟัง) มีสิทธิที่จะเข้ามาแสดงความคิดเห็นได้ซึ่งเมื่อมีคนเข้ามา 1 คนก็จะต้องมีคนออกไป 1 คน (ซึ่งดูเหมือนจะมีคนจ้องจะออกตลอด)

src: https://www.scrum-tips.com/agile/stacey-complexity-model/

นอกจาก Fishbowl แล้ว Session นี้ยังทำให้ผมได้รู้จักกับ Stacey Matrix ซึ่งเป็นกราฟในการประเมินรูปแบบของ Software Project ว่าเราอยู่ในสภาพไหนและเราควรจะใช้ Process อะไรมาจับโดยแบ่งเป็น 3 แกนคือ Requirement, People และ Technology ยกตัวอย่างเช่นถ้า Requirement ของโปรเจ็คเราแทบไม่เปลี่ยนแปลงเลยและ Technology ที่ใช้ก็คาดเดาได้เราก็จะตกอยู่ในโซน Simple ซึ่ง Process ที่แนะนำให้ใช้ก็คงจะเป็น Waterfall นะโดยแต่ละโซนจะมี Process ที่น่าจะรองรับได้เช่น Agile จะอยู่ในโซน Complicated แต่ถ้าไปตกอยู่ในโซน Anarchy ก็บอกได้คำเดียวว่า “วอดวาย” สุดท้ายพี่รูฟสรุปด้วยประโยคที่ว่า “Software is Business, Business is never stop” จริงๆมันยาวกว่านี้แต่ผมจำได้แค่นี้ความหมายประมาณว่าขนาดธุรกิจยังไม่เคยหยุดที่จะเปลี่ยนแปลงเลยตัวซอฟท์แวร์ก็เช่นเดียวกันคำถามที่เหลือใน session นี้ผมขอสรุปไว้เป็น bullet ดีกว่าเพราะว่ายังมีอีกหลาย session ให้เขียนต่อนะครับ

ข้อดีของ Agile

• ทำให้มุมมองที่มีต่อการสร้าง Software เปลี่ยนไป (มีเอกลักษณ์เฉพาะตัว)
• กลับไปสู่ความเป็นมนุษย์อีกครั้ง (งานมีแค่เสร็จกับไม่เสร็จไม่มีเสร็จไปกี่เปอร์เซ็นต์)ข้

เสียของ Agile

• ทำ Long Estimation ไม่ได้ และยืนยันว่าจะทำตาม Plan ที่วางไว้ไม่ได้ซึ่งทำให้จ่ายเงินแบบโปรเจ็คปกติไม่ได้เช่นเดียวกัน
• ต้องเผชิญกับความกลัวในการเปลี่ยน Culture ขององค์กร

ถ้าอยากทำอาชีพอย่างวิทยากร

• เพิ่งรู้ว่าอาชีพ Coach นี่มันแบ่งเป็น 3 แขนง Organization, Team และ Technical ซึ่งการจะเป็นได้สำคัญคือแค่อ่านหนังสือไม่พอ แต่ต้องทำเป็นด้วย (Lead by example)

วิธีรับมือกับ Requirement ที่เปลี่ยนแปลงบ่อย

• ทำ Automate ให้มากที่สุดให้เห็นว่าเกิด effect กับส่วนไหนบ้าง
• มีระบบป้องกันความเสียหายจากความเปลี่ยนแปลงซึ่งการทำ Unit Test และ Continuous Integration ช่วยได้
• ต้องสร้าง Environment ที่รองรับการเปลี่ยนแปลงด้วย
• คำคม: ถ้าทุกอย่างสำคัญหมดแสดงว่าไม่มีอะไรสำคัญเลย

Scrumban = Scrum + Kanban: Managing flow in a chaotic world

สำหรับ Session นี้คนที่เป็น Speaker นั้นมาจาก Malaysia ครับเลยฟังยากนิดหน่อยโดย Speaker พาเราไปรู้จักหัวใจของ Scrum ก่อน (5 Artifact 3 Role 5 Ceremony 5 Value) หลังจากนั้นจึงพาเราไปรู้จักกับ Kanban ซึ่งประโยคหนึ่งที่กินใจมาก (เพราะตัวเองก็เพิ่งเริ่มทำ Kanban ได้ 2 อาทิตย์กว่าๆ) คือ Kanban is all around us แล้วคุณ Tze ก็ยกตัวอย่างให้ฟังเช่นเวลาคุณไปดูหนังที่โรงหนังตัวคุณนะแหละเป็น Kanban, เวลาคุณไปซื้อกาแฟ Starbuck ตัวแก้วนะแหละคือ Kanban คือทุกอย่างที่กล่าวมามันจะมี Flow ซึ่งก็คือหัวใจของ Kanban นั่นเองนอกจากนั้นยังพูดถึง Push vs Pull ซึ่งใน Kanban เราต้องบอกว่า How much I can do (ซึ่งก็คือ Pull) สุดท้ายของ Kanban คือ Identified and manage constraint ซึ่งถ้าสมมติเป็นท่อน้ำตัว Constraint ก็คือคอขวดนะแหละโดยเราต้องหาวิธียังไงก็ได้ที่จะจัดการกับคอขวดที่เกิดขึ้น

ในส่วนของ Scum + Kanban ซึ่งก็คือหัวข้อหลักที่จะคุยกันวันนี้ผมจับใจความได้สองข้อข้อแรกคือตัวบอร์ดหรือที่เรียกกันว่า Work Stage และตัว WIP Limit ใน Kanban จะเป็นตัวสะท้อนของสิ่งที่ทีมเป็นและคุณค่าในตัวของมันเอง (ไม่รู้ว่าผมเข้าใจตรงนี้ถูกรึเปล่านะ) และการเอา Kanban มารวมกับ Scrum จะเปลี่ยนพฤติกรรมของทีมแทนที่จะสร้าง Task ใหม่ๆขึ้นมาแต่จะเปลี่ยนเป็นส่งมอบ Value แทน

ช่วงถามตอบมีคำถามซึ่งถ้าไม่มีคนถามผมก็ไม่ทันสังเกตุและเป็นสิ่งที่น่าสนใจมากคือในสไลด์บอกว่าในทีมมี Developer 9 คนแต่ทำไมตั้ง WIP ใน In Progress ไว้ 8 แล้วอีกคนทำอะไร ? คุณ Tze ตอบได้น่าสนใจมากว่าอีกคนหนึ่งนั้นมีหน้าที่ในการเดินไปทั่วและสังเกตุงานที่คนอื่นกำลังทำอยู่และเข้าไปช่วยถ้าทำได้ซึ่งจะได้อะไรมากกว่าการนั่งทำงานอยู่คนเดียวแน่นอนซึ่งก็มีคำถามตามมาอีกว่าถ้าไอ 1 คนมันไม่ยอมลุกไปไหนกูจะนั่งเล่น Hayday อยู่ตรงนี้แหละเราจะทำไงคุณ Tze แนะนำถึง Effect ของ Peer power จะมีประโยชน์มากกว่าให้ Manager มาสั่งว่าคุณต้องทำอย่างนั้นอย่างนี้นะในสถานการณ์นี้

Building high performance culture

เมื่อวันจันทร์ที่ผ่านมาผมได้ไปร่วมAgile 66 Community Eventมาซึ่งได้เชิญคุณ Henrik Kniberg มาบรรยายเรื่องCultural > Processซึ่งถ้าผมมีโอกาสก็คงจะมาเขียนเกี่ยวกับสิ่งที่ได้รับมาจากงานนั้น (ดองไว้ก่อน) ประเด็นคือในงานนั้นมีคนๆหนึ่งทักผมครับซึ่งผมมาทราบทีหลังว่าคือคุณ Arunthep ซึ่งก็คือ Speaker ของ Session ที่เรากำลังจะมาพูดถึงนี้โดยถ้ามองย้อนกลับไปไม่ว่าจะเป็น Agile Thailand หรือ TPSE ผมก็เห็นชื่อคุณ Arunthep อยู่บ่อยมากแต่ไม่เคยคิดจะเข้าเลยวันนี้เลยนึกครึ้มลองเข้าไปฟังดูและอาทิตย์นี้ดูเหมือนบรรยากาศการสร้าง Culture แทบจะอยู่รอบตัวเราหัวข้อนี้ซึ่งมีคำว่า Culture อยู่จึงล่อลวงผมเข้าไปได้ง่ายขึ้นไปอีก

ตัว Session พูดถึงโครงสร้างของ High Performance Culture ว่าประกอบด้วย 3 องค์ประกอบคือ Human Dynamic, Practices และ Environment (ซึ่ง Agile จัดอยู่ใน Practices นะครับ) หลังจากนั้นก็ตั้งคำถามว่าถ้าเราทำ Software เหมือนเดิมเป๊ะๆเลยเนี่ยเราจะทำได้เร็วขึ้น, เท่าเดิมหรือช้าลงซึ่งก็มีหลากหลายคำตอบมากในห้องแต่สรุปก็คือเร็วขึ้น 60-80% โดยทางวิทยากรพูดถึงลูปซักอย่างที่คล้ายๆกับของ Lean มากแต่ผมจำไม่ได้ว่าชื่ออะไรเป็นตัวอธิบายถึงคำตอบข้างบน ในเรื่องขององค์ประกอบในการสร้าง High Performance Team ทางวิทยากรอธิบายว่าจะประกอบด้วยหลายๆอย่างคือ

• Trust คือการยอมที่จะรับความเสี่ยงและให้โอกาสคนอื่น ต้องขอโทษเป็นและไม่มีการเมืองภายใน โดยได้โยงไปถึง Spiral Trust หรือความจริงของ Trust ว่ามันไม่ได้สร้างยากและเสียไปยากเลย ถ้าเราให้โอกาสคนอื่นและคนอื่นก็ให้โอกาสกับเราเหมือนกัน ยกตัวอย่างเช่น US vs THEM ซึ่งเป็นวัฒนธรรมที่ไม่มีใครได้มีแต่เสียกับศูนย์ (Zero Sum) โดยเราจะพยายามปกป้องตัวเอง (+1 US) และไปโทษคนอื่น (-1 THEM)
• Commitment อันนี้ยกตัวอย่างง่ายๆ คือเราต้องกล้าที่จะบอกว่าทำได้หรือทำไม่ได้ (ไม่ใช่ YES หมด (อันนี้ใน REWORK พูดถึงด้วย)) และยังมีวิธี Fixing breaking commitment เป็นสเตปดังต่อไปนี้- ยอมรับตามตรงว่าทำไม่ได้- ขอโทษ- จะทำอะไรให้มันดีขึ้นบ้าง- ครั้งต่อไปจะไม่เกิดขึ้นอีก
• Accountability อันนี้จะกลับกันกับ Commitment ซึ่งผมคิดว่าทางวิทยากรได้พูดไว้ในเรื่อง Personal Response Pyramid นะครับ ซึ่งผมก็หาภาพที่ตรงกับ Slide ไม่ได้แต่จะไล่จากฐานพีระมิดคือ Self -> Clarity -> Ask -> Agree -> Call
• Common Goal หัวข้อนี้คงไม่ต้องอธิบายอะไรมาก
• Conflict เป็นอะไรที่แปลกมากแต่ผมก็คิดว่าจริงคือ ทีมที่ดีคือทีมที่ทะเลาะกัน (เพราะถ้ามันไม่พูดกันนั่นก็เกินเยียวยาแล้ว) ถ้านั้นยังไม่เห็นภาพทางวิทยากรให้ทุกคนในห้องจับคู่กันแล้วมองตากันโดยไม่ต้องพูด 1 นาทีหลังจากนั้นแล้วถามความรู้สึก ซึ่งหลายคนก็รู้สึกตรงกันว่า แม่งฮามาก แต่วิทยากรก็อธิบายว่ามนุษย์เรามักจะเลี่ยงที่จะเผชิญหน้ากันเสมอ ซึ่งถ้าเราจัดการข้อจำกัดข้อนี้ไปได้ จะทำให้การแก้ปัญหาความขัดแย้งมันง่ายขึ้น

หลังจากนี้เป็นพักเที่ยงครับซึ่งบุฟเฟ่อร่อยมากไม่รู้จะบรรยายยังไงไปดูรูปที่เพจAgile Tour Bangkokก็คงจะเข้าใจมากขึ้นนะครับ

No Reuse Before Use

Session แรกตอนบ่ายนี่เลือกยากระดับนึงเลยครับแต่ผมก็ตัดสินใจเข้า Session นี้ซึ่งผมจัดให้เป็น Session ที่ฮาที่สุดของงานนี้แล้ว (แม้จะฟังออกบ้างไม่ออกบ้าง) โดยคุณ Terry Yin มาเล่าให้เราฟังเรื่อง Software Reuse ซึ่งเป็น Term ที่ผมได้ยินมาบ่อยมากแต่ไม่เข้าใจว่ามันคืออะไรแต่พี่แกเล่นตัดบทโดยบอกว่าเราจะมาพูดถึง Software Use แทน

วิทยากรเริ่มพาเราจินตนาการไปกับผังเมือง Brazilia เมืองหลวงของประเทศ Brazil ซึ่งเพิ่งรู้ว่านอกจากจะออกแบบเพื่ออนาคตเมื่อกว่า 60 ปีที่แล้วเองนั้นตัวเมืองยังออกแบบให้เป็นรูปเหมือนนกอินทรีและที่สำคัญไม่มีไฟแดงครับ !! แต่ปัญหาก็คือในอนาคตที่คนออกแบบผังเมืองมองไว้นั้นไม่มีคนเดินถนน (Pedestrian) ครับเพราะเขาสันนิษฐานว่าคนในอนาคตคงใช้รถกันหมดทุกคนแล้วซึ่งปัจจุบันมันเกิดสิ่งนี้ขึ้นครับ

สิ่งที่เกิดขึ้นคือมันมีคนเดินถนนครับแล้วคนเหล่านั้นได้สร้างเส้นทางที่เห็นดังภาพข้างบนขึ้นกลางเมืองซึ่งการที่คนจะข้ามจากทุ่งฝั่งนึงไปอีกฝั่งนึงได้ต้องผ่านถนน 6 เลนย้ำอีกที 6 เลนนะครับซึ่งเสี่ยงชีวิตโคตรๆเลยซึ่งสอดคล้องกับสถิติคือคนบราซิลจะเสียชีวิตจากอุบัติเหตุทางถนนประมาณ 10,000 คนทุกปีซึ่งถ้าคนออกแบบผังเมืองรู้ว่าในอนาคตยังมีคนเดินถนนอยู่คำถามคือมันจะเกิดอะไรขึ้นบ้าง

จากเรื่องข้างบนพาเราย้อนกลับมาถึง Software Reuse ซึ่งเกิดคำถามขึ้นว่าเราจะรู้ได้ไงว่าส่วนไหนควรจะ Reuse ถ้าเรายังไม่ Use มันด้วยซ้ำวิทยากรพูดถึง Duplication หรือการทำซ้ำว่าเป็น Root of all evil in Software และการ Refactoring นั้นควรจะทำก็ต่อเมื่อสิ่งที่เราเขียนลงไปนั้นมันทำงานได้แล้วไม่ใช่ทำก่อนซึ่งจะทำให้การ Refactoring เป็นการเปลี่ยนแปลงตัว Structure ภายในส่วนนั้นไม่ใช่เปลี่ยน Output ที่ออกมาแต่ถ้าเราเขียนทุกอย่างตามหลักการ Once and only once ปัญหาพวกนี้ก็จะเกิดขึ้นน้อยลงจริงๆแล้วยังมีอีกหลายเรื่องใน Session นี้แต่ผมจับใจความไม่ได้เลยขอทิ้งท้ายด้วยประโยคที่ว่า “Design from perspective of use ratherthan implementation” ครับ

Building Software Development Culture for Any Scale

ผมสังเกตุเห็นสิ่งหนึ่งที่เกิดขึ้นตลอดสัปดาห์ที่ผ่านมาคือมีคนพูดถึงเรื่อง Culture ในองค์กรเยอะมากๆในวันนี้มีถึง 2 Session เลยซึ่งสารภาพตามตรงว่าผมมา Session นี้เพราะโดนกล่อมครับฮ่าพอดีตอนเที่ยงได้มีโอกาสสนทนากับพี่แอมป์+Tanawat Tassanaรวมถึงที่พี่แกมาโฆษณาใน Session ตอนเช้าด้วยเลยตัดสินใจไม่ดู Real Agile#2 ละ (ซึ่งโชคดีมากเพราะ Session นั้นมีคนอัดวิดีโอไว้ที่ » http://www.youtube.com/watch?v=zWIALP-vqEk)

Session นี้เริ่มด้วยคำถามว่าทำไมถึงต้องมี Culture โดยยกตัวอย่างสมาชิกใหม่ที่เข้ามาทำงานในทีมว่าเขาไม่ได้เรียนรู้จากกฏแต่เรียนรู้จาก Culture ที่มีอยู่เช่นถ้ามีคนบ่นเกี่ยวกับกฏสักพักเดี๋ยวก็มีคนบ่นตามเป็นต้นคำถามต่อมาคืออะไรคือ Culture คำตอบคือCulture = set of mindsetsทีนี้มันก็จะเกิดคำถามแล้วว่าแล้วกฏหล่ะปรากฏว่า Rules มันคือ Set of behaviors ครับคือรูปแบบพฤติกรรมที่กำหนดมาซึ่งกำหนดได้แค่พฤติกรรมครับแต่ในใจนั้นอีกเรื่องซึ่งทั้งสองอย่างทั้ง Culture และ Rules ต่างมุ่งไปที่เป้าหมายสุดท้ายเดียวกันคือ Bahaviors นี่แหละครับ

ทีนี้เนี่ยเราจะทำวัฒนธรรมที่เราสร้างให้มันเข้มแข็งได้อย่างไรมี 2 ข้อครับข้อแรกคือต้องเปิดรับการเปลี่ยนแปลง (คล้ายๆ Agile แหะ) เพื่อที่จะพัฒนาตัวมันเองรวมถึงต่อต้านความเปลี่ยนแปลงอะไรก็ตามที่ทำให้เกิดผลเสียต่อมันข้อสองพูดถึง Self-Selecting อารมณ์จะประมาณ Natural selection คือแน่นอนว่าไม่ใช่ทุกคนที่จะเห็นคล้อยไปตามวัฒนธรรมที่เกิดขึ้นซึ่งเมื่อส่วนน้อยเห็นไม่ตรงกับส่วนใหญ่เขาก็มีทางเลือกอยู่หลายทางจะทนอยู่, จะสู้หรือจะออกไปประมาณนั้นครับ

พอพูดถึง How หรือการสร้างวัฒนธรรมให้เกิดขึ้นได้อย่างไรสิ่งสำคัญคือสภาพแวดล้อมครับเพราะสภาพแวดล้อมสามารถส่งเสริมให้พฤติกรรมมันเติบโตได้ (ถ้าดูสไลด์ในส่วนนี้คือต้นไม้ที่มีโครงครับ) ซึ่งก็เกิดคำถามว่าแล้วถ้าสภาพแวดล้อมไม่ดีมันเป็นไงก็เหมือนต้นไม้โตโดยเอากระถางครอบข้างบนมันครับมันโตก็จริงแต่โตได้แค่ในกระถางที่ครอบมันอยู่และในข้อนี้ยังทิ้งท้ายโดยเตือนไว้อีกว่า “ถ้าหากเราไม่สร้างวัฒนธรรมของเราขึ้นมาแล้วก็จะมีใครซักคนสร้างมันขึ้นมาแทน”

ในส่วนสุดท้ายพูดถึงGood Software Development Cultureที่พี่เขาแนะนำโดยสามารถไปดูได้ในสไลด์ที่แปะลิงค์ไว้ข้างล่างนะครับแต่ข้อที่ผมชอบที่สุดคือIntegrityหรือการซื่อสัตย์กับตัวเองต้องยอมรับผิดถ้าเราผิดไม่ใช่แถให้ตัวเองชนะโดยหนีเหตุผลที่เรายืนหยัดเพื่อมันในตอนแรกCross Pollenationซึ่งก็คือสิ่งที่ผมคิดว่าตัวเองทำอยู่บ่อยๆคือหาของเล่นใหม่ๆที่เห็นคนอื่นทำแล้วดีมาทำกับทีมตัวเองบ้างและสุดท้ายFocus on GOAL not SOLUTIONอันนี้โดนทีมจังๆเลย

(ลิงค์สไลด์ » http://slid.es/amptanawat/building-sw-dev-culture-for-any-scale)

Introduction to Scrum (A.K.A Agile 101)

หลังเบรคสำหรับ Session สุดท้ายนี่ผมไม่รู้จริงๆครับว่าจะเข้า Session ไหนคือเดินไปเหลือบมันทุกห้องจนมาหยุดที่ห้องนี้ (ซึ่งตอนแรกไม่มีในตาราง) สิ่งที่ผมได้รับจาก Session นี้ส่วนใหญ่เป็นสิ่งที่รู้หรือคิดว่าตัวเองรู้อยู่แล้วทั้ง Agile Manifesto, Agile Principle, Scrum, Kanban ฯลฯจึงไม่ได้จดอะไรเลยแต่ Session นี้ทำให้ผมคิดอะไรได้อย่างนึงคือในหลายๆครั้งเราก็ควรยกหัวโขนว่าตัวเองรู้อยู่แล้ววางไว้หน้าห้องแล้วทำตัวเป็นมือใหม่ไม่รู้อะไรเลยจะทำให้เรามองอะไรได้ชัดเจนยิ่งขึ้นและเปิดโอกาสให้เราได้เก็บเกี่ยวในสิ่งที่เราไม่เคยคิดว่ามันมีอยู่กลับมาด้วย

Panel-Discussion

หลังจากจบทุก Session สุดท้ายแล้ว Panel Discussion ซึ่งคราวนี้คือการทำ Fishbowl กันอีกรอบแต่รอบนี้ดีกว่ารอบใน Session เพราะได้เห็นกรณี dislike ชัดเจนกว่าส่วนเรื่องที่สนธนาก็เป็นคำถามที่หลากหลายมากและผมมัวแต่ฟังแบบฟินๆเลยไม่ได้จดอะไรมาเลย

Conclusion

สุดท้ายขอบคุณAgile66ที่จัดงานดีๆอย่างนี้ถึงแม้เป้าหมายที่ผมตั้งไว้ให้ตัวเองคือรู้จักคนใหม่ๆเพิ่มขึ้นมันจะไม่สำเร็จแต่อย่างน้อยผมก็ได้สนทนากับคน 2-3 คนซึ่งดีขึ้นกว่างานที่แล้วที่แทบไม่ได้คุยกับใครเลย (เพราะไปคนเดียวด้วยส่วนนึง) น่าเสียดายที่ Session หนึ่งมีเวลาแค่ 45 นาทีเพราะรู้สึกว่ามันจบเร็วเกินไปหลายๆอันยังค้างคา (แต่ก็ยังดีกว่า Barcamp ที่มีแค่ 30 นาที)

ปล.วันนี้เป็นครั้งแรกนับตั้งแต่ฝึกงานที่ได้ลง BTS เพลินจิตเรื่องเล็กๆแต่ความทรงจำไหลหลั่งมาเต็มๆ

Original post at: https://yothinix.blogspot.com/2013/12/agile-tour-bangkok-2013.html

สมัยตอนท้าย Project I เป็นช่วงที่เราเริ่มจะจริงจังกับการทำ Scrum เป็นอย่างมากและหนึ่งในเครื่องมือที่ช่วยให้เราทำ Scrum ได้ประสบความสำเร็จในระดับหนึ่งโดยจะไม่พูดถึงไม่ได้เลยก็คือ TFS ซึ่งหน้าตาก็เป็นดังรูปที่แปะอยู่ข้างล่างนี้แหละครับ

เสียดายไม่เคยแคปหน้าจอไว้ตอนทำงานแต่ก็จะหน้าตาประมาณนี้ทีนี้เนี่ยพอปิดเทอมไปเราก็ไปพัฒนา Technical Skill แยกกันไปซะส่วนใหญ่และยังไม่มีการใช้บอร์ดร่วมกันเลยเป็นโอกาสที่ผมได้ทดลองหาเครื่องมือใหม่ๆหลายตัวอีกครั้งแต่ไม่ว่าผมจะพยายามหาเพียงแค่ไหนมันก็ยังสนองความต้องการไม่ได้ผมต้องการเพียงแค่บอร์ดง่ายๆที่สามารถเอาไว้ดูงานได้ไม่ต้องมีฟีเจอร์หรูหรายุ่งยากซึ่งในที่สุดผมก็กลับมาสู่จุดเริ่มต้นที่ผมทำ Agile นั้นคือEidosครับ

ตัว Eidos เองเนี่ยตอนใช้แรกๆผมแฮปปี้กับมันมากครับมีฟีเจอร์แค่บอร์ด, ตัวจัดการ Backlog แล้วก็ Burndown ซึ่งเพียงพอกับความต้องการแล้วดูเหมือนจะมีความสุขใช่มั้ยครับไม่ครับผมประสบปัญหากับการลากแล้วค้างบ่อยมาก (วิธีแก้คือกด Refresh แล้วลากใหม่) ซึ่งแรกๆก็ทนใช้ได้ครับแต่นานๆไปมันเป็นปัญหาเกินไปแล้วนะผมเลยตัดสินใจเราต้องเปลี่ยนแล้วกระบวนการค้นหาจึงเริ่มต้นขึ้นอีกครั้งแต่ก็เหมือนครั้งที่แล้วไม่ว่าเราพยายามจะค้นหาแค่ไหนเราก็ไม่เคยเจอกับสิ่งที่ตรงกับที่เราต้องการจริงๆ (รอบนี้รู้สึกจะลองJIRAด้วยยิ่งใช้ยากหนักขึ้นไปอีก) สุดท้ายครับเราตัดสินใจกลับคืนสู่สามัญสู่จุดเริ่มต้นที่เราเคยได้ลองเพียงน้อยนิดและประสบความล้มเหลวกับ Project ก่อนหน้าไปและเราไม่ได้ใช้มันอีกเลยเรากลับมาลองมันอีกครั้งนั่นคือจุดเริ่มต้นที่เรากลับมาใช้Physical Board ครับ

จริงๆแล้วบอร์ดในภาพข้างบนไม่ใช่บอร์ดแบบแรกที่ทีมผมเอากลับมาใช้นะครับเนื่องจากตอนนั้นยังทำ Scrum กันอยู่ยังมี Sprint บลาๆเพราะฉะนั้นแล้วเนี่ยโครงสร้างบอร์ดจะมีรายละเอียดหลายๆอย่างมากกว่านี้ครับแต่หลังได้มีโอกาสไปฟังLean/Kanban Going beyond Scrumที่งานTPSEทำให้ผมเกิดไอเดียหลายๆอย่างครับสิ่งสำคัญก็คือ Scrum เยอะไปสำหรับทีมเราข้อเท็จจริงที่สำคัญที่สุดคือทีมเราต้องเรียนไปด้วยทำ Project ไปด้วยปัญหาที่เราเจอมาตลอดตั้งแต่เริ่มทำ Scrum และยังแก้ไม่ได้เลยก็คือเราไม่เคยส่งงานได้ครบทุกอย่างตามที่เราแบ่งไว้ในแต่ละ Sprint เลยกรณีดีสุดก็ยังเหลือซัก 1-2 งานเสมอซึ่ง Kanban ตอบโจทย์ข้อนี้ได้ครับเพราะมีกฏแค่ 3 ข้อ (ผมคงไม่ลงรายละเอียดนะครับ) แต่เราก็ยังมีกรอบที่เราต้องทำอยู่คือเราจำเป็นต้อง Release งานออกมาให้ได้ภายในทุกอาทิตย์ตาม Requirement ของอ.ที่ปรึกษาของทีมเราซึ่งการทำแบบนี้มันดียังไงพูดง่ายๆก็คือตั้งแต่เปลี่ยนมาใช้ Kanban ผมและทีมไม่เคยกังวลเกี่ยวกับ Task ที่ค้างเกินอาทิตย์อีกเลย (หรืออย่างน้อยก็กังวลน้อยลง) เพราะยังไงมันก็เป็น Flow ไหลไปเรื่อยๆของมันและนอกจากนั้นแล้วการที่เราหันไปดูบอร์ดแทนที่จะเปิดเว็บขึ้นมาลากๆรวมถึงความสะใจในการย้ายงานจาก Todo ไปจนถึง Done นั้นมันเป็นอะไรที่ฟินมากและเราส่งงานได้ต่อเนื่องขึ้นอย่างเห็นได้ชัดนั่นทำให้ผมมีเวลาทดลองอะไรบางอย่างดังรูปที่อยู่ข้างล่างนี้ครับ

ช่วงเวลาประมาณ 2 สัปดาห์ที่แล้วเป็นช่วงที่การเมืองอยู่ในภาวะ Unstable อย่างที่รู้กันแล้วทีมผมจากที่เคยรวมตัวกันทำงานอยู่ใน Office เดียวกันเลยได้โอกาสแยก (เนื่องจากมหาวิทยาลัยประกาศปิดแล้วตรงกับวันพ่อเลยหยุดยาวเลย) ผมเลยทำการทดลองกลับมาใช้บอร์ดอิเล็กอีกครั้งระหว่างที่เราไม่ได้นั่งอยู่ใน Office เดียวกันเป็นเวลาเกือบ 1 สัปดาห์และทำRetrospectiveหลังจากนั้นได้ผลดังต่อไปนี้ครับ

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

ทีมที่มีชีวิตต้องมีวิวัฒนาการ

แล้วเจอกันใหม่เอนทรี่หน้าสวัสดีครับ

Original post at: https://yothinix.blogspot.com/2013/12/adwise.html

Retrospective คืออะไร

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

ผมรู้จักการทำ Retrospective ครั้งแรกในวันเดียวกับที่ผมรู้จัก Agile เป็นครั้งแรกที่งาน Agile Thailand 2013 ในวันนั้นมี Session หนึ่งที่ผมไปเข้าในตอนบ่ายชื่อว่า Retrospective: The art of continuous improvement ซึ่งสิ่งที่ดีที่สุดใน Session นี้นอกจากได้รู้ว่า Retrospective คืออะไรแล้วยังได้ฟังประสบการณ์จริงๆด้วยว่าทำแล้วเกิดอะไรขึ้นต่อมาและนั้นคือเหตุผลให้ผมอยากทำมาตลอดแต่ไม่มีโอกาสและที่สำคัญไม่มีดราม่า

Drama นั้นสำคัญไฉน

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

Good Bad Try

จริงๆแล้ววิธีการทำ Retrospective นั้นมีหลายแบบมากๆแต่ที่ผมรู้จักและเลือกที่จะเอามาใช้คือ Good Bad Try ครับจริงๆแล้วผมบอกตามตรงเลยว่าผมไม่รู้ว่า Good Bad Try แบบจริงๆตามหลักการนั้นทำยังไงนอกจากมีคำว่า Good Bad Try และให้ทุกคนในทีมเอากระดาษโพสอิทไปแปะแต่สิ่งที่ผมจะกล่าวต่อไปคือขั้นตอนการทำ Good Bad Try ในแบบฉบับของทีมผมเอง

ขั้นแรกผมแจกกระดาษโพสอิทให้แต่ละคนในทีมโดยแต่ละคนก็จะได้สีแตกต่างกันไป (โชคดีที่ทีมผมมีแค่ 3 คนสีมันก็เลยไม่เยอะจนเกินไป) แล้วให้แต่ละคนในทีมเขียนใน 3 อย่างคือ

• สิ่งที่คิดว่าตัวเองทำได้ดี
• สิ่งที่คิดว่าตัวเองทำได้ไม่ดี
• สิ่งที่คิดว่าตัวเองควรจะปรับปรุง

ซึ่งแน่นอนว่าการให้มนุษย์ยอมรับข้อผิดพลาดของตัวเองหรือแม้กระทั่งบอกข้อดีของตัวเองนั้นเป็นเรื่องที่ยากมากพอๆกันผมกำหนดเวลาให้ 7 นาทีในการเขียนสิ่งดังกล่าวแล้วเอามันไปแปะมันไว้บนบอร์ดช่วงห้านาทีแรกเป็นช่วงที่ผมรู้สึกได้ทันทีเลยว่าเป็นช่วงเวลาเปิดใจทีมการจะเขียนอะไรสักอย่างลงไปในกระดาษกลายเป็นเรื่องที่ยากพอๆกับการเขียน Method เพื่อแก้ปัญหาซักอย่างหนึ่งแต่พอผ่านพ้น 5 นาทีแรกไปแล้วทุกคนในทีมก็เริ่มรู้สึกว่ามีอะไร “อยากจะเขียน” มากขึ้นเรื่อยๆหลายๆเรื่องเป็นเรื่องที่ชวนขบขันและไม่จริงจังแต่หลายๆเรื่องกลายเป็นเรื่องที่เราทุกคนในทีมไม่เคยคิดเลยว่าเราจะคิดเหมือนๆกันพอหมด 7 นาทีในขณะที่ทุกคนในทีมกำลังสนุกกับการเริ่มเขียนสิ่งที่ “ตัวเองคิด” ลงไปในกระดาษผมต่อเวลาให้ทีมอีก 3 นาทีจนหมดเวลาก็มีกระดาษโพสอิทติดอยู่ใต้หัวข้อเต็มไปหมด (โดยเฉพาะ Try)

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

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

เมื่อถึงเวลาดูบอร์ดหลายๆอย่างเป็นไปตามคาดไว้นั้นแสดงให้เห็นว่าไม่ว่าจะเป็นข้อดี, ปัญหาหรือสิ่งที่เราพยายามจะแก้ไขหลายๆอย่างนั้นดูเหมือนเราจะเข้าใจมันดีอยู่แล้วแต่หลายๆอย่างทีมของเราไม่เคยคิดมาก่อนเลยว่ามันจะเป็นปัญหาหรืออย่างน้อยในมุมมองของคนอื่นๆในทีมข้อสำคัญคือข้อความในกระดาษโพสอิทแต่ละอันก็เหมือน Task ที่เราเขียนไว้ใน Backlog หลายๆครั้งเราที่เราไม่เข้าใจว่าคนอื่นเขียนอะไรลงไปสิ่งที่จะตามมาก็คือเราต้องให้เจ้าของกระดาษโพสอิทนั้นอธิบายซึ่งถ้ายังไม่เข้าใจอยู่ต้องจบด้วยคำว่า “ยกตัวอย่างเช่น” (เอาเทคนิคนี้มาจาก TPSE Conference) เมื่อเรายกประเด็นในเรื่องใดขึ้นมาพูดแล้วสิ่งที่ตามมามักจะเป็นวิธีแก้ปัญหาและสิ่งที่คนนั้นควรจะปรับปรุงซึ่งหลายๆครั้งคนที่ถูกพูดถึงในการ์ดเองก็มองข้ามวิธีเหล่านี้ไปสิ่งนี้ผมถือว่าเป็นสิ่งที่เราได้อะไรมากที่สุดจากการทำ Retrospective ในครั้งนี้เลย

การจบ Retrospective

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

สิ่งที่ผมเรียนรู้จากการทำ Retrospective ครั้งนี้

• ทุกๆ คนในทีมรู้ตัวว่าเขียนโค้ดไม่สะอาด, เละเทะและไม่เป็นระเบียบมาก แต่ทั้งๆ ที่รู้ตัวก็ยังเขียนแบบเดิมอยู่อย่างนั้น
• เรามีทั้งแม่พระ, ตัวก่อดราม่า ในทีมเดียวกัน
• เรามักจะคิดว่าตัวเองขี้เกียจ ในขณะที่คนอื่นมองว่าเราขยัน
• ปัญหาใน Try ส่วนใหญ่ไม่ใช่ปัญหาในตัวงานแต่เป็นปัญหาที่เกี่ยวกับสภาพแวดล้อมการทำงาน
• ผมเป็นคนจริงจังเกินไปในสายตาของเพื่อนร่วมทีม ซึ่งก็เป็นทั้งข้อดีและข้อเสียในเวลาเดียวกัน

Original post at: https://yothinix.blogspot.com/2013/12/retrospective-drama.html

Keynote: Challenges of Managing a Complex Project - The Case Study of Landing a Rover on Mars

Session นี้ถือว่าเป็น Highlight ของงานเลยครับแค่คนพูดนี่ก็สุดๆแล้วDr.Firouz Naderiผู้อำนวยการโครงการสำรวจในระบบสุริยะทั้งหมดจาก NASA JPL เรียกได้ว่าตั้งแต่ดวงอาทิตย์ยันดาวพลูโต Dr. คนนี้มีเอี่ยวหมดโดยดร.ฟิรุสมาเล่าให้ฟังเกี่ยวกับโครงการสำรวจดาวอังคารที่แกกำลังทำอยู่โดยเริ่มการค่อยๆเกริ่นจากไอเดียภาพรวมของการทำโครงการซักโครงการนึงว่า 1)เราเริ่มจากการมีความฝันแล้ว 2)เราขายฝันจากนั้นแล้วในวันถัดมา 3)เราก็เริ่มจะคิดได้ว่า “กูมองโลกในแง่ดีเกินไปแล้วนะ” ซึ่งพอผ่านจุดนี้เราจะ 4)เริ่มทำงานหนักขึ้นที่ 60 ชั่วโมงต่อสัปดาห์และ 5)เราก็จะเริ่มเครียดขึ้นอีกเรื่อยๆจากปัญหาต่างๆที่รุมเข้ามาไม่ว่าจะเป็นปัญหาทางเทคนิค, งบหรือแม้กระทั่งกำหนดส่งปัญหาเหล่านี้จะส่งผลให้ 6)เราทำงานหนักขึ้นอีกเป็น 70 ชั่วโมงต่อสัปดาห์ซึ่งเมื่อถึงท้ายที่สุดแล้วไม่มีใครบอกได้ว่า 7)โครงการที่เราทำอยู่จะประสบความสำเร็จ….. หรือล้มเหลว

ดร.ฟิรุซบอกว่าในตอนเริ่มต้นของทุกโครงการทุกอย่างมักจะง่ายเสมอเขาใช้คำว่า “Give me the money I give you a profit” แต่ปัญหาก็คือบางคนที่เริ่มทำโครงการจากสิ่งที่คนอื่นทำมาก่อนแล้วนั้นมักจะไม่เข้าใจปัญหาพื้นฐานที่แท้จริงซึ่งเมื่อทำโครงการไปถึงจุดๆหนึ่งคนเหล่านั้นจะเจอทางตันจนไปต่อไม่ได้เหมือนกับนักวิ่งมาราธอนที่จะมีขีดจำกัดของตัวเองอยู่ (km ที่ 35) โดยดร. แนะนำว่าสิ่งแรกที่ควรจะทำในการทำโครงการที่ซับซ้อนมากๆไม่ใช่การหา Project Manager แต่เป็นเรื่องของทีมโดยดร.ฟิรุซสรุปสิ่งหน้าที่ๆสำคัญที่สุดของ Team Leader ให้เราไว้ 3 ข้อดังนี้

1. ต้องหาคนที่ “ดีที่สุด” ให้มาร่วมทีมกับเราให้ได้ซึ่งจะทำให้โอกาสที่ไอเดียที่เรามีประสบความสำเร็จได้สูงกว่าการหาคนที่ “ดีรองลงมา” แต่อย่างไรก็ตามการหาคนที่ดีที่สุดมาก็จำเป็นต้องทำให้แน่ใจให้ได้ว่าเขาเหล่านั้นเข้ากับคนอื่นในทีมได้เพราะคนที่ “เก่งที่สุด” ส่วนใหญ่มักจะมี EGO เสมอ
2. ต้องกระตุ้น (Motivate) ทีมให้มีความมุ่งมั่นอยู่ตลอดเวลาโดยดร. ได้ยก Quote ของ Antoine de Saint-Exupéry ซึ่งผมก็สารภาพตามตรงว่าอ่านมาหลายรอบแล้วก็ยังไม่เข้าใจความหมายของมันมาว่า“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea."
3. PM ควรจะต้องแชร์วิสัยทัศน์ร่วมกับทีมให้ตรงกันเหมือนนายพลกับกองทหารแต่ PM ที่ดีต้องยังเป็น Fair Leader ด้วยคือเป็นทั้งคนแรกที่รับคำด่าและคนแรกที่รับคำชม

หลังจากนั้นแล้วดร.ฟิรุซก็เริ่มยกตัวอย่างของMars Exploration Programโดยดร. บอกว่าเป้าหมายของการสำรวจดาวอังคารนั้นก็เพื่อตอบคำถาม 3 ข้อคือ 1) ดาวอังคารเคยอาศัยอยู่ได้หรือไม่ ? 2) ถ้าได้เคยมีสิ่งมีชีวิตอยู่รึเปล่า ? 3) ถ้ามีตอนนี้มันยังอยู่มั้ยดร.ฟิรุซเล่าต่อไปว่ายานสำรวจCuriosityเป็นวัตถุลำดับที่ 50 ที่ไปดาวอังคารหนึ่งใน 23 โครงการที่ลงจอดสำเร็จถ้านั่นยังไม่เห็นภาพพอดร.ฟิรุซเปรียบเทียบว่าการส่งวัตถุไปดาวอังคารก็เหมือนการเตะลูกฟุตบอลจากโตเกียวมาลงที่สนามราชมังฯกรุงเทพฯซึ่งถ้าคิดว่านั้นยากแล้วให้คิดภาพไปอีกว่าสนามหมุนด้วยความเร็ว 100,000 กม./ชม. แต่นั้นไม่ใช่สิ่งที่ยากที่สุดสิ่งที่ยากที่สุดไม่ใช่การเดินทาง 9 เดือนไม่ใช่การหาจุดที่ต้องลงจอดแต่เป็น 7 นาทีสุดท้ายก่อนที่ยานจะลงจอด

ใน 7 นาทีสุดท้ายของการลงจอดนั้นยานจะพุ่งไปด้วยความเร็วถึง 20,000 mph ซึ่งยานสำรวจในยุคต่างๆกันจะใช้เทคนิคต่างกันโดยรุ่นแรกๆจะใช้ Airbags คือส่งตกลงไปก็เป็นลูกบอลลมกลิ้งไปกลิ้งมาจนหยุดแต่สำหรับ Curiosity นั้นไม่สามารถทำได้เนื่องจากมันใหญ่และหนักมากพอๆกับรถเก๋งคันหนึ่งเลยทีเดียวเลยต้องใช้เทคนิคพิเศษซึ่งสามารถไปค้นได้ตามWikipediaนะครับ

พอลงจอดได้แล้วทำไรต่อคำถามที่นักวิทยาศาสตร์ต้องการคำตอบก็คือมันเกิดอะไรขึ้นที่นี่เมื่อ 1000 ปีที่แล้วซึ่งดร.ฟิรุซก็อธิบายให้ฟังว่าประวัติศาสตร์ของดาวนั้นจริงๆแล้วเขียนอยู่ในหินในแต่ละ Layer เหมือนหนังสือประวัติศาสตร์โดยคนที่อ่านหินพวกนั้นออกก็เดาได้ไม่ยากเลยนักธรณีวิทยาซึ่งนั่นก็ทำให้เกิดคำถามกับพวกเราว่าทำไมไม่ส่งคนจริงๆไปหล่ะดร.ฟิรุซได้ให้สาเหตุไว้ 4 ข้อคือ

1. Technical Problem เพราะเรายังไม่รู้ว่าจะขนของน้ำหนัก 40 ตันไปดาวอังคารยังไง
2. Psychological Problem เพราะเราไม่รู้ว่าคนเราจะทนอยู่ใน Small Capsule ได้ถึง 9 เดือนหรือไม่
3. Biological Problem เพราะเราไม่รู้ว่าการอยู่ในอวกาศ นานขนาดนั้นจะส่งผลต่อร่างกายยังไงบ้าง
4. Financial Problem อันนี้คงไม่ต้องอธิบาย ประมาณการไว้ว่าต้องใช้งบถึง Half Trillion Dollar เพราะฉะนั้นแล้วเนี่ยทาง NASA ถึงได้ส่งหุ่นไปทำหน้าที่แทนมนุษย์

หลังจากเกริ่นเรื่องการสำรวจดาวอังคารมาพอหอมปากหอมคอดร.ฟิรุซก็ได้พาเราย้อนกลับมาสู่เรื่องของโครงการกันต่อโดยเล่าให้เราฟังว่าปัญหาแรกอยู่ที่เรามีงบประมาณจำกัด (จากการเปลี่ยนผอ. ใหม่) เริ่มต้นเพียงแค่ 100M Dollar แต่ทีมก็ทำสำเร็จทำให้ได้เพิ่มงบจาก 240M เป็น 250M ซึ่งทำให้ดร.ฟิรุซสามารถทำโครงการสำรวจได้มากถึง 2 โครงการแต่ทุกโครงการย่อมมีความเสี่ยง 2 โครงการดังกล่าวล้มเหลวอย่างสิ้นเชิงซึ่งดร. ก็ได้ให้ข้อคิดที่ดีกับเราว่า “อย่ากลัวที่จะล้มเหลวและอย่าสิ้นหวังกับความล้มเหลวถ้าเราได้เรียนรู้จากความผิดพลาดที่ก่อให้เกิดความล้มเหลวความล้มเหลวนั้นก็ไม่ใช่ความล้มเหลวซะทั้งหมด” นอกจากนี้ดร.ฟิรุซยังแนะอีกว่าให้เราในฐานะ PM ยอมที่จะเสี่ยงกับโครงการที่ High Risk, High Reward โดยตัวดร.ฟิรุซเองนั้นมักมองหาโครงการที่ยากที่สุดเสมอโดยทำตามสูตร 3 ข้อของโครงการข้างบนแล้วโอกาสสำเร็จจะมากขึ้นเอง

ในการทำงานที่ NASA นั้นทุกครั้งที่มีการนำเสนอโครงการให้จะมี PM ของโครงการเก่าๆนั่งพิจารณาด้วยอยู่เสมอและบ่อยครั้งที่เรามักจะคิดผิดไปแต่บางครั้งเราก็ไม่ได้คิดผิดไปมากขนาดนั้นดร.ฟิรุซเล่าถึงโครงการ Mars Exploration Rover ว่าขณะ 1 ปีก่อนส่งจรวดทีมเขาก็ยังหาวิธีที่จะสร้าง Air Bag ไม่ได้เลยนอกจากนั้นแล้วยังเจอข้อจำกัดจากการที่จะสามารถส่งวัตถุไปดาวอังคารได้ภายในทุกๆ 26 เดือนเท่านั้นและโอกาสที่จะปล่อยจากโลกมีเพียงแค่ 21 วันซึ่งดร.ฟิรุซทำโครงการเสร็จแต่ใช้งบเกินไป 18% จากตอนขอครั้งแรกนอกจากนั้นแล้วดร.ฟิรุซยังยกตัวอย่างไว้อีกว่าช่วงวิกฤตของโครงการเช่นตอนกางร่มนั้นต้องการระยะที่เฉพาะมากๆแต่ก็มีปัญหาเข้ามาอีกคือช่วงนั้นเกิดพายุทรายในดาวอังคารซึ่งดร.ฟิรุซได้ฝากข้อคิดไว้ว่า “ในโครงการที่มีความซับซ้อนมากๆเราไม่เคยมีข้อมูลที่ครบถ้วนสำหรับการตัดสินใจและบ่อยครั้งที่เราต้องตัดสินใจจากข้อมูลที่ไม่สมบูรณ์แบบ”

ในช่วงของคำถามก็ยังมีคำถามที่น่าสนใจหลายๆคำถามด้วยกันโดยเฉพาะคำถามแรกที่มีผู้ถามดร.ฟิรุซว่าเราจะรวมทีมที่เป็น “The Avenger” เข้าด้วยกันได้ไง (คืนก่อนไปงานผมเพิ่งดู) ดร.ฟิรุซตอบโดยยกตัวอย่างเวลาเราอยู่ในสงครามนั้นถ้าคนเราโดนถล่มอยู่ในป้อมเดียวกันสุดท้ายแล้วทุกคนก็จะเริ่มสู้ด้วยกันเป็นทีมในสถานการณ์เดียวกันแต่อย่างไรก็ตามสำหรับทีมที่เป็น Super Star ต้องทำให้เขารู้สึกสบายใจที่จะทำงานด้วยได้และถ้ามีปัญหาก็ควรจะบอก PM ทันทีโดยที่ NASA การที่เราบอกถึงปัญหาและแก้ปัญหาได้จะทำให้เรานั้นรู้สึกเป็นเกียรติมากแต่สิ่งสำคัญและเป็นบทสรุปของคำตอบคือเราต้องWork on human personalityนอกจากนั้นแล้วก็ยังมีคำถามอื่นๆที่น่าสนใจเช่นทำไมเราไม่ส่งคนไปดาวอังคาร, ทำไมเราต้องสำรวจดาวอังคาร (ข้อนี้ทำให้ได้ความรู้ว่าจุดต่อไปที่ NASA สนใจคือดวงจันทร์ Europa ของดาวพฤหัส), เราจะจัดการความเปลี่ยนแปลงที่เกิดขึ้นอย่างไร (ได้ศัพท์ใหม่Requirement Creep ) และข้อสุดท้ายการสำรวจดาวอังคารเราจะออกแบบการจำลองสถานการณ์อย่างไรดร.ฟิรุซปิดท้ายด้วยคำตอบ “Test as you fly, Fly as you test”

ปล.แค่ Keynote วันแรกก็ซัดไป 1 Entry เต็มๆ แล้วจะพยายามมาส่งที่เหลือให้เร็วที่สุดครับ

Original post at: https://yothinix.blogspot.com/2013/11/tpse-conference-2013-1-keynote.html

Release Backlog แรกสุดที่ทำ มีแค่ Excel

ผมเริ่มต้นการศึกษาหลักการนี้จากงาน Agile Thailand 2013 แล้วต่อยอดมาอ่านAgile SamuraiและScrum Primerซึ่งสุดท้ายแล้วก็เลือกที่จะนำเอาแนวคิด Scrum มาใช้ในการทำ Project อย่างที่ท่านๆได้เคยเห็นไปแล้วในบล็อกตอนก่อนๆเครื่องมือที่ใช้ในช่วงแรกๆนั้นมีแค่ Excel, Post-It และ Whiteboard แค่นั้นในการทำ Backlog Grooming ครั้งแรกซึ่งการคุยกันครั้งแรกสามารถแตก User Story บางเรื่องที่ไม่เคยคิดว่าจะใหญ่ออกเป็นก้อนเล็กๆได้และสามารถคิด Feature เพิ่มขึ้นมาได้หลายอย่างด้วยพอเรียงลำดับความสำคัญกันเสร็จผมและทีมก็ประสบปัญหาทันทีคือจะเอามันไปไว้ตรงไหนให้ดูได้ตลอด Story ในเวลานั้นก็เลยย้ายไปติด Product Backlog ไว้มุมห้องมุมหนึ่งซึ่งสรุปในเวลาต่อมาไม่นานว่าแทบไม่มีใครดูเลยเพราะมันติดกันอัดแน่นมากผมจึงเริ่มมองหาเครื่องมือใหม่อีกครั้ง

โชคไม่ดีที่หลังจากนั้นไม่นานผมและทีมตัดสินใจที่จะเปลี่ยนหัวข้อการทำ Project ใหม่สิ่งที่ส่งผลตามมาคือทุกอย่างที่เราเคยทำไว้ก่อนหน้านี้ถือว่าเซตซีโร่, ยกเข่งทำใหม่หมดช่วงนั้นหนึ่งในเรื่องพื้นฐานที่สุดที่ต้องเปลี่ยนคือเราต้องการ Tool ที่ทุกคนสามารถที่จะเข้าไปดูความคืบหน้าของแต่ละคนได้และสามารถรองรับแนวคิด Scrum ที่เรากำลังยึดถือกันอยู่ได้ความต้องการแค่นี้หลังจากนั้นเป็นการหาข้อมูลและผมค้นพบว่ามีการถกเถียงกันอย่างกว้างขวางในเรื่องของ Tools ในสังคม Agile หลายๆที่ไม่ว่าจะเป็นใน Stack overflow, ตามบล็อกอิสระทั่วไปหรือแม้กระทั่งในกลุ่มAgile66เองแต่นอกจากแนวคิดที่ใช้แค่ Post-It กับกระดานบอร์ดนั้น Tools ที่ใช้มีหลักๆที่คนแนะนำอยู่ไม่กี่ตัวหนึ่งในนั้นคือ Trello

Trelloเป็นหนึ่งในเครื่องมือที่ใช้ในการทำ Agile ได้ง่ายที่สุดและเร็วที่สุดเพราะแทบจะไม่มีอะไรเลยนอกจาก Kanban board ซึ่งเอาเข้าจริงก็ตอบโจทย์ผมได้ในระดับนึงเลยทีเดียวความสามารถในการปรับแต่งตัวโครงสร้างของบอร์ดให้รองรับกับรูปแบบของทีมถือว่าเป็นจุดเด่นอย่างหนึ่งที่ผมยอมรับเลยว่า Trello ทำออกมาได้ดีมาก (แต่ก็อย่าลืมว่าเครื่องมือส่วนใหญ่หลายๆตัวก็สามารถปรับแต่งในจุดนี้ได้) ผมยอมรับตามตรงว่าไม่ได้มีโอกาสสัมผัส Trello อย่างจริงจังมากเพราะในตอนนั้นผมคิดแต่เพียงว่าในเมื่อมันเป็นแค่ Board และตัวอื่นๆก็สามารถทำได้หมดทำไมไม่หาเครื่องมือที่มันครบเครื่องกว่านี้หล่ะ (เป้าหมายจริงๆคืออยากได้เครื่องมือที่วาด Burndown Chart ให้ได้พอมาคิดดูตอนนี้ทำไมแนวคิดผมโคตรเด็กเลยแหะ)

จริงๆผมมีเครื่องมือที่อยากพูดถึงอีกหลายตัวก่อนจะเข้า TFS ซักทีตัวสุดท้ายที่ผมอยากจะพูดถึงก่อนเราจะเข้าเรื่องหลักที่จะมาพูดกันในวันนี้คือAsanaครับ Asana เป็น Project Management Tool ที่เพิ่งเปิดตัวได้ไม่นานเป็นผลงานของ Dustin Moskovitz (Facebook Co-founder) และทีมงานซึ่งด้วยเหตุนี้ทำให้เครื่องมือตัวนี้ออกจะโด่งดังอยู่ซักหน่อยจุดเด่นจริงๆของ Tool ตัวนี้คือ Task Management โดยหลักการแล้วแทบไม่แตกต่างจากBasecampหรือตัวอื่นๆมากนักแต่ที่ประทับใจที่สุดก็คงจะเป็น UX ที่วืดวาดๆได้ถูกใจวัยรุ่นเป็นอย่างมากรวมถึงระบบส่ง email ในการแจ้งเตือน Task ที่ใกล้จะเสร็จก็พูดตามตรงว่าโคตรน่ารำคาญแต่ได้ผลมากระดับนึงอย่างไรก็ตามผมมองว่าสำหรับทีมผมการที่เราไม่เลือกใช้เครื่องมือตัวนี้มีเพียงเหตุผลเดียว “มันไม่มีบอร์ดงาน”

Microsoft Team Foundation Serviceมาเตะตาผมตอนที่ผมคิดจะเริ่มไปใช้ Microsoft Project แต่ด้วยเหตุผลบางอย่างผมมองว่า Microsoft Project เป็นเครื่องมือที่โบราณและอุ้ยอ้ายเกินกว่าที่จะทำ Agile ได้ผมเลยผ่านมาหา TFS อีกรอบจริงๆแล้วนี่ไม่ใช่ครั้งแรกที่ผมคิดจะใช้ TFS ตอนช่วงระหว่างฝึกงานภาคฤดูร้อนผมเคยมีแนวคิดที่จะใช้ TFS ในการจัดการงานที่ทำในช่วงฝึกงานอยู่พักนึง (เนื่องจากตอนนั้น Scale งานเริ่มใหญ่ขึ้นเรื่อยๆ) แต่การที่ในช่วงฝึกงานยังมีความรู้ในแนวคิดของ Agile และ Scrum อยู่น้อยมากทำให้ความพยายามในการใช้งานครั้งแรกไม่ประสบความสำเร็จซักเท่าไรและผมก็ลืมมันไปจนกระทั่งอย่างที่บอกลอยมาเตะตาอีกครั้งต้องสารภาพไว้ก่อนว่าผมได้ใช้ TFS แค่ในส่วนของ Work Management แค่นั้นในส่วนของ Source code management และ Build/Test Server ผมไม่ได้แตะมันเลย (เนื่องจากโปรเจ็คของทีมผมเป็น PHP-Based)

เนื่องจากทีมของผมเป็นทีมที่โคตรมีขนาดเล็ก (มีกันอยู่ 3 คน) ทำให้สามารถใช้โปรโมชั่นฟรีของเครื่องมือหลายๆตัวได้ TFS เองก็เป็นหนึ่งในนั้นโดยมี Free Plan ไว้จำกัดที่ไม่เกิน 5 User ตัว TFS เองมาพร้อมกับ Process Template ทั้ง Agile และ CMMI โดย Template ที่ทีมผมเลือกใช้คือ Microsoft Visual Studio Scrum 3.0 ซึ่งตอบโจทย์ผมได้พอดีจากที่กล่าวไปในตอนต้นว่าผมใช้ Scrum เป็นแนวคิดหลักในการทำงานของทีมเครื่องมือที่ TFS มีมาให้พูดจริงๆก็เรียกได้ว่าครบครันพอเพียงตรงตามความต้องการหลายๆอย่างไม่ว่าจะเป็นตาราง Backlog ตั้งแต่ในระดับ Release จนถึงในระดับ Sprint, Cumulative Flow, เครื่องมือวัด Team Velocity และ Board ในการทำงานพร้อม Burndown Chart ที่ไว้คอยจับคนอู้ได้อย่างชัดเจน

Sprint Backlog ช่วงท้ายๆ Project I

ในช่วงเดือนกันยายนปี 2013 ซึ่งเป็นช่วงที่เข้มข้นที่สุดของ Project I เลยก็ว่าได้ผมยอมรับเลยว่า TFS มีส่วนช่วยมากกว่า 50% ในการจัดการงานให้ทีมของผมสามารถทำสำเร็จลุล่วงไปได้จนถึงการสอบปัญหาที่เจอในช่วง Sprint แรกคือทีมผมไม่สามารถประเมินเวลาการทำงานได้อย่างต่อเนื่องอาจจะยังเป็นเพราะยังไม่ชินกับการทำงานในแบบนี้ (ลากจาก To-dos->Done ทีเดียวตอนงานเสร็จ) ทำให้พอจบ Sprint 1 ต้องมาคุยกันอีกรอบว่าต้องขยันอัพเดทบอร์ดกันมากกว่านี้และสิ่งที่เป็นปัญหาอีกอย่างคือการไม่ได้กำหนด Definition of Done ของหลายๆงานที่สร้างกันไว้ทำให้คำว่าเสร็จของแต่ละคนในทีมความหมายไม่ตรงกันและสุดท้ายมันก็ไม่เสร็จ (ในความหมายของทุกคน (แต่อาจจะเสร็จในความหมายของบางคน)) ซึ่งนี่ก็เป็นอีกจุดหนึ่งที่ทีมผมพยายามปรับปรุงกันตลอด 4 Sprint

อย่างไรก็แล้วแต่สิ่งสำคัญที่สุดสิ่งหนึ่งที่ได้เรียนรู้หลังจากการทำงานใน Project I ผ่านไปคือยิ่งทีมนั่งทำงานด้วยกันมากเท่าไรโอกาสที่ Flow การทำงานมันจะไหลไปได้เร็วโดยไม่ขลุกขลักก็มีสูงขึ้นมากเนื่องจากในช่วงแรกๆจนถึงกลางๆของการทำ Project I ผมเป็นคนเดียวในทีมที่แยกออกมานั่งทำงานจากคนละที่กับทีมทำให้เจอปัญหาสำคัญคือการสื่อสารไม่เข้าใจกันและทำให้เกิดความไม่เข้าใจกันในเรื่อง Definition of Done อย่างที่กล่าวไปแล้วขอกล่าวไว้ก่อนว่าผมไม่ได้บอกว่าการทำงานแบบ Remote เป็นสิ่งที่ไม่ดีแต่การจะทำงานแบบนั้นได้มีประสิทธิภาพให้ใกล้เคียงกับการทำงานด้วยกันในที่เดียวกันคือต้องสื่อสารกับทีมให้เคลียร์และไม่ค้างคาตลอดเวลาของการทำ Project ไม่ใช่เพียงเฉพาะช่วงเริ่มต้น (แต่ช่วงเริ่มต้นอาจจะมากหน่อย)

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

ปล.Project II ปัจจุบันผมเลิกใช้ TFS แล้วครับด้วยเหตุผลบางอย่าง…

Original post at: https://yothinix.blogspot.com/2013/11/tde-3-team-foundation-service.html

• Individuals and interactions over processes and tools
• Responding to change over following a plan

ในหลักปรัชญาแบบ Zen ได้มีการกล่าวถึงความคิดของผู้เริ่มต้น (Beginner’s mind) ไว้ว่า

ในความคิดของมือใหม่ โอกาสมีอยู่มากมาย แต่ในความคิดของมืออาชีพ โอกาสมีอยู่ไม่มากนัก

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

ความต้องการแต่ละคนนั้นแตกต่างกัน การเลือกใช้ Tools ใดๆ ก็ตามก็ต้องคำนึงถึงจุดนั้นด้วย คุณไม่สามารถจะใช้ Tools ตัวเดียวกันในทีมที่แตกต่างกัน แม้ว่าความแตกต่างนั้นจะน้อยมากก็ตาม สิ่งที่ผู้ถามต้องการกับสิ่งที่ผู้ตอบต้องการบางครั้งก็ไม่ใช่สิ่งเดียวกัน บางทีมอาจจะต้องการเครื่องมือในการประเมิน เพื่อปรับปรุงความสามารถในการทำงานของทีมอย่างต่อเนื่อง, บางทีมต้องการเพียงแค่บอร์ดงานเพื่อจะได้รู้ว่างานทำไปถึงไหนแล้ว สิ่งเหล่านี้คือความแตกต่างของความต้องการในแต่ละทีม ในฐานะผู้ตอบบางครั้งจากประสบการณ์เพียงอย่างเดียวก็ไม่สามารถตอบโจทย์ผู้ถามได้ และสิ่งที่ควรทำก็คือหาความต้องการของทีมและหาเครื่องมือที่ดีที่สุดให้เขาไป ซึ่งบางครั้งสุดท้ายแล้วอาจจะจบลงด้วยการใช้แค่ Post It กับ Whiteboard เกลี้ยงๆ แค่นั้นก็ได้

Agile Manifesto ข้อแรกระบุไว้อย่างชัดเจนว่า Individuals and Interactions over processes and tools ซึ่งนำผมกลับมาที่คำถามสุดท้ายแล้ว ที่ว่าสิ่งที่เราต้องการคืออะไร ไม่ใช่เพื่อการสื่อสารภายในทีมเหรอ ทำไมต้องมานั่งกังวลว่าเราควรจะใช้ Tools ตัวไหนดีหรือไม่ดี และถ้ามันไม่ดีเราก็ควรจะ Responding to change ไม่ใช่หรือ ตอนนี้ผมว่าผมยึดติดกับอะไรบางอย่างมานานเกินไปแล้ว น่าจะถึงเวลาลองสิ่งใหม่ๆ ดูเผื่อความคิดของมือใหม่ มันจะกลับมาอีกครั้ง

ปล.ที่เขียนเรื่องนี้จุดประสงค์จริงๆ คืออยากจะเตือนสติตัวเองมากกว่า ไม่ได้พาดพิงใครนะครับ

Original post at: https://yothinix.blogspot.com/2013/10/individuals-and-interactions-over.html

ไหนๆ วันนี้ก็ได้ Applied Scrum เข้ากับ Project อย่างเต็มตัววันแรกละ ขอเขียนอะไรไว้เป็นที่ระลึกหน่อย

จริงๆ ผมตั้งใจไว้ว่าจะสอนทีม Senior Project ทำ Agile Methodology มาซักพักแล้ว ไอเดียนี้มันติดใจมาตั้งแต่ครั้งไปร่วมงาน Agile Thailand 2013 แต่ติดปัญหาอยู่สองสามข้อ อย่างแรกคือ ผมยังมีความรู้พื้นฐานเรื่อง Agile ไม่มากพอ อย่างที่สอง ผมยังมองภาพรวมของ Project ตัวเองไม่ออก อย่างที่สามสำคัญสุดขี้เกียจ

เวลาผ่านไปเดือนกว่าๆ ถ้าไม่นับเรื่องเชียร์ เร่งส่ง Proposal และก็หาข้อมูลเกี่ยวกับ Data Mining ถ้าผมว่าง ผมก็จะพยายามหาความรู้เพิ่มเติมเกี่ยวกับ Agile มาโดยตลอด แรกๆ ก็หา Tools บ้างแต่ยังไม่ครบเพราะได้ Tools มาก็ใช้ไม่เป็น แถมมีคนแขวะ ไว้อีกว่า Collaboration more than tool เพราะฉะนั้นจะไปสนทำไม (แต่ก็ยังสนอยู่) จนกระทั่งผมค้นพบหนังสือ The Agile Samurai ซึ่งผมคิดว่าเป็นหนังสือที่อ่านง่าย อ่านสบาย เกี่ยวกับ Agile เล่มนึง แต่ผมอ่านจบไปแค่ Part II เพราะเจียดเวลามาอ่านไม่ได้จริงๆ เนื้อหา Data Mining บีบ ทำให้ผมต้องรีบหาวิธีทำ Agile แล้วมาประยุกต์ใช้กับทีมให้เร็วที่สุด ก่อนที่ทีมจะทำงานไปมากกว่านี้

ผมรู้จัก Scrum มาจริงๆ ก็เกือบปีแล้ว ตั้งแต่น้อง Xenon เอามาแนะนำให้รู้จักที่ CSAG ใช้เป็นวิธีการประชุม แต่เนื่องด้วยตอนนั้นผมยังไม่สนใจ Software Development จริงๆ จังๆ เลยไม่สนใจเท่าไร ผมมาสะดุดอีกทีก็หลังจากงาน ATH2013 มีคนแชร์ภาพ Scrum Process เป็นภาพการ์ตูนญี่ปุ่นโมเอะ ดังภาพข้างล่าง ซึ่งสะดุดตาเป็นอย่างมาก จนกระทั่งมาถึงเมื่ออาทิตย์ก่อน ผมพอมีเวลาว่างหาข้อมูลเกี่ยวกับ Agile อีกก็ไปสะดุดเข้าที่เว็บ http://scrumprimer.org/ ซึ่งเป็นคู่มือการทำ Scrum เบื้องต้น แบบสั้นๆ ซึ่งระหว่างค้นหาข้อมูลผมก็ค้นพบอีกว่ามีพี่ๆ ในกลุ่ม Agile66 เคยมีโครงการแปลหนังสือเล่มนี้เป็นภาษาไทยด้วย ค้นไปจนเจอจนได้ต้นฉบับมาแล้วผมก็อ่านครับ ภายใน 30 หน้าผมตรัสรู้ อย่างน้อย ปัจจัยข้อแรกเรื่องที่ผมไม่มีความรู้พื้นฐานก็หายไปละ ผมพร้อมละที่จะประยุกต์ใช้ Scrum ในทีมผม มันต้องออกมาดูดีแน่ และผมก็ไม่ต้องใช้ Waterfall ที่โคตรหน้าเบื่อเหมือนกลุ่มอื่นซักที เย้ คิดแค่นี้ก็ตัวลอยละครับ

http://scrumprimer.org/anime

ผมเตรียมตัวอ่านอยู่สองสามรอบ จนเข้าใจระดับหนึ่ง หนังสือ Scrum Primer เหมาะสำหรับทีมที่ทำ Scrum ใหม่ๆ มากครับ เพราะเตรียมเนื้อหาไว้ให้พอเพียง ผมเข้าใจว่าทีมผมยังใหม่กับ Agile มาก เพราะอย่างน้อยวิชา SE ก็ไม่ได้เน้นในจุดนี้ มากนัก ก็คือต้องเริ่มใหม่เกือบหมด แต่ยังไม่เป็นไร วิธีที่ผมถ่ายทอดให้เพื่อนจะคล้ายๆ กับเวลาเรียนวิชาอะไรวิชาหนึ่งแล้วมาสรุปให้เพื่อนฟัง (จริงๆ ผมก็สรุปเป็น Bullet เก็บไว้เองแล้วชุดหนึ่ง) แล้วมาถ่ายทอดให้ฟัง ไล่ไปทีละจุดตามเนื้อหาใน Scrumprimer ประกอบกับภาพ Overview ใช้ได้ผลดี จนทีมมีความรู้ ความเข้าใจ Scrum ตั้งแต่ Role ของแต่ละคน Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrum, Burndown Chart, Product Backlog Refinement อาจจะไม่เข้าใจ 100% แต่อย่างน้อยก็พอจะเข้าใจ Concept ได้ว่าคืออะไร ไว้พอจะประยุกต์ใช้และถ่ายทอดต่อไปได้ แค่นี้ผมก็ดีใจแล้วครับ (ที่หนีพ้น Waterfall ได้มากขึ้นก้าวหนึ่ง)

Original post at: https://yothinix.blogspot.com/2013/07/scrum-1st-day-introduction-to-scrum.html