Jump to content


Windows Server 2012

- - - - -

สูงสุดของ Software Development Process คือมุ่งสู่ Agile


  • Please log in to reply
51 replies to this topic

#1 minimalist

minimalist

    Star

  • Star
  • 892 posts

Posted 23 July 2007 - 10:44 PM

ก่อนอื่นต้องบอกก่อนว่าไม่ใช่เซียน Agile
ที่มาโพสต์ในกลุ่มนี้เนื่องจากเห็นว่าน่าจะเกี่ยวกับ Announcements ได้ เพราะได้รับข้อมูลดี ๆ จากสื่อดี ๆ มาเล่าสู่กันฟัง

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

ในต่างประเทศก็กำลังมีจัดสัมนาระดับโลกเกี่ยวกับ Software Process Improvement ก็มีหัวข้อเกี่ยวกับประเด็นนี้
Agile จึงไม่ใช่ Process หรือ Methodology เล็ก ๆ หรือใช้ในวงแคบ ๆ อย่างที่หลายคนเข้าใจ แต่คือการ 'เข้าถึง' ถึงความ...'พอเพียง'!
CMM/CMMI พิสูจน์ให้เห็นแล้วว่ามันใหญ่โต Best Practice คือปรับให้เข้ากับองค์กรและทีมมากที่สุด และมุ่งสู่ Agile
คิด ๆ แล้วนึกถึงคุณ Bomber, siros และอีกหลายท่าน เอาไว้จะขอสัมภาษณ์เก็บข้อมูลในเชิงปฏิบัติ ประสบการณ์ และการนำมาใช้หน่อยนะครับ
เคยคุยกับคุณ Bomber ไว้นานแล้ว ยังไม่ได้ลงมือรวบรวมข้อมูลจริงจังเสียที

่และหากเปรียบเทียบแล้ว เมื่อเราเข้าใจสิ่งใดจนถึงแก่นแท้แล้ว เมื่อนั้นเปรียบได้กับการเข้าถึงแก่นแท้แห่งปรัชญาเศรษฐกิจพอเพียง...ด้วย ผมเขียนบทความไว้ชิ้นหนึ่งเกี่ยวกับประเด็นนี ้เอาไว้จะเอามาลงใน Blog ดูนะครับ

ปรัชญาเศรษฐกิจพอเพียง ของในหลวงเราถือว่าสุดยอดมาก ๆ ยิ่งคิดยิ่งปลื้มพ่อหลวงของเรา

หรือหากนำแนวคิด ปรัชญาเศรษฐกิจพอเพียง ไปใช้กับการออกแบบสถาปัตยกรรมหรือตกแต่งภายใน ก็เป็นแนว Minimal Design นี่ล่ะ :) ใครนึกไม่ออกว่า Minimal Design เป็นยังไงลองไปเดิน B2S แถวแผนกหนังสือกราฟฟิกดีไซน์ดูได้ครับ

และแนวทางการออกแบบผลิตภัณฑ์ และสิ่งต่าง ๆ อีกมากมาย ก็เป็นไปในสไตล์ Minimal มากขึ้น คล้ายแฟชั่น แต่ไม่ได้มีการ Define ออกมาจนชัดเจน สมบูรณ์ บูรณาการ และ Define องค์ประกอบแบบครบถ้วนเท่ากับโมเดลเศรษฐกิจพอเพียงของในหลวงเราเลย

ลอง search 'เศรษฐกิจพอเพียง' ใน wikipedia ดูนะครับ แล้วจะเห็นว่า ปรัชญาเศรษฐกิจพอเพียง ไม่ใช่เรื่องง่ายที่จะเข้าใจ ต้องอาศัยการตีความพอสมควร แต่ก็ไม่ใช่เกินจะเข้าใจ เมื่อเข้่าใจคุณจะเห็นว่าทุกสิ่งเมื่อเข้าถึงแก่นแท้แล้ว...ก็คือความพอเพียง

ความพอเพียงไม่ใช่พอดี ไม่ใช่ 50/50, 70/30, 80/20 หรือการเดินทางสายกลางก็ไม่ได้หมายถึงการเดินตรงกลาง หรือการไม่เลือกฝ่ายใดฝ่ายหนึ่งเลย (เอ๊ะ ชักไปเอี่ยวกะการเมือง)

