6. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
7.
8.
9.
10.
11. Story Card User Story Description http :// www . agilemodeling . com / images / models / userStoryFormal . jpg Story ID From Discussion Story Points Exit Criteria
23. Burndown Chart 150 125 100 75 50 25 0 1 2 3 4 5 6 7 8 9 10 With estimated velocity, we can estimate how long the release may take. The Burndown chart needs to be updated every iteration to reflect the actual situation.
45. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
46.
47.
48.
Editor's Notes
Brain product includes creativity and talent Brain = complex
Barry Boehm ในปี 1981
Advocates ชอบให้เกิดการโปร่งใส One of the key ideas behind agile software development is providing information as early as possible to allow the business to best make decisions .
Management มักจะบอกว่า ทีมมี 4 คน ใช้เวลา 2 เดือน ถ้าใส่เข้าไปอีก 4 คนก็ต้องเหลือเดือนเดียวสิ งานบางอย่าง share ไม่ได้ communication & process overhead - งานไม่จบถ้า test ไม่เสร็จ จากครั้งที่แล้ว dev & test คิดต่างกัน แต่ point เท่ากัน possibility ที่จะเกิดอย่างนั้นมีได้หน่อย ก็แค่ estimate ผิดพลาดก็คือการเรียนรู้ เมื่อเทียบกับการที่มีคนที่ไม่ได้ทำงานจริง estimate มาให้ โอกาสที่จะได้คุยกันในแบบนี้มีมากกว่า
ไม่ใช่การคาดเดา แต่เป็นการค้นพบ Customer defines the scope เราจะเอาทรายใส่แค่ไหน ถังใหญ่แค่ไหน
highest priorities from the Release (after customer has re-prioritized if it’s the later release) Switching task takes more time than you think Stories ไม่ควรจะข้ามพาด iteration เพราะนานเกิน ไม่ได้ test ไม่ได้ feedback
Duration estimate is harder to match ยากที่จะทำให้ได้ตามนั้น ถ้ากำหนดเป็นวันที่ Plans are made at different levels: Project, Release, Iteration เราเห็นภาพของแต่ละ level อย่างชัดเจน และสามารถย้อนจาก level ที่แคบกว่า ขึ้นไปมอง level ที่กว้างกว่าได้ ให้เห็นความสัมพันธ์ e.g. burndown chart is a must because sometimes can lose track State Uncertainty in no Uncertain terms ใน agile เราบอกไปตรงๆเลยว่า แน่นอน project นี้มันมีความไม่แน่นอน ทุกคนต้องยอมรับความจริงในจุดนี้ Plans are by Features, not Tasks We want the features not the tasks Tracking is at the Team level, not Individual ตัดปัญหา ถ้ามีคนป่วย ลาออก
People who make the product happens participate
Testers can write tests while developers write code มี tool ช่วยเยอะนะ เดี๋ยวนี้ สามารถแปลง user story exit criteria มาเป็น test cases ได้เลย ถ้าเกิดส่งนี้ใน state นี้ของโปรแกรม จะต้องได้สิ่งนี้ออกมา exit criteria เป็น functional tests Junior developer can make changes to old code encourage growth Technical debt may appear faster at first, but things that hidden underneath the carpet will creep back at you later ทำแล้วไม่ผิด แต่ไปตามเก็บด้วยนะเออ
the developer MUST fix it immediately ถ้าไม่ทำอย่างนี้ก็ไม่มีประโยชน์ ไม่ว่าจะเป็น test ใดๆ ถ้าต้องทำซ้ำๆ automation is the key ไม่งั้นก็ไม่มีวันทันต่อการเปลี่ยนแปลง
บางทีม เปิดเพลงเมื่อ success เปิดเสียงหวอ เมื่อ fail Fail นี่ต้องบอกอยู่แล้ว แต่อาจจะมี success notification ใน step ย่อยๆได้ เพื่อให้คนที่เกี่ยวข้องสบายใจ หรือจะเลือก test เป็น set set เพื่อให้ test เสร็จเร็วช้า แล้วแต่ต้องการ
Burndown chart ก็คงจะไม่ราบเรียบเหมือนชีวิตคนเรา ที่ขึ้นก็คือ requirements ที่เพิ่มเข้ามา เห็นชัดเจน transparent สีแดงคือ worst case สีน้ำเงิน คือ best case สีดำคือ average ใช้ average velocity
Learn from mistakes, Learn from success – ไม่ได้ learn from failure อย่างเดียวนะ อะไรที่ทำแล้วดี ก็ควรทำต่อ แต่ถ้าบางทีเราไม่หยุดมาดู เราจะไม่รู้ ว่าอะไรทำแล้วดี ช้าไป ทุกอย่างอาจจะสายเกินแก้ Time for improvement ถ้าเราหยุดอยู่กับที่ ก็เท่ากับเดินถอยหลัง Stop to Breathe ไม่หยุดมันเหนื่อย
Define Improvement Goals – only a few because we want to be able to see progress in the next retrospective