Gaia/Dialer/Restructure: Difference between revisions

From MozillaWiki
< Gaia‎ | Dialer
Jump to navigation Jump to search
m (Add long-term projects.)
(Moved to FirefoxOS/Comms/Dialer/Restructure.)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Summary=
Moved to [[FirefoxOS/Comms/Dialer/Restructure]].
 
We have discovered that the dialer team could use some improvements in the areas of organization and planning. In the past, we have mostly worked ad-hoc, with little planning besides a very relaxed sprint planning session.
 
Please contribute to this as much as you feel/want! We can't fix this problem without you.
 
=Good/Problem Areas=
 
==Good Areas==
* Wasting very little time in meetings
* Very nimble and able to switch gears to get things done when needed
* Anthony is very vocal about UX and is a great liaison for us there
 
==Problem Areas==
* Not anticipating problems
* No clear vision for future
* Little accountability when things go wrong, not much formal retrospective or discussion about processes
* Not capable of effectively expanding to include more team members
 
=Interviews=
I (Doug) spoke with people on other teams and got some useful information about what they're doing and what's working well for them. I really wanted to talk with Julien, but unfortunately he's on PTO.
 
==Contacts==
In general, the contacts team is in the middle-ground between the dialer and messages teams. It seems that Francisco always has a pretty good idea of what everyone is doing and is able to organize things in his head without as much on-paper planning as Julien uses. This seems to work well for them, and they're experimenting with new approaches.
 
Everyone in the contacts team is in Europe, so they don't have as many scheduling conflicts for meetings and random chats.
 