ไปดีกว่า ไม่งั้นเดี๋ยวได้เม้าเรื่องการเมืองกันมันส์

minimalist (ณรงค์)

Edited by minimalist, 23 July 2007 - 10:47 PM.


#2 minimalist

minimalist

    Star

  • Star
  • 892 posts

Posted 23 July 2007 - 10:58 PM

ใครเก่งภาษาอังกฤษช่วยเช็คให้หน่อยหรือคิดให้หน่อยครับ ว่า คำว่า Agile จะใช้ภาษาไทยสั้น ๆ กระชับ ๆ ว่าอะไรดี

#3 SouLsKI

SouLsKI

    Member

  • Members
  • PipPip
  • 238 posts

Posted 24 July 2007 - 10:47 AM

อยากฟังเรื่อง Agile ในงาน NJUG4 จังเลยครับพี่อยากรู้ว่าเป็นยังไงมีประโยชน์ในเรื่องอะไรบ้าง  :P

#4 นายข้าวโพดหวาน

นายข้าวโพดหวาน

    Committee

  • Committee
  • 7138 posts

Posted 24 July 2007 - 01:20 PM

View Postminimalist, on Jul 23 2007, 09:58 AM, said:

ใครเก่งภาษาอังกฤษช่วยเช็คให้หน่อยหรือคิดให้หน่อยครับ ว่า คำว่า Agile จะใช้ภาษาไทยสั้น ๆ กระชับ ๆ ว่าอะไรดี
แปลยากครับ หาคำไทยตรงๆไม่ได้เลย ถ้าแปลตามความหมายคือ เร็วและเบา

#5 นายข้าวโพดหวาน

นายข้าวโพดหวาน

    Committee

  • Committee
  • 7138 posts

Posted 24 July 2007 - 01:26 PM

พอดีผมไม่ชำนาญเรื่อง CMMi เลยสงสัยว่าในทางปฏิบัติ CMMi มีประโยชน์จริงมากน้อยแค่ไหน และการใช้ CMMi ร่วมกับ agile process จะดีกว่าการที่องค์กรใช้ agile อย่างเดียวขนาดไหน

ผมคิดว่าปัญหาเมืองไทยตอนนี้ อยู่ที่ผู้บริหารหรือผู้มีอำนาจตัดสินใจ ยังไม่เข้าใจหลักการ agile เท่าไรนัก ปรัชญา agile และวิธีปฏิบัติหลายๆข้อ ฟังดู counterproductive จนทำให้ผู้บริหารรวมไปถึงผู้ปฏิบัติการไม่แน่ใจว่าจะนำมาใช้ได้ผลจริงขนาดไหน (ขนาดที่อเมริกา บ.ทั้งหลายยังเชื่อครึ่งๆกลางๆไม่น้อย)

พอคุณ minimalist เอ่ยถึง consultant เลยคิดว่าสงสัยคงต้องให้ consultant ไปจูงใจผู้บริหาร ท่าจะดี

#6 Pink Dragon

Pink Dragon

    Topgun

  • Topgun
  • 3900 posts

Posted 24 July 2007 - 01:59 PM

ผมสงสัียว่า ทำไมถึงเปรียบเทียบ CMMI กับ Agile
CMMI เป็น process improvement ส่วน Agile เป็น methods ไม่น่าจะเอามาเปรียบเทียบกันได้ตรง ๆ ครับ

#7 plynoi

plynoi

    Star

  • Star
  • 1433 posts

Posted 24 July 2007 - 02:28 PM

View Postนายข้าวโพดหวาน, on Jul 24 2007, 01:25 PM, said:

พอดีผมไม่ชำนาญเรื่อง CMMi เลยสงสัยว่าในทางปฏิบัติ CMMi มีประโยชน์จริงมากน้อยแค่ไหน

แหะๆ ผมเคยอยู่มาทั้งบริษัทได้ที่ CMMI lv2 ตอนนี้มีอยู่ บ. ที่ได้ CMMI lv 5
บอกตรงๆ ว่ามันการันตีเฉยๆ ครับว่ากระบวนการทำงานจะมีหลักฐานที่แน่นอน มีเอกสาร track ได้
คือเป็นกระบวนการพัฒนา process การทำงานเฉยๆ

....

ไม่ได้บอกถึงคุณภาพ Software แต่อย่างใด

#8 Pink Dragon

