วันอังคารที่ ๓๐ ตุลาคม พ.ศ. ๒๕๕๐

การบริจาคโลหิตกับระบบสารสนเทศไปด้วยกันได้อย่างไร

ตั้งคำถามเพื่อให้เป็นประเด็นซะอย่างนั้นแหละ

คำถามที่ไม่ตรงประเด็นกับหัวข้อบ้าง

ถ้ามีเหตุการณ์เกิดขึ้นสามกรณี ต่อไปนี้ท่านคิดว่า ท่านจะเลือกทำแบบใด ในการบริจาคโลหิต

  1. มี forward mail มาขอบริจาคโลหิตจากใครไม่รู้ ให้ไปบริจาคได้ที่ ร.พ. ????? วันนั้น วันนี้
  2. มีญาติผู้ป่วยมาขอร้องด้วยตนเอง เพื่อขอบริจาคโลหิตจากเรา
  3. ไปบริจาคโลหิตที่ ร.พ. เองโดยไม่ต้องรู้ว่ามีผู้ป่วยหรือไม่

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

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

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

http://202.29.16.20/blood/

XP คืออะไร อะไรคือ XP


ตั้งคำถามขึ้นมาแบบนี้หลายคนตอบได้ ง่ายมาก มันคือ Windows XP ใช่เปล่า?

คำตอบ คือไม่ใช่ครับ XP เมื่อพูดถึงการพัฒนาซอฟต์แวร์ จะนึกถึงความสำเร็จ นึกถึงความเร็วในการพัฒนา และคุณภาพของซอฟต์แวร์ เพราะฉะนั้น XP ในตรงนี้ก็เป็นกระบวนการ วิธีการการพัฒนาซอฟต์แวร์อีกแบบหนึ่งที่จะนำเสนอ ดังนั้น XP จึงย่อมาจาก extreme programming

XP เป็นกระบวนการที่มีลำดับขั้นตอนเช่นเดียวกัน ดังนี้

1. Collecting user stories เป็นการเก็บรวบรวมเรื่องราวความต้องการของลูกค้า จริง ๆ แล้วการทำแบบอื่นๆ ก็เน้นแบบนี้เช่นกัน แต่กระบวนการรวดเร็วกว่า ใช้กระดาษโน้ตแผ่นเล็ก ๆ ให้ผู้ใช้ระบบเขียนความต้องการ โดยไม่มีการพูดคุยด้านเทคโนโลยี หรือฐานข้อมูล หรืออัลกอริทึ่ม เป็นการพูดคุยกันระหว่างโปรแกรมเมอร์กับผู้ใช้โดยตรง โดยไม่ผ่านนักวิเคราะห์ระบบ เมื่อโปรแกรมเมอร์ ทราบความต้องการแล้วรวบรวมจำนวน stories นำมากำหนดวันแล้วเสร็จในงานนั้น ๆ เพื่อกำหนดวันส่งมอบต่อไป
2. Create Spike Solution เป็นการนำเอา user stories มาหากระบวนการแก้ปัญหาด้วยวิธีการทางการเขียนโปรแกรม โดยเน้นการเขียนโปรแกรมแบบง่าย ๆ ไม่ต้องซับซ้อน ถ้าแก้ปัญหาคนเดียวไม่ได้ แนะนำให้ใช้วิธีการ Pair Programming เพื่อลดความเสี่ยงที่เกิดขึ้น
3. Release Planning เป็นการวางแผนการดำเนินงานทั้งหมดจนแล้วเสร็จ กระทั่งส่งมอบงานให้ผู้ใช้ วิธีการคือให้นำ user stories ทั้งหมดนำมาให้ทีมโปรแกรมเมอร์พิจารณางานแล้วเสร็จ โดยพิจารณาตาม story แต่ละ story แล้วบวก ลบ 20 % จะได้วันแล้วเสร็จ
4. Iteration Planning ขั้นตอนนี้เป็นการทำซ้ำแล้วซ้ำอีก เพราะ XP ใช้วิธีการส่งมอบงานไปเรื่อย ๆ เมื่องานก้าวหน้าแต่ละ story แล้วทดสอบระบบเมื่อผ่านเรียบร้อย จึงส่งมอบงานและนำ story ใหม่มาทำอีก แต่งานเดิมทดสอบไม่ผ่านต้องทำซ้ำ ให้ดูภาพประกอบ



ที่มา : www.extremeprogramming.org


5. Development หมายถึงขั้นตอนการพัฒนาระบบเป็นการเขียนชุดคำสั่ง แต่ XP Model จะมีกระบวนการย่อยเพิ่มขึ้น เช่น มีการ Stand up meeting เป็นการพูดคุยกันก่อนการทำงานในแต่ละวันเพื่อหาปัญหาและวิธีแก้ปัญหา และนอกจากนี้ยังนำเอาวิธีการที่เรียกว่า Pair Programming มาใช้ในการพัฒนาด้วย
6. Acceptance Tests เป็นกระบวนการทดสอบจากผู้ใช้ ที่ผู้ใช้ได้กำหนดความต้องการเอาไว้ ว่าถูกต้องตรงกันหรือไม่ มีคุณภาพหรือไม่ กระบวนการตรวจสอบคุณภาพก็อยู่ในกระบวนการนี้ด้วย โดยจะต้องมีทีมตรวจสอบคุณภาพมาจากภายนอกด้วย แต่ต้องทำงานอย่างใกล้ชิดกับทีมพัฒนาโปรเจ็คนี้ด้วย
7. Small Releases การส่งมอบงานไปทีละขั้น ทีละฟังก์ชันเป็นเรื่องภาพลักษณ์ทางธุรกิจที่ดี ทำให้ผู้ใช้มองเห็นความก้าวหน้าของโปรเจ็ค เห็นความน่าเชื่อถือทีมพัฒนา และเมื่อเจอปัญหาอีกจะได้เร่งแก้ไขแต่เนิ่น ๆ