Agile

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

หนึ่งในวิชาบังคับที่ผมต้องเรียนให้ผ่านก่อนจบปี 4 คือวิชาสัมมนาครับเป็นวิชาที่นศในชั้นปีที่ 4 จะต้องแบ่งกลุ่มกันแล้วไปเชิญวิทยากรมาจัดงานสัมมนาหรือพูดง่ายๆมาบรรยายนั่นเองครับโดยในสัปดาห์นี้เป็นความรับผิดชอบของกลุ่มผมกับเพื่อนอีก 10 ชีวิตได้ช่วยกันจัดงานขึ้นมาในเช้าวันนี้ซึ่งวิทยากรก็ไม่ใช่คนที่ไหนไกลก็คือคุณกุลวัฒน์วงศาโรจน์หรือพี่ปอมจากกลุ่ม Agile66 นั่นเองครับ ระหว่างที่กลุ่มอื่นก็จัดงานสัมมนาไปในช่วง 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 แบบต่างๆกันแต่ละกลุ่มพัฒนาการและเทคนิคที่ซับซ้อนของแต่ละกลุ่มผมไม่รู้ว่าเพื่อนที่เล่นอยู่สนุกมั้ยแต่ผมรู้สึกดีมากที่ได้เห็นกิจกรรมแบบนี้รู้สึกดีจริงๆบรรยายไม่ถูกเลย ...

เมื่อประมาณ 6 เดือนที่แล้วมีงาน Event หนึ่งที่เปลี่ยนชีวิตผมไปตลอดกาลงานนั้นคือ Agile Thailand 2013 อย่างที่ผมพูดถึงมาหลายๆครั้งและตลอดหลายเดือนที่ผ่านมาความรู้ความเข้าใจในอไจล์นั้นก็เพิ่มขึ้นตามเวลาเป็นเหมือนขนมที่กินเท่าไรก็ไม่เบื่อ (อย่างน้อยก็ตอนนี้) และกินมาตลอดหลายเดือนด้วยความเอร็ดอร่อยในวันนี้ความรู้สึกหลังจากไปงานAgile Tour Bangkok 2013มาคือผมรู้สึกสดใหม่อีกครั้งผมก็ไม่รู้จะบรรยายยังไงให้เข้าใจว่ามันฟินมากเพื่อไม่ให้เสียเวลาไปมากกว่านี้ข้างล่างคือสรุป Session ที่ผมไปนั่งฟังมาในงานวันนี้ครับ 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 ให้เขียนต่อนะครับ ...

