Agile Project Management
•
10 gostaram•1,647 visualizações
Embracing Change with Agile
![Speaker’s Background ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[email_address]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (12)
Semelhante a Agile Project Management
Semelhante a Agile Project Management (20)
Último
Último (20)
Agile Project Management
- 1. Agile Project Management: Embracing Change Sinaporn Suebvisai Agile Evangelist
- 6. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
- 11. Story Card User Story Description http :// www . agilemodeling . com / images / models / userStoryFormal . jpg Story ID From Discussion Story Points Exit Criteria
- 18. Planning Poker
- 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.
- 24. Burndown Chart (later) http :// www . mountaingoatsoftware . com / system / asset / file / 65 / PredictiveBurndownChart . jpg
- 31. Special Thanks to K.Kulawat W. & K.Werachai P. from Thomson Reuters
- 40. Burndown Chart (later) http :// www . mountaingoatsoftware . com / system / asset / file / 65 / PredictiveBurndownChart . jpg
- 45. Cost of Change Curve http :// www . ambysoft . com / essays / whyAgileWorksFeedback . html
Notas do Editor
- 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 .
- Absolute estimation จะขึ้นอยู่กับมุมมองของแต่ละคน junior, senior developer จะเอาเครื่องวัดไปนั่งวัดก็ได้ แต่ก็คงใช้เวลานาน คล้ายๆกับใช้เวลา plan project 3 เดือน แทนที่จะเอาเวลาไปทำงานจริงๆ แต่ถ้าให้คาดเดาแล้วล่ะก็ relative estimation เหมาะกับมนุษย์มากกว่า
- Management มักจะบอกว่า ทีมมี 4 คน ใช้เวลา 2 เดือน ถ้าใส่เข้าไปอีก 4 คนก็ต้องเหลือเดือนเดียวสิ งานบางอย่าง share ไม่ได้ communication & process overhead - งานไม่จบถ้า test ไม่เสร็จ จากครั้งที่แล้ว dev & test คิดต่างกัน แต่ point เท่ากัน possibility ที่จะเกิดอย่างนั้นมีได้หน่อย ก็แค่ estimate ผิดพลาดก็คือการเรียนรู้ เมื่อเทียบกับการที่มีคนที่ไม่ได้ทำงานจริง estimate มาให้ โอกาสที่จะได้คุยกันในแบบนี้มีมากกว่า
- ไม่ใช่การคาดเดา แต่เป็นการค้นพบ Customer defines the scope เราจะเอาทรายใส่แค่ไหน ถังใหญ่แค่ไหน
- ณ วันที่เริ่ม project ใช้ velocity จากโปรเจคเก่า ที่มีลักษณะใกล้เคียงกัน หรือ เลือก stories ที่อยู่ใน highest priorities ที่คาดว่าน่าจะทำเสร็จได้ใน iteration แรก แล้วเอา story point ตรงนั้นมาเป็น estimated velocity
- Burndown chart ก็คงจะไม่ราบเรียบเหมือนชีวิตคนเรา ที่ขึ้นก็คือ requirements ที่เพิ่มเข้ามา เห็นชัดเจน transparent
- 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
- สรุป ก็จะเห็นว่า มีหลายอย่างที่มีประโยชน์ และเอามาเลือกใช้ได้ แล้วแต่ nature ของ project ของคุณ ในแต่ละอันก็มี technique ย่อยๆ ลงไปอีก
- มีเป้าหมายก่อนว่าจะทำ practice เหล่านั้นเพื่อมาแก้ปัญหาอะไร