การแย่งชิงโปรแกรมเมอร์เดียว? [ปิด]

ฉันถูกเรียกเก็บเงินในฐานะ "ผู้เชี่ยวชาญของ Windows" ใน บริษัท ขนาดเล็กของฉันซึ่งประกอบด้วยตัวเองวิศวกรเครื่องกลที่ทำงานในบทบาทการขายและการฝึกอบรมและประธาน บริษัท ทำงานด้านการออกแบบการพัฒนาและการสนับสนุน

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

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

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

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

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

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

Backlog - แย่งชิงกันหรือไม่เก็บรายการที่สำคัญที่คุณต้องทำ ฉันชอบ Excel (หรือ Google Spreadsheet ... ) คุณอาจชอบอย่างอื่น ฉันจะเก็บเครื่องมือเล็ก ๆ ไว้ถ้าคุณเป็นทีมเล็กมาก (สเปรดชีต >> โปรแกรมประมวลผลคำเพราะคุณสามารถจัดเรียงได้อย่างง่ายดาย)

การแยกการวางแผนและการทำสัญญา - วางแผนในรูปแบบนามธรรม (จุด) และมีความสอดคล้องกัน (8 พอยต์เป็นเรื่องเกี่ยวกับ 2x a 4pt เรื่องราวและ 4x a 2 จุดเรื่องราว) เมื่อถึงเวลาที่จะ "ทำงาน" ดูปัญหาและร่างใหม่ ในไม่กี่ชั่วโมง อย่าเปลี่ยนคะแนน

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

ย้อนหลัง - หลังจากที่คุณส่งมอบแล้วให้ไตร่ตรองดูว่าสิ่งใดที่ทำได้ดีกว่านี้

ฯลฯ

การต่อสู้นั้นง่ายพอที่จะเข้าใจว่ามันอาจเป็นจุดเริ่มต้นที่ดี ถ้าคุณชอบมันฉันต้องการพิจารณาโดยใช้ "การแย่งชิงกันห้าม" ตัวแปร - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban ไม่มีสิ่งใดที่ทำให้ฉันเป็น "เอกสารที่ดี" กับชุมชนที่มีเหตุผลพอที่จะให้การสนับสนุน

ฉันชอบที่จะแนะนำวิธีการแบบคริสตัลของ Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer และhttp://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-) เล็ก / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ) แต่มันเกี่ยวข้องกับการอ่านและขุด

สิ่งต่าง ๆ เช่น XP มีรายละเอียดเพิ่มเติมเกี่ยวกับการปฏิบัติเฉพาะฉันยังบอกว่าอ่านหนังสือ: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= หนังสือและเช่น = UTF8 & qid = 1304359834 & sr = 1-1

คำแนะนำในการอ่านขั้นสุดท้าย: ตราบใดที่คุณเห็นด้วยกับการประกาศ Agile และปฏิบัติตามหลักการ: http://agilemanifesto.org/principles.html คุณควรมีรูปร่างที่เหมาะสม

คำแนะนำส่วนบุคคล: นำ TDD (ไม่สามารถต่อรองได้, IMHO) รักษา backlog (ตามการต่อสู้) เก็บขนาดและจัดเรียงตามลำดับความสำคัญแยกแยะสิ่งต่าง ๆ "ใหญ่เกินไปที่จะทำระหว่างการขัดจังหวะ" ชิ้นเล็ก int มีคนอื่นจัดลำดับความสำคัญ สองรายการได้รับการจัดลำดับความสำคัญเท่าเดิมเสมอ) ทำให้สภาพแวดล้อมการสร้างของคุณสามารถสร้าง / ทดสอบ / ปรับใช้ (ไปยังห้องปฏิบัติการ env) ใน 5-10 นาทีแสดงลูกค้าของคุณ (ภายในและภายนอก) ผลลัพธ์ของการจบเรื่องราว ลูกค้าของคุณตกลง ดึงเรื่องจากด้านบนของกองและทำงานกับพวกเขาในขณะที่คุณทำเรื่องปัจจุบันอย่าเปิดมากกว่า 2 สิ่งในเวลาเดียว เสร็จสิ้นสิ่งที่ทำให้ไขว้เขวก่อนที่จะเริ่มอีก

หวังว่านี่จะช่วยได้

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

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

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

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

ฉันลองสิ่งนี้เมื่อฉันทำงานคนเดียว ณ จุดหนึ่ง สิ่งที่ทำงานได้ดีคือ:

