การประมาณต้นทุนซอฟต์แวร์ในการจัดการโครงการแบบ Agile

บทนำ

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

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

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

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

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

คุณจะประเมินขนาด ระยะเวลา และต้นทุนของโครงการได้อย่างไร มาสำรวจการประมาณโครงการ Agile และต้นทุนการพัฒนาซอฟต์แวร์ และวิธีที่เราดำเนินการที่ Toptal

การกำหนดราคาและการประมาณการตามสัญญา

ตามธรรมเนียมแล้ว โครงการซอฟต์แวร์ใช้แนวทางปฏิบัติที่ไม่คล่องตัวเพื่อแก้ไขฟังก์ชันการทำงานหรือขอบเขต และปล่อยให้เวลาและต้นทุนเป็นตัวแปร สิ่งนี้ทำให้เกิดปัญหา:

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

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

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

มีผลลัพธ์อื่นๆ มากมายของเวลาและต้นทุนผันแปร ซึ่งมักจะเป็นผลลบและไม่พึงปรารถนา

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

สัญญา Agile สำหรับโครงการซอฟต์แวร์

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

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

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

สัญญา Agile มุ่งเน้นไปที่สิ่งต่อไปนี้:

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

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

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

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

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

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

แนวทางของเราในด้านต้นทุนซอฟต์แวร์และราคา

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

มีการดำเนินการตามขั้นตอนต่อไปนี้ในการปรับปรุงโครงการประมาณการและราคาคงที่:

1. ขอบเขตระดับสูงเริ่มต้น

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

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

ก. การกำหนดวิสัยทัศน์และวัตถุประสงค์ เราต้องสร้างอะไร? คุณต้องการบรรลุอะไรและวัตถุประสงค์ทางธุรกิจของคุณคืออะไร? การทำความเข้าใจคำถามเหล่านี้ทำให้เรากำหนดขนาดของโครงการได้ คุณต้องการต้นแบบเพื่อทดสอบแนวคิด แนวคิด หรือเทคโนโลยีเบื้องต้นหรือไม่? คุณได้ระบุข้อเสนอที่ชัดเจนซึ่งได้รับการทดสอบกับตลาดของคุณแล้ว และคุณพร้อมหรือยังที่จะสร้าง Minimal Viable Product (MVP) ตัวแรกของคุณ? หรือคุณกำลังขยายธุรกิจหรือผลิตภัณฑ์ที่มีอยู่เพื่อก้าวไปสู่ระดับต่อไปหรือไม่?

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

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

2. ข้อเสนอ

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

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

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

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

3. การวางแผนการเปิดตัว

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

ก. Backlog ของผลิตภัณฑ์ Backlog ของผลิตภัณฑ์เป็นเพียงรายการสั่งซื้อของ "Epics" หรือ "User Stories" ที่แสดงถึงคุณลักษณะที่จำเป็นสำหรับผลิตภัณฑ์ รายการนี้เริ่มต้นชีวิตตามที่อภิปรายกล่าวไว้ก่อนหน้านี้ แต่ระหว่างทีมโครงการที่ได้รับมอบหมาย ผู้จัดการโครงการ และลูกค้า ตอนนี้เราแบ่งสิ่งเหล่านี้ออกเป็นรายการที่มีความหมายมากขึ้น แต่ละรายการแสดงถึงส่วนหนึ่งของมูลค่าทางธุรกิจให้กับลูกค้า เราไม่ได้ลงรายละเอียดในขั้นตอนนี้ เราไม่จำเป็นต้องรู้เกณฑ์การยอมรับ เราไม่จำเป็นต้องรู้ว่าปุ่มเป็นสีน้ำเงินหรือสีเขียว เราแค่ต้องรู้ว่ามีปุ่มที่ช่วยให้ทำงานบางอย่างได้ ที่จะดำเนินการ

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

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

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

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

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

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

แผนการเผยแพร่ยังให้ข้อมูลเชิงลึกว่าโครงการจะสอดคล้องกับแผนกลยุทธ์ของลูกค้าอย่างไร

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

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