Pink Dragon

    Topgun

  • Topgun
  • 3900 posts

Posted 24 July 2007 - 02:38 PM

View Postplynoi, on Jul 24 2007, 02:28 PM, said:

บอกตรงๆ ว่ามันการันตีเฉยๆ ครับว่ากระบวนการทำงานจะมีหลักฐานที่แน่นอน มีเอกสาร track ได้
คือเป็นกระบวนการพัฒนา process การทำงานเฉยๆ

....

ไม่ได้บอกถึงคุณภาพ Software แต่อย่างใด
ถูกต้องครับ process improvement เช่น CMMI, ISO 9000 รับประกันกระบวนการทำงานครับ ไม่ได้รับประกันผลิตภัณฑ์ อย่าง ISO 9000 จะมีข้อกำหนดที่ซีเรียสว่า ห้ามเอาโลโก้ ISO 9000 ไปติดไว้ที่กล่องผลิตภัณฑ์เด็ดขาดครับ ถ้าเอาไปติดจะโดนถอด certified

บริษัทที่ implement CMMI/ISO 9000 อาจจะผลิต software ที่คุณภาพต่ำมาก ๆ ออกมาก็ได้ บริษัทที่ไม่ได้ implement CMMI/ISO 9000 อาจจะไม่มี process อะไรเลย ก็อาจจะผลิต software คุณภาพสูงมาก ๆ ออกมาได้ครับ

แต่ถ้าเราเน้นไปที่บริษัทเดียวกัน บริษัท A ที่ไม่ได้ใช้ process improvement กับบริษัท A ที่ใช้ process improvement การที่บริษัท A ใช้ process improvement ก็ควรจะทำให้ products ที่ผลิตออกมามีคุณภาพสูงกว่าตอนที่ไม่ได้ใช้ครับ

#9 siros

siros

    Topgun

  • Topgun
  • 1623 posts

Posted 24 July 2007 - 05:38 PM

ผมคิดว่า สมมติฐานของมาตรฐาน SPI คือ ... ถ้าคุณมีกระบวนการผลิตที่ีดี คุณมีแนวโน้มที่จะทำผลิตภัณฑ์ออกมาได้ดีกว่า คนที่ผลิตโดยใช้กระบวนการที่ไม่ดี
ซึ่ง ตรงนี้ ต้องยอมรับว่า เป็นจริงในบางแง่มุม ในระดับหนึ่งครับ (เช่น ในมุมของ defect และ testing ... การมีกระบวนการที่ดี ย่อมทำให้รู้ถึงความครอบคลุมในการทดสอบ ทำให้ซอฟต์แวร์ที่ได้ น่าเชื่อถือว่า การทดสอบแบบ ad hoc)

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

รอฟังคุณ minimalist มาเล่าต่อนะครับ
คำว่า Agile เนี่ย .. ตัวมันเองน่าจะแปลว่า ว่องไว กระฉับกระเฉง
ผมนึกถึงคำว่า "กระชับ" (ที่คุณ minimalist พูดมาแล้ว) ครับ

#10 xcaleber

xcaleber

    Star

  • Star
  • 1442 posts

Posted 24 July 2007 - 05:54 PM

ทฤษฎีเค้าว่ากันว่า 3P (Product - Process - People) มีความสัมพันธ์กัน

ถ้ากระบวนการผลิตดี หรือบุคคลากรดี แนวโน้มของการที่ผลิตภัณฑ์จะออกมาดีก็มีสูง

แต่พอดี Process มันเป็นสิ่งที่ควบคุมและวัดได้ด้วยตัวเลขมากกว่า People เลยเกิดเป็น Software Process Improvement ขึ้นมาและโปรโมตกันอย่างบ้าระห่ำ เม็ดเงินมากมายถูกโยนลงไปในงานนี้

บ้านเรา คนที่รับ SPI ไปใช้ ก็พยายาม implement กันอย่างบ้าระห่ำตามไปด้วย โดยไม่เข้าใจถึงแก่นว่าเราต้องการ improve ให้ได้ product และสายการผลิตที่ได้คุณภาพมากขึ้นกว่าเดิม