===Francisco (Lead)===
* Daily meetings
** This is the time to say "I have problems here" and have others help you
** Takes less than 10 minutes
** Helpful to know what everyone else is doing (sometimes there's overlap between work and useful tidbits)
* Starting to do estimations
** Being relaxed on it
** Leave some free time for important things that come up during the sprint
** Commit to at least a specific minimum amount of work done
** It's very motivating to look at a list of bugs and watch them fall
* Wiki articles
** Helpful for going into the comms meeting (though this will be phased out)
** List of global things before meet
* Planning (not just sprint)
** Try to have long-term projects going on on the side
** Ask people what is not working in contacts (not just retrospective)
*** Example question, "if you were going to rebuild contacts from scratch, what would you improve?"
*** Have a list of tasks to get to one of these
** Spend time designing, ask other people about architecture decisions
*** Do prototypes, there will be unexpected problems in any big projects
** Likes this middle-ground of planning
* People organization
** People should focus on one task
** Have some people working on blockers, and others workers on future things, have them rotate
* Awareness of big problems
** Current big problems: performance (DataStore?), design (Haidification)
** Try to make time to have people work towards these
* UX relations
** Lets UX do their job, isn't very picky about UX decisions
** Easier to chat with people in person about UX, liked being able to talk with Vicky when at Telefonica, but still not perfect
** Was unhappy about VR work that happened without him there (I may have misunderstood what he meant here, so please don't judge him :))
** Would like to have Vicky on IRC or otherwise quick to contact (Skype, Vidyo, etc)
* Random useful insights
** "Work is not just about working, it’s also about letting other people know what you’re doing"
** Planners look at the last time a blocker was updated
* Comms meeting
** They take turns taking notes and going to the comms meeting to present them
* Takeaways and suggestions for the dialer team
** Consider having our meeting later in the day (we already do this for sprint planning)
** Work on integrating Tamara into the team
** Identify big things that we can be working on to move dialer forward instead of just reacting
 
===Michal===
* Daily meetings
** This is a good to get help from other people
** They have their own IRC channel, #fxos-contacts
** 15 minute meeting every half hour before the comms meeting
** Every day there's someone missing, wishes everyone would attend
* Wiki articles
** History of daily standups, who worked on what, when
** Videos with demos of what we achieved
** Don’t need to attend the comms standup
** Favorite part of this process
** Makes him feel better and being able to track his progress
* UX relations
** Not really any relations with UX
*** Mostly Bugzilla comments, patches that need ux-review
*** Contacts refactoring is rebuilding the app from scratch, will change things
 
==Messages==
The messages team is very tightly scheduled and has many, more formal, processes to make sure that things get done. The messages team has 2 people in Europe and 1 in Taiwan, so there are significant scheduling difficulties.
 
===Julien (Lead)===
on PTO :(
 
===Oleg===
Useful links:
https://etherpad.mozilla.org/sms-retrospective
https://wiki.mozilla.org/Gaia/SMS/Scrum/3
https://wiki.mozilla.org/Gaia/SMS/Scrum
https://etherpad.mozilla.org/sms-standup
https://etherpad.mozilla.org/messages-datastore
https://etherpad.mozilla.org/sms-haida
 
* Daily meetings
** Done async over Etherpad: https://etherpad.mozilla.org/sms-standup
** Doesn't think there's significant overhead to this (takes him about 10 minutes each day)
** Likes Etherpad format
** Mention updates in daily standup
* Estimations
** Velocity of 8 points
** Sometimes only assigned 1 bug with point value of 1
** They only estimate bugs that take 1 day or more (lowest point value is 1 point which is 2 days, should be adjusted in the next sprints to be more precise)
* Wiki articles
** Great way to get summaries
* Sprint planning
** Every 2 weeks, same day as comms planning
** They do retrospective first: https://etherpad.mozilla.org/sms-retrospective
** 2 hours, too much, trying to improve
** Done over IRC
** Will try it over Etherpad, as IRC doesn't work well
** Vidyo more efficient, but hard to schedule
* People
** Everyone works on whatever
** Doesn't like specialization on blockers, even just in terms of temporary time specialization
** One time they tried specialization and it worked well, but he doesn't think it should happen all the time
* Awareness of big problems
** DataStore, Haidification
** Split into small bugs that are manageable
** Not breaking down big bugs was not working
* UX relations
** Mostly needinfos for UX
** Would like to have Vicky on IRC
** Problems with UX organization in general, mockups problems, not much discussion
** Painful use of time, hard to get good responses
** Really didn't like visual refresh bugs
* Action items that they've decided on and haven't been able to do
** Estimating for people on other teams is hard and inaccurate, so invite those people to standups
** Hard to invite people from other teams, they have own commitments
* Comms team meeting
** People don't care about little things, focus more on high-level
* Takeaways and suggestions for the dialer team
** Julien has an Etherpad script for making a wiki article from Etherpad
 
===Steve===
todo
 
==Dialer==
 
===Etienne===
todo
 
===Anthony===
todo
 
===Tamara===
* Is a scrum master!
* It would be helpful to know what other people are doing.
* Being mentored by Gabriele to get started.
 
===Gabriele===
todo
 
===German===
todo
 
=Analysis=
 
==Differences Between Teams==
{| class="wikitable"
|-
! Category !! Dialer !! Contacts !! Messages
|-
| ''Tactical Planning'' || None. No daily meetings. || Lots. Daily meetings, own IRC channel, lots of back-and-forth. || Some. Daily meetings done async.
|-
| ''Operational Planning'' || Very little. Mostly during sprint planning and ad-hoc. || Some. Notes taken, wiki articles, light estimation. || Lots. Burndown charts, wiki articles, heavy estimation, full scrum.
|-
| ''Strategic Planning'' || Little/some. Most ideas are discussed between Etienne and Anthony and are rarely shared. || Lots. Discussion with every team member about designs, architecture, and lots of prototypes. There are always side projects going on meant for the long-term. || Some. There are long-term pushes but they are mostly broken down into smaller chunks. *Note: This is tainted by not having talked with Julien yet.
|-
| ''People'' || Ad-hoc. People work on whatever they are generally best at, when they can. Most of the team was part-time until recently. || Rotating pushes. One person may work on a long-term push like Haidification for a week, then go to blockers. Another person may be working entirely on blockers during that time. || Ad-hoc. People work on whatever they are generally best at.
|}
 
==Similarities==
* People don't find the comms meeting useful and want it to be killed.
* Estimations are generally working well, but are experimental on both other teams.
* Every team wants to know what's working well and what isn't for the other teams (people on both teams asked me).
* People like to know what others are working on.
* A short, daily standup has gotten very good feedback for usefulness.
* Wiki articles helpful for watching progress and retrospectives.
* Nobody is happy with the process of working with UX right now. It's not the UX people, it's just the timezone differences and lack of availability on IRC.
* Both other teams are happy to experiment with new techniques to organize themselves and do so regularly.
 
=Moving Forward=
 
==Long Term Projects==
* Carrie's redesign for sheet navigation.
* General redesign and refactors (a la Haidification).
* Testing CDMA in regions that don't use it, perhaps using the emulator.
* Better support for testing emergency calls without accidentally placing them.
* Moving more towards using HTML template fragments for more realistic testing.
* Clean up keypad and DMTF tones code (blocked partially on platform WebAudio work)
* Clean up USSD/MMI code, add multi-SIM support.
* Improve emulator use and documentation.
 
==Suggestions==
* Make a new #fxos-dialer channel on IRC (done! please join).
* Start having daily meetings. I think we can do this over IRC for a start, but be flexible with it.
* Track planning, progress, and discussions on wiki articles.
* Start estimating during sprint planning.
* Kill the comms meeting (not really in our scope but it's partly our fault that it still happens).
 
==Ideas==
* Do video demos of important new features.
* Be more willing to experiment with things that seem like they create overhead. Be willing to kill them if they're not working.
* Discuss vision for the future of the dialer, including the app itself, the team organization, and how we work.
* Do burndown charts and scrum.

Latest revision as of 17:43, 26 June 2014

Moved to FirefoxOS/Comms/Dialer/Restructure.

Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/Dialer/Restructure&oldid=992809"