Confirmed users
821
edits
Gaia/SMS/Scrum/FxOS-S3: Difference between revisions
/* Retrospective
(/* Remaining points and burndown chart) |
(/* Retrospective) |
||
| Line 932: | Line 932: | ||
== Demos == | == Demos == | ||
== Retrospective == | == Retrospective == | ||
===Previous sprints' actions=== | |||
From 2.1S3: | |||
* Look into VM with gaia dev environment | |||
*: Nothing more done in this sprint | |||
From 2.1S5: | |||
* 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 | |||
*: Oleg started this: https://wiki.mozilla.org/Gaia/SMS/Current_App_State | |||
From 2.2S4: | |||
* undercommit in the sprints. | |||
* use bugs and github's PR for spec definition and changes | |||
From 2.2S14: | |||
* move more discussions to #gaia | |||
* figure out 2.5 features for SMS | |||
===What was good in the last sprint=== | |||
* Discovered several important issues in NGA-toolkit libs so that they were fixed | |||
* Have a testable patch that can verify our structure over bridge library. | |||
===What was bad in the last sprint=== | |||
* Our estimations were quite bad for this sprint | |||
*: (Julien) Yeah I think we could do a *3 operation on our estimations. For each estimation we do, we need to step back and look again to know if it's realistic. | |||
*: (Oleg) And we don't have to afraid small p1 tasks even if they seem too trivial in attempt to split p2+ ... probably. I found that during this sprint every my p2+ task could be split into smaller ones. The only thing is that it may be difficult for reviewer when some parts can't be tested on device or browser. Like we had with layout of services - but I still think it was better to do layout first even knowing that it can't be tested. | |||
*: (Julien) if you detect during development that the task can be split, do you do it then ? | |||
*: (Oleg) For some I did :) This sprint will do for everything I suspect can be split. | |||
*: (Steve) Yeah, try to spilt as small as possible | |||
*: (Julien) for the navigation patch I feel I could do it more. | |||
*: (Oleg) I'd say navigation patch is more like an exception, personally I think it's not that easy to split such patch, so I believe it's fine (mainly because there is no point in navigation patch until you see it works for all cases, but some cases should be fixed first :), so that's why I suspect it's big). It's easier for services - I like that we have one meta for implementation and one-bug-per-method or at least for small group of methods. | |||
*: (Julien) yep, for services, try to separate with use cases; and even in one use case we can separate the work for separate services. Maybe separate commits in one PR is good enough instead of separate bugs ? (like they do in Gecko). About Navigation patch: there was some preparation work I could do in a separate patch, but now it's quite too late (and I found these preparation work after I did the big part of the patch too :p) | |||
*: (Steve) I'm fine if we need to do separated commit in one bug, but we might need to handle the whiteboard more carefully the it contains sufficient information for our estimation history. | |||
* I didn't do timely reviews because of the navigation patch; it's difficult for me to find the balance between working on a big patch and doing reviews. Did you find it was an issue for you ? | |||
*: (Oleg) Mostly for the sprint being completed in time, but for me personally slow reviews were not problem because my new tasks didn't depend on ones being reviewed. Or you've asked something different? :) | |||
*: (Steve) yeah.. especially while working on the huge patch and it's not easy to doing the review efficiently. But I think it's acceptable. | |||
*: (Julien) Oleg: that was my question :) ok then, but I think we still should not lag as much for sprint bugs reviews. | |||
===Any questions=== | |||
* Agenda or clear goal for the workweek in next week? | |||
*: (Oleg) Yeah, we need agenda :) | |||
*: (Julien) I think we'll present what we did so far, and try to work a little more closer together. So part of the workweek will be sharing information, and other part will be working together (and hopefully resolve issues or questions we have, eg performance). | |||
===Actions for next sprint=== | |||
* split patches as much as we can when we develop it, and split bugs as much as we can when planning them. (what do you think ?) | |||
*: (Oleg) Sounds good, also "split patches as much as we can even that some parts are not used/clear (don't know how to express better)" | |||
*: (Steve) Let's try it in the new sprint :) | |||