ว่าด้วยเรื่องของ Change

วันก่อนได้อ่านบทความหนึ่งของทาง chapterpiece.com ที่พูดเกี่ยวกับเรื่อง change แล้วเกิดความรู้สึกว่า ต้องเขียนเกี่ยวกับเรื่องนี้ในมุมอไจล์ เพื่อให้ทุกคนได้เข้าใจมุมมองแบบอไจล์มากขึ้น ออกตัวไว้ก่อนว่า อาจจะขัดกับแนวคิดของผู้เขียนแบบตรงๆ ต้องขออภัยล่วงหน้าด้วยครับ ส่วนตัวไม่ได้ขัดแย้งอะไรครับ

จุดใหญ่ใจความที่ทำให้ผมสะดุดคือมุมมองที่ว่า change เป็นปัญหา ซึ่งความจริงแล้วไม่ใช่ ลองมาดูโดยเริ่มจาก Agile Manifesto กันก่อน

Responding to change over following a plan
การตอบสนองต่อความเปลี่ยนแปลงความต้องการของผู้ใช้ สำคัญกว่า การทำตามแผนที่วางไว้

คำว่าตอบสนองนั้นมันค่อนข้างคลุมเครือ แต่ถ้าเราเริ่มจากมุมมองที่ว่ามันเป็นปัญหา ธรรมชาติของเราเมื่อมีปัญหามันก็ต้องหาทางแก้ แล้วก็ไม่พ้นที่จะทำสองเรื่องคือ ป้องกันและควบคุม (prevention and control) เกิดเป็นสิ่งที่เรียกว่า Change Control Process และ Change Management แล้วก็ไปจบที่ Waterfall ซึ่งเราปฏิเสธเพราะรู้ดีถึงความไม่สมบูรณ์ของมัน

ถ้าอย่างนั้นมุมมองต่อ Change แบบอไจล์ล่ะเป็นอย่างไร ต้องมาดูต่อว่า Agile Principles พูดเกี่ยวกับเรื่องนี้อย่างไร

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
ยอมรับการเปลื่ยนแปลงความต้องกา​รของลูกค้าแม้ในช่วงท้ายของการพ​ัฒนา (เพราะ) การเปลี่ยนแปลงในกระบวนการอไจล์​นั้นเป็นไปเพื่อความได้เปรียบใน​การแข่งขัน(ทางธุรกิจ)ของลูกค้า

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

สำหรับโปรเจ็คของผมสิ่งที่อยากให้เป็นคือ
– น่าจะดีถ้ามี change มากๆ เพราะทำให้เรามั่นใจว่า เราได้ตอบสนองต่อความต้องการของลูกค้าได้ถูกต้อง
– เพราะรู้ว่า change นั้นมีค่าใช้จ่าย ผมจะตัดสินใจในแต่ละเรื่องในเวลาที่จำเป็นต้องตัดสินใจจริงๆ เท่านั้น เรื่องไหนที่ยังไม่จำเป็นต้องตัดสินใจก็จะ delay ออกไปให้นานที่สุด เท่านี้ก็สามารถลด change ที่ไม่จำเป็นได้ ตามหลักการ JIT (Just In Time)
– ใช้หลักการที่เหลืออีก 11 ข้อของอไจล์ เพื่อให้การทำงานร่วมกันของทีมพัฒนาและลูกค้าเป็นไปอย่างคล่องแคล่วและคล่องตัว(agile)
– ความต้องการของลูกค้า อาจไม่ใช่สิ่งที่ลูกค้าบอก หากแต่เป็นสิ่งที่ทำให้ความสามารถในการแข่งขันทางธุรกิจของเขาสูงขึ้น จะต้องนำหลักการ 5Why มาใช้ในการหาสิ่งที่ลูกค้าต้องการอย่างแท้จริง โดยสำหรับแต่ละ requirements เราจะต้องถามคำถามที่ขึ้นต้นว่า “ทำไม” อย่างน้อย 5 ครั้ง เพื่อไปให้ถึงต้นตอของ requirement นั้น
– ความรู้สึกเป็นเจ้าของเกิดจากการมีส่วนร่วม ทุกเรื่องควรจะให้ทุกคนได้มีส่วนร่วมในการตัดสินใจ เมื่อเป็นอย่างนั้น ความรู้สึกเป็นเจ้าของจะเกิดขึ้นเอง
– ใช้การพูดคุยซึ่งหน้าในการสื่อสารให้มากที่สุดเท่าที่จะทำได้

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
วิธีที่มีประสิทธิภาพและประสิทธ​ิผลสูงสุดในการถ่ายทอดสาระต่างๆ​ไปสู่ทีมพัฒนาและภายในทีมพัฒนาเ​องคือการพูดคุยแบบซึ่งหน้า

เท่านี้ทุกคนก็จะยิ้มได้ เมื่อมี change แล้วล่ะครับ

