คุณจะเพิ่มอะไรในรายการตรวจสอบโครงการพัฒนาซอฟต์แวร์นี้ [ปิด]


14

ฉันเป็นแฟนตัวยงของรายการตรวจสอบ มีรายการตรวจสอบการเดินทาง , การย้ายรายการตรวจสอบและแม้กระทั่งรายการตรวจสอบการแย่งชิงกัน

บริบท : คุณได้รับการว่าจ้างจาก บริษัท ขนาดใหญ่และกำหนดภารกิจในการติดตั้งสภาพแวดล้อมการพัฒนาซอฟต์แวร์กระบวนการทีม ฯลฯ คุณมี "carte blanche" คุณจะต้องรับผิดชอบในการสร้างการเพิ่มขึ้นของการทำงานของซอฟต์แวร์ ขนาดโครงการ: 2,000 คน / วัน

รายการใดบ้างที่คุณจะเพิ่มในรายการตรวจสอบ (เล็กและไม่สมบูรณ์) ต่อไปนี้:

  • ติดตั้งเซิร์ฟเวอร์การรวมอย่างต่อเนื่อง
  • เขียนกระทรวง
  • เขียนแนวทางการเข้ารหัสหนึ่งหน้า
  • สร้างสินค้าค้าง
  • ติดตั้งระบบติดตามบั๊ก
  • กำหนดเวลาหน้าปกติ

คำตอบ:


10

* 1. ) คุยกับผู้พัฒนาเพื่อดูว่าพวกเขาต้องการอะไรจริงๆ! * * * *

2. ) ตรวจสอบวิธีการแก้ปัญหาเพื่อให้เกิดสภาพแวดล้อมที่หลากหลายอย่างรวดเร็ว (คิดว่าอินสแตนซ์สาธารณะหรือส่วนตัวบนคลาวด์หรือเครื่องเสมือนที่ล้าสมัยหากคุณไม่สอดคล้องกับ buzzword)

3. ) การควบคุมแหล่งที่มา / รุ่น

4. ) ระบบตรวจสอบโค้ด (Crucbile / Fisheye เป็นตัวอย่าง)

5. ) กำแพง Kanban (หรืออะไรทำนองนั้น)

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

7. ) กระดานไวท์บอร์ดอิเล็กทรอนิกส์

8. ) สภาพแวดล้อมที่สะดวกสบายสำหรับนักพัฒนา (เตียงนอน, โต๊ะ, พื้นที่ chillout, WiFi ที่ดี ฯลฯ )

9. ) กาแฟที่ยอดเยี่ยม !!!


cofee สร้างความแตกต่าง:) + 1
RBA

ไวท์บอร์ดอิเล็กทรอนิกส์ที่คุณใช้คืออะไร

@Pierre 303 - การพิมพ์ผลลัพธ์ของเซสชั่นกระดานไวท์บอร์ด a (ภาพคุณภาพสูงจะทำแบบเดียวกันกับที่ฉันเดา)
Martijn Verburg

