Confirmed users
821
edits
Gaia/SMS/Scrum/2.1S5: Difference between revisions
→Retrospective
| Line 599: | Line 599: | ||
== Retrospective == | == Retrospective == | ||
===Previous sprints' actions=== | |||
From 2.1S3: | |||
* Look into VM with gaia dev environment | |||
** I've checked out FoxBox, looks like it's the best way to go, but we still need to adapt it a bit for our needs: 1. maybe update guest OS to the latest one to simplify loading of dependencies, 2. Provide some tips and tricks for the inside VM - like set of shortcuts to build debug\release, work with PR and etc. Maybe install IRC client :) | |||
**: (Julien) what do we want to do here exactly? | |||
**: (Oleg) I'd like to fix issues in current default FoxBox installation - it didn't work for me out of the box; Provide additional script that will adopt env for SMS development more. At least this for now. And provide link to fox box from our SMS wiki/Readme | |||
**: (Julien) oki ! | |||
From 2.1S4: | |||
* add a README.md explaining the first steps for contributing to SMS | |||
*: (Julien) not done this time, let's keep it because it's important | |||
===What was good in the last sprint=== | |||
* We did lots of work | |||
===What was bad in the last sprint=== | |||
* some visual refresh is not finished in time... | |||
* we did not finish lots of work ;) | |||
* Refactoring estimates weren't quite right | |||
*: (Julien) +1, we need to increase estimations for refactoring stuff. | |||
*: (Steve) ya, we always underestimate the refactoring item | |||
*: (Julien) we need to take care for refresh too. We're quite good at estimating for "normal" bugs but not for the other type of bugs yet :) We need to keep doing the "split the bug in tasks" to estimate. | |||
*: (Steve) For the refresh item, it seems we easily ignoring some details, and need to confirm with UX/visual again while implementation. I remember we have spec review in the previous release, but didn't do this spec review now. | |||
*: (Oleg) Yeah, I think the full spec is the point, it would be great if we have up-to-date ongoing (maybe versioned) spec, that we or UX can update - so that we don't miss stuff | |||
*: (Julien) I think it's part of the agile way to not have full spec and discussing with designers during sprint. We just need to take this into account when estimating, and also try to discuss before the sprint (but we easily ignore things when we don't try to implement the spec, like Steve said) | |||
*: (Oleg) Yep, by full spec I meant at least list of possible cases that need to be covered | |||
*: (Steve) No full spec review during the sprint is right, but we actually added lots of refresh issue in this release, but these items is not committed while planing. | |||
*: (Julien) what do you mean "we added lots of refresh issue in this release" ? | |||
*: (Julien) any action we can take to avoid estimation issues in the future? Take care to refresh/refactoring bugs and split into tasks big bugs? (also last time steve was not here to estimate, maybe we missed him :D) | |||
*: (Steve) I mean, in 2.0 we knew we got visual refresh item and must be done in 2.0 release, so we review the spec carefully before implementation. But the refresh in 2.2 is more likely "nice to have", so we didn't plan for it carefully. | |||
*: (Julien) yeah it's more "adhoc". | |||
*: (Julien) ok, as an action, we can try to have more actionable bugs. But that means we need to look at bugs earlier and ask UX/Design earlier. So maybe in planning for sprint N we can try to pick refresh bugs for sprint N+1 so that we can ask earlier to Fang and Jenny? Without committing to them, just trying to plan in advance? In ideal world, we should do this for 3 or 4 sprints in advance in one "release planning" :) http://www.scrum-institute.org/Release_Planning.php | |||
*: (Oleg) That would help, I'll also try to make some wiki page "Current State of App" with screenshots grouped by panels/views with different cases (like not-downloaded for report and etc. that weren't visible to UX initially, but we clearly see this in code as developers), so that is easier to analyze the front of work :) I remember the same missed cases during Thread redesign, some not obvious cases where missed initially. | |||
*: (Julien) I'm adding some lines in the 'actions' part, tell me if that's good for you | |||
*: (Oleg) Good for me :) | |||
*: (Steve) +1 | |||
===Any questions=== | |||
* Since we got longer release cycle now(6 month), do we have any long term planing from BD/UX feature request? The only long term item I could image is only engineering issue. | |||
*: (Julien) as I understood, UX is working now, and we'll have planned features only in November. I don't completely like this, I think this could be more open (we can maybe ask later today). | |||
*: (Steve) +1 for opening UX WIP status, it would be great if we could provide any suggestion for new UX. | |||
===Actions for next sprint=== | |||
* in planning for sprint N, we pick some items we want to do in sprint N+1 to ask early questions to UX and Designers (esp refresh bugs, but also bugs with UX changes) | |||
* we'll add screenshots of panels in Wiki, with the various cases for these panels, to help analyzing change impacts and not forgetting things | |||
* ask UX about WIP status for v2.2, so that developers can give ideas and feedbacks | |||