5720518
Descripción
Fichas por minal Kotwal, actualizado hace más de 1 año
|
Creado por minal Kotwal
hace más de 8 años
|
|
| Pregunta | Respuesta |
| Agile estimation issues: There are 2 common problems with Agile estimation 1. Analysis paralysis: - Spending too much time attempting to develop detailed estimates - delaying making commitments until all of information required to make decision has high level of certainty 2. Cavalier approach - Not worrying about managing uncertainity and risk at all and just starting the project with no planning at al - Assuming that whatever uncertainty and risk is inherent in the project will be discovered and somehow work itself out as the project suceeds So managment of uncertainty is very important | |
| B: Story points: - Traditional software teams give estimates in a time format: days, weeks months - Many agile teams, have transitioned to story points - Story points rate the relative efford of work in a Fibinaaci-like format : 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 - Its a way to estimate the amount of work done in an agile project | Story point advantages: - Dates don't account for the non-project related work that creeps into our days - emails, meetings, and interviews that a team member will be involved in - Dates have an emotional attachment to them. Relative estimation removes the emotional attachement - Each team wille stimate their work on a slightly different scale, which means their velocity will naturally be different. |
| Story point calculations: - In reality, its very hard for a new agile team to start calculating story points bc they have no frame of reference to compare it to - Product owner/Scrum master might make it easier by stationg one story point == one man-day at work - In grooming the product backlog, stories are estimated in story points - A voting technique is used to estimate the level of effort associated with each story in story points - The size of the story point will provide the product owner some info to assess the business value against the level of effort - Project team works out the team's velocity in story point on the number of story points completed in a sprint - You can then find out how many sprints are required = total of high level story points / velocity of team in story points per sprint | Estimating technques: Planning poker 1. Each team member is given a set of cards with numbers on them. The numbers are usually ordered from 0 to 21 using the Fib sequence 2. The each story is read aloud. After each story is presented everybody on the team is asked to hold up a card showing the level of effort that they believe this story represents for the team 3. Once all the votes are in, the team members with the lowest and the highest card explain why they chose their score - Through this process everybody learns about what is involved in estimating stories in and out of their capabilites, increasing their knowledge sharing across the team - The numbers are imp. A story with a 2 should be one fourth as difficult as a story estimated as an 8 - Stories estimated at 20 or higher may be so large that they need to broken up into smaller stories before they can attempted |
| Estimating techniques - T-shirt sizes - Items are split into t-shirt sizes: XS, S, M, L , XL - The sizes can be given numerical values after the estimation is done - Decision about the size are based on open, collaborative discussion, possibly, with the occasionally vote to break a stalemate - T-shirt size scales also require extra efort on the part of the person coordinating the agile process. - The T-shirt sizes need to be converted to numeracial values for the sake of tracking effort over time and charting an estimated velocity for the team | Estimating techniques: Burn-down charts - It is a chart often used in scrum agile development to track work completed against time - The x-axis is the time frame and the y-axis is the amount of remaining work left that is labelled as story points and man hours. - The chart begins with the greatest amount of remaning work, which decreases during the project and slowly burns to nothing. |
| Criticism of Lean: - Lack of consideration of human aspects - Lack of creativity - Promotes culture of incrementalism - Coping with variable nature of project management - Does not apply to every project | Miscellaneous Agile concepts: Agile practices found in industry: - Cross functional teams: instead of setting up separate teams of analysts, developers, testers. Try to make of 5-9 people that includes analysts, coders, and testers. Then ask them to collaborate and produce working software together every couple of weeks. Which will force analysts to do some testing, and testers to do some coding. Iterative and incremental development: Instead of building block A, and the building block B, and then block C, only find out that nothing works until block Z is in place. Try to deliver small working version of the system ASAP |
| - Feature driven development: If we have to deliver working software every 2 weeks or so, a high stress has to be put on developing working features as a whole. Instead of spending some months developing the architecture, then another few months developing the core, then application logic, so on. - Planning game - Agile teams participate as a whole in project planning, as everyone will have valueable information in this part of the project. The use of games like planning poker, story points, or workshops to create a user story maps is frequent in Agile teams. | Co-location - This refers to co-location of cross-functional team together. Pair programming - This practice started among developers, but it is gradually being applied by other memebers of the team. For eg: developers and testers are pairing, so code is easier to test. And analysts and coders are pairing so coders better understand what they need to solve and produce. When two people pair, only one computer is used. While one of them is at the keyboard, the other plays the navigator or observer role. |
| Disciplines agile delivery (DAD) - The disciplined agile delivery process dedcision frameowkr is a people- first, learning-oriented hybrid agile approach to IT solution delivery. - It has a risk value delivery lifecycle * is goal-driven * is enterprise aware, and * is scalable - DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modelling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, etc. | - DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solutions to its end users - DAD takes a goals-driven approach - In doing so, DAD provides contextual dvice regarding viable alternatives and their trade offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. - By describing what works, what doesn't work and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you. |
| DAD lifecyle is more complex 1. An agile/basic version that extends the scrum construction lifecycle with proven ideas from PUP 2. An advanced/lean lifecycle 3. A lean continuous delivery lifecycle | done |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.