ในการใช้สถานการณ์พื้นฐาน เราใช้จำนวนประเด็นเรื่องราวทั้งหมดที่เราได้รับจากการปรับขนาดงานในมือแล้วหารด้วยความเร็วที่ทีมของเราคาดไว้ (โดยปกติความเร็ว NB จะแสดงเป็นช่วง แต่เพื่อความง่าย เราจะใช้ตัวเลขเดียวที่นี่) เราทำงานในการวนซ้ำสองสัปดาห์ ดังนั้นความเร็วของเราจึงสะท้อนด้วยว่าเราสามารถทำได้มากเพียงใดในรอบสองสัปดาห์โดยมีค่า ความสามารถของทีม หากเรื่องราวของเรามีทั้งหมด 120 คะแนน และเราคาดว่าจะทำ 20 คะแนนต่อการทำซ้ำแต่ละครั้ง ระยะเวลาในการพัฒนาทั้งหมดจะเท่ากับ 12 สัปดาห์หรือ 6 ครั้ง เราเพิ่มการวิ่ง 0 ของ 2 สัปดาห์และการวิ่งเตรียมการเปิดตัวเป็นเวลาสองสัปดาห์ โดยรวมแล้ว โครงการของเรามีความยาว 16 สัปดาห์ มีเทคนิคที่เราสามารถใช้ได้ซึ่งจะช่วยสร้างบัฟเฟอร์ความเสี่ยงที่เหมาะสมในการวางแผนของเรา ซึ่งเราจะหารือกันในภายหลัง แต่ในระยะสั้น เราใช้บัฟเฟอร์เพื่อจัดการความเสี่ยงของความไม่แน่นอนและเพื่อบรรลุข้อตกลงขั้นต่ำของประเด็นเรื่องที่คาดว่าจะได้รับ ผลลัพธ์อาจเป็นช่วง 90 ถึง 150 เรื่องที่มีการส่งมอบ 90 เป็นขั้นต่ำที่เป็นที่ยอมรับในการสร้างผลิตภัณฑ์ที่ทำงานได้

อีกทางหนึ่ง หากโครงการต้องแล้วเสร็จภายในวันที่กำหนด เช่น 10 สัปดาห์ ทีมงานจะเป็นผู้กำหนดจำนวนงานในมือที่จะแล้วเสร็จในช่วงเวลานั้น หากเราคาดหวัง 20 คะแนนเรื่องราวต่อการวิ่งหนึ่งครั้ง บวกกับ Sprint 0 และการปล่อย sprint เราจะตั้งเป้าหมายที่ 60 คะแนนที่เสร็จสมบูรณ์เมื่อสิ้นสุดโปรเจ็กต์ อีกครั้ง เราจะมองหาการจัดการความเสี่ยงโดยเพิ่มบัฟเฟอร์ที่เหมาะสม ซึ่งอาจส่งผลให้เป้าหมายมีเนื้อเรื่อง 45 ถึง 75 เรื่องที่เสร็จสมบูรณ์และพร้อมที่จะเผยแพร่ ประเด็นเรื่อง 45 เรื่องจะสอดคล้องกับค่าต่ำสุดที่ยอมรับได้เพื่อส่งมอบผลิตภัณฑ์ที่มีศักยภาพและมีคุณค่า นี่เป็นสถานการณ์หนึ่งที่คุณอาจคาดหวังว่าจะเพิ่มสมาชิกในทีมเพื่อเพิ่มความเร็ว หากเหมาะสม

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

4. สัญญาราคาคงที่

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

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

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

เทคนิคการประมาณค่า

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

ขนาดโดยประมาณ

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

แม้ว่าทั้งสองโครงการจะเป็นโครงการขนาดใหญ่ แต่ขอบเขต ความซับซ้อน มิติ ขนาดและขนาดจึงแตกต่างกัน

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

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

คะแนนเรื่องราว

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

เรื่องราวแต่ละขนาดสัมพันธ์กับอีกเรื่องหนึ่ง ตัวอย่างเช่น เรื่อง A อาจมีขนาดเป็นหนึ่งจุด เรื่อง B เป็นสองจุด และเรื่อง C เป็นสามจุด ที่นี่ Story C มีขนาดใหญ่อย่างน้อยสามเท่าของ Story A และอย่างน้อยครึ่งหนึ่งของเรื่องราว B อีกครั้ง