บางที่หนักกว่า คิดว่าการ improve Process จะทำให้ people ไม่สำคัญเท่า ทำกับพนักงานเหมือนเป็นเครื่องจักรที่เสียหรือขาดไปเมื่อไหร่ก็พร้อมจะหาอะไหล่มาเปล
ี่ยนทดแทนได้เสมอ ตรงนี้ยังพอรับได้บ้าง หากอะไหล่เป็นอะไหล่ที่มีคุณภาพเกรดดี แต่เท่าที่เคยเจอมาบริษัทจะให้ความสนใจน้อยในการคัดสรรอะไหล่ชั้นดีเข้าบริษัท ส่วนใหญ่จะไปเน้นหาอะไหล่ที่อยู่ทน ที่สามารถปลูกฝังแนวคิดเครื่องจักรให้กับเค้าได้ โดยเอาสวัสดิการและเงินเดือนเป็นฐานตัวล่อ

พออะไหล่ไม่ดี ของปลอมอยู่เยอะ ตัวที่จะมองเห็นปัญหาใน methodology ขององค์กรเลยไม่มี หลายที่ที่เห็น มี SPI level สูงๆ แต่ methodology ที่ใช้ในการพัฒนายังเป็น water fall โบราณไม่ได้พัฒนาตามไปด้วย

คนที่ใส่ใจ SPI ก็มีความรู้ไม่พอที่จะมาจัดการเรื่อง methodology ที่ต้องใช้ประสบการณ์ใน field development มาช่วย ซึ่งอยู่คนละสายกับ SPI ที่ตัวเองเชี่ยวชาญ

การ drive จากเม็ดเงินและความเชื่อที่ว่าถ้ามี cert จาก SPI เจ้าใดๆ แล้วบริษัทจะมีความน่าเชื่อถือ รับงานใหญ่ๆ ได้ ทำให้รูปแบบการ improve มาจากเบื้องบนแทนที่จะดิ้นรนกันมาอย่างเสถียรกว่าจากข้างล่าง

ถ้าบริษัทเหล่านั้นให้ความสำคัญกับบุคคลากรมากกว่านี้ เข้าใจธรรมชาติของคนเก่ง ควบคุม process ตามสมควร และซ่อนความยุ่งยากที่เพิ่มเข้ามาออกไปได้ เข้าใจถึ่งแก่นว่าเรา improve ไปเพื่อหวังให้ product ออกมาดีก็คงจะดีกว่านี้ ปัจจุบัน หลายที่ประเมินออกมาแล้ว defect ของ product ลดลงจริง แต่ design, architecture หรือเวลาที่ใช้ไม่ได้ดีขึ้นหรือแย่ลง ROI ก็ลดลงสวนทางกับสิ่งที่คาดหวังว่า SPI จะช่วยให้ผลิตได้เยอะๆ เร็วๆ รวยไวๆ

พี่ Siroz มาเสริมพอดีเลย :D

Edited by xcaleber, 24 July 2007 - 06:04 PM.


#11 Pink Dragon

Pink Dragon

    Topgun

  • Topgun
  • 3900 posts

Posted 24 July 2007 - 05:54 PM

View Postsiros, on Jul 24 2007, 05:37 PM, said:

ผมคิดว่า สมมติฐานของมาตรฐาน SPI คือ ... ถ้าคุณมีกระบวนการผลิตที่ีดี คุณมีแนวโน้มที่จะทำผลิตภัณฑ์ออกมาได้ดีกว่า คนที่ผลิตโดยใช้กระบวนการที่ไม่ดี
ผมคิดว่า่น่าจะเป็น "ถ้าคุณมีกระบวนการผลิตที่ีดี คุณมีแนวโน้มที่จะทำผลิตภัณฑ์ออกมาได้ดีกว่า การที่คุณผลิตโดยใช้กระบวนการที่ไม่ดี" มากกว่านะครับ

#12 hus

hus

    Member

  • Members
  • PipPip
  • 469 posts

Posted 24 July 2007 - 09:42 PM