8
  • การตั้งค่า Toolchain - IDEs, เซิร์ฟเวอร์ CI, เซิร์ฟเวอร์คุณภาพของรหัส, การควบคุมแหล่ง, เว็บเซิร์ฟเวอร์, ฐานข้อมูล, ติดตามปัญหา ฯลฯ
  • สำรองข้อมูล - บทบาทใดที่แต่ละคนในทีมมี? กระบวนการ / โมดูลใดที่เขาเป็นเจ้าของและใครเป็นผู้สำรองข้อมูล
  • (การยอมรับของผู้ใช้) การตั้งค่าสภาพแวดล้อมการทดสอบ - ไม่เพียง แต่ผสานรวมอย่างต่อเนื่อง การทดสอบหน่วย แต่การทดสอบการรวมเพื่อครอบคลุมสิ่งเลวร้ายจริง ๆ หลายแพลตฟอร์มเซิร์ฟเวอร์แอปพลิเคชัน VMs ฯลฯ
  • การตั้งค่าการทดสอบประสิทธิภาพ - เร็วกว่าเนื่องจากคุณจะต้องใช้ข้อมูลในอดีตที่จะตอบว่า "คุณสมบัติใด / เหตุการณ์สำคัญที่ทำให้ประสิทธิภาพลดลงอย่างมาก"
  • ร่างเอกสารผู้ใช้ (ผู้ใช้ปลายทาง) - อะไรจะอยู่ในเอกสารประกอบ? จำเป็นต้องใช้เอกสารประเภทใด
  • ช่องทางการตลาด - ความคืบหน้าภายในและการเผยแพร่ภายนอกมีการประกาศอย่างไร คุณมีชื่อที่น่าสนใจสำหรับซอฟต์แวร์โลโก้สีถ้อยคำ ฯลฯ หรือไม่?
  • การสื่อสารภายใน - เพื่อน ๆ จากทีมอื่น ๆ จะได้รับแจ้งเกี่ยวกับการเปลี่ยนแปลงอย่างไร การทำงานร่วมกันเป็นอย่างไร วิกิพีเดีย? เข้าถึงสิทธิ์หรือไม่
  • ผู้คน & กระบวนการประกันคุณภาพ - ใครจะไปทดสอบอะไรบ่อยแค่ไหนและมีเกณฑ์อะไรบ้าง
  • ขั้นตอนการเผยแพร่ - เมื่อไหร่ความถี่อย่างไรใครกำลังทำใครกำลังรับการเปิดตัว ฯลฯ
  • การจัดการความเสี่ยง - สถานการณ์เลวร้ายที่สุด (จากโครงการ mgmt pov และจาก runtime pov เช่น 'ลูกค้ากำลังสูญเสียเงินเนื่องจากซอฟต์แวร์ล้มเหลวที่โมดูล X แผนสำรองคืออะไร)
  • การรักษาความปลอดภัยของสภาพแวดล้อมการพัฒนาหลักเช่นการจำลองเสมือนสำหรับ Escrow
  • สถานที่สำหรับการประชุมที่เป็นทางการและไม่เป็นทางการ
  • การฝึกอบรมหรืออินโทรสำหรับทุกคนเพื่อให้พวกเขารู้ว่าการตั้งค่าทั้งหมดคืออะไรแต่ละส่วนมีไว้เพื่ออะไรและใช้อย่างไร
  • ระบุผู้ดูแลและมอบทุกสิ่ง (เช่นสิทธิ์) ที่เขาต้องดูแลจริง ๆ เมื่อสิ่งต่าง ๆ แย่ลง

+1 สำหรับการสำรองและฝึกอบรม
Liviu T.

สำรองแม้ว่าฉันคิดว่าบางส่วนนี้เป็น extranious
BlackICE

5

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


4

เริ่มจากจ้างทีมงานมืออาชีพที่เหมาะสมสำหรับโครงการของคุณ ในแอปทางธุรกิจทั่วไปคุณจะต้องจ้างนักพัฒนาฐานข้อมูลและ dba บุคคล QA ผู้ดูแลระบบนักวิเคราะห์ธุรกิจนักพัฒนาแอพพลิเคชั่นผู้เชี่ยวชาญ UI และทีมที่เป็นผู้นำอย่างน้อยที่สุด DBA ผู้ดูแลระบบนักวิเคราะห์ธุรกิจและ QA ควรอยู่ในสายการรายงานแยกต่างหากจากทีมพัฒนา ผู้เชี่ยวชาญฐานข้อมูลการพัฒนาควรรายงานไปยังลูกค้าเป้าหมายทางเทคนิคเช่นเดียวกับผู้พัฒนาแอปพลิเคชันและผู้เชี่ยวชาญ UI

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

ตั้งค่าเซิร์ฟเวอร์ dev / qa / staging และ prod สำหรับทั้งแอปพลิเคชันและฐานข้อมูล ฐานข้อมูลไม่ควรอยู่บนเซิร์ฟเวอร์เดียวกับแอปพลิเคชัน ขึ้นอยู่กับขนาดและขอบเขตของโครงการคุณอาจต้องใช้เซิร์ฟเวอร์หรือ SAN หลายเครื่อง ฯลฯ สำหรับแต่ละสภาพแวดล้อม

ทันทีที่ติดตั้งเซิร์ฟเวอร์ให้กำหนดเวลาการสำรองข้อมูลของไฟล์ระบบฐานข้อมูลและบันทึกธุรกรรมฐานข้อมูล ทำสิ่งนี้ในวันแรกที่มีการตั้งค่า จ้าง บริษัท เช่น Iron Mountain เพื่อสำรองข้อมูลนอกสถานที่ทุกสัปดาห์

ตั้งค่าระบบควบคุมแหล่งที่มาและสร้างเอกสารที่อธิบายถึงวิธีการใช้งาน อย่าลืมยืนยันว่าการเปลี่ยนแปลงโครงสร้างฐานข้อมูลทั้งหมดและแทรกข้อมูลสำหรับตารางประเภทการค้นหาอยู่ในสคริปต์ในการควบคุมแหล่งที่มา สิ่งนี้จะทำให้การปรับใช้ง่ายขึ้น

ซื้อซอฟต์แวร์เชิงพาณิชย์หรือดาวน์โหลดซอฟต์แวร์โอเพ่นซอร์สสำหรับชุดเครื่องมือที่คุณตัดสินใจใช้กับใบอนุญาตสำหรับผู้ใช้ที่เกี่ยวข้องทั้งหมด

ซื้อเครื่องจักรสำหรับนักพัฒนาที่กำลังกรีดร้องอย่างรวดเร็วและมีจอภาพสองจอ ซื้อเครื่องผู้ใช้ทดสอบอย่างน้อยหนึ่งเครื่องที่ส่งเสียงครวญครางช้าและเป็นเรื่องปกติของสิ่งที่ผู้ใช้จะมีบนเดสก์ท็อป

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

กำหนดสิ่งที่ต้องทำในสิ่งที่เป็นระเบียบ (เส้นทางที่สำคัญ) อย่ามอบหมายงานในตอนท้ายของเส้นทางที่สำคัญจนกว่างานที่พวกเขาพึ่งพานั้นจะเสร็จสมบูรณ์

สร้างแผนการทดสอบและข้อกำหนด

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

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

ในการวางแผนโครงการสมมติว่า QA จะพบข้อบกพร่องและพวกเขาจะใช้เวลาในการแก้ไข อย่ากำหนดเวลาให้ QA เพียงวันเดียวในตอนท้าย

สร้างข้อมูลการทดสอบที่มีขนาดประมาณคุณคิดว่าฐานข้อมูลจะเป็น ทำให้นักพัฒนาทั้งหมดทดสอบรหัสกับฐานข้อมูลขนาดนี้ ไม่อนุญาตให้ผู้พัฒนาทำการพัฒนาเทียบกับฐานข้อมูลขนาดเล็กบนเครื่องส่วนตัวของพวกเขา นี่เป็นสาเหตุของรหัสบ่อยครั้งที่ทำงานได้ดีจนกว่าจะมีการผลิต

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

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


ฉันคิดว่าเครื่องทดสอบของผู้ใช้ควรจะ "ครางช้า" ไม่ใช่ "กรีดร้องช้า";) รายการที่ดีมาก
BlackICE