ถ้าหากว่าเรามีความเข้าใจต่อ change ว่าเป็นปัญหาจะพบว่าผลลัพธ์คือ
1. requirements ไม่มีวันเรียบร้อย แม้ว่าเราคิดว่ามันเรียบร้อยแล้ว สุดท้ายก็เกิด change อยู่ดี
2. ไม่ว่า requirements จะละเอียดแค่ไหน ก็ไม่เคยเพียงพอ
3. ไม่ว่าจะใช้เทคนิคดีแค่ไหนในการวิเคราะห์ requirements ก็จะเกิด change อยู่ดี
4. เมื่อ change เกิดขึ้นแล้วทีมพัฒนาไม่รับ ความสามารถในการแข่งขันทางธุรกิจของลูกค้าก็ลดลง สุดท้ายเขาก็ไม่มีเิงินจ่ายหรือไม่อยากจ่าย
5. Requirements analysis ไม่ใช่งานของ Dev และ UAT ไม่ใช่งานของ QA การแบ่งแยก Dev/QA เป็นปัญหาใหญ่ที่สุดในการนำอไจล์มาใช้ สิ่งที่ควรปฏิบัติคือวางแผนร่วมกันแต่แยกปฏิบัติ Dev เก่งโค้ดก็เขียนโค้ด QA เก่งเท้สก็ทำเท้ส แต่โค้ดไม่ใช่ของ Dev และเท้สไม่ใช่ของ QA ทุกอย่างเป็นของทุกคน ไม่มีการบอกว่าโค้ดฉันเสร็จแล้วที่ขึ้นไม่ได้เพราะติดเท้ส มีแต่งานของเราไม่เสร็จเอาขึ้นไม่ได้
6-7. วิธีทำงานร่วมกัน คือ Product Manager มีหน้าที่หา change ที่ตอบสนองต่อความสามารถในการแข่งขันของลูกค้าให้มากที่สุด QA มีหน้าที่กำหนด test cases ที่ถูกต้องให้แก่ Dev และ Dev มีหน้าที่เขียนโค้ดที่ง่ายสำหรับการเท้ส
8. แบ่งงานย่อยเท่าที่จำเป็น มากไปจะทำให้โฟกัสไม่ได้ คิดให้ไกลที่สุด แต่ทำให้น้อยที่สุด พูดนอกเรื่องบ้างก็ได้ บางครั้งเพราะนอกเรื่องนั่นแหละจึงทำให้แก้ปัญหาได้

Continuous attention to technical excellence
and good design enhances agility.
การใส่ใจในความเป็นเลิศทางเทคนิ​คและงานออกแบบที่ดีอย่างต่อเนื่​องจะช่วยเพิ่มความเป็นอไจล์

Simplicity–the art of maximizing the amount
of work not done–is essential.
ความเรียบง่ายหรืออีกนัยหนึ่งคื​อศิลปะอันจะทำให้ปริมาณงานที่ไม​่ถูกทำมีมากที่สุด(ก็ทำน้อยที่ส​ุดนั่นล่ะ)นั้นสำคัญยิ่ง

9. Standup meeting ไ่ม่ใช่คำตอบสำหรับการสื่อสารทั้งหมด ควรใช้เมื่อจำเป็นและเท่าที่จำเป็น
10-12. change เป็นเรื่องดี แต่ change ที่ไม่จำเป็นเป็นความสูญเปล่า การ assume แล้วทำๆ ไปก่อน ทำให้เกิด defects ที่เป็นอีกหนึ่งความสูญเปล่าที่ควรหลีกเลี่ยง
13. ถ้าเข้าใจกันดีตั้งแต่ต้น ก็ไม่ต้อง review กันมากมาย
14. 10 นาทีต่อวัน ในการ review change = stand-up meeting
15. change ยิ่งทิ้งไว้นานยิ่งแพงเพราะฉะันั้นควรใช้หลัก “ทำทันที” คือเมื่อมี change ต้องนำมาคุยกันทันที
16. เมื่อ support engineer เป็นคนหนึ่งที่ได้รับผลกระทบจากโปรเจ็ค เขาก็เป็นคนหนึ่งในทีมตั้งแต่ต้น
17. การจัดลำดับความสำคัญของ requirements (prioritization) เป็นหน้าที่ีของทุกคน
18. การตอบสนองต่อความเปลี่ยนแปลงความต้องการของผู้ใช้ สำคัญกว่า การทำตามแผนที่วางไว้

“The bitterness of poor quality remains long after the sweetness of low price is forgotten” – Benjamin Franklin

19. ถูกต้องครับ face-to-face ดีที่สุด (ว่าแต่ถ้าเป็น off-shoring ล่ะ?)
20. การอัดเสียงแล้วมาทวงสัญญาขัดกับ Agile Manifesto ที่ว่า

Customer collaboration over contract negotiation
การร่วมมือกับลูกค้าทำงานร่วมกัน สำคัญกว่า การเจรจาต่อรองข้อสัญญา

21. อย่างที่บอก change = เงิน, ไม่มี change = ไม่ได้ตังค์

Links
http://www.chapterpiece.com/project-management/2011/06/05/ideas-of-the-month-about-change/

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

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