เรียน คุณพี่ บ.ก. ที่เคารพ
วันนี้น้องมีเรื่องมาเล่าให้ฟังสองเรื่องค่ะ (เย้ ในที่สุดก็ได้ส่งต้นฉบับแล้ว 
) น้องคิดว่าเกี่ยวกับ การมองว่า Agile เป็น process ที่มี checklist 1 2 3 4 ต้องทำตาม กับ การมอง Agile เป็นเพียง concept กว้างๆ ที่เอาไป adapt ได้ตามความเหมาะสม
เรื่องแรกก็คือ วันก่อนคุณน้องไปบรรยายมา แล้วได้มีโอกาสคุยกับ ผู้เข้าฟังบรรยายสองท่าน แต่น้องรู้สึกว่า ด้วยความตื่นเต้น และรู้สึก หัวเดียวกระเทียมลีบ วันนั้นไม่ได้ตอบไปดีเท่าที่ควร หลังจากได้มาคุยกับคนรู้จักที่ทำ Agile ท่านอื่นๆ ก็ได้แนวคิดที่จะไปตอบคุณพี่คนนั้นมากขึ้น เลยอยากเขียนมาเล่าให้คุณพี่ บ.ก. (และคนอื่นๆ 
) ฟัง เผื่อจะมีไอเดียอะไรมากกว่านี้มาแบ่งปันกันค่ะ
คำถามของคุณพี่คนนั้นในวันนั้นมีดังนี้
1. คุณพี่เค้า lead project team ทั้งหมด 5 team เค้าสงสัยว่า อย่างนี้เค้าไม่ต้องยืน stand up ทั้งวันรึ ทำอาทิตย์ล่ะครั้งได้รึเปล่า?
วันนั้นน้องตอบพี่เค้าไปว่า จริงๆก็ให้แต่ละทีม stand up กันเอง แล้ว representative มา stand up กับพี่ ก็น่าจะได้ แต่เหมือนพี่เค้าจะยังไม่เห็นด้วยเท่าไร เพราะว่า representative ก็ต้อง stand up 2 ครั้งอยู่ดี แล้วก็จบไป เหมือนไม่ได้ทางออกที่ดี
พอมาคิดๆดูแล้ว น้องน่าจะบอกไปอีกว่า ถึงแม้พี่เค้าจะทำไม่ได้ทุกวัน แต่ถ้า คนในทีมย่อยๆ ได้ stand up กันทุกวัน ก็ยังจะช่วยให้เกิดการแบ่งปันให้ได้รับรู้ทั่วกัน ว่าใครทำอะไรอยู่ ใครติดปัญหาอะไร เผื่อจะได้สามารถช่วยกันได้ ก็ยังจะเป็นประโยชน์อยู่ดี
จริงๆ ถ้าเป็นน้อง ในฐานะ team lead น้องขอรับรู้ status ของทีมด้วยการ stand up ดีกว่า นั่งอ่าน status report เพราะการเขียน status report มักจะเขียนหลังจากเหตุการณ์เกิดขึ้นแล้ว ถ้ามีปัญหาก็ติดมานานซักพักแล้ว สู้ให้รู้ปัญหา ตั้งแต่เนิ่นๆ น่าจะดีกว่า
2. ลูกค้าไม่ยอมเข้ามามีส่วนร่วม
สำหรับข้อนี้ น้องตอบไปว่า จริงๆ บริษัทยักษ์ใหญ่ที่น้องเคยทำงานด้วย ทีมทำงานเค้าก็ไม่ได้เจอลูกค้าเหมือนกัน แต่เค้าจะมี ตัวแทนของลูกค้า ที่เรียกว่า product manager ซึ่งบุคคลเหล่านี้ก็ตามจิกเราไม่แพ้กับลูกค้าเลยทีเดียว (อิ อิ) แต่วันนั้น เค้าก็ตอบน้องมาว่า บริษัทที่น้องเคยทำงานด้วย ทำ product แบบเป็นกล่องส่งออกขาย ง่ายกว่ากันเยอะ น้องจำไม่ได้ว่า น้องตอบสุดท้ายไปว่าอะไร แต่รู้สึกว่าก็ยังไม่ได้ให้คำตอบที่ดีให้เค้าเหมือนกัน
เรื่องความยากง่ายของ product ที่บริษัทยักษ์ใหญ่ทำนี่ น้องคิดว่า พี่คงตอบได้ดีกว่าน้อง ฮ่าๆๆ แต่เรื่องของการที่ลูกค้าไม่เข้ามามีส่วนร่วมเนี่ย น้องว่าน่าจะมีปัญหาอยู่สองแบบ อย่างแรก คือ ลูกค้าไม่ได้เป็นคนที่ได้ประโยชน์จาก product ตัวนี้จริงๆ (อะแฮ่ม gov อะแฮ่ม) จึงไม่ได้สนใจว่างานจะออกมาดีไม่ดี หรือ อย่างที่สอง คือ ลูกค้ายังไม่เข้าใจว่า การได้มาดู software ที่ release ออกมาบ่อยๆ มันมีผลประโยชน์กับเค้าแค่ไหน แล้วการเสียเวลามามีส่วนร่วมเพียงเล็กน้อย จะช่วยให้เค้าได้สิ่งที่มี value มากที่สุด ได้อย่างไร ซึ่งจากประสบการณ์ หลังจากลูกค้าได้ลองตรงนี้แล้ว ก็อยากมีส่วนร่วมไม่ยอมเลิกเลยทีเดียว – -”
จริงๆ เรื่องนี้เป็นเรื่องของความสามารถในการขายของส่วนบุคคลด้วย ซึ่งน้องคงต้องยอมรับตรงๆ ว่าน้องคงให้คำแนะนำอะไรไม่ค่อยได้ เพราะไม่ใช่แนวที่ถนัด (บังเอิญมีหัวหน้าขายของเก่ง เราก็ชิลไป)
3. ลูกค้าพี่เค้าเป็นธนาคาร มันยากที่จะ test งานที่ทำออกไป เพราะไม่มีข้อมูลจริง (อันนี้ที่น้องพอจับใจความได้)
อันนี้ น้องมัวแต่ไปตอบแต่เรื่องการทำ mock module เพราะเหมือนคุยต่อมาจากเรื่อง unit test ซึ่งก็เหมือนจะไม่ได้ให้คำตอบที่เค้าต้องการเหมือนกัน
วันนี้เลยอยากจะบอกว่า ลูกค้าของบริษัทยักษ์ใหญ่ที่เคยทำงานอยู่ ลูกค้าก็เป็นธนาคารเหมือนกัน มีทั้ง dev และ test environment ประมาณ 7 environment เห็นจะได้ test แล้ว test อีก เพราะถ้าขึ้น production มีความผิดพลาด ก็สูญเสียเยอะอยู่เหมือนกัน แต่ถ้าเราไม่ test เลย จะรู้ได้อย่างไร ว่า product ที่เราทำออกไปมีคุณภาพ
แต่อันนี้อาจจะต้อง ขอคนที่ทำงานกับธนาคารมาช่วยออกความเห็นเพิ่มเติม ในความยากง่ายอีกทีค่ะ
4. คนในทีม project ของคุณพี่เค้า ต้องทำหลายๆ project ในเวลาเดียวกัน
อันนี้ น้องว่าเป็น basic ของปัญหา management กันซะมากกว่า การให้คน switch task บ่อยๆ ไม่เป็นผลดี กับการทำงานอย่างแน่นอน ซึ่งพี่เค้าบอก เค้าก็รู้ แต่เค้าไม่ทำอย่างนี้ไม่ได้หรอก…. อันนี้ น้องก็คงบอกอะไรต่อไม่ได้ เพราะไม่ได้อยู่ในเหตุการณ์จริง แต่ขอ quote พี่ที่รู้จักกัน พี่ ธีรพงศ์ มหธรรม ที่มา comment ให้น้องใน facebook ละกันค่ะ
So before he can do agile he needs to adjust his organization structure first. It’s the classic example of a need to change what we have done previously that is wrong… rather than change the new concept to be compatible with our old, wrong way of doing things. It would simply defeat the purpose of adapting a new concept .
เรื่องที่สอง วันก่อนน้องมีโอกาสได้ไปป่วน เอ้ย ไปลงความเห็นใน status ของเพื่อนคนนึงใน facebook เนื่องจากเพื่อนของน้องได้ copy คำแปล manifesto ของคุณพี่ใน “Agile คือ อะไร” ไปเป็น status ก็มีน้องคนนึง comment ว่า ถ้า project ใดไม่มี document ก็คงจะ doom (อันนี้เอาคำของน้องเค้ามา)
อันนี้อาจจะเป็นการเข้าใจความหมายของข้อที่ว่า
ให้ความสำคัญกับ(การส่งมอบ)ซอฟต์แวร์ที่นำไปใช้งานได้จริง มากกว่าการทำเอกสาร(ที่ไม่มีใครอ่าน)
บิดเบือนไปนิดนึง ซึ่งน้องมองว่า มีหลายๆคนที่ มอง agile เป็นแบบนี้ คือ ไม่ต้องเขียนเอกสาร แต่จริงๆแล้ว คำว่า การให้ความสำคัญมากกว่า ไม่ได้แปลว่า จะไม่มีอีกฝั่งเลย แต่จะมีข้างขวา ก็ต่อเมื่อมันจะไปให้ประโยชน์และส่งเสริมสิ่งที่อยู่ข้างซ้าย ซึ่งในที่นี้คือ ซอฟต์แวร์ที่นำไปใช้งานได้จริง ถ้าการมีเอกสาร ทำให้การใช้งานของซอฟต์แวร์เป็นไปได้อย่างสะดวกขึ้น (User Manual) ก็จำเป็นแน่นอน หรือถ้าเอกสารช่วยให้คนที่มา maintain ซอฟต์แวร์นี้ต่อ ทำงานได้สะดวกขึ้น ก็ควรจะมีเช่นกัน ซึ่งในหลายๆองค์กร มักจะมีปัญหากับข้อหลังนี้มากกว่า แต่วิธีการแก้ของ Agile ไม่ได้พูดถึง document อย่างเดียว แต่อย่าพูดวันนี้เลย เดี๋ยวยาว (เก็บไว้จะได้มีต้นฉบับ ฉบับหน้าด้วย อิอิ)
จากที่ได้เล่ามาทั้งหมดวันนี้ ก็เหมือนจะมีข้อคิดอยู่บ้าง (นะเนี่ย หุ หุ)
Agile ไม่ใช่ 30 บาทรักษาทุกโรค บางอย่างเป็นเรื่องของ management, politics, หรือ organization structure ก็อาจจะต้องค่อยๆแก้กันไปตามความเหมาะสม
Agile ไม่ได้มีกฎบังคับ ว่าต้องทำอย่างนู้นอย่างนี้ ถึงจะเป็น Agile Agile เป็นเพียง concept กว้างๆ ที่มี practice ต่างๆที่แนะนำให้เอามาเลือกใช้ได้ตามความเหมาะสม จริงๆแล้ว Agile จะมีแนวคิดคล้ายกับหนังสือเล่มนึงที่คุณหัวหน้าของน้องแนะนำให้อ่าน ชื่อว่า Principal of Software Engineering Management by Tom Gilb หลักสำคัญก็คือ เราต้องแยกแยะให้ออกว่า Goal ที่เราจะไปถึงคืออะไร สิ่งอะไรคือสิ่งที่เราต้องการอย่างแท้จริง แล้วจึงจะเลือก Solution ให้เหมาะสมกับ Goal นั้นๆ
โอ้ เล่ามายาวกว่าที่คิดนะเนี่ย เบื่อจะฟังรึยังคะ ฮ่าๆๆ วันนี้พอแค่นี้ก่อนละกัน ไว้วันหลังจะมาเล่าให้ฟังใหม่นะคะ
ด้วยความเคารพอย่างสูง
น้องอจายล์ อิแวนเจลลิส คนเดิม
Iteration ที่มีระยะเวลาตายตัว (Time Boxed Iterations)
