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

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

61 project-management  agile  time-tracking 

ฉันได้อ่านหลักการสำหรับสถาปนิกว่องไวที่พวกเขานิยามหลักการต่อไป: หลักการ # 1 ทีมที่ใช้รหัสออกแบบระบบ หลักการ # 2 สร้างสถาปัตยกรรมที่ง่ายที่สุดที่อาจเป็นไปได้ หลักการ # 3 เมื่อมีข้อสงสัยรหัสมันออกมา หลักการ # 4 พวกเขาสร้างมันพวกเขาทดสอบ หลักการ # 5 ยิ่งระบบยิ่งใหญ่ หลักการ # 6 สถาปัตยกรรมของระบบคือการทำงานร่วมกันของบทบาท หลักการ # 7 ไม่มีการผูกขาดกับนวัตกรรม บทความกล่าวว่าการออกแบบสถาปัตยกรรมส่วนใหญ่เสร็จสิ้นในระหว่างขั้นตอนการเข้ารหัสและการออกแบบระบบก่อนหน้านั้นเท่านั้น นั่นเป็นเรื่องปกติ ดังนั้นการออกแบบระบบทำได้อย่างไร? ใช้ UML หรือเปล่า หรือเอกสารที่กำหนดอินเทอร์เฟซและบล็อกหลัก อาจจะเป็นอย่างอื่น?

59 architecture  agile  large-scale-project 

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

56 agile  development-process  scrum 

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

55 project-management  agile  issue-tracking 

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

55 agile  scrum  methodology  culture 

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

53 agile  code-reviews 

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

52 agile  scrum 

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

52 agile  project-management  scrum  development-process 

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

51 agile  scrum  sprint  meetings  process-improvement 

เราใช้ Scrum และบางครั้งพบว่าเราไม่สามารถทำเรื่องราวของผู้ใช้ให้จบได้ในการวิ่งที่วางแผนไว้ ในรูปแบบการต่อสู้ที่แท้จริงเราจัดส่งซอฟต์แวร์ต่อไปและพิจารณารวมเรื่องของผู้ใช้ในการวิ่งครั้งต่อไปในช่วงการวางแผน Sprint ถัดไป เนื่องจากเรื่องราวของผู้ใช้ที่เรากำลังดำเนินการอยู่นั้นเสร็จสมบูรณ์บางส่วนเราจะประเมินได้อย่างถูกต้องในเซสชันการวางแผน Sprint ครั้งถัดไปอย่างไร เราได้พิจารณาแล้ว: a) การปรับจำนวนคะแนนสตอรี่ลงเพื่อแสดงเฉพาะงานที่ยังคงทำให้เรื่องราวของผู้ใช้เสร็จสมบูรณ์ น่าเสียดายที่สิ่งนี้จะทำให้การรายงาน Backlog ผลิตภัณฑ์ล้มเหลว b) ปิดเรื่องราวของผู้ใช้ที่เสร็จสมบูรณ์บางส่วนและเพิ่มใหม่เพื่อใช้งานคุณสมบัติที่เหลือซึ่งจะมีคะแนนเรื่องราวน้อยลง สิ่งนี้จะส่งผลต่อความสามารถในการมองย้อนกลับไปในสิ่งที่เราไม่ได้ทำในการวิ่งครั้งนั้นและดูเหมือนจะใช้เวลานาน c) ไม่ต้องกังวลกับ a หรือ b และคาดเดาต่อไปในระหว่างการวางแผน Sprint ว่าสิ่งต่าง ๆ เช่น "เรื่องราวของผู้ใช้อาจเป็นจุดเรื่องราว X แต่ฉันรู้ว่ามันเสร็จ 95% ดังนั้นฉันแน่ใจว่าเราสามารถใส่ได้"

50 agile  scrum  estimation  planning 

ฉันแค่สงสัยว่าเราควรกำหนดเรื่องให้กับงานซ่อมบั๊กหรือไม่ JIRA ซึ่งเป็นซอฟต์แวร์ติดตามปัญหาของเราไม่มีฟิลด์จุดเรื่องราวสำหรับปัญหาประเภทBug (เฉพาะสำหรับStory s และEpicเท่านั้น) เราควรเพิ่มประเภทของปัญหาBugไปยังประเภทของปัญหาที่เกี่ยวข้องในฟิลด์Story Pointsหรือไม่ ข้อดีและข้อเสียคืออะไร? มันจะเหมาะสำหรับการต่อสู้แย่งชิงกันหรือไม่

50 agile  scrum  bug  user-story 

