คำถามติดแท็ก agile

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

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

5
มันเป็นความคิดที่ดีที่จะแต่งตั้งหนึ่งในสมาชิกในทีมการต่อสู้หรือต้นแบบการต่อสู้ในฐานะเจ้าของผลิตภัณฑ์?
เมื่อเร็ว ๆ นี้เรามีโครงการที่ลูกค้าไม่ว่างในการทัวร์ ทีมการต่อสู้ตามปกติก่อตั้งขึ้นฝ่ายบริหารจึงตัดสินใจแต่งตั้งนักวิเคราะห์ของเราในฐานะเจ้าของผลิตภัณฑ์เนื่องจากลูกค้าจะไม่สามารถเข้าร่วมได้ นักวิเคราะห์เป็นคนหนึ่งที่ทำงานอย่างใกล้ชิดกับลูกค้าในการวิเคราะห์ความต้องการและร่างข้อกำหนด ลูกค้าไม่มีเวลาที่จะตรวจสอบสองรุ่นแรก ทุกอย่างเป็นไปอย่างราบรื่นจนกระทั่งลูกค้าเห็นรุ่นที่สาม; เขาไม่พอใจกับฟังก์ชันการทำงานบางอย่างและสิ่งเหล่านั้นได้รับการแนะนำโดย make shift Product Owner (นักวิเคราะห์ของเรา) เราได้รับคำสั่งให้รอจนกระทั่งทีมออกแบบเสร็จการเยาะเย้ยหน้าทุกหน้าและลูกค้าตรวจสอบแต่ละรายการและอนุมัติให้ทำงานต่อไป ทีมต่อสู้แย่งกันอยู่ที่นั่น แต่ไม่มีการวิ่ง - เราทำงานเกือบเสร็จเหมือนวิธีน้ำตกแบบดั้งเดิม เป็นความคิดที่ดีไหมที่จะแต่งตั้งสมาชิกทีมหรืออาจารย์ในการเป็นเจ้าของผลิตภัณฑ์? เราจำเป็นต้องติดตามการทะเลาะวิวาทในกรณีที่ไม่มีลูกค้า / เจ้าของผลิตภัณฑ์มีส่วนร่วมหรือไม่?
13 agile  scrum  waterfall 

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

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

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

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

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

8
การสร้างต้นแบบอย่างรวดเร็วนั้นเข้ากับวิธีการแบบเปรียวได้อย่างไร?
ฉันทำงานให้กับ บริษัท ขนาดใหญ่ซึ่งสั่งให้ใช้กระบวนการที่คล่องตัว ตัวอย่างเช่นสำหรับโครงการของเราเราใช้บริการบนคลาวด์ที่มีเป้าหมายเฉพาะในการจัดการการพัฒนาที่คล่องตัว กลุ่มวิศวกรรมเฉพาะที่ฉันทำงานไม่ได้พัฒนาซอฟต์แวร์แบบดั้งเดิม (แต่เราช่วยผลักดันโครงการจากมุมมองที่สูงขึ้น) แต่มันกำลังเปลี่ยนแปลง เรามีโครงการซอฟต์แวร์ที่กำลังมาถึง / วางแผนหลากหลายซึ่งส่วนใหญ่เป็นศูนย์ข้อมูลเช่นเราจะทำการตรวจสอบข้อมูลการรวบรวมรวมและการรายงานบางอย่าง งานอื่น ๆ ที่เกี่ยวข้องกับระบบอัตโนมัติด้วยฮาร์ดแวร์เฉพาะและสถาปัตยกรรมไคลเอนต์ / เซิร์ฟเวอร์ (หลายเทียร์) ฉันจะช่วยในกระบวนการจ้างคนหลายคนและกำหนดแผนการหลายอย่างในการก้าวไปข้างหน้า คำถามของฉันคือการทำต้นแบบอย่างรวดเร็วหรือไม่ (รหัส throwaway) เหมาะกับปรัชญาเปรียว ตัวอย่างเช่นฉันชอบ Python และแพ็คเกจที่หลากหลาย ฉันเห็นความเป็นไปได้ที่จะนำความคิดของเราไปใช้อย่างรวดเร็วด้วยขั้นตอนการทำงานของ Python อย่างไรก็ตามฉันคิดว่าจะมีการรับรู้มากมายที่ Python ไม่ใช่ "คุณภาพระดับองค์กร" และงานนี้ส่วนใหญ่จะต้องเขียนใหม่ใน Java หรือ C ++ อย่างไรก็ตามการสร้างต้นแบบของ Python จะทำให้เรามีข้อบกพร่องมากมายในการทำให้เราสามารถให้ผลลัพธ์ที่แท้จริงได้อย่างรวดเร็ว คุณสามารถรวมต้นแบบอย่างรวดเร็ว - หวังว่าใน Python เข้ากับเวิร์กโฟลว์ที่คล่องตัวในสภาพแวดล้อมขององค์กรหรือไม่

