Timeline for Agile Practices: Code Review - Fail the review or raise an issue?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 28, 2018 at 6:21 | comment | added | cjs | @RandomUs1r I've successfully practiced in the real world what you seem to be calling "textbook agile." If by "perfect efforting" you mean "perfect iteration estimation," no, that doesn't always happen, and isn't supposed to in textbook agile. The point is, pick the effort you want to put in and always use that amount of effort, no more, no less; then use what actually happened as feedback to improve your estimates. Since you're comparing estimated and actual velocity, the particular velocity number that comes out at any time isn't important and can indeed vary. | |
| Oct 26, 2018 at 21:45 | comment | added | RandomUs1r | @Curt classic textbox agile, I've never seen it successfully practiced in the real world might be where our experiences differ. For one you assume perfect efforting, something juniors devs don't do well, and while I agree pushing harder = burnout = empty chairs, I've never seen a velocity chart without noticeable fluctuation, thereby the case by case nature of my answer. Lastly, I've never met a developer in Agile who hasn't failed a sprint... hmmm ;) | |
| Oct 26, 2018 at 10:38 | comment | added | cjs | @RandomUs1r Also, your conception of a sprint is backwards: sprints can't run "tight" any more than a ruler can sometimes be "short" or "long"; how much you get done in a sprint is a measurement of your velocity, and to do that accurately you shouldn't every try to push harder than normal. | |
| Oct 26, 2018 at 10:36 | comment | added | cjs | @RandomUs1r I work in the real world too, I take shortcuts all the time, and I always put the business first, so I don't think I'm lacking in understanding here. But the OP's description was not "we normally always get this right and this was just a standard minor burp" or he wouldn't have been posting the question. As I explained in my answer it looks like a process problem, and you fix that by practising doing the process correctly before relaxing with it. | |
| Oct 25, 2018 at 21:18 | comment | added | RandomUs1r | @Curt I get that mine may be an unpopular view from a dev standpoint (I'm a dev too btw), but the business really should come first, they sign the paychecks and that deserves some respect. As far as leaving time goes, I'll again challenge your understanding of the real world, and you need to realize that's not always possible and a lot of sprints run tight because devs need stuff to do at the end of the sprint too. It's not like because the code's SOLID, a department can kick their feet up 1/10 days every 2 weeks and do nothing, that might be great in the short term, but isn't a viable long. | |
| S Oct 25, 2018 at 8:10 | history | suggested | Peter Mortensen | CC BY-SA 4.0 |
Copy edited (e.g. ref. <https://www.scruminc.com/product-backlog-item-pbi/> and <https://en.wikipedia.org/wiki/Technical_debt>).
|
| Oct 25, 2018 at 4:33 | comment | added | cjs | As other reviewers have pointed out, in this case there's potentially a lesson to be learned from the code's failure to truly pass the review. It looks to me as if the folks in this project really don't well understand that a) you need to leave time for review and fixes for each story, and b) the refactoring necessary to leave clean code behind is an essential part of the story. In that case, the best thing to do is to fail the story to make it clear that these things really are not optional. | |
| Oct 25, 2018 at 0:54 | review | Suggested edits | |||
| S Oct 25, 2018 at 8:10 | |||||
| Oct 24, 2018 at 6:00 | comment | added | VLAZ | @PaŭloEbermann I had an amusing conversation with a company I interviewed with one time. They claimed their process was not agile because it wasn't a textbook example of agile. Even though everything they did was in the spirit of agile. I pointed it out to them but was only met with (essentially) "No, we are not following an established agile procedure to the letter, even if we borrow the concepts heavily. Therefore, we are not agile". It was quite bizarre. | |
| S Oct 23, 2018 at 22:09 | history | suggested | Paŭlo Ebermann | CC BY-SA 4.0 |
write the abbreviations out
|
| Oct 23, 2018 at 21:31 | review | Suggested edits | |||
| S Oct 23, 2018 at 22:09 | |||||
| Oct 23, 2018 at 21:30 | comment | added | Paŭlo Ebermann | nobody in the real world follows agile to the T – it won't be "agile" anymore if we have too strict rules, right? | |
| Oct 23, 2018 at 19:39 | history | answered | RandomUs1r | CC BY-SA 4.0 |