เอนทรี่นี้ถ้าจะให้พูดตามตรงก็เหมือนภาคต่อของTDE&W (3) :: Team Foundation Serviceเลยทีเดียวเพราะในเอนทรี่ดังกล่าวผมทิ้งท้ายไว้ว่าปัจจุบันผมไม่ได้ใช้ TFS แล้วอย่างไรก็ตามเอนทรี่นี้ก็ไม่ใช่สิ่งที่ผมตั้งใจจะเขียนแต่แรกเพราะผมอยากจะพูดถึง Process ด้วยเพียงแต่ว่าวัฒนธรรมของเราที่ AdWise ยังคงมีวิวัฒนาการอย่างต่อเนื่อง, เปลี่ยนแปลงและเพิ่มขึ้นอย่างมากในช่วง 2 เดือนที่ผ่านมาทำให้ผมคิดว่าเรื่องกระบวนการทำงานผมรอให้ใกล้ๆจบ Project II ค่อยพูดถึงน่าจะดีกว่าวันนี้เราจะมาพูดถึงบอร์ดกันครับ สมัยตอนท้าย Project I เป็นช่วงที่เราเริ่มจะจริงจังกับการทำ Scrum เป็นอย่างมากและหนึ่งในเครื่องมือที่ช่วยให้เราทำ Scrum ได้ประสบความสำเร็จในระดับหนึ่งโดยจะไม่พูดถึงไม่ได้เลยก็คือ TFS ซึ่งหน้าตาก็เป็นดังรูปที่แปะอยู่ข้างล่างนี้แหละครับ เสียดายไม่เคยแคปหน้าจอไว้ตอนทำงานแต่ก็จะหน้าตาประมาณนี้ทีนี้เนี่ยพอปิดเทอมไปเราก็ไปพัฒนา Technical Skill แยกกันไปซะส่วนใหญ่และยังไม่มีการใช้บอร์ดร่วมกันเลยเป็นโอกาสที่ผมได้ทดลองหาเครื่องมือใหม่ๆหลายตัวอีกครั้งแต่ไม่ว่าผมจะพยายามหาเพียงแค่ไหนมันก็ยังสนองความต้องการไม่ได้ผมต้องการเพียงแค่บอร์ดง่ายๆที่สามารถเอาไว้ดูงานได้ไม่ต้องมีฟีเจอร์หรูหรายุ่งยากซึ่งในที่สุดผมก็กลับมาสู่จุดเริ่มต้นที่ผมทำ Agile นั้นคือEidosครับ ตัว Eidos เองเนี่ยตอนใช้แรกๆผมแฮปปี้กับมันมากครับมีฟีเจอร์แค่บอร์ด, ตัวจัดการ Backlog แล้วก็ Burndown ซึ่งเพียงพอกับความต้องการแล้วดูเหมือนจะมีความสุขใช่มั้ยครับไม่ครับผมประสบปัญหากับการลากแล้วค้างบ่อยมาก (วิธีแก้คือกด Refresh แล้วลากใหม่) ซึ่งแรกๆก็ทนใช้ได้ครับแต่นานๆไปมันเป็นปัญหาเกินไปแล้วนะผมเลยตัดสินใจเราต้องเปลี่ยนแล้วกระบวนการค้นหาจึงเริ่มต้นขึ้นอีกครั้งแต่ก็เหมือนครั้งที่แล้วไม่ว่าเราพยายามจะค้นหาแค่ไหนเราก็ไม่เคยเจอกับสิ่งที่ตรงกับที่เราต้องการจริงๆ (รอบนี้รู้สึกจะลองJIRAด้วยยิ่งใช้ยากหนักขึ้นไปอีก) สุดท้ายครับเราตัดสินใจกลับคืนสู่สามัญสู่จุดเริ่มต้นที่เราเคยได้ลองเพียงน้อยนิดและประสบความล้มเหลวกับ Project ก่อนหน้าไปและเราไม่ได้ใช้มันอีกเลยเรากลับมาลองมันอีกครั้งนั่นคือจุดเริ่มต้นที่เรากลับมาใช้Physical Board ครับ ...

สิ่งหนึ่งที่เป็นเรื่องที่เกิดขึ้นเสมอเมื่อคุณทำงานร่วมกับคนอื่นก็คือ “ดราม่า” ครับไม่ว่าทีมคุณจะห่วยแตกจะเข้ากันดีมากจะสมบูรณ์แบบแค่ไหนอย่างน้อยต้องมีสักครั้งที่เกิดเรื่อง “ดราม่า” ขึ้นในทีมซึ่งการเกิดดราม่าในทีมไม่ใช่สิ่งที่แย่เสมอไปจริงอยู่มันอาจจะทำให้ทีมเกิดปัญหาเสียจังหวะหรือโมเมนตัมที่กำลังดำเนินอยู่ไปเพราะความเห็นต่างหรือการไม่พอใจเพียงอย่างใดอย่างหนึ่งก็ตามแต่สุดท้ายแล้วถ้าคุณเป็นอไจล์ทีมสิ่งหนึ่งที่คุณควรจะทำเมื่อเกิดเหตุการณ์เหล่านี้ขึ้นคือ Retrospective ครับ 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 ในแบบฉบับของทีมผมเอง ...