1. มีรายการงานทั้งหมดบนไวท์บอร์ด ฉันสามารถเห็นได้อย่างรวดเร็วว่างานที่โดดเด่นมี; ที่พึ่งพาและอุดตันอยู่ นอกจากนี้ผู้คนจำนวนมากจะแวะมาที่บอร์ดของฉันและอ่านมัน - และเราจะคุยกัน ฉันคิดว่ามันช่วยให้พวกเขาเข้าใจสิ่งที่ "เกินบรรยาย" กำลังทำอยู่ทั้งวัน ;-)
2. แผนภูมิที่แย่ลงก็ยอดเยี่ยมเช่นกัน ฉันเพิ่งใช้ Excel กับสิ่งนี้ มันทำให้ฉันสามารถทำประมาณการได้ดีขึ้นในสภาพแวดล้อมนั้น มันทำให้ฉันเห็นภาพรวมที่ดีว่าฉันกำลังมุ่งหน้าไปที่การทำซ้ำ ผู้จัดการของฉันซึ่งไม่ใช่บุคคลด้านเทคนิคก็ชอบสิ่งนี้เพราะเธอสามารถเห็นสิ่งต่าง ๆ ทั้งหมดที่เกี่ยวข้องกับคุณลักษณะและที่ที่พวกเขาอยู่
3. ยืนขึ้นทุกวัน ดีที่สุดเท่าที่ฉันจะทำได้ ทุกเช้าฉันอัปเดตรายการงานทั้งหมดและแผนภูมิเบิร์นดาวน์และจดบันทึกสิ่งกีดขวางทั้งหมดที่จำเป็นต้องได้รับการแก้ไข
4. การทดสอบอัตโนมัติและการรวมอย่างต่อเนื่อง (MSTest / TFS) โดยเฉพาะอย่างยิ่ง TDD จะช่วยทีมพัฒนาใด ๆ โดยใช้วิธีการใด ๆ - แต่ควรพูดถึงที่นี่
5. การทำซ้ำสั้น ๆ (1 สัปดาห์) ช่วยให้ฉันจดจ่อกับการส่งของบางอย่างจริงๆ
6. การรักษายอดคงค้างนั้นเยี่ยมมากเมื่อฉันได้งานใหม่ฉันสามารถวางมันในบริบทของงานอื่น ๆ ทั้งหมดและให้เจ้าของผลิตภัณฑ์กลับมาจัดลำดับความสำคัญใหม่

สิ่งที่ไม่ทำงานคือ:

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

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

ฉันคิดว่าทุกคนควรเก็บบันทึกย้อนหลังและทำ TDD

องค์ประกอบของ Agile / Scrum / Kanban ที่ฉันคิดว่าเหมาะสมในโลกนักพัฒนาเดียว:

1. มีกระดานที่คุณจัดระเบียบเรื่องราวของผู้ใช้ / รายการค้างที่ใช้งานอยู่บนบัตรดัชนีเช่น kanban

2. รับการซื้อจากผู้ที่ไม่ใช่นักพัฒนาตามหลักการเหล่านี้:

   • ให้เวลาฉันในการทำงานโดยไม่เปลี่ยนลำดับความสำคัญของฉันกับฉันหรือการย่อขนาด (จุดของการวิ่ง) ให้เวลากับฉันและฉันจะพยายามคิดให้ดีก่อนว่าฉันสามารถทำอะไรได้มากแค่ไหนและฉันจะพยายามทำให้ดีที่สุด

   • หากฉันต้องการบางสิ่ง (ฉันถูกบล็อก) และฉันมาหาคุณและคุณไม่สามารถเรียงลำดับให้ฉันได้การวิ่งอาจต้องถูกยกเลิกอย่างผิดปกติ (นั่นแปลว่าเราต้องการแผนใหม่)

   • ไม่มีใครเปลี่ยนแปลงอะไรเลยในช่วงกลางของการวิ่ง หรือถ้าเราทำเราเพียงแค่ยกเลิกการวิ่งและเราสร้างใหม่ หากสิ่งนี้เกิดขึ้นมากผลผลิตจะลดลง

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

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

ฉันได้อ่านบล็อกเกี่ยวกับเรื่องนี้แล้วและคิดว่ามันสามารถช่วยคุณได้

ส่วนแรก: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

ส่วนที่สอง: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

คุณอาจพบข้อมูลเพิ่มเติมในบล็อกนี้

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

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

คำตอบเหล่านี้จำนวนมากขาดจุดสำคัญ

ทีมต่อสู้ไม่จำเป็นต้องประกอบด้วยโปรแกรมเมอร์อย่างหมดจด

หนึ่งในเพื่อนร่วมงานของคุณทำ 'ออกแบบ' / 'พัฒนา' และอีกคนทำ 'ขาย'

บางทีเพื่อนร่วมงาน 'ฝ่ายขาย' ของคุณอาจเป็นเจ้าของผลิตภัณฑ์ (พร็อกซี) ความคาดหวังของลูกค้าคืออะไร?

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