ผมคิดเอาเองว่าการจะไปถึง agile นั้น คือให้แต่ละคนรู้เองว่าเขาจะต้องทำอะไร
ผมคิดอีกว่ากระบวนการที่ดีคือ การลดขั้นตอนที่ไม่จำเป็น เพิ่มขั้นตอนที่จำเป็น
ระบุตัวงานให้ชัดเจน มีเส้นขีดที่ชัดเจน ให้บุคลากรได้ทำงานเต็มความสามารถโดย
ให้เกิดการรอคอยน้อยที่สุด (การคาบเกี่ยวกันระหว่างเส้นน้อยที่สุด) ผมคิดว่ากระบวนการ mass production
เน้นปริมาณ ตรงไหนมีปัญหาก็ยัดกำลังคนลงไป ไม่ใช่การแก้ปัญหาที่ถูกวิธี เพราะทำให้มองไม่เห็นปัญหา
ทั้งๆที่ปัญหายังอยู่ เหมือนการเติมน้ำลงไปให้ตอลดลง แต่ตอก็ยังคงอยู่ ไร้ประโยชน์ (แต่ดูเหมือนหลายๆที่ยังทำเช่นนั้นอยู่)
การแก้ปัญหาให้ถูกวิธี คือ การทำให้บุคลากรทำงานได้สบายที่สุด คือการปรับปรุงกระบวนการ ไม่ใช่ว่าปรับปรุงกระบวนการแล้วลำบากขึ้น
ทำงานมากขึ้นไปกับส่วนที่ฟุ่มเฟือยโดยที่ไม่ได้ใช้ประโยชน์จากกระบวนการที่ทำ ผมว่าไม่ถูกต้อง ซึ่งจริงๆแล้ว ผมคิดว่า
ทฤษฏีมันเป็นแค่แนวทางการศึกษา ไม่ใช่แนวทางปฏิบัติ เพราะธุรกิจแต่ละประเภทแตกต่างกัน วัฒนธรรมก็แตกต่างกันตามแต่ละสังคม
องค์กรควรสร้างองค์ความรู้และออกแบบขั้นตอนการปฏิบัติงาน ทั้งจากประสบการณ์และความรู้ภายใน จากทฤษฏีที่หลายๆส่วนก็นำมาใช้ได้
จากคู่แข่ง จากพันธมิตรทางธุรกิจ จากลูกค้า เป็นต้น รู้เขารู้เรา รบร้อยครั้งชนะร้อยครั้ง นั้นเป็นจริง เราไม่ต้องทำเยอะ แต่ทำให้มีคุณค่า
ให้ใช้ประโยชน์ได้ ไม่ใช่ว่าเอกสารมีเป็นพันหน้า แต่อ่านไม่รู้เรื่อง เทียบกับเอกสารร้อยหน้าอ่านแล้วรู้เรื่อง ไม่ได้เลย
การสร้างองค์ความรู้ภายในเป็นเรื่องสำคัญ (ที่ๆผมเคยทำงานก็เริ่มตระหนักถึงการสร้างองค์ความรู้ภายในแล้ว และได้เริ่มลงมือปฏิบัติแล้ว)
แต่การจะทำให้เกิดเป็น วัฒนธรรมขององค์กรขึ้นมา เป็นเรื่องที่ไม่ง่ายและต้องใช้เวลา
ทำไมต้องสร้างองค์ความรู้ภายใน? เพราะว่าจะได้ไม่ต้องยึดติดกับตัวบุคคล และผลงานหลายๆส่วนที่เคยทำสามารถนำกลับมาใช้ใหม่ได้
โดยไม่ต้องทำใหม่ ผมว่าทุกคนเคย เห็น code ยาวๆแล้วถอดใจไม่รู้มันทำอะไร แต่รู้ว่าตัวเองต้องการอะไร ก็คิดว่าทำใหม่ง่ายกว่า
แต่กลับพบว่ามันไม่ง่ายอย่างที่คิดเพราะ ต้องเจอปัญหาที่คนเคยทำมาแล้วเจอ ก็ต้องหาวิธีแก้ ก็ต้องใช้เวลามากอยู่ดี
และสุดท้ายเราก็ได้สร้าง code ที่อ่านไม่รู้เรื่องให้คนรุ่นหลังต่อไป มันก็วนเป็นวัฎจักร ดังนั้นจึงควรทำเอกสารที่ระบุชัดเจนถึงวิธีการ
ที่ให้คนอ่านรู้เรื่อง และ ควรสร้างเป็นรูปแบบเดียวกันทั้งองค์กรไม่ใช่โครงการนั้นใช้แบบนั้น โครงการนี้ใช้แบบนี้ แล้วแข่งกันเองภายในองค์กร
อย่างนี้ไปไม่รอด เพราะอย่างไรภายในบริษัทต้องมีการเคลื่อนย้ายบุคลากรเป็นปกติอยู่แล้ว ให้ทุกคนสามารถทำงานแทนกันได้จะดีที่สุด
ผมว่าบ้านซอฟท์แวร์ (software house) แนวจับฉ่ายนี่ น่าจะเหนื่อยที่สุด เพราะไม่มีหลักให้จับ การพัฒนากระบวนการคงจะช่วยได้ยาก
เพราะมีหลายปัจจัยเข้ามาเกี่ยวข้อง โดยเฉพาะความเชี่ยวชาญ ทั้งในตัวธุรกิจ ตราบใดที่คนออกแบบระบบไม่สามารถที่จะออกแบบระบบ
ได้เพราะไม่เข้าใจธุรกิจที่กำลังทำ เพราะไม่มีความเชี่ยวชาญไม่สามารถให้ลูกค้าทำตาม แต่ทำตามลูกค้าเพราะความไม่รู้ จะทำให้การเก็บ
ความต้องการจากลูกค้าลำบาก(มาก) และเกิดการรอคอย คนเขียนโปรแกรมก็ต้องรอ รอคนออกแบบระบบ คนออกแบบรอลูกค้า เกิดอะไรทราบไหมครับ
dead lock? ไม่หรอกยังโชคดีอยู่ที่ลูกค้าไม่รอคนเขียนโปรแกรม  :lol: หลายๆที่จึงรวมตำแหน่งคนออกแบบและคนเขียนโปรแกรมให้เป็นคนๆเดียวกันซะเลย
โดยลดช่องว่างการรอ และลดเวลาทำความเข้าใจแต่ละฝ่าย เน้นบุคลากรฝีมือชั้นสูง ที่ค่าแรงแพงกว่าปกติหน่อย แต่บางทีเขาคิดว่าคุ้มค่า

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

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

