Agile 101

ถึงแม้ว่าผมจะไม่เคยได้ทำงานบริษัท Agile จริงๆ จังๆ เลยก็ตาม แต่วันนี้จากประสบการณ์ที่ผมได้ทำงานในบริษัทพัฒนาซอฟต์แวร์มา การที่ผมได้ศึกษาด้วยตนเอง และพบปะ community ผมว่าผมสำเร็จหลักสูตร Agile 101 แล้ว ด้วยการตัดสินโดยตนเอง 🙂

ผมค้นพบว่า ทุก agile practices สามารถเชื่อมโยงย้อนกลับถึง 3 สิ่งต่อไปนี้ได้เสมอ

  • Feedback เราต้องเปิดโสตประสาทของเราและทีมให้รับ feedback จัดการมันอย่างเป็นระบบ และสร้าง feedback ในด้านที่ขาดไปขึ้นมา
  • Change ระบบที่เราพัฒนาจะต้องอยู่ในจุดที่สามารถรับมือกับ change ได้
  • Bring value value จะเกิดขึ้นได้ก็ต่อเมื่อ เรา release ในสิ่งที่ผู้ใช้งานพึงพอใจ ในระยะเวลาที่เหมาะสม

แน่นอนว่าอ่านแค่นี้แล้ว คนที่ไม่รู้จัก Agile มาก่อนย่อมไม่เห็นภาพอะไรเลย จริงๆ แล้ว target ของ blog นี้ ผมตั้งใจสะกิดให้ท่านที่ใช้ agile อยู่ หรือกำลังเริ่มปรับใช้ ให้ย้อนกลับมาคิดว่าแต่ละสิ่งในกระบวนการพัฒนาซอฟแวร์ที่เราทำและไม่ได้ทำ มันมีเหตุผลอะไรแฝงอยู่ เพราะโดยส่วนตัวผมเคยพบคนที่บอกว่าตัวเองใช้ agile อย่างนี้อย่างนั้น แต่ทั้งทีมไม่เข้าใจ 3 สิ่งข้างต้นนี้เลย ผลลัพธ์ที่ออกมาก็จะค่อนข้างกระจัดกระจาย ไม่ดีเท่าที่ควร หรือ fail ไปเลยก็มี

ปล. ถ้ามีอะไรผิดพลาด รบกวนชี้แนะ และเพิ่มเติมด้วยนะครับ

Advertisements

8 thoughts on “Agile 101

  1. Maythee Anegboonlap

    อยากจะเพิ่มอีกข้อคือ Limit โดยเฉพาะ Change และ Behavior เราสามารถให้ทีมมี feedback หากันอย่างยอดเยี่ยม สามารถรับมือกับ Change ได้ดีมี Value ที่เพิ่มขึ้นเรื่อยๆ แต่ถ้าไม่มี Limit มันจะไม่มีจุดที่เรียกว่าเสร็จ

    Reply
  2. Maythee Anegboonlap

    สิ่งที่ Process Agile ควรทำให้เกิดคือ มี Limit ของ Change เป็นช่วงๆ และถี่ๆ เพื่อให้มันเร็วสมชื่อ Agile หน่อย

    Reply
  3. Nuttanart Pornprasitsakul

    มันไปอยู่ในการ bring value ในระยะเวลาที่เหมาะสมอะครับพี่แน็ท การที่ไม่เสร็จทำให้เราได้รับ feedback ไม่ครบอีกต่างหาก คือ เราจะไม่ได้ feedback จากผู้ใช้งานจริงสักที

    Reply
  4. Maythee Anegboonlap

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

    Reply
  5. Nuttanart Pornprasitsakul

    >> feedback ในด้านที่ขาดไปคือยังไงอ่ะ?อันนี้คือ การตั้งใจจะบอกว่าหลายๆ practice ที่ทำๆ กันอยู่ มันคือการสร้าง feedback อะ เช่น iteration review, standup meeting, retrospective, pair programming, เขียน test, … “ขาดหายไป” ที่จะสื่อ คือ เริ่มต้นเราอาจจะไม่ต้องใช้ทั้งหมดก็ได้ แต่ค่อยๆ สังเกตว่าปัญหาในการพัฒนาของเรามันเกิดจากอะไร แล้วก็ค่อยๆ หยิบแต่ละ practice มาใช้

    Reply
  6. Nuttanart Pornprasitsakul

    >> ตอบพี่แน็ทผมเข้าใจที่พี่ต้องการจะสื่อครับ แต่ผมว่ารายละเอียดว่า เราจะต้องจัดการวิธีการทำงานของเราแบบใด ให้ bring value ได้ในเวลาที่เหมาะสม เป็นเรื่องระเอียดลงไปเกินกว่าที่จะสรุปให้สั้นอยู่ใน 101 ของผมอะครับแต่ motivation ของการตัด scope,limit คือ การ bring value ในเวลา และเพื่อ feedback จาก real user ครับ

    Reply
  7. Pingback: ย้อนกลับไปมองความคิดในเรื่องการพัฒนาซอฟแวร์ | Tap

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