@ David ฉันชอบคำแนะนำของคุณและมีการเปลี่ยนแปลงในข้อความ
HLGEM

คำตอบที่ดี - ชื่อหัวข้อย่อยหรือชื่อส่วนอาจช่วยได้เล็กน้อย
JBRWilkinson

3

บางสิ่งที่ฉันไม่เห็นในคำถามและคำตอบที่ตามมา:

  • แผนกู้คืนภัยพิบัติ คุณสำรองข้อมูลกล่อง dev, staging, การทดสอบและอื่น ๆ อย่างไร? Dev ทุกคนมีสิ่งที่พวกเขาต้องการทำงานจากที่บ้านในวันหิมะตกเป็นครั้งคราวหรือไม่? เป็นต้น

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

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

  • รวม ALM มากเท่าที่คุณจะยืนหรือซื้อได้ โดยทั่วไปแล้วเหตุผลของ "อิมพิแดนซ์ไม่ตรงกัน" การเข้าคู่การซ้อนกันของเครื่องมือและการรวมแอพพลิเคชั่นเก้าอี้หมุนได้นั้นเป็นเพราะระบบขยายตัวเป็นบิตและชิ้นส่วน ตั้งแต่เริ่มต้นคุณต้องการแสดงให้เห็นว่าคนของคุณสามารถอยู่ในเครื่องมือเดียวตลอดวงจร ไม่พิมพ์รหัสใน X, คอมไพล์ด้วย Y, ทดสอบด้วย Z, เปลี่ยนสถานะของไอเท็มงาน / งานด้วย A, รายงานเวลาที่ใช้กับ B บอกผู้ที่กำลังรอว่าพวกเขาสามารถดำเนินการกับ C ได้ในขณะนี้ ว่าจะทำอย่างไรต่อไปกับ D, วัดความก้าวหน้าโดยรวมกับ E, ฯลฯ


