|
|
| (3 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
| |
| * Not enough planning, documentation, updates
| |
| * 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===
| |
| * Daily meetings
| |
| ** Over Etherpad (all work) + IRC (major work/questions)
| |
| ** At first started with IRC only, but they found that there was lots of redundancy
| |
| ** This system is working well for them
| |
| ** If you have some kind of question or need help, this is a good time, don't need to ping as much (instead ask questions in a batch)
| |
| * Wiki articles
| |
| ** Mostly helpful for managers, not as much for him (and in his opinion other developers)
| |
| ** He sometimes sees them used to track progress on previously fixed bugs
| |
| ** Used to track how many people working on bugs, for example when people on PTO
| |
| ** When asked directly about burndown charts: the point is not for our developers but for management
| |
| * Sprint planning
| |
| ** Takes too long (1.5 - 2 hrs), needs to be improved
| |
| *** Point estimates are currently taking about half of the time
| |
| *** Considering do estimation offline in free time
| |
| *** Another idea: have people look at bugs on their own, but still do estimates together
| |
| ** Retrospect first
| |
| * Planning
| |
| ** Long way to go here, for example, no metabug for Haida
| |
| ** But there are some clear goals about what next steps to take for long-term projects
| |
| ** Not much thought goes into planning
| |
| ** Some discussion on Etherpads, for example for Haida and DataStore
| |
| ** Need to find some more time to have more detailed discussion here
| |
| *** Biggest roadblock is too many branches at the same time
| |
| * people
| |
| ** When told about how contacts team works: likes it and wants to try rotation system
| |
| ** Would like to have long-term work
| |
| * Awareness of big problems
| |
| ** Haida
| |
| ** DataStore
| |
| * UX relations
| |
| ** Very convenient to chat with Jenny because she sits beside him; no problems here
| |
| ** Some concerns about visual, hard to discuss
| |
| *** Mostly through Bugzilla
| |
| *** Would like to chat on Skype/Vidyo/IRC
| |
| * Being remote
| |
| ** Because there's some overlap between timezones, there's still some time for communication, but not much
| |
| ** Tries to get all work that needs communication done during this overlap
| |
| * Suggestions for dialer
| |
| ** Long-term projects
| |
| *** Separate communications into different apps
| |
| *** Haida
| |
| ** Organization
| |
| *** Should break down schedule and planning
| |
| *** Start working on the wiki pages
| |
| | |
| ==Dialer==
| |
| | |
| ===Etienne (part-time)===
| |
| * General
| |
| ** Agrees there's a problem within dialer
| |
| ** Optimistic about these plans in general and that people are looking into ways to restructure
| |
| * Daily meetings
| |
| ** Ok with coming to daily meetings, not super enthusiastic though
| |
| ** Would like for it to be over IRC
| |
| ** Worried when he sees people saying standups help them get unblocked
| |
| *** Thinks people should be using needinfos/IRC instead
| |
| *** Likes having time to think before responding
| |
| *** (drs/note) I mentioned that we'll be getting more people soon and not everyone is as familiar with the dialer as him, and he agreed that there's value for us there
| |
| * Vision for his role
| |
| ** Work mostly on blockers
| |
| ** Likes working on stuff he actually uses
| |
| ** Feels a bit like dialer is mostly done
| |
| ** Always worked on other stuff, didn't just suddenly decide to move out of dialer
| |
| ** There was an idea within the comms team of people rotating around inside the team but it never happened, he liked this idea
| |
| ** Was owner once most of the features were already done, module ownership came relatively late
| |
| * Estimations (bugs)
| |
| ** Bugs take constant time for him (cool!) so he doesn't think they're worth estimating
| |
| *** Only takes bugs he can repro locally
| |
| *** debug/console.log a bit
| |
| *** make a dirty fix, make a test, make a clean fix
| |
| * Estimations (features)
| |
| ** More valuable to do estimations here than for bugs
| |
| ** We don’t have a lot of practice
| |
| ** No strong opinion
| |
| ** Doesn't believe that feature work can be constant time
| |
| ** Would support it if we did it
| |
| * Wiki articles
| |
| ** management likes having this
| |
| ** Not sure how he would use them
| |
| ** Workflow is very Bugzilla-driven
| |
| ** Would start contributing to dialer docs, has wanted to for a while
| |
| * Sprint planning
| |
| ** Last one went pretty well
| |
| ** Not sure about sprints themselves, planned items are not the majority of his work
| |
| ** Likes treating blockers differently, likes the way contacts team is run
| |
| * Planning
| |
| ** Anthony and Etienne talk about the CSS and how to organize it
| |
| ** Not much planning on other things
| |
| ** The last year, biggest change was DSDS, rushed last minute
| |
| ** No strong opinion on this stuff yet (such as anticipating changes)
| |
| ** Now is first time we got the opportunity to fix stuff properly
| |
| * Long term project ideas
| |
| ** Integration testing
| |
| *** If we get better integration testing, refactors will be easier
| |
| **** ex: if we had tools, we could cover all of CDMA fairly quickly
| |
| *** Mulet (b2g desktop on firefox) inject chrome scripts to mock the telephony api
| |
| **** Implement RIL daemon in JS
| |
| **** Been discouraged on doing this because emulator coming (but waiting a while)
| |
| **** Compromise: stub the ril.js
| |
| * People
| |
| ** No opinion
| |
| ** The way the contacts team is working sounds good
| |
| * UX relations
| |
| ** Getting better
| |
| ** Doesn't need to contact UX a lot for his work
| |
| ** Progress-based meetings would be good instead of scheduled
| |
| *** In system, they have a meeting with UX designer rob where they go through everything they need to talk about
| |
| **** Once every 3 weeks during feature dev, once every week during bug fixing
| |
| * Comms meeting
| |
| ** Getting worse
| |
| ** Wasting time
| |
| ** Wants to kill it
| |
| | |
| ===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 (part-time)===
| |
| * Daily meetings
| |
| ** Too much to have daily meetings, would get distracted from work
| |
| ** Talks directly with people when needed
| |
| ** Not a lot of overlap with other people's work
| |
| ** Works on specific components of dialer that are very self-contained
| |
| * Estimations
| |
| ** His bug take a long time to investigate, hard to estimate because of that
| |
| * Wiki articles
| |
| ** Would like to know more about what others are doing
| |
| ** Has specific components within the dialer and doesn't really see how they fit into the greater picture
| |
| ** Would like to have wiki articles, but raised that they need to be maintained
| |
| * Sprint planning
| |
| ** Last sprint planning session was his first
| |
| ** Thinks it worked ok, good for finding new bugs to work on
| |
| ** Hard to find urgent bugs to work on without this
| |
| * Planning
| |
| ** Doesn't know where the dialer is going
| |
| ** The callscreen took him by surprise, bitrotted some stuff he was working on
| |
| * Awareness of big problems
| |
| ** Would love to participate in fixing big arch problems, long-term projects
| |
| ** Sometimes has time for large refactors, but can't land something or uplift, hard to justify risk
| |
| * Long-term projects and problems
| |
| ** CDMA
| |
| *** Unit tests based on feedback from Taiwan
| |
| *** Write a patch and have someone in Taiwan test it
| |
| *** It worked fairly well but is a bad way to do development
| |
| *** It's well documented now in the Telephony WebIDL file
| |
| *** The emulator has extensive support for CDMA
| |
| *** Also possilble to do development in the emulator
| |
| *** No clue how to run emulator in this way, or with 2 SIMs, or anything like that
| |
| **** Vicamo Yang, Edgar Chen, Yoshi Huang can help here
| |
| ** WAP Push (unrelated to dialer but still nice to know)
| |
| *** Delivers special messages over SMS
| |
| *** Normally from carrier
| |
| *** Can contain links, configuration messages, full text documents with APN, configuration for data connectivity, etc.
| |
| *** Handled by Gecko as system messages
| |
| *** Originally were going to go into Messages app
| |
| *** Now a separate app, closes itself when messages are processed
| |
| *** Apps can't close themselves, so hacks needed to work around this
| |
| *** Lots of vendor-specific stuff
| |
| *** Sent using special software from vendors called NowSMS, we don't have access to this
| |
| *** Race: receive and process a message, then signal to close the app, then receive a message before app closed gets into a weird state
| |
| ** USSD/MMI
| |
| *** Numbers that start with * or #
| |
| *** Network replies with some carrier-specific information
| |
| **** ex: how much credit left, or data traffic left, enable/disable voicemail
| |
| *** Can be transactions
| |
| **** Can get a reply, interact with the reply, etc
| |
| **** Very hacky
| |
| **** Designed for single-SIM
| |
| **** UI uses window.postMessage, makes testing difficult, uses setTimeouts
| |
| *** Biggest issues: needs multi-SIM support, needs better testing
| |
| *** Special function for sending telephony.sendMMI function
| |
| **** Should use normal telephony.dial function
| |
| *** Hacks depending on the network
| |
| *** Whitelist of codes reimplemented on CDMA (normally for GSM) even though it doesn't really have it (we simulate them)
| |
| **** Covered well by unit testing
| |
| *** Biggest issues:
| |
| **** Needs multi-SIM support
| |
| **** Needs better testing
| |
| **** Replies can be mixed up
| |
| ***** 1. You send a message
| |
| ***** 2. Get an event reply on that connection
| |
| ***** 3. System message (unrelated) triggered when you get a response
| |
| ****** Juggling both is not easy
| |
| ****** What we do: ignore the connection events
| |
| ****** Only set an event handler for system events
| |
| ****** In there we try to figure out if it was solicited or not
| |
| ** DTMF tones
| |
| *** Used by answering machines, for example, to see what number was pressed
| |
| *** The keypad code is not very nice
| |
| **** More than 50 numbers breaks down our logic for example
| |
| **** Swiping fingers over the keypad doesn't work very well
| |
| *** When user hits a button, we play the sound for that number and send over network at the same time
| |
| **** Sound is very glitchy on first play due to WebAudio blugs
| |
| **** Was a certification blocker
| |
| **** Plastered with workarounds, 2 separate hacks in keypad, should be as simple as playing a sound
| |
| | |
| ===Germán===
| |
| * General
| |
| ** Agrees mostly with Etienne
| |
| ** Agrees we need more organization within dialer app
| |
| ** Need to refine the way choose bugs and prioritize what's important and what should be delayed
| |
| *** This should be coming from product management, not necessarily our responsibility
| |
| ** Has some idea what other people are doing, but not in detail, doesn't want to know very specific details, but would like more information
| |
| ** Generally doesn't like being put on the spot
| |
| * History (I asked because I didn't know, also helpful for scaling to include more partners)
| |
| ** Initially in Telefonica they were trying to do something similar to Mozilla
| |
| ** They knew about each other's initiatives, started working together
| |
| ** He is basically assigned completely to Firefox OS
| |
| * Daily meetings
| |
| ** Hard to recall what he did the day before
| |
| ** Useful to know what other people are doing
| |
| ** Wants to have daily meetings
| |
| ** When I mentioned the way messages works with Etherpad+IRC: likes it
| |
| ** Would help him get unblocked
| |
| * Estimations
| |
| ** Hard to make
| |
| *** Example: facing Travis issues recently which are hard to take into account
| |
| ** Not very useful for the work itself
| |
| ** Helpful to at least organize each person’s work
| |
| ** Would be in favor of trying
| |
| * Wiki articles
| |
| ** Completely supports it
| |
| ** Wanted to find some up to date information about API, looks at MDN, but it's out of date, so contacts Etienne instead
| |
| ** Would read other people's entries, likes that he can choose the time
| |
| ** Would participate in editing and maintaining wiki articles if others were as well
| |
| * Sprint planning
| |
| ** Would like to have more involvement from product management for help with prioritizing
| |
| ** They're useful, especially the smaller ones before the main one
| |
| ** Also useful for knowing what other people will be doing
| |
| ** More support tools for sprint planning, for example at Telefonica use JIRA, which provides more information about what they're doing, better organize the work
| |
| *** Bugzilla is good, but more specific tools would be helpful
| |
| *** Ex: Anthony was working on Kanban dashboard
| |
| *** Would like to see, in realtime, what everyone is working on, if bugs are blocked, more detailed status of bugs
| |
| * Planning
| |
| ** Dialer has been pretty stable, no real new goals
| |
| ** Misses having a roadmap
| |
| ** Thinks it's a problem that we don't have these high-level goals
| |
| ** From "Long-Term Projects" (so far)
| |
| *** Was only aware of "Separate communications apps into different apps."
| |
| *** Heard of Carrie’s redesign but not much of the rest
| |
| * Challenges working for Telefonica with Mozilla people
| |
| ** Very proud to work with Mozilla
| |
| ** Trying to inherit many of our ways of doing things
| |
| *** Not being too formal like Telefonica is
| |
| *** Let people do things instead of telling people exactly what to do; trust them
| |
| * People
| |
| ** Likes the way the contacts team works
| |
| ** Having everyone involved in long-term tasks is good, everyone feels ownership
| |
| * UX relations
| |
| ** Really good, direct connection with Vicky, Paolo, Paco (VD)
| |
| ** Most of the Telefonica UX/VD team is in Barcelona
| |
| ** Likes our relations with UX
| |
| * Suggestions for dialer
| |
| ** Tools to manage work, for example trello.com (he uses this himself)
| |
| | |
| =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 generally like to know what others are working on.
| |
| * A short, daily standup has gotten very good feedback for usefulness. Nobody who is currently doing it wants to end it or make serious changes.
| |
| * Wiki articles helpful for watching progress and retrospectives. Having them makes managers happy. Mixed reports for engineers.
| |
| * Nobody is happy with the process of working with UX or VD right now. It's not the UX/VD people, it's just the timezone differences and lack of availability on IRC. It would also be nice to be able to chat with them periodically over Vidyo.
| |
| * 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.
| |
| * Separate communications apps into different apps.
| |
| | |
| ==Potential Action Items==
| |
| * 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. Clean up general docs on dialer.
| |
| * Start estimating during sprint planning.
| |
| * Kill the comms meeting (not really in our scope but it's partly our fault that it still happens).
| |
| * Begin setting aside time for long-term projects.
| |
| | |
| ==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.
| |