คุณสามารถทำกระบวนการทะเลาะกับคุณสามคน

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

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

ตันของเหตุผลในการใช้ scrum imho

ฉันขอแนะนำให้ลอง Kanban และเริ่มต้นด้วยพื้นฐาน: การสร้างภาพและการ จำกัด งานระหว่างทำ (WIP)

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

ฉันขอแนะนำหนังสือ Kanban ของ David Anderson และคุณสามารถดูสไลด์ของฉันจากการพบปะกันในท้องถิ่นเกี่ยวกับสาเหตุและวิธีการเริ่มต้นด้วย Kanban แบบง่าย ๆหรือcrisp.se/kanbanสำหรับอินโทรสั้น ๆ

สำหรับบริบทของคุณฉันมีความคิดเล็กน้อย:

• การมองเห็นเป็นกุญแจสำคัญดังนั้นให้ใช้ไวท์บอร์ดแบบฟิสิคัลมากกว่าเครื่องมือดิจิตอลหากคุณไม่สามารถแสดงมันบนหน้าจอ (ใหญ่) อย่างถาวร (ถ้าคุณอยู่ร่วม)
• เริ่มต้นด้วยกระบวนการปัจจุบันของคุณ
• เริ่มต้นด้วยอิทธิพลที่มีอยู่ของคุณเท่านั้นรวมถึงขั้นตอนการส่งมือขึ้นและลง (กลายเป็นคิวสำหรับคุณเช่นคุณสมบัติที่ออกแบบมาสำหรับ dev หรือคิวจากคุณเช่นคุณสมบัติที่เสร็จสมบูรณ์พร้อมสำหรับการขาย)
• หากเพื่อนร่วมงานของคุณมีความสนใจในการขยายการแสดงภาพต้นน้ำหรือปลายน้ำดีกว่าทั้งหมด บางทีคุณอาจจะเห็นภาพกระแสทั้งหมด (หรือเครือข่าย) สำหรับ บริษัท ของคุณเช่นการไหลของมูลค่าจากแนวคิดสู่เงินสด
• ลดการทำงานหลายอย่าง (!) ด้วยการ จำกัด งานระหว่างทำ หากเพื่อนร่วมงานของคุณมองเห็นกระบวนการทำงานพวกเขาควรเข้าใจว่าทำไมและเห็นสิ่งที่อยู่บนจานของคุณได้อย่างง่ายดาย
• อาจจะเป็นประโยชน์ในการแยกงานออกเป็น 3 หรือ 4 ประเภทงาน (คลาสของการบริการ) ซึ่งมีความต้องการที่แตกต่างกัน: f.ex ข้อบกพร่องปัญหาที่สำคัญทำงาน w / กำหนดเวลาที่ยากทำงานโดยไม่ต้องกำหนดเวลา
• สังเกตว่ากระบวนการทำงานของคุณเช่นหากคุณได้รับคอขวดที่ใดที่หนึ่งหรืองานถูกบล็อกหรือคุณ "หิวโหย" สำหรับการทำงานในรูปแบบที่คาดเดาได้ค่อนข้าง สิ่งนี้จะง่ายขึ้นในระยะยาวถ้าคุณใช้เครื่องมือดิจิทัลอ้างอิงสไลด์สุดท้ายของฉัน
• ปรับปรุงการไหลของงานทีละขั้นตอน

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

หลังจากอ่านคำตอบอื่น ๆ ทั้งหมดที่นี่ฉันคิดว่าคำตอบง่าย ๆ คือ:

ใช้กระบวนการหรือเทคนิคหรือวิธีการที่ใช้เพื่อเรียนรู้สิ่งที่จะช่วยให้คุณทำงานได้ดีขึ้น

ตอนนี้อาจหมายถึงการจัดลำดับความสำคัญงานของคุณ - ทุกวัน - อย่างเคร่งครัด

มันอาจหมายถึงการทำงานที่ค้าง

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

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

ทำสิ่งที่ใช้งานได้ (สำหรับคุณในสถานการณ์ปัจจุบันของคุณ) ให้ทิ้งสิ่งที่ไม่ได้ทำ

เว้นแต่คุณจะมีสิ่งต่อไปนี้

• หมายถึงการจัดระเบียบและจัดลำดับความสำคัญของความต้องการที่เข้ามา

• ในการประเมินความพยายามที่จะดำเนินการอย่างแม่นยำเพื่อที่คุณจะได้รู้ว่าคุณสามารถทำอะไรได้บ้างในการทำซ้ำ

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

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

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

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

การต่อสู้ไม่ได้เป็นการต่อสู้ถ้าคุณไม่สามารถปรับให้เข้ากับความต้องการของคุณและปรับให้เข้ากับสถานการณ์ปัจจุบันของคุณ