เมื่อวันพฤหัสและศุกร์ที่ผ่านมาผมได้มีโอกาสโดดเรียนวิชา DSP ไปร่วมงานThailand Practical Software Engineering Conferenceที่Software Parkมาครับซึ่งงานนี้เรียกได้ว่าเป็นครั้งแรกที่จัด (ในชื่อนี้) โดยกลุ่มผู้จัดงานก็คือThailand SPINซึ่งถ้าเคยไปร่วมงานสัมมนา Agile หลายๆงานมาก็จะค้นพบว่าคือวงการเดียวกันนี่แหละเป้าหมายของงานสัมมนานี้ตามที่ผมเข้าใจจากผู้จัดงานคือมาแลกเปลี่ยนประสบการณ์เกี่ยวกับ Software Process (ซึ่ง Agile ก็เป็นหนึ่งในนั้น) ของจริงเจ็บจริงไม่ใช่งานสัมมนาเพื่อมาขายของซึ่งนอกจากผู้จัดแล้วผมก็เพิ่งค้นพบอีกว่าวงการ Software บ้านเรานั้นมันไม่ได้กว้างใหญ่เลยปีนี้ไปมาแล้ว 3 งานคือ Agile Thailand 2013, Barcamp Bangkhen และงานนี้ก็เจอแต่คนหน้าเดิมๆอาจจะเจอคนหน้าใหม่ๆบ้างแต่ถือว่าน้อยมาก (แต่ก็ยังไม่กล้าทักใครก่อนอยู่ดี T^T) ข้อเสียอย่างเดียวของงานนี้ที่นึกออกคือการไปจัดอยู่ Software Park ซึ่งมันไกลมากจากลาดกระบังแต่นับว่าเดินทางสะดวกอยู่ทีเดียวคือนั่งรถเพียงแค่ 2 ต่อ (แต่ต้องขึ้น 166 ให้ถูกคันทั้งขาไปและกลับเลย) เกริ่นมานานแล้วมาไล่ดู Session ที่ผมไปเข้ามาดีกว่า 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)โครงการที่เราทำอยู่จะประสบความสำเร็จ….. หรือล้มเหลว ...

ก็เป็นตอนที่ 3 แล้วสิ่งที่ผมจะมาพูดถึงในวันนี้คือหนึ่งในเรื่องที่ตัดสินใจยากที่สุดตั้งแต่ตอนเริ่มทำ Project I แล้วคือการหา Project Management Tool ครับย้อนกลับไปในเดือนกรกฎาคมปี 2013 เป็นช่วงเวลาที่โปรเจ็คเริ่มตั้งไข่หลังจากส่ง Proposal และได้รับการอนุมัติแล้วในช่วงเวลานั้นผมยังคงยอมรับว่าผมยังคงใหม่กับ Agile Practice มาก (จนถึงตอนนี้ก็ยังยอมรับว่ายังใหม่อยู่) และสิ่งที่มือใหม่ Agile มักจะทำกันจากที่ผมสังเกตมาหลายคนที่ศึกษาเองคือหาเครื่องมือที่เหมาะสมกับตัวเองและทีมเพื่อที่จะใช้ Agile ได้อย่างสมบูรณ์แบบ (แต่ผมก็ไม่ได้บอกว่าวิธีการนี้เป็นวิธีการศึกษาที่ดีนะครับจริงๆพอมามองย้อนกลับไปผมน่าจะไปศึกษาแนวคิดให้มันแน่นกว่านี้แต่อย่างว่ามือใหม่มักจะตื่นเต้นกับ Tools มากกว่าหลักการจริงๆเสมอ) 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 ...