ผมเขียนอะไรมาไม่รู้เหมือนกัน แต่รู้ว่าต้องไปอาบน้ำแล้ว ฝันดีนะครับ

#13 Pink Dragon

Pink Dragon

    Topgun

  • Topgun
  • 3900 posts

Posted 24 July 2007 - 11:20 PM

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

บ้านเรา คนที่รับ SPI ไปใช้ ก็พยายาม implement กันอย่างบ้าระห่ำตามไปด้วย โดยไม่เข้าใจถึงแก่นว่าเราต้องการ improve ให้ได้ product และสายการผลิตที่ได้คุณภาพมากขึ้นกว่าเดิม
ทำไมถึงคิดว่าคนที่ implement ไม่เข้าใจล่ะครับ คุณ xcaleber ได้เคยลองวิจัยดูหรือว่ายังไงครับ

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

หลายที่ที่เห็น มี SPI level สูงๆ แต่ methodology ที่ใช้ในการพัฒนายังเป็น water fall โบราณไม่ได้พัฒนาตามไปด้วย
...
หลายที่ประเมินออกมาแล้ว defect ของ product ลดลงจริง แต่ design, architecture หรือเวลาที่ใช้ไม่ได้ดีขึ้นหรือแย่ลง
ผมว่ามันคนละเรื่องกันนะครับ

#14 xcaleber

xcaleber

    Star

  • Star
  • 1442 posts

Posted 24 July 2007 - 11:44 PM

View PostPink Dragon, on Jul 24 2007, 11:20 PM, said:

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

บ้านเรา คนที่รับ SPI ไปใช้ ก็พยายาม implement กันอย่างบ้าระห่ำตามไปด้วย โดยไม่เข้าใจถึงแก่นว่าเราต้องการ improve ให้ได้ product และสายการผลิตที่ได้คุณภาพมากขึ้นกว่าเดิม
ทำไมถึงคิดว่าคนที่ implement ไม่เข้าใจล่ะครับ คุณ xcaleber ได้เคยลองวิจัยดูหรือว่ายังไงครับ

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

View PostPink Dragon, on Jul 24 2007, 11:20 PM, said:

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

หลายที่ที่เห็น มี SPI level สูงๆ แต่ methodology ที่ใช้ในการพัฒนายังเป็น water fall โบราณไม่ได้พัฒนาตามไปด้วย
...
หลายที่ประเมินออกมาแล้ว defect ของ product ลดลงจริง แต่ design, architecture หรือเวลาที่ใช้ไม่ได้ดีขึ้นหรือแย่ลง
ผมว่ามันคนละเรื่องกันนะครับ