2

เจรจาต่อรองวันคนมากขึ้น

มันเป็นเหตุการณ์ที่เกิดขึ้นไม่บ่อยนักเมื่อมีคนจัดสรรให้อย่างเพียงพอ

[ต่อมา ... เจรจาอีกครั้งยิ่ง ... ]


การที่มีมุมมองว่าต้องมีการเจรจาต่อรองกับคนมากขึ้นทุกวันไม่ใช่สิ่งที่ฉันอยากจะแนะนำฉันต้องการให้การประเมินที่ถูกต้องและเชื่อถือได้สำหรับงานหรือระยะเวลาโครงการ
NimChimpsky

@NimChimpsky มีการพูดคุยกันที่นี่เมื่อเร็ว ๆ นี้เกี่ยวกับความสามารถในการประมาณการที่เชื่อถือได้ว่าเป็นตำนานในโครงการคอมพิวเตอร์หรือไม่ นอกจากว่างานจะเป็นที่รู้จักกันดีและไม่มีการวิจัยดังนั้นจึงยากที่จะคาดการณ์เวลาได้ แม้ว่าคุณจะสามารถคาดการณ์กำหนดการทีมของคุณเองได้ - การทำนายปัจจัยภายนอกและความล่าช้านั้นเป็นไปไม่ได้ ดังนั้นการประมาณการ "ถูกต้องและเชื่อถือได้" ไม่ใช่สิ่งที่ฉันเชื่อว่ามีอยู่ทั่วไป
Orbling

@Orbling พวกเขาอยู่ที่ฉันทำงาน ผู้ค้าปลีกระดับชาติ ftse 250 ที่จดทะเบียนในสหราชอาณาจักร บางโครงการจะล่าช้า แต่ก็ไม่ช้าและก็เป็นข้อยกเว้น
NimChimpsky

@NimChimpsky เป็นไปได้ที่จะได้รับประมาณการที่ค่อนข้างแม่นยำหากคุณมีการควบคุมเต็มรูปแบบของการส่งมอบทั้งหมดภายในโครงการจะไม่ถูกบล็อกโดย externals และงานในมือไม่เกี่ยวข้องกับการวิจัย การให้งบประมาณของคุณขยายไปถึงการวิเคราะห์อย่างละเอียดก่อนการประเมินเวลา ใน บริษัท ส่วนใหญ่งบประมาณเพียงแค่ไม่ได้มีการตรวจสอบอย่างเต็มที่ก่อนที่จะเริ่ม
Orbling

@orbling ความเป็นไปได้ที่มักจะขอเวลามากขึ้นนั้นเป็นไปโดยพลการและไม่ได้อยู่บนพื้นฐานของหลักฐานการส่งมอบการวิเคราะห์หรืองบประมาณ
NimChimpsky

2

เห็นว่าฉันมีปัญหามากที่สุดกับห้องสมุดบุคคลที่สามและการใช้งาน:

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

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


1

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

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

มิฉะนั้นคุณจะต้องลงเอยด้วยการรักษาความปลอดภัยหลังจากนำไปใช้งาน - ซึ่งอาจมีราคา 8 - 10 เท่า (ตัวเลขจาก Gartner, IBM และอื่น ๆ ) จะทำให้ผู้คนเสียความรู้สึกเนื่องจากการทำงานมีแนวโน้มที่จะได้รับผลกระทบ และความเสียหาย


ฉันอยากรู้อยากเห็นนี่ควรเป็นส่วนหนึ่งของรายการตรวจสอบการตั้งค่าโครงการหรือไม่ ฉันใส่ไว้ในส่วนหนึ่งของการพัฒนาซอฟต์แวร์ แต่ฉันไม่รู้เกี่ยวกับการตั้งค่าโครงการ ฉันจะใส่มันด้วยเหตุการณ์สำคัญ dev แต่ฉันไม่คิดว่านั่นคือสิ่งที่ OP กำลังถามเกี่ยวกับฉันอาจจะผิด
BlackICE

เดวิด - บางทีคุณคิดถูกที่รายละเอียดระดับนี้ไม่ควรอยู่ที่นั่น แต่ฉันคิดว่าอย่างน้อยก็ควรมีรายการโฆษณาเพื่อความปลอดภัย ดีขึ้นหรือไม่
Rory Alsop

1

1. นำไปให้ทีม

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

2. ตรวจสอบและปรับตัว

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.