Requirement ทางซอฟต์แวร์ กับการเปลี่ยนแปลงบ่อยๆ
.
ศัพท์ในวงการซอฟต์แวร์ คำว่า "Requirement" คือ "ความต้องการ" ที่ทีมพัฒนาซอฟต์แวร์ ต้องไปสกัดเอามาจากลูกค้า (หรือผู้ว่าจ้าง) ว่าเขาต้องการให้ซอฟต์แวร์ทำงานอะไรได้บ้าง มีฟังก์ชั่นอะไร หน้าตาเป็นแบบไหน บลา บลา ....
.
ตอนได้งานจากลูกค้าใหม่ๆ ก็เหมือนพบรักกับลูกค้า 😍 ความรักยังหวานชื่น เพราะโอกาสได้งาน ได้เงินมาอยู่ในมือ ขอแค่นำ Requirement ของลูกค้ามาพัฒนาซอฟต์แวร์จนเสร็จ แล้วส่งมอบงานแค่นี้เองก็ปิดจ๊อบแหละ
.
แต่ชีวิตใช่ว่าจะหวานหอม เหมือนตอนคบกับลูกค้าใหม่ๆ เพราะสัจธรรมในวงการพัฒนาซอฟต์แวร์ ตัว Requirement จะไม่ค่อยนิ่ง มีการเปลี่ยนแปลงบ่อย ราวกับอากาศเปลี่ยนแปลงบ่อย คำว่าเปลี่ยนแปลงจะเรียกทับศัพท์ไปเลยว่ามี "Change" เกิดขึ้นใน Requirement
.
ซึ่งเรื่อง change ในวงการนี้ ถือว่าปกติมาก ...แน่นอนเมื่อเกิด change ขึ้นมาทีไร ในฝั่งคนสร้างซอฟต์แวร์ อาจรู้สึกไม่ชอบสักเท่าไร 😫 เพราะต้องตามแก้โน่นแก้นี้ ทำแทบตายทั้งคืน ดันไม่เอาซะงั้น ไหนจะเป็น Bug ที่แอบแฝงขึ้นมาโดยไม่รู้ตัว และปัญหาอื่นๆ อีกสารพัด
.
🤔🤔 คำถาม ทำอย่างไรถึงจะอยู่กับ change ของลูกค้าโดยยิ้ม และมีความสุข (หรือเปล่า) เหมือนตอนพบรักลูกค้าใหม่ๆ ?
.
อันนี้เป็นคำแนะนำของคุณ Piyorot (ก็อปมาอีกที) เผื่อช่วยท่านได้ เป็นวิธีการบริหารจัดการ change ในโลกของซอฟต์แวร์ ดังต่อไปนี้
.
👉 1) ตั้งกฎไว้เลยว่าเราจะไม่เริ่มทำงานถ้า Requirement ยังไม่เรียบร้อย
.
👉 2) ทำ Requirement Analysis อย่างละเอียดตั้งแต่แรก
.
👉 3) ใช้ Operational Concept มาช่วยในการทำ Requirement Analysis
.
👉 4) กำหนดกฏเกณฑ์การรับ/ไม่รับ Change ที่แน่นอน ไม่ใช่ใครสั่งอะไรก็ต้องทำตาม
.
👉 5) ให้ QA มาช่วยทำ Requirement Analysis แล้วเอา Dev มาเขียน UAT บ้างเพื่อแลกเปลี่ยนมุมมอง Requirement Analysis จะได้สมบูรณ์ขึ้น
.
👉 6) Dev และ QA และ Product Owner ต้องช่วยกันกำหนดหัวข้อสำคัญที่ต้องพิจารณาเวลาคุยถึง Requirement หรือ Design เช่น เรื่อง Data Format, Exception, Condition, State Diagram และ Data Flow
.
👉 7) ทำ Pair Implementation ซะเลย เอา Dev และ QA มานั่งทำงานไปพร้อมกัน Dev เขียนโค๊ดไป QA เตรียม Test Case, Test Data เสร็จแล้วก็ลองเทสตรงนั้นเลย เจ๊งก็แก้ทันที ไม่ต้องเสียเวลารออะไรต่ออะไรกัน
แบ่งงานเป็นส่วนย่อยๆเพื่อสร้างโฟกัสที่ชัดเจนขึ้น ไม่ต้องคิดมาก ไม่ต้องคิดไกล ไม่ต้องพูดนอกเรื่องเวลาทำ Requirement Analysis หรือ Design
.
👉 8) มี Standup Meeting เพื่อลดเวลาในการสื่อสาร เวลาในการรอใครต่อใครตอบคำถามระหว่าง Dev, QA และ Product Owner
.
👉 9) ดึง Product Manager หรือ Product Owner หรือถ้าได้ลูกค้ายิ่งดี เข้ามาช่วยยืนยันความถูกต้องของงานบ่อยๆ เพื่อลดการเกิด Change ขนาดใหญ่
.
👉 10) ไม่ต้องเสียเวลารอคำตอบ ไม่ต้องเสียเวลาคุยอะไรมากหรอก ทำๆไปก่อนแหละ (แต่ทำงานเล็กๆนะ) ถ้าผิดค่อยมาแก้ทีหลัง
.
👉 11) เผื่อ Buffer ไว้สำหรับ Change พวกนี้บ้าง
.
👉 12) ทำ Code Review และ Test Review เพื่อยืนยันความถูกต้องและความเข้าใจที่ตรงกันก่อนทำงานขั้นต่อไป
.
👉 13) ขอเวลาวันละ 10 นาทีมา Review พวก Design/Implementation/Test Case กันหน่อยว่าไม่มีอะไรเปลี่ยนแปลง
.
👉 14) ไม่รับ Change ทันที เอาไปใส่ Product Backlog ไว้แล้วค่อยว่ากันวันหลัง
.
👉 15) อยากให้มีมุมมองของลูกค้าเพิ่มเข้ามาบ้าง ขอให้ Support Engineer หรือ Customer Service Staff มาช่วยแล้วกัน
.
👉 16) จัดลำดับความสำคัญของ Requirement หน่อยก็ดีนะ จะมี Change ทั้งทีจะได้คุ้มค่าที่จะเสียเวลาทำหน่อย
.
👉 17) มีข้อมูล/หลักฐาน/ตัวเลขอะไรก็ได้ที่บอกเราได้ว่าถ้ารับ Change ตัวนี้แล้วจะส่งผลกระทบแค่ไหนกับงานโดยรวม Change Management จะได้มีหลักการมากขึ้น
.
👉 18) เอาส่งเมล์แนบเอกสารที่อยากให้รีวิวมันไม่ได้ผล ก็เปลี่ยนเป็นเดินไปหาที่โต๊ะคนที่เราอยากให้รีวิวเอกสารให้ แล้วอธิบายให้เค้าฟังว่าอะไรเป็นอะไร ขอความเห็นเค้าตรงนั้นเลย
.
👉 19) คุยๆๆ เรื่อง Requirement หรือ Design แล้วก็ปล่อยให้คำพูดและความคิดหายไปกับสายลม … อย่าให้เป็นแบบนั้น … อัดเสียงไว้บ้างหรืออัดวิดีโอก็ได้ (iPhone มีกันแทบทุกคน) จัดกลุ่มให้เป็นหมวดหมู่ เก็บไว้เป็น Requirement Analysis and Design document (รูปแบบใหม่) … สุดท้าย
.
👉 20) ไม่รับ Change อะไรทั้งสิ้น (เบื่อ)
+++++อ้างอิง+++++
https://medium.com/pure-project-management/อยู่กับ-requirement-change-อย่างมีความสุข-219d10d65751
.
✍ โปรแกรมเมอร์ไทย thai programmer
「data flow diagram」的推薦目錄:
- 關於data flow diagram 在 โปรแกรมเมอร์ไทย Thai programmer Facebook 的最佳貼文
- 關於data flow diagram 在 DavidKo Learning Journey Facebook 的最佳解答
- 關於data flow diagram 在 臨床筆記 Facebook 的最讚貼文
- 關於data flow diagram 在 How to Draw a Data Flow Diagram - YouTube 的評價
- 關於data flow diagram 在 380 Data flow diagrams ideas in 2021 - Pinterest 的評價
data flow diagram 在 DavidKo Learning Journey Facebook 的最佳解答
今日在公司帶看板遊戲
在解說cumulative flow diagram 的結果
大多團隊不會解讀數據
或者利用數據來看哪些地方做的好不好
Data driven improvement 是件重要的事
這次的團隊比較不會注重 還技術債
因此進展比較慢
data flow diagram 在 臨床筆記 Facebook 的最讚貼文
敗血性休克使用輸液急救的指引,很好用,一目瞭然。
PS:除了文謅謅的論文寫作之外,這種圖表式的流程圖最能表達理念及作法指引。
任何一篇實務性的長篇大論,若是無法以這種流程圖(Algorithm)來表達作者理念,就是有兩種原因,第一,作者本身還沒完全搞清楚他在寫些什麼;第二,就是這篇文章跟本沒有健全結構,無法呈現Algorithmm。
PS again, 有時候學生學習不佳,考試成績差,實務應用差,授課老師也是有責任的。
A users’ guide to the 2016 Surviving Sepsis Guidelines
Two aspects of the guidelines should be understood. We illuminate these two aspects through an analysis of the priority currently assigned to early identification and initial treatment of sepsis, including antibiotics and fluid therapy.
First, the recommendation for antibiotic administration within an hour of diagnosis of sepsis is a lofty goal of care, judged to be ideal for the patient but not yet standard care. Despite the best intentions of the healthcare team, antibiotic administration within 1 h from time of diagnosis may be difficult due to the complexity of the hospital environment and essential care being delivered to other patients during the same time period by the same healthcare practitioners and health system. This is one among several “aspirational recommendations” considered by the experts to represent best practice that individual practitioners and healthcare teams should strive to operationalize.
Second, the clinician may push back from use of recommendations for fear that evidence-based guidelines lead to “cookie cutter” medicine and reflexive behaviors that deemphasize the “art” of medicine. The recommendations are intended for a “typical” septic patient. Patients still benefit from the art of medicine, which includes interpretation of data and individualization of treatment. The recommendations provide much-needed general treatment guidance to the bedside decision maker who is busy, pressured to see more patients in less time, and who will use a distillation of the current literature into a coherent set of recommendations suitable for the large majority of septic patients who are “typical”. For most of us in the trenches of everyday care, the lists of specific recommendations (seen in the tables in the manuscript) are a welcome adjunct to personalizing care.
This guidance includes sepsis management in the emergency department, the general hospital floors, and the ICU. For example, the recommendation for an initial 30 mL/kg crystalloid infusion for tissue hypoperfusion is chosen as a one value fit for bedside guidance. Administering 30 mL/kg crystalloid is a useful initial therapy for the majority of patients and this literature supported fluid dose is linked to good outcomes [3, 4]. Figure 2 offers guidance for initial fluid resuscitation and is built forward from the guidelines recommendation for 30 mL/kg initial crystalloid fluid administration within the first six hours for sepsis-induced tissue hypoperfusion. The flow diagram incorporates some of our own opinions for successful fluid resuscitation based on experience and our understanding of the literature.
http://rdcu.be/oGqJ
data flow diagram 在 380 Data flow diagrams ideas in 2021 - Pinterest 的推薦與評價
Nov 4, 2021 - Explore Christine Mondor's board "data flow diagrams" on Pinterest. See more ideas about data flow diagram, diagram architecture, ... ... <看更多>
data flow diagram 在 How to Draw a Data Flow Diagram - YouTube 的推薦與評價
... <看更多>