6
วิธีการเข้าประชิดงานล้มเหลวเมื่องานมีส่วนร่วมของหลายคน?
ใน บริษัท ของฉันงานเดียวไม่สามารถทำได้โดยคน ๆ เดียว จะมีบุคคลที่แยกต่างหากเพื่อ QA และตรวจสอบรหัสแต่ละงาน สิ่งนี้หมายความว่าแต่ละคนจะให้การประเมินของพวกเขาต่องานว่าจะใช้เวลาเท่าไหร่ในการทำให้เสร็จสมบูรณ์ ปัญหาคือฉันจะเข้าใกล้เผาไหม้ได้อย่างไร? หากฉันรวมชั่วโมงเข้าด้วยกันให้ถือว่าการประมาณการต่อไปนี้: 10 ชั่วโมง - เวลาการปรับปรุง 4 ชม. - QA 4 ชม. - ตรวจสอบรหัส ประมาณการงาน = 18 ชม ในตอนท้ายของแต่ละวันฉันขอให้งานได้รับการอัปเดตด้วย "เหลือเวลาเท่าไหร่จนกว่าจะเสร็จ" อย่างไรก็ตามแต่ละคนโดยทั่วไปเพียงแค่คิดเกี่ยวกับส่วนของพวกเขา พวกเขาควรจะทำเครื่องหมายความพยายามที่เหลืออยู่และจากนั้นเพิ่มความพยายามประมาณว่า พวกคุณเป็นยังไงบ้าง UPDATE เพื่อช่วยอธิบายสิ่งเล็ก ๆ น้อย ๆ ที่องค์กรของฉันแต่ละงานในเรื่องราวต้องใช้ 3 คน ใครบางคนในการพัฒนางาน (ทำการทดสอบหน่วย ฯลฯ ... ) ผู้เชี่ยวชาญด้านคุณภาพเพื่อตรวจสอบงาน (โดยหลักแล้วพวกเขาจะทำการทดสอบการรวมและการถดถอย) ฝ่ายเทคนิคนำไปสู่การตรวจสอบโค้ด ฉันไม่คิดว่าจะมีวิธีที่ผิดหรือถูกวิธี แต่นี่เป็นวิธีของเรา …
12 agile  scrum 

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

