Project Management and Software Development Blog for Thais

The Cartoon

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

The Manifesto

ในมุมมองของผมแนวคิด Agile Development เหมือนยืนกันคนละข้างกับ CMMi เลยนะฮะถึงแม้จะมีจุดประสงค์หลักเดียวกันคือทำให้ software มีคุณภาพ ดูได้จากคำประกาศ (manifesto) ทั้ง 4 ข้อในการ์ตูน อย่างแรกที่ผมเห็นด้วยเต็มที่คือเรื่องทำเอกสารที่มันมากเกินไปใน Process ของ CMMi นี่แหละฮะ ก็พอเข้าใจครับว่าเอกสารบางอย่างสำคัญแต่สุดท้ายแล้วถามว่าเอกสารเหล่านั้นลูกค้ามองเป็น deliverable ของ project รึเปล่า?? ส่วนมากแล้วไม่ใช่เลยครับ จากประสบการณ์จริงๆการทำตาม CMMi มันเสียเวลาทำเอกสารมากจริงๆ แต่ Agile ไม่นะ เวลาเกือบทั้งหมดเอาไปทำให้เกิด Working software ครับผม เมื่อประกอบกับอีกสามข้อที่เหลือทั้ง

1. สนับสนุนการทำงานร่วมกันภายในทีม
2. พยายามทำงานโดยมีการติดต่อประสานงานกับลูกค้าอยู่ตลอดเวลา และ
3. เตรียมพร้อมรับการเปลี่ยนแปลงที่เกิดขึ้นกับงาน

ผมคิดว่า Agile Development จะช่วยให้ชีิวิตคน IT มีความสุขขึ้นนะครับ

Agile

ใครที่รู้จัก Software Development Life Cycle (SDLC) แบบดั้งเดิม เช่น Waterfall หรือ Iterative อยู่แล้ว ก็ไม่ยากเลยครับที่จะทำความเข้าใจกับ Agile Development เพราะว่าเจ้านี่เป็นสมาชิกใหม่ในบ้าน SDLC นั่นเอง แล้วทำไมต้องมี Agile ขึ้นมาหละ? ส่วนตัวผมเองคิดว่าก็เพื่อเติมเต็มส่วนที่ SDLC เก่าๆทำได้ไม่ดีนั่นแหละครับ … แล้วของเก่าไม่ดียังไง?

Success

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

From CIO Magazine:

Projects that were found to meet all of the traditional criteria for success?time, budget and specifications?may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business.

… Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value. For example, at a financial services company, a new system… was six months late and cost more than twice the original estimate (final cost was $5.7 million). But the project ultimately created a more adaptive organization (after 13 months) and was judged to be a great success?the company had a $33 million reduction in write-off accounts, and the reduced time-to-value and increased capacity resulted in a 50 percent increase in the number of concurrent collection strategy tests in production.*

ข้อความข้างบนบ่งชี้ให้เห็นถึงปัญหาได้อย่างชัดเจนเลยครับ โดยสรุปก็คือถึงจะทำเสร็จตรงเวลาที่งบประมาณที่กำหนดและมีคุณภาพดี แต่สิ่งนั้นอาจจะไม่ได้เป็นที่ต้องการของตลาดอย่างแ้ท้จริง เราจะพูดได้ว่า Project นี้ประสบความสำเร็จหรือ? Read the rest of this entry »

Requirements

สัปดาห์ที่แล้วผมมีโอกาสได้แสดงความคิดเห็นต่อคำถามของคุณ siam2advance เกี่ยวกับกระบวนการหลังจากได้รับ requirement จากลูกค้ามาแล้ว ซึ่งผมอยากจะขยายความต่อในบทความนี้ครับ

ผมเชื่อว่าพวกเราทุกคนในวงการ software development คงจะเคยเจอปัญหาที่เกี่ยวข้องกับ requirement อยู่บ่อยๆโดยเฉพาะอย่างยิ่งปัญหาที่เกิดจาก requirement ที่ได้มาไม่มีความสมบูรณ์หรือละเอียดเพียงพอที่จะทำงานต่อ ทั้งในส่วนของ software development ซึ่งต้องทำการออกแบบระบบสำหรับแต่ละ requirement และในส่วนของ project management ซึ่งต้องทำ estimation and planning

ความไม่สมบูรณ์ของ requirement ที่ผมพบบ่อยๆก็เช่น

Completeness: requirement ไม่สมบูรณ์ในตัวเอง อธิบายเรื่องราวหรือความต้องการได้ไม่ครบถ้วนครับ เช่น “เพื่อเพิ่มความสามารถของระบบในการสนับสนุนการตัดสินใจของผู้บริหาร รายงานประจำปีรูปแบบใหม่จึงควรถูกสร้างขึ้น” สำหรับผม ถ้าได้ requirement มาแค่นี้จริงๆคงเศร้าหละครับเพราะว่าจะทำอะไรต่อก็ลำบากไปหมด ที่มึนมากๆก็คือ “รูปแบบใหม่” นี้มันแบบไหนหละ?

