อันนี้เป็นคำถามที่น่าสนใจเหมือนกัน ผมเลยลอง Research มาดูนะ เพราะ Pattern ที่ใช้กันตอนนี้ T<TICKETID>_<DESCRIPTION NOTE> หลังจากลอง Research มาพบว่ามีคนเขียนไว้เหมือนกันนะ 7 Popular Strategies: Unit Test Naming Conventions – DZone ลองดูแล้วมีตัวที่น่าสนใจอยู่นะ อย่าง Pattern ที่ 7 คนที่เข้ามาอ่าน Code ของ Unit Test จะได้เข้าใจด้วยเลย Reference
ถ้าถามผม ตอนแรกที่มาเรียน ผมคิดเป็นภาพ Requirement เลย 5555 ปัญหกส่วนใหญ่มาจากคน และเข้าใจว่ามีอะไรสักอย่างที่มาสะท้อน Software Architecture เพราะหลายครั้งที่ทำงาน เรามีอิหยังวะ แต่ไม่รู้ว่ามัน เพราะอะไร มันแค่ไม่ใช่แหละ เลยลองสมัครดูรอบแรกแค่เต็มไปซะก่อน เลยเป็น Waiting List ของรอบ#02 ครับ หัวข้อก็มี ดังนี้ครับ การเดินทาง Day1 ก่อนเรียนให้มอง useful > correct นะครับ เริ่มต้นด้วยอะไรที่มองว่าเป็น problem จะช่วยให้เราแยก หรือ Sense ได้นะ ว่า อะไรเป็น ภาพในหัวผมไปตอนทำ Requirement…
Blog นีัเขียนดองมานานเกือบปีและ แต่พยายามให้ใจเย็น และมา Re-Write ให้มัน Soft ลงหน่อยมั้งเรามาดูกันครับว่าทำไมก่อนจะทำอะไรไป ต้องมีการ Estimate (ประมาณ) เวลา / resource ที่ใช้ แล้วทำไมต้องเผื่อเวลาขึ้นมา เพื่อให้งานมันไม่บีบรัดจนเกินไป มาดูกันครับว่าทำไมต้องเผื่อ คนซื้อไม่ได้ใช้ คนใช้ไม่ได้ซื้อ คนให้ Requirement ไม่ได้ใช้จริง ๆคนใช้ System ไม่ได้ให้ Requirement จริงๆ คนที่ Deal / Estimate ไม่ได้ทำเอง ? คน Estimate ประเมินแบบ Estimate ทีมพัฒนาไม่ได้รู้ในทุกเรื่องของ Technology…
พอดีได้ช่วยเพื่อน Review Slide สอนวิชา Software Engineering ของ ป. ตรี ครับ เลยขอสรุปศัพท์แต่ละแขนงของสายวิชา Software Engineering ไว้ ดังนี้ครับ ความต้องการซอฟต์แวร์ (Software Requirements) การออกแบบซอฟต์แวร์ (Software Design) การพัฒนาซอฟต์แวร์ (Software Development) การสร้างซอฟต์แวร์ (Software Construction) การทดสอบซอฟต์แวร์ (Software Testing) การบำรุงรักษาซอฟต์แวร์ (Software Maintenance) การจัดการโครงแบบซอฟต์แวร์ (Software Configuration Management) การจัดการโครงการ (Project Management)…
หลังๆมาตอน Implement ระบบที่ Site ใหม่ๆ ต้องเจอคำถามว่า ควรมี Solution Backup อย่างไร / ถ้ามีปัญหาที่ DC เราจะเตรียมความพร้อมกันอย่างไร เป็นต้นครับ มันเลยเป็นที่มาของ Blog นี้ด้วยครับ ที่มาสรุป Keyword ต่างๆ ที่สำคัญกันครับ Disaster คือ อะไร ? เหตุการณ์ที่ผิดแปลกไปจากสถานการณ์ปกติ เช่น เครื่อง Server พัง, Network ขาด, ไฟไหม้ หรือ ตึก DC โดนตัดไฟ เป็นต้น แม้ว่ามันจะเป็นเหตุการณ์ที่ไม่เจอประจำ…
ตัว CMMI มี Practices Area ใน Capability Area หลายอันนะ แล้ว PCM / PAD และ II มันต่างกันอย่างไรนะ ? กลับมาดูที่ละ Practices Area ว่าเน้นอะไรกัน ถ้าดูจาก Intent และ Value ที่ได้ครับ ผมขอสลับลำดับนะครับ จบไปแล้วกับการอธิบาย Practice Area PAD / PCM และ II ตามแบบฉบับของผมครับ ถูกผิดอะไรทักมาคุยได้ครับ
มีกระบวนการที่ดี แต่ทำงานปัญหาเดิมยังอยู่? พอไปตรวจสอบเงื่อนไขการตรวจวัดต่างๆ มันก็ผ่านแล้วนะ ทำไหมหละ ลองมายกตัวอย่างสักกระบวนการดีกว่า ตัวอย่างกระบวนการที่ผมยกมานั้นเป็นกระบวนการบริการลูกค้า เมื่อเกิดปัญหาการใช้งาน Software โดยใช้ระบบ Ticket Management อย่าง Redmine / Jira เป็นต้นครับ โดยกระบวนการตัวอย่างผมมีรายการละเอียด ดังนี้ เมื่อลูกค้าพบปัญหาการใช้งาน Software เข้ามาใน Ticket Management โดยอยู่ในสถานะ New ทีม Customer Support ได้การแจ้งเตือนว่ามี Incident ใหม่เข้ามาผ่าน Line และดึง Ticket นั้นเข้ามาตรวจสอบเปลี่ยนสถานะจาก New > CS Review…
สำหรับเจ้า PQA และ VV เป็น Practice Area หนึ่งใน CMMI 2.0 ครับ ที่ผมใช้คำว่า practice area เพราะในนิยามของ CMMI ได้ปรับจาก Process Area ที่มีในเวอร์ชันก่อนหน้ามาครับ เพราะเหตุในอันนี้ตามมาในอีก Blog ได้เลยครับ เอาหละกลับมาที่ Practice Area แต่ละอันมัน คือ อะไรกันบ้าง PROCESS QUALITY ASSURANCE (PQA) ตรวจสอบว่า Process ถูกใช้งานตามที่กำหนด หรือไม่ ทุกคนใช้งาน Process ไปในทิศทางเดียวกัน…
เนื่องจากบริษัทที่ผมทำงานอยู่ มีความต้องการปรับปรุงกระบวนการที่ใช้อยู่ให้สอดคล้องกับมาตรฐาน CMMI 2.0 จึงต้องมีการเตรียมความพร้อมกับการตรวจสอบครั้งนี้ และ ATM ก็เป็นหนึ่ง Keyword ที่เกี่ยวข้องในนั้นครับ ATM ในมุมของ CMMI แล้ว ไม่ได้มีหน้าที่สำหรับให้กดเงินนะครับ 555 ในมุมของ CMMI ATM ย่อมาจาก Appraisal Team Member ที่มีหน้าที่ช่วยประเมินกระบวนการขององค์กรครับ ตอนในช่วง Appraisal CMMI ครับ โดย Requirement ของ ATM มี ดังนี้ครับ ต้องมีประสบการณ์ในการทำงานที่เกี่ยวข้องอย่างน้อย 3 ปีคร้บ ผ่านการ Train Course…
ตอนแรก ผมไม่อยากเข้าไปในกลุ่มนี้ครับ (เอาจริงๆมันเป็น UAT เก่าครับ) แต่ทีม Support ของบริษัท ก็ก่อคดีไว้เยอะมาก เช่น หลังจากโดนบ่นซะหน้าชา เอาหวะลองเข้ามาดูและกัน แม้ว่ามันจะผิดกฏของบริษัทก็ตามครับ ผ่านมา 2 สัปดาห์และลองมาดูผลกัน สรุป ความจริง กลุ่ม Line กับ End User ควรเอามาใช้ตอนสำหรับช่วงระยะเวลาเร่งด่วนมากกว่า ที่มีระยะเวลาชัดเจน เช่น ช่วง UAT ของโครงการ แต่ในระยะยาวเอาจริงๆ ผมว่าไม่เหมาะสมนะ งานควรเดินตามกระบวนการ MA มากกว่านะ แล้วต้องเปิดรับ Feedback จาก End User จริงๆ…