แล้วคุณ Pink Dragon คิดว่ายังไงละ ช่วยขยายความหน่อยสิครับ

#15 Pink Dragon

Pink Dragon

    Topgun

  • Topgun
  • 3900 posts

Posted 24 July 2007 - 11:55 PM

View Postxcaleber, on Jul 24 2007, 11:44 PM, said:

View PostPink Dragon, on Jul 24 2007, 11:20 PM, said:

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

บ้านเรา คนที่รับ SPI ไปใช้ ก็พยายาม implement กันอย่างบ้าระห่ำตามไปด้วย โดยไม่เข้าใจถึงแก่นว่าเราต้องการ improve ให้ได้ product และสายการผลิตที่ได้คุณภาพมากขึ้นกว่าเดิม
ทำไมถึงคิดว่าคนที่ implement ไม่เข้าใจล่ะครับ คุณ xcaleber ได้เคยลองวิจัยดูหรือว่ายังไงครับ

ผมว่ามันแล้วแต่ที่นะ บางที่ก็แค่อยากได้ชื่อว่ามีกับเค้าด้วย อย่าเข้าใจผิดว่าผมไม่เชื่อ SPI สิครับ ผมเรียน SE มา  มีโอกาสได้ฟังปัญหาที่บริษัทบางแห่งกำลังประสบอยู่พอสมควร ทุกวัันนี้ยังเชื่อว่า SPI ช่วยได้จริง แต่หลายบริษัทกำลังหลงทาง
ก็เป็นไปได้ครับ แต่จากประสบการณ์ที่เคยมีส่วนร่วมในการทำ process มา ผมมองว่าถ้าไม่มีความรู้ความเข้าใจ ไม่น่าจะสามารถ implement ได้ครับ ถ้า external auditor เข้ามาตรวจ แล้วปรากฏว่าผิด ๆ ๆ มี corrective action requests ออกมาเยอะแยะไปหมด QA คงไม่รู้จะเอาหน้าไปไว้ไหนครับ

View Postxcaleber, on Jul 24 2007, 11:44 PM, said:

View PostPink Dragon, on Jul 24 2007, 11:20 PM, said:

View Postxcaleber, on Jul 24 2007, 05:54 PM, said:

หลายที่ที่เห็น มี SPI level สูงๆ แต่ methodology ที่ใช้ในการพัฒนายังเป็น water fall โบราณไม่ได้พัฒนาตามไปด้วย
...
หลายที่ประเมินออกมาแล้ว defect ของ product ลดลงจริง แต่ design, architecture หรือเวลาที่ใช้ไม่ได้ดีขึ้นหรือแย่ลง
ผมว่ามันคนละเรื่องกันนะครับ

แล้วคุณ Pink Dragon คิดว่ายังไงละ ช่วยขยายความหน่อยสิครับ
โมเดลการพัฒนาซอฟต์แวร์, การออกแบบ, สถาปัตยกรรมพวกนี้ มันอยู่นอก scope ของ process improvement ครับ พูดง่าย ๆ ก็คือการทำ process improvement ไม่ได้ช่วยให้ออกแบบดีขึ้นหรือสถาปัตยกรรมดีขึ้นครับ ส่วนนั้นมันอยู่ที่คนทำต่างหากครับ ว่ามีความรู้ความเชี่ยวชา่ญมากน้อยแค่ไหน การทำ process improvement อาจจะช่วยได้บ้างในแง่ที่ทำให้มีการตรวจสอบ ช่วยลดความผิดพลาด แต่ก็ไม่ได้เป็นส่วนสำคัญที่จะช่วยให้การออกแบบดีขึ้น คือ คนมันไ่ม่เก่ง จะ peer review, joint review กันกี่รอบ มันก็ไม่ได้เก่งขึ้นมาเดี๋ยวนั้นหรอกครับ

ถ้าผมเข้าใจอะไรผิดไป คุณ xcaleber ช่วยชี้แนะหน่อยนะครับ

อาจจะพูดคุยนอกประเด็นกระทู้ไปบ้าง ขออนุญาตคุณ minimalist ด้วยนะครับ

Edited by Pink Dragon, 25 July 2007 - 12:06 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users