ประสบการณ์จากการทำโปรเจค SE

From LifeOnVM

มาเขียนเรื่องนี้ช้าไปหน่อยนึง ก็จบไปแล้วสำหรับการเรียนวิชาที่ขึ้นชื่อว่า "ถีก" ที่สุดวิชาหนึ่งของภาคคอม

วิชานี้ (SE - Software Engineering) เป็นอะไรที่ดูเผินๆแล้วดูจะคาบเกี่ยวกับ SA (System Analysis) ซะมาก  ซึ่งพอเรียนจริงๆแล้วปรากฎว่า ...

มันก็เป็นแบบนั้นจริงๆ! (แป่ว ~)

ถ้าจะให้สรุปจริงๆก็คือว่า SA มันดูจะไม่ค่อยลงลึกใน Technical Detail มากแค่นั้นแหละ จะทำอะไรให้มันดู Generic ไว้ก่อน เรื่องเทคโนโลยีที่ใช้ Implement จะใช้อะไรก็ได้ ส่วน SE นี่จะละเอียดถึงขั้นมองกันเป็น Class เลยทีเดียว

ตอนทำโปรเจคก็อยู่กลุ่มเดียวกัน แจน แจ๋ เอย ต้น ปัน แบงค์ลาว สร้อย สุธี ปาย แล้วก็ จ้า พอจะรู้ชะตาตัวเองอยู่แล้วว่ายังไงก็ได้ทำโค้ดแน่ๆ Y_Y

ขอสรุป Lessons Learned จากโปรเจคไว้เป็นหัวข้อให้อ่านง่าย ดังต่อไปนี้

แบ่งงาน Document

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

ปัญหาอีกอย่างก็เรื่องเข้าใจไม่ตรงกัน เช่น ตอนเขียน Use Case - Sequence นี่ก็แบ่งไปทำคนละอันสองอัน แล้วปรากฎว่าพอทำเสร็จแล้วเข้าใจไม่ตรงกันก็ต้องมาแก้ อาจจะแก้ได้โดยการคุยกันให้เข้าใจก่อนกลับไปเขียนล่ะมั้ง

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

นัดบ่อย

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

เลยได้ข้อสรุปของตัวเองว่า วิธีนัดที่ดีควรจะนัดไปนั่งทำงานกันตรงนั้นเลยครับ การนัดในลักษณะ ตกลง ทำความเข้าใจ แบ่งงาน แล้วแยกย้ายกลับไป หวังว่าจะได้งานตามที่ตกลงกลับมา ดูจะเวิร์คแค่กับคนบางประเภทจริงๆนะ 

เทคโนโลยีที่ใช้

ผมพบจบเจอคนหลายคนที่ไม่ค่อยปลื้มกับการเขียนโปรแกรมประเภท Database-driven Application ส่วนหนึ่งก็เพราะมันวนไปวนมาครับ เขียนมาเสร็จก็มีคนเขียนไว้แล้ว แถมดีกว่าด้วย งานก็ซ้ำไปซ้ำมาจะทำไปบ่อยๆทำไม ลักษณะงานส่วนใหญ่ก็มีออกแบบ Database เขียน SQL ทำหน้า User Interface ก็จบ ผมเองก็ต้องยอมรับว่าเป็นหนึ่งในคนกลุ่มนั้นเหมือนกัน ตอนทำงานนี้ก็เลยพยายามจะดึงอะไรใหม่ๆแปลกๆมาใช้ซะหน่อย งานนี้ผมก็ได้ลอง Subsonic ไปเรียบร้อยสมใจอยาก

แบ่งงาน Design + UI + Coding

อันนี้จัดว่าเป็นเรื่องยากถึงยากที่สุด o__O

เนื่องจากว่าตั้งแต่ตั้งเป้าไว้ว่าคราวนี้จะใช้ ASP.NET + Subsonic + MySQL แล้วไม่มีคนอื่นในทีมที่เคยเขียน ASP.NET มาก่อนเลย ตอนแรกก็คิดไว้ (ในอุดมคติ) ว่าจะให้ทุกคนไปหัดมา เป็นแล้วก็มาช่วยกันเขียนครับ

แต่จริงๆในสถานการณ์ที่เวลามันบังคับ แต่ละคนก็ไม่ค่อยมีเวลาให้โปรเจค มันทำแบบนั้นไม่ได้หรอก วิธีการที่ดีคือต้องโยนให้แต่ละคน "รับผิดชอบ" ไปเป็นส่วนๆเลย ส่วนๆที่ว่านี้ ถ้าดีหน่อยก็อาจจะแบ่งกันเป็น Class  แต่ส่วนใหญ่ที่เห็นแบ่งกันแล้วทำงานสะดวกก็คือแบ่งกันเป็นราย Page ซึ่งมันทำให้แบ่งงานง่ายขึ้น แต่ก็ให้ข้อเสียตามมามากมาย เช่น แต่ละคนก็ใช้วิธีติดต่อ Database ไม่เหมือนกัน บางคนก็ hard-coded บางคนก็แยกไว้ใน configuration file กระจัดกระจายไปหมด เคยไปบ่นๆเรื่องนี้ไว้ใน Twitter @wienat ก็มาตอบอย่างตรงไปตรงมาว่า โปรเจค SE มันไม่ต้องแคร์เรื่อง maintainability มากก็ได้ ทำให้จบไปพอ o__O' ... ซึ่งก็ถูกต้องนะครับ

สำหรับโปรเจคกลุ่มผมเองก็วางแผนไว้ว่าจะให้ Coding 5 คน แต่ทำไปทำมาได้ทำจริงๆแค่ประมาณ 3 คน คือ ต้น ปัน แก๊น คือปกติแล้วผมรู้สึกว่า คนเราพอทำอะไรซักอย่างเป็น (Just Work) ในการทำครั้งต่อๆมา เราก็มักจะไม่อยากทำแบบเดิมๆ แต่มักจะหาวิธีที่มันเป็น Best Practice เสมอ ซึ่งคนอื่นๆเค้าไม่อยากมาเสียเวลากับเราด้วยน่ะสิ

ก็เลยเรียนรู้ว่าจะแบ่งงานแบบไหนก็ต้องดูกลุ่มด้วยครับ ถ้าเป็น Embedded Environment อยู่แล้ว ก็คงต้องต้องเอางานเสร็จไว้ก่อน (รึเปล่า)

จริงๆแล้วอยากเขียนอีกแต่นึกไม่ออก - -'' ทิ้งเวลาไว้นานเกิน

เกรดออกแล้ว เรื่องนี้ก็จบด้วยดีครับ :)