เมื่อหลายวันก่อนมีรุ่นน้องมาถามผมว่าใช้ Tools ตัวนี้ๆ ดีรึเปล่าสำหรับ Project Management ซึ่งผมก็ตอบไปตามทรรศนะและประสบการณ์ และเมื่อวานนี้ก็มีรุ่นพี่ที่รู้จักได้ยกเรื่องคล้ายๆ กันนี้มาพูดอีกครั้ง ผมก็ยังแนะนำไปตามประสบการณ์ที่เคยใช้งานมา พอดีผมได้มีโอกาสอ่านหนังสือ “ใช้ความสุขทำกำไร” (Delivery Happiness) เป็นเรื่องราวของบริษัทขายรองเท้าออนไลน์ Zappos ซึ่งมีการกล่าวถึง ค่านิยมหลัก 10 ข้อของบริษัท Zappos และเป็นตัวบ่งบอกความเป็นวัฒนธรรมองค์กรของบริษัทนี้ ประเด็นอยู่ที่ว่าผมไปสะดุดกับข้อ 2)เปิดรับและขับเคลื่อนความเปลี่ยนแปลง 4)พร้อมผจญภัย สร้างสรรค์ และเปิดกว้าง และ 10)รู้จักถ่อมตน ทั้ง 3 ข้อนี้ทำให้ผมคิดถึง Agile Manifesto 2 ข้อคือ Individuals and interactions over processes and tools Responding to change over following a plan ในหลักปรัชญาแบบ Zen ได้มีการกล่าวถึงความคิดของผู้เริ่มต้น (Beginner’s mind) ไว้ว่า ในความคิดของมือใหม่ โอกาสมีอยู่มากมาย แต่ในความคิดของมืออาชีพ โอกาสมีอยู่ไม่มากนัก มันทำให้ผมหันกลับมามองย้อนดูตัวเองว่าหลายๆ ครั้งที่เราศึกษาอะไรซักอย่างมาอย่างยาวนาน มันมักจะทำให้เรามีความมั่นใจในตัวเองสูงในเรื่องดังกล่าวซึ่งก็เป็นเรื่องดีเพราะมันทำให้เรากล้าที่จะถ่ายทอดไปได้อย่างเต็มที่ แต่บางครั้งมันก็เป็นหลุมพราง (Pitfall) ที่ทำให้เราพลาดที่จะเรียนรู้สิ่งใหม่ๆ และไม่กล้าที่จะเปิดใจลองสิ่งใหม่ๆ เหมือนตอนที่เราเริ่มต้นศึกษามันก็เป็นได้ ความต้องการแต่ละคนนั้นแตกต่างกัน การเลือกใช้ Tools ใดๆ ก็ตามก็ต้องคำนึงถึงจุดนั้นด้วย คุณไม่สามารถจะใช้ Tools ตัวเดียวกันในทีมที่แตกต่างกัน แม้ว่าความแตกต่างนั้นจะน้อยมากก็ตาม สิ่งที่ผู้ถามต้องการกับสิ่งที่ผู้ตอบต้องการบางครั้งก็ไม่ใช่สิ่งเดียวกัน บางทีมอาจจะต้องการเครื่องมือในการประเมิน เพื่อปรับปรุงความสามารถในการทำงานของทีมอย่างต่อเนื่อง, บางทีมต้องการเพียงแค่บอร์ดงานเพื่อจะได้รู้ว่างานทำไปถึงไหนแล้ว สิ่งเหล่านี้คือความแตกต่างของความต้องการในแต่ละทีม ในฐานะผู้ตอบบางครั้งจากประสบการณ์เพียงอย่างเดียวก็ไม่สามารถตอบโจทย์ผู้ถามได้ และสิ่งที่ควรทำก็คือหาความต้องการของทีมและหาเครื่องมือที่ดีที่สุดให้เขาไป ซึ่งบางครั้งสุดท้ายแล้วอาจจะจบลงด้วยการใช้แค่ Post It กับ Whiteboard เกลี้ยงๆ แค่นั้นก็ได้ ...

ขณะกำลังทำ Sprint Planning ไหนๆ วันนี้ก็ได้ 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 แล้วมาประยุกต์ใช้กับทีมให้เร็วที่สุด ก่อนที่ทีมจะทำงานไปมากกว่านี้ ...