7
เอกสารย่อยสลาย - วิธีจัดการกับมัน?
ที่สำคัญเรายังมีปัญหาไม่ว่ากรณีใด ๆ กับเอกสารรหัสแหล่งที่มา นี่เป็นของการตรวจสอบรหัสปกติและได้รับการปรับปรุงให้ทันสมัยอยู่เสมอ ปัญหาของเราคือเอกสารประกอบสำหรับนักพัฒนา (หรือ "ภายนอก" หากคุณต้องการ) เคล็ดลับเล็ก ๆ น้อย ๆ เช่นบล็อกจากโปรแกรมเมอร์ถึงโปรแกรมเมอร์ซึ่งมักจะเขียนครั้งเดียวมักจะถูกทิ้งไว้ข้างหลัง เราใช้ระบบคล้ายวิกิเพื่อจัดทำเอกสารโปรแกรมเมอร์ - บทความที่เขียนโดยโปรแกรมเมอร์สำหรับโปรแกรมเมอร์อธิบายในรายละเอียดเพิ่มเติมเล็กน้อยว่าชิ้นส่วนของรหัสทำงานอย่างไร หน้าวิกิเหล่านั้นมักจะรวมถึง: แรงจูงใจที่อยู่เบื้องหลังการตัดสินใจออกแบบสำหรับส่วนต่างๆของ API (ตัวอย่างเช่นเราทำสิ่งนี้น่าเกลียดเพราะห้องสมุดบุคคลที่สามนี้ต้องการให้ทำสิ่งนี้ด้วยวิธีนี้เพราะห้องสมุดอื่นนี้ ... เพราะ ... คำอธิบายเกี่ยวกับวิธีที่เราจัดการกับงานทั่วไปโดยเฉพาะ (ตัวอย่างเช่นการแสดงป๊อปอัปเล็กน้อยซึ่งจำเป็นต้องอ้างอิงรูปแบบแอปพลิเคชันที่เหมาะสมลงทะเบียนในองค์ประกอบของรีจิสทรีและใช้อินเทอร์เฟซบางอย่างเพื่อสแกนโดยอัตโนมัติ การปฏิบัติที่ดี (ส่วนตัวเหมือนเดิมเราเขียนสิ่งนี้ลงไป) การกำหนดค่าสภาพแวดล้อมเครื่องมือที่จำเป็นและการตั้งค่า โดยทั่วไปแล้วสิ่งที่เกี่ยวข้องกับการเขียนโค้ดที่ไม่เหมาะกับรหัสเอกสารทั่วไปเนื่องจากขนาดและลักษณะของบล็อก / บทความที่คล้ายกัน ปัญหา เท่าที่การแนะนำระบบนี้ดูเหมือนจะเป็นความคิดที่ดีไม่กี่เดือนที่ผ่านมาทุกวันนี้ฉันรู้สึกว่ามันทำให้เกิดปัญหามากกว่าที่จะแก้ ตัวอย่างเช่น: คนทำบทความเขียน ... แต่เมื่อเปลี่ยนรหัสปรับปรุงวิกิพีเดียไม่ค่อยดังต่อไปนี้ มีบทความเกี่ยวกับรอยขีดข่วนจำนวนมากเขียนโดยใครบางคนที่รีบร้อนและทิ้งไว้เช่นนั้น แม้ว่าโดยปกติแล้วการร้องขอบทความจะมาจากผู้นำโครงการ แต่ก็ไม่ค่อยมีการตรวจสอบความถูกต้อง / องค์ประกอบซึ่งบางครั้งอาจส่งผลให้มีคุณภาพไม่ดี ความเสื่อมโทรมตามปกติ รหัสมีการเปลี่ยนแปลงวิกิยังคงเหมือนเดิม ครั้งต่อไปที่มีคนค้นหาข้อมูลสิ่งที่เขามักจะพบคือสิ่งของที่ล้าสมัยและมีคุณภาพต่ำ - และกำลังสงสัยว่าเกิดอะไรขึ้นไม่ว่าจะเป็นสิ่งที่เขาพบว่ามีความถูกต้องหรือ (แย่ยิ่งกว่า) ส่วนใดของมัน และสิ่งที่ควรจะช่วยจบลงด้วยการทำตรงกันข้าม …

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

7
จะให้โครงการย่อยใหม่แยกต่างหากจากนักพัฒนาที่มีประสบการณ์ช่วยให้มือใหม่เพิ่มขึ้นเร็วขึ้นหรือไม่
เรามีนักพัฒนา 7 คนในทีมและต้องเพิ่มความเร็วในการพัฒนาเป็นสองเท่าในช่วงเวลาสั้น ๆ (ประมาณหนึ่งเดือน) ฉันรู้ว่ามีกฎสามัญสำนึกที่ว่า "หากคุณจ้างนักพัฒนามากขึ้นคุณจะสูญเสียประสิทธิภาพในช่วงสองสามเดือนแรก" โครงการดังกล่าวเป็นบริการเว็บอีคอมเมิร์ซและมีโค้ดประมาณ 270K บรรทัด ความคิดของฉันในตอนนี้คือการแบ่งโครงการในโครงการย่อยอิสระสองโครงการมากขึ้นหรือน้อยลงและปล่อยให้ทีมใหม่ทำงานในโครงการย่อยขนาดเล็กสองโครงการในขณะที่ทีมปัจจุบันทำงานในโครงการหลัก กล่าวคือทีมใหม่จะทำงานในการชำระเงินซึ่งในที่สุดจะกลายเป็นบริการเว็บอิสระเพื่อลดข้อต่อ ด้วยวิธีนี้ทีมใหม่ทำงานในโครงการที่มีโค้ดเพียง 100K บรรทัด คำถามของฉันคือ: วิธีการนี้จะช่วยให้นักพัฒนามือใหม่สามารถปรับตัวเข้ากับโครงการใหม่ได้ง่ายหรือไม่? มีวิธีอื่นในการขยายทีมพัฒนาอย่างรวดเร็วโดยไม่ต้องรอสองเดือนจนกว่ามือใหม่จะเริ่มผลิตซอฟต์แวร์มากขึ้น ======= UPDATE องค์กรนี้ล้มเหลวอย่างสมบูรณ์ แต่ไม่ใช่เหตุผลที่คุณพูดถึง ก่อนอื่นฉันเข้าใจผิดเกี่ยวกับขนาดและความสามารถของทีมใหม่ ฉันควรประเมินตนเอง ประการที่สองการจ้างงานกลายเป็นงานหนักที่ไซต์นั้น ที่ตั้งของสำนักงานใหญ่การจ้างงานนั้นง่ายกว่ามาก แต่ในเมืองของทีมที่สองดูเหมือนจะมีนักพัฒนาไม่เพียงพอที่มีคุณสมบัติที่ต้องการ ดังนั้นแทนที่จะคาดการณ์ 1.5 เดือนงานขยายไปถึงประมาณ 4.5 เดือนและถูกยกเลิกในช่วงกลางของมันโดยผู้บริหารระดับสูง ข้อผิดพลาดอีกอย่างที่ฉันทำ (และถูกเตือนเกี่ยวกับเรื่องนี้โดย Alex D) คือฉันพยายามขายการปรับโครงสร้างให้ผู้บริหารระดับสูง คุณไม่เคยขาย refactoring เฉพาะฟีเจอร์เท่านั้น การเริ่มต้นจะประสบความสำเร็จอยู่ดี การปรับโครงสร้างที่ไม่เคยเกิดขึ้นกลายเป็นหนี้ทางเทคนิค: ระบบกลายเป็นเสาหินมากขึ้นและบำรุงรักษาได้น้อยลงผลผลิตของผู้พัฒนาลดลงเรื่อย ๆ ฉันไม่ได้อยู่ในทีมตอนนี้ แต่ฉันหวังว่าพวกเขาจะสำเร็จในอนาคตอันใกล้ มิฉะนั้นฉันจะไม่ให้เงินกับการอยู่รอดของโครงการ

6
มันคุ้มค่าหรือไม่สำหรับนักพัฒนาที่จะเป็นอาจารย์การต่อสู้? มันเป็นการแต่งตั้งอย่างเป็นทางการหรือ
มันจะเป็นประโยชน์สำหรับนักพัฒนาที่จะกลายเป็น 'การต่อสู้ต้นแบบ' หรือไม่? นี่คือการรับรองอย่างเป็นทางการหรือเพียงแค่คนที่เชี่ยวชาญหรือไม่ ขั้นตอนต่อการเป็นหนึ่งคืออะไร?

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

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