ในที่ทำงานสัปดาห์นี้ฉันรู้สึกกระวนกระวายอีกครั้ง ด้วยวิธีการที่ได้รับมาตรฐาน TDD ความเป็นเจ้าของร่วมกันวิธีการพัฒนาแบบเฉพาะกิจที่ไม่เคยวางแผนอะไรเลยนอกจากเรื่องราวของผู้ใช้เพียงไม่กี่เรื่องบนการ์ดชิ้นเดียวด้วยการเคี้ยวเคี้ยวมากกว่าวาจาของเทคนิคการรวมกลุ่มของบุคคลที่สาม ความคิดหรือความขยันหมั่นเพียรและสถาปัตยกรรมที่เชื่อมโยงรหัสการผลิตทั้งหมดกับการทดสอบครั้งแรกที่เข้ามาในหัวของทุกคนในช่วงไม่กี่เดือนที่ผ่านมาเราถึงจุดสิ้นสุดของวงจรการปล่อยและแท้จริงและเห็นคุณสมบัติหลักภายนอกที่มองเห็นได้ ใช้บั๊กกี้กลายเป็นเขาวงกตที่ซับซ้อนและยืดหยุ่นได้อย่างสมบูรณ์ ในระหว่างกระบวนการนี้ "spikes" ได้ทำไปแล้ว แต่ไม่เคยมีการบันทึกและไม่ได้มีการออกแบบสถาปัตยกรรมเดียว (เคยไม่มี FS ดังนั้นนรกเอ๊ะถ้าคุณไม่รู้ว่าคุณกำลังพัฒนาอะไรคุณจะวางแผนหรือค้นคว้าได้อย่างไร ?) - โครงการส่งต่อจากคู่หนึ่งไปยังอีกคู่แต่ละคนเท่านั้นที่เคยมุ่งเน้นไปที่เรื่องราวของผู้ใช้เพียงครั้งเดียวและผลที่ได้ก็คือหลีกเลี่ยงไม่ได้ ในการแก้ไขปัญหานี้ฉันออกจากเรดาร์ไปน้ำตกที่น่ากลัววางแผนเขียนรหัสและโดยทั่วไปไม่ได้สลับคู่และพยายามให้มากที่สุดเท่าที่จะทำได้เพื่อทำงานคนเดียวโดยมุ่งเน้นไปที่สถาปัตยกรรมและข้อมูลจำเพาะมากกว่าการทดสอบหน่วย จะมาในภายหลังเมื่อทุกอย่างถูกตรึงไว้ ตอนนี้โค้ดดีขึ้นมากและสามารถใช้งานได้จริงยืดหยุ่นและรวดเร็ว คนบางคนดูเหมือนจะไม่พอใจฉันจริง ๆ ที่ทำสิ่งนี้และพยายามออกไปก่อวินาศกรรมความพยายามของฉัน (อาจไม่รู้ตัว) เพราะขัดกับกระบวนการอันศักดิ์สิทธิ์ของความคล่องตัว ดังนั้นในฐานะนักพัฒนาคุณอธิบายให้ทีมทราบว่าไม่ใช่ "ไม่ว่องไว" ในการวางแผนงานของพวกเขาและคุณจะปรับการวางแผนให้เข้าสู่กระบวนการที่คล่องตัวได้อย่างไร (ฉันไม่ได้พูดเกี่ยวกับ IPM ฉันกำลังพูดถึงการนั่งลงกับปัญหาและร่างการออกแบบแบบ end-to-end ที่บอกว่าปัญหาควรได้รับการแก้ไขในรายละเอียดที่เพียงพอซึ่งใครก็ตามที่ทำงานเกี่ยวกับปัญหารู้ว่าอะไร สถาปัตยกรรมและรูปแบบที่ควรใช้และตำแหน่งที่รหัสใหม่ควรรวมเข้ากับรหัสที่มีอยู่)

50 agile  planning 

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

50 agile  pair-programming 

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

49 agile 

เราได้รับการบอกต่อไปว่าเราจะทำงานอย่างคล่องตัวในโครงการใหม่โดยผู้บริหารระดับสูง พวกเขาได้ตั้งค่าสแตนอัพการวางแผนการวิ่งการหวนรำลึก ฯลฯ ฯลฯ อย่างไรก็ตามตอนนี้พวกเขาได้วางแผนรายละเอียดงานทั้งหมดที่พวกเขาต้องการให้เราจัดส่งพร้อมกับวันที่กับแต่ละองค์ประกอบและวันที่แสดงอีกครั้ง หนึ่ง. แผนนี้ออกไปในไตรมาสที่ 2 ปี 2560 สำหรับฉันดูเหมือนว่า Waterfall ในแง่ที่เลวร้ายที่สุดแผนที่ไม่มีการป้อนข้อมูลจากทีมงานด้านเทคนิคได้ถูกวาดขึ้นมาโดยที่เรื่องราวบางอย่างในแผนไม่ชัดเจนมากและไม่มีทีมใดที่ถูกประเมินโดย Dev อย่างไรก็ตามฉันรู้ว่าข้อโต้แย้งของพวกเขาจะเป็น "ผู้มีส่วนได้ส่วนเสียระดับสูงต้องมีนัดและต้องมีแผนเราไม่สามารถทำงานจาก backlog ได้" สำหรับฉันนี่ดูเหมือนว่าผู้มีส่วนได้ส่วนเสียอาวุโสยังไม่ได้ซื้อเข้าสู่ Agile ดังนั้นเราจึงต้องล้มเหลวในการนำไปใช้ในระดับที่ต่ำกว่า นี่เป็นการตัดสินที่ยุติธรรมหรือฉันทำเกินจริงต่อแผนนี้หรือไม่?

47 agile  project-management