หากเรื่องราวต่อไปนี้ใน Backlog ผลิตภัณฑ์ของเรามีขนาดที่เกี่ยวข้องกัน:

ขนาดรวมของโครงการคือ 12 คะแนนเรื่อง

วันในอุดมคติ

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

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

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

เทคนิคการประมาณค่า

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

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

เราจะทำแบบฝึกหัดนี้ต่อกับเรื่องราวทั้งหมด เมื่อเสร็จแล้ว เราสามารถวางเรื่องเล็ก กลาง ใหญ่ และใหญ่พิเศษทั้งหมดเคียงข้างกัน และตรวจสอบขนาดของเราเพื่อให้แน่ใจว่ามีระดับความสม่ำเสมอในการประมาณค่าของเรา

Planning Poker ได้รับการเขียนขึ้นมากมายเกี่ยวกับ Planning Poker; ฉันยังพูดถึงมันในบล็อกที่แล้วของฉัน หนึ่งในแหล่งข้อมูลที่ดีที่สุดสำหรับการทำความเข้าใจอยู่ที่นี่

โดยพื้นฐานแล้วจะรวมความคิดเห็นของผู้เชี่ยวชาญ การเปรียบเทียบ และการทำงานร่วมกันเป็นทีมเข้าเป็นกระบวนการเดียวที่ง่าย รวดเร็วและเชื่อถือได้

เป็นการรวบรวมผู้เชี่ยวชาญหลายคนที่เหมาะสมที่สุดในการสร้างการประมาณโดยอิงจากประสบการณ์ทางเทคนิคและประสบการณ์ในโดเมน บทสนทนาที่มีชีวิตชีวา และการให้เหตุผลที่ถูกต้อง

ความเร็ว

ความเร็วเป็นตัววัดความสามารถของทีมในการทำงานให้เสร็จตามรอบที่กำหนด (หรือวิ่งเร็ว)

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

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

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

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

• สมาชิกในทีม 4 คน * สองสัปดาห์ * 40 ชม. ต่อสัปดาห์ = 320 ชั่วโมง
• คูณด้วยความจุ 70 เปอร์เซ็นต์ของเรา = 224 ชั่วโมง
• เพิ่มงานคุณสมบัติทั้งหมดและหยุดการนับที่224
• นำคุณสมบัติที่เสร็จสมบูรณ์ทั้งหมด บวกคะแนนเรื่องราว แล้วคุณจะได้ความเร็ว พูด 36
• ใช้ 20 เปอร์เซ็นต์ด้านใดด้านหนึ่งเพื่อให้ได้ช่วงที่ต่ำที่สุดและสูงสุด เพื่อให้ได้ความเร็วโดยประมาณที่ 29 ถึง 43 เรื่อง

ความเร็วมักจะแปรผันในการวนซ้ำสองถึงสี่รอบแรก จากนั้นจะคงที่ภายในช่วงจุดเล็กๆ ดังนั้น เมื่อช่วงเริ่มต้นของเราก่อนการวิ่งแบบหนึ่งคือ 29 ถึง 43 โดยการวิ่งสี่ช่วง มันอาจจะหยุดนิ่งจาก 34 เป็น 38 ซึ่งจะทำให้เรามีความมั่นใจมากขึ้นในการคาดการณ์วันที่เสร็จสิ้นขั้นสุดท้ายของเรา

แผนบัฟเฟอร์สำหรับความเสี่ยงและความไม่แน่นอน

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

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

โดยทั่วไป มีบัฟเฟอร์สองประเภท: คุณลักษณะและกำหนดการ เนื่องจากเรามักกำหนดราคาคงที่สำหรับวันที่จัดส่งที่แน่นอน จึงควรใช้บัฟเฟอร์คุณลักษณะ

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

คุณสมบัติบัฟเฟอร์

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

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

ความคิดปิดบางส่วน

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

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

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

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

สรุป

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

ปฏิบัติตามแนวทางเหล่านี้ แล้วคุณจะพบกับเส้นทางที่น่าพอใจในการทำให้ผลิตภัณฑ์ซอฟต์แวร์ของคุณมีชีวิต