International Conference on IT Management and Engineering Practices (ITMEP) 2013-Day 2
18 มกราคม 2556 ซึ่งเป็นวันที่สองของงานสัมมนา โดยหัวข้อที่ได้พูดถึงในวันนี้จะเป็นประเด็นที่เกี่ยวข้องกับ Quality, Development Technique, Agile & Process Improvement และ Scrum ค่ะ โดยรายละเอียดจะสรุปตามแต่ละ Session ได้ดังนี้ค่ะ
KEYNOTE SPEECH : Mobile Governance – the CLP Experience
โดย Mr. Andre Blumberg, Director, Information Technology, CLP Power, Hong Kong
Mr. Blumberg ทำงานใน mobile industry มากว่า 12 ปี
• Mr. Blumberg เล่าว่า ก่อนหน้านี้ 6-8 ปี ยังไม่มีการใช้ mobile devices มากนัก CLP จึงต้องเน้นการให้ข้อมูล educate และ training เพื่อให้คนเข้าใจก่อน
• การ launch product แต่ละครั้ง CLP จะมีการจัด roadshow เพื่อให้คนได้ลองใช้ technology ก่อน
• CLP ได้ focus เรื่องความปลอดภัย (security) เป็นหลัก แต่สำคัญคือคนต้องมีวินัย และความรับผิดชอบ เพราะต่อให้ใช้เงินมากแค่ไหน ก็ไม่สามารถทำให้เกิดความปลอดภัยได้ หากคนไม่ปฏิบัติตามกฎ ดังนั้น CLP จึงเน้น การให้การศึกษาและความรู้ในด้านนี้ CLP มี CLP databox ซึ่งคล้ายกับ dropbox แต่มีความ secure กว่ามาก
• ในช่วง 2-3 ปีที่ผ่านมา mobile devices เริ่มหลากหลายมากขึ้น คนฮ่องกงมักซื้อมือถือใหม่ แล้วขายของเก่า เปลี่ยนไปเรื่อยๆ พนักงาน office มีทั้ง PC ที่ทำงาน และ laptop คนสูงอายุเริ่มมีการใช้ technology มากขึ้น
• นอกจากนี้การใช้ Android และ iPad มากขึ้นเรื่อยๆ trend ของการใช้ iPhone เพิ่มขึ้นเรื่อยๆ สำหรับคนฮ่องกง ในขณะที่ Microsoft ลดลง ทั้งนี้เนื่องจากผู้บริหารบริษัทผลิต application ต่างๆ ต้องเลือกว่า devices ไหนที่จะ support บ้าง เพราะไม่สามารถ support devices ทุกอันได้ ดังนั้นจึงต้องยึดตาม market share เป็นหลัก ในการเลือก support devices
• เนื่องจากมี devices ที่ต้อง support หลากหลาย CLP จึงคิดรูปแบบของ Mobile Application Device Platform ขึ้นมา เพื่อเป็น layer ในการช่วยปรับ application ที่พัฒนาด้วยภาษาหนึ่ง ให้สามารถ deploy บน devices หลากหลายได้ ซึ่งหากมี application มากๆ ก็จะคุ้มในการลงทุน
• Technology ตัวอย่างที่ CLP คิดให้กับลูกค้า เช่น มีฟาร์มผลิตกระแสไฟฟ้า แห่งหนึ่ง จดบันทึกข้อมูลต่างๆ ด้วยกระดาษหมด โดยมีแบบฟอร์มให้กรอก เมื่อ CLP เข้าไปช่วยพัฒนาระบบโดยให้ลูกค้าใช้แบบฟอร์มหน้าตาแบบเดิม แต่ภายในมีจุดที่ตามองไม่เห็นอยู่ เมื่อใช้ digital pen เขียนข้อมูลการผลิตกระแสไฟฟ้าต่างๆลงไป ข้อมูลที่เขียนนั้นจะถูกส่งไปยัง server ทันที
• สรุปคือ technology ที่ไม่จำเป็นต้องแพง แต่ต้องเหมาะสมกับการใช้งาน (fit for use)
โดย Mr. Jonathan Lui, inspearit Group
Technical Debt ถูกนิยามโดย Ward Cunningham เมื่อ 20 ปีมาแล้วว่า “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt…” (การส่ง code ออกไปในตลาดครั้งแรกเปรียบเสมือนกับการเริ่มสร้างหนี้ หนี้สินจำนวนน้อยและการจัดการอย่างทันท่วงทีจะทำให้งานพัฒนาเป็นไปได้อย่างรวดเร็ว อันตรายจะเกิดขึ้นเมื่อหนี้สินจำนวนนั้นไม่ได้ถูกชำระ การใช้เวลาแต่ละนาทีกับ code ที่ไม่ดีนักก็จะถือเป็นดอกเบี้ยของหนี้สินนั้นๆ)
Technical Debt อาจจะเกิดจาก Logic, Naming, Copy & Paste, Presentation, Architecture, Structure, Test Coverage, Process หรืออื่นๆ อีกมากมาย โดยทุกคนในองค์กรสามารถเป็นผู้ก่อให้เกิด Technical Debt ได้ ไม่ใช่เพียงแค่ developer เท่านั้น
SQALE Framework ย่อมาจาก Software Quality Assessment based on Lifecycle Expectations คิดค้นโดย Inspearit ในปี 2009 โดยจะทำการประเมินค่า quality characteristic ของแต่ละrequirements เรียงตามลำดับ ดังนี้
• Testability
• Reliability
• Changeability
• Efficiency
• Security
• Maintainability
• Portability
• Reusability
จากนั้นใช้ Estimation and Analysis Model ทำการวิเคราะห์หา Impact and Cost of Technical Debt ของแต่ละ requirement และทำการเลือก take action ทั้งนี้แต่ละองค์กรก็ควรจะร่วมกันกำหนดนิยาม model และเลือกตัดสินใจ take action อย่างเหมาะสม
An End-to-End Quality Management Framework to Ensure Software Quality and Productivity
โดย Mr. Vincent Yip, Development Manager, Thomson Reuters Hong Kong Ltd, Hong Kong
End-to-End Quality Management Framework เป็น Model หรือ Framework ที่ทางบริษัท Thomson Reuters Hong Kong ได้นำเอาเข้ามาปรับใช้เพื่อช่วยในเรื่องของคุณภาพของซอฟต์แวร์ที่ส่งมอบไปยังผู้ใช้มีคุณภาพที่ดีและสามารถส่งมองงานได้ตามเวลา ซึ่ง Product ที่ทางบริษัทพัฒนาจะรองรับงานทางด้าน Financial ที่ข้อมูลจะเป็น real-time เช่น การเช็คราคาตลาดหุ้น หรือการซื้อขายหุ้นในแต่ละวัน ดังนั้นจึงจำเป็นต้องมีลักษณะ low latency แต่ high frequency trading และเรื่องของ Performance ของระบบเป็นเรื่องสำคัญมาก ดังนั้นข้อมูลจึงจำเป็นต้องมีความถูกต้องและเชื่อถือได้ ดังนั้น Quality จึงเป็นสิ่งที่จำเป็น และทางบริษัทได้เริ่มรับ CMMI เข้ามาใช้ปรับปรุงกระบวนการจนได้ Level 5 ในปี 2004 และ Optimize Process อย่างต่อเนื่อง โดยเริ่มใช้ Six-sigma ในการวิเคราะห์และปรับปรุงกระบวนการ
ในการพัฒนาซอฟต์แวร์ทางบริษัทพบว่าปัญหาที่เกิดขึ้นกับโครงการมาจากในช่วงต่างๆ ของ Lifecycle เช่น Requirement phase ก็พบว่าเก็บข้อมูลมาไม่ครบ ไม่เข้าใจถึงความต้องการจริงของผู้ใช้ หรือใน Testing phase ก็เขียน Test case ไม่ครอบคลุม เป็นต้น รวมถึงมีแรงกดดันจากเรื่องของระยะเวลาส่งมอบงานด้วย บริษัทจึงหันมาให้ความสำคัญกับ Cost of poor quality หรือ Cost ที่เกิดจากการที่แก้ไข Defect ซึ่ง Cost เหล่านี้เกิดขึ้นจากการทำ Peer Review หรือ Testing นั่นเอง และทางบริษัทได้เริ่มศึกษาข้อดีของทั้ง Peer Review และ Testing พบว่าการ Test มีค่าใช้จ่ายสูงกว่าการทำ Peer Review ทางบริษัทจึงให้ความสนใจกับการทำ Peer Review ในการนำเข้ามาใช้ในการ optimize process
จากนั้นจึงเริ่มเก็บข้อมูลโดยดูจาก Project ที่มีลักษณะใกล้เคียงกัน และดูข้อมูล Defect Distribution และ Defect Density เพื่อจะนำมาสร้าง Model สำหรับคาดการณ์จำนวน Defect จะสามารถ Capture ได้จากแต่ละ phase ด้วยการทำ Peer Review และวิเคราะห์ผลโดยใช้ Regression ซึ่งผลที่ได้จาก Model จะเป็นจำนวน Expected Defect ที่ถูกนำมาตั้งเป็น Target และนำกลับไปวางแผนการทำ Peer Review ในแต่ละ Phase รวมถึง Estimate resource และ Estimate #Defect found เพื่อเปรียบเทียบกับ Target ด้วย ซึ่งจากผลการศึกษาพบว่า หากไม่ได้มีการนำ Framework ในการการปรับปรุงคุณภาพดังกล่าวมาใช้งาน และไม่ได้มีการทำ Peer Review อาจจำเป็นต้องใช้ Resource มากถึง 80% ในการ Rework ก่อนที่จะส่งมอบงานได้
Writing “Good” Requirements
โดย Ms Judy Bamberger, Process Solutions, Australia
Ms Bamberger กล่าวว่า การป้องกันไม่ให้เกิด defects ได้เร็วที่สุด คือการเขียน requirements ที่ดี
Requirements ที่ดีจะต้อง SMART
• Specific โดยยึดตามหลัก 5C : Clear, Complete, Consistent, Concise, Correct
• Measurable หรือ verifiable คือสามารถ test ได้ ตรวจสอบได้ วัดค่าได้
• Attainable/Achievable คือทำได้จริง ทั้งในด้านเทคนิค ต้นทุน เวลา และคุณภาพ
• Relevant คือสามารถบอกได้ว่า requirement นี้สำหรับส่วนไหนของ product
• Trackable/Testable คือ verifiable
Syntax ของ Requirement ที่ดีได้แก่
• บอกชัดเจนว่า ใคร หรือ อะไร เป็นผู้กระทำ หรือเป็นผู้รับผิดชอบ (who, what is responsible)
• จะต้องทำอะไร (Shall perform what action)
• ทำกับอะไร (on what object)
• ทำแล้วเกิดผลอย่างไร (causing what result)
• ภายใต้สถานการณ์ใด (under what conditions)
เช่น ระบบใบแจ้งหนี้ (what) จะต้องแสดง (shall perform what action) ใบแจ้งหนี้ที่ถูกร้องขอ (object) ภายใน 2 วินาที หลังจากผู้ใช้กดปุ่ม “go” (conditions)
ข้อควรระวัง
• ควรใช้ shall เพราะหมายถึงต้องมี หากใช้ will, should หรือ must จะให้ความหมายต่างออกไป หากมีการใช้คำอื่นที่ไม่ใช่ shall ใน requirements ควรถามว่าหมายถึงอะไร
• ควรหลีกเลี่ยงคำกำกวมต่างๆ เช่น Fast, Timely, Effective, User-friendly, Etc, และอื่นๆ เพราะไม่สามารถ verify ได้
• ควรใช้ประโยคแบบ “active” ไม่ใช่ “passive” เช่น ผมทำ code review เป็นประโยคแบบ “active” แต่ code review ถูกทำ เป็น “passive” ซึ่งทำให้ไม่ชัดเจนว่า ใคร เป็นคนทำ
• Action ใน requirement ควรเป็น action เดียว ไม่ผสมหลายอัน ควรแยก 1 requirement ต่อ 1 action เช่น An invoice system shall record and report… แบบนี้ไม่ได้ เพราะมีทั้ง record และ report
Best Practices and Challenges in Mobile Applications Development
โดย Ms Gigi Ng, Manager (Product & Business Development), MTel Ltd, Hong Kong
Challenges ที่พบใน Mobile Applications Development ได้แก่
• Spectrum of New Devices
From Smartphones to Tablets
Limitation of Screen size
Usability and simplicity
• Changing in Development Environments
• Short Development Cycle
• Tempting Price Challenges
• A Product Need to LIVE and EVOLVE
• Knowledge Gap
และตอนนี้ Mobile application ไม่ใช่แค่ Software แล้วแต่เป็น Advertising ด้วย ซึ่งเกี่ยวโยงกับทั้งทีม IT และ ทีม Marketing ดังนั้นในโปรเจคหนึ่งๆ ก็จะไม่ได้มีแค่ Project Manager, Developer, Tester แต่ยังต้องมี Designer, Creative Director, Content Strategist จากฝั่งลูกค้าด้วย
Mobile Development ยังมีความแตกต่างกันระหว่าง Native (e.g. iOS, Android) กับ Cross Platform (Web App, HTML5, Hybrid) รวมถึงความแตกต่างระหว่าง Web กับ Application อีกด้วย
Going Agile … Are You Sure?
โดย Dr. Bram van Oosterhout, Senior Consultant, ICON Redevelopment Project – Software Delivery, Biosecurity Services Group (BSG), Australia
Mr Oosterhout มีประสบการณ์ ในวงการ IT มากว่า 30 ปี ปัจจุบันเป็น Quality Manager ของ Fujitsu รับผิดชอบด้าน process improvement
Mr Oosterhout ได้ยกตัวอย่าง project หนึ่ง ซึ่งมีความซับซ้อน และ ความเสี่ยงสูงมาก มี features 277 อัน แบ่งออกเป็น SR1 (47 features, Q1 2009 – Q1 2010), SR2 (48 features, Q3 2009 – Q3 2010), SR3 (51 features) และ SR4 (111 features, Q1 2010 – Q2 2011)
เมื่อถึงเดือนมิถุนายน 2011 พบว่าไม่สามารถ deliver SR4 ได้ทันแน่นอน ปัญหาส่วนใหญ่เกิดจากจำนวน stakeholders ที่มากขึ้นกว่าเดิมมาก และ stakeholders เหล่านั้นไม่มีความคุ้นเคยกับ system ใหม่ รวมถึง project team บางส่วน ขาดประสบการณ์ในด้านนี้ จึงได้ปรับวิธีการทำงาน คือ
• ใน 1 subsystem จะมี Customer และ Supplier ร่วมกันสนับสนุนข้อมูลแก่ design team (Solutions team 1 คน & System Analyst 1 คน) ซึ่งทำงานร่วมกับ developer 2 คน และ tester 1 คน ซึ่ง implement ระบบตาม specification จาก design team
• ออก sub-system เล็กๆ ในวันที่ 1 ตุลาคม 2011 ซึ่งทดสอบแล้วว่าตรงตาม contract
การออก sub-system ที่สามารถใช้งานได้จริง ช่วยเพิ่มความมั่นใจ และยุติการถกถียงกันระหว่าง stakeholders และการจัดโครงสร้างทีมแบบใหม่ ช่วยแก้ปัญหาบางอย่างที่ไม่สามารถตัดสินใจได้
หลังจากประสบความสำเร็จในการใช้วิธีใหม่นี้กับ sub-system แรกใน SR4 จึงได้นำวิธีการนี้ปรับใช้กับส่วนอื่นๆ ต่อไป โดยนำ concept ของ SCRUM methodology มาใช้วางแผนและติดตามโครงการใน SR4 ทำให้ส่งมอบได้สำเร็จ