Ambiguity: ข้อมูลที่ระบุใน requirement มีความกำกวมไม่ชัดเจน เช่น “การสร้้้้างรายงานประจำปีต้องดึงข้อมูลจากตารางที่เกี่ยวข้องในฐานข้อมูล” คำว่า “ที่เกี่ยวข้อง” นั้นไม่ชัดเจนเพียงพอที่จะลงมือ design ระบบได้ทันทีหรอกครับ ยิ่งสำหรับคนที่ไม่มีประสบการณ์ในงานด้วยแล้ว ยิ่งยากใหญ่ Read the rest of this entry »

ปัญหายังอยู่ …

จากบทความก่อนหน้า ผมเสนอแนะวิธีการใช้ Tasks และ Task Request ใน Microsoft Outlook เพื่อแก้ปัญหาคนในทีมลืมทำงานที่ได้รับมอบหมายไปแล้ว แต่ว่า … แหะๆ เพื่อนร่วมทีมคนอื่นๆสบายขึ้นแต่สำหรับ Project Manager ก็ใช่จะสบายซะทีเดียวหรอก ทำไมหนะหรอ? ถ้า Project มี Task ไม่เยอะ มีคนทำงานไม่มากก็คงไม่เป็นปัญหาเท่าไร แต่ในโลกความจริงมันต่างจากนั้นมากครับ ลองนึกดูครับ ถ้า Project มี Task เป็นร้อย คนทำงานซักสามสิบคน Project Manager ต้องมีมึนแน่ๆครับกับการไล่ส่ง Task Request ให้ครบทุก Task และทุกคน ฝันร้ายยังไม่จบแค่นั้น เป็นไปได้ยากมากๆที่เราจะใช้ Project Plan ฉบับเดิมตั้งแต่ต้นจนจบโปรเจก ดังนั้นถ้า Project Plan มีการแก้ไข เปลี่ยนแปลง Project Manager ก็ต้องมานั่งลุยส่ง Task Request กันอีกรอบหละครับ … คิดแล้วเหนื่อย

… แต่ทางออกก็พอมี

ไม่ต้องคิดมากครับ ผมมีทางออกให้ อาศัยที่เป็น Programmer มาซักพัก ผมเลยเขียน VBA Macro ใส่ใน Microsoft Project Template ช่วยทำหน้าที่ในการส่ง Task และ Task Request แบบอัตโนมัติออกมาครับ เพื่อนๆลองเอาไปใช้ดูได้เลยครับ Download: project-to-outlook template (168)

เมนูใหม่

เปิดมาจะเห็นมีเมนูเพิ่มมา 1 เมนู อยู่ขวาสุดชื่อ “Outlook” คลิ๊กเข้าไปจะมี 2 เมนูย่อยให้ลองใช้กัน อันแรก “Selected Row(s) to Task(s)” ทำหน้าที่ส่ง Task ให้ตัวเอง(สำหรับสมาชิกทั่วไป) ส่วนอันที่สอง “Selected Row(s) to Task Request(s)” ทำหน้าที่ส่ง Task ให้กับคนที่กำหนด(สำหรับ Project Manager) ครับ

New Menu

Read the rest of this entry »

วันนี้ผมมีโอกาสได้อ่านบทความของคุณ Bomber เรื่องกระบวนการพัฒนาระบบของ Google ที่พูดถึงแนวคิดและแนวปฏิบัติในการทำงานของ Google ซึ่งมีหนึ่งประเด็นที่น่าสนใจครับเกี่ยวกับกระบวนการ Peer Review ตอนแรกผมไม่คิดว่าบริษัทใหญ่ๆอย่าง Google จะให้ความสำคัญของกระบวนการนี้มากขนาดนี้

Peer Review

มีมาตรฐานของสไตล์การเขียน code ทุกๆคนต้องผ่านการ train ตรงนี้ก่อน code จะต้องผ่านการ review ว่าเขียนถูกต้องตามสไตล์กลาง ก่อนจะเข้า code base จะต้องมี design document เสมอ ไม่ว่าจะเป็น project เล็กแค่ไหน และจะมีคนคอยตรวจดู format ของ document ว่าถูกต้องหรือไม่ งานทุกชิ้นที่ขึ้น codebase กลางต้องมีคุณภาพตามมาตรฐาน process เหล่านี้ทำให้ช้าอยู่บ้าง แต่แลกกับคุณภาพที่ดีของงานแล้วคุ้มค่ามาก

จากประสบการณ์ส่วนตัว ผมมองว่าการทำ Peer Review ในระดับที่เหมาะสม (ไม่มากเกินไป ไม่น้อยเกินไป) จะเป็นประโยชน์มากต่อการพัฒนาระบบ ไม่ว่าจะเป็น Code Review หรือ Document Review ก็ตาม Read the rest of this entry »