+1 to autonomous, cross-functional teams. In my experience, they work very well because everyone is focused on the same goal (or limited number of goals) and because they are cross-functional, the teams tend to get blocked less often by needing deliverables from other groups. Another benefit I've seen in autonomous, cross-functional teams is they tend to promote a camaraderie that also improves efficiency.
-Russ On Fri, Nov 20, 2015 at 4:01 AM, Benjamin Francis <[email protected]> wrote: > On 20 November 2015 at 10:18, Vivien Nicolas <[email protected]> wrote: > >> >> Having a dedicated set of people that works on it, is definitively part >> of the plan that nobody knows but is the companion of the new architecture >> proposal: Architecture Transition Plan >> <https://wiki.mozilla.org/Gaia/Architecture_Transition_Proposal#Toolkit_Team> >> > > Wow, thanks for sharing this. > > Firstly, I really love the fundamental principle of the new architecture > to split the web apps into a REST API and a front end. This separation of > concerns is well established good practice in web development. Service > Workers will give us the magic we need to make this work offline. I also > really love the idea that the apps that make up Gaia become real web apps > with real URLs on the web which can be updated independently of Gonk and > Gecko using the web's built in update mechanism, not reliant on giant OTA > updates. This is the way of the web. I also agree that Web Components are > complimentary to this architecture and are solving a different problem. > > On the transition plan, I think the front end/back end split makes perfect > sense from a technical point of view, but I'm very concerned about the idea > of reorganising our 100+ person team into a front end team, back end teams > and a toolkit team. This organisational structure seems like it would be a > nightmare for our EPMs as virtually every single feature we develop would > have cross-team dependencies. Cross-team dependencies kill our > productivity, especially given the distributed nature of our teams across > timezones. It's bad enough having Gecko dependencies for Gaia > features,representing another level of architectural abstraction in our > organisational structure seems like a recipe for not moving anywhere fast. > > Let me give you an example of a user story, "As a user I want to create a > playlist of songs". Implementing this feature would require an addition to > the API (media back end team) and also an addition to the UI (front end > team). The front end team now has dependencies on the back end team and has > to file user stories in their backlog like "As a Gaia developer I want to > add a playlist", "As a Gaia developer I want to remove a playlist", "As a > Gaia developer I want to add a song to a playlist" etc. Now imagine this > new UI requires a new or modified web component - the front end team has a > dependency on the Toolkit team. Now imagine it requires some platform > support for streaming M3U playlists, the back end team now has a dependency > of Gecko. All these pieces have to be implemented by all of these separate > teams in their separate timezones with clearly defined interfaces for one > feature to be completed. Then Product or UX change the requirements > (inevitable) and the whole process has to start again! > > I think the new architecture does give us an opportunity to make a change > to the way we manage our teams. It gives us the freedom to create even more > autonomous cross-functional teams like the media team, productivity team > and communications team who have less dependencies on the wider project and > can move fast to deliver updates on their own timescale. Whilst I agree > with the front end/back end split and shared components, I think directly > mapping the architecture onto our organisational structure is maybe a bit > simplistic and could be a recipe for disaster. My view is that what we need > is agile, autonomous, cross-functional teams who specialist in one product > area. We probably need the existing specialists in those apps to carry out > the front end/back end split in the first place anyway. I wouldn't have a > clue how to create a front end or back end for our music app, but the media > team does. > > One other more technical comment is that one part of the architecture I > don't understand is why our "back end" pieces and our "data sync" service > are not the same thing. Wouldn't web apps usually work by having a > server-side REST API where all the data is stored, then multiple front ends > on different form factors which talk to that API and cache data on the > client? Why are we creating a web API which stores its data locally then > syncs via a separate service? Is that just applying native Firefox app > development thinking to web development? > > BTW, thanks for having this discussion in the open :) > > Ben > > > <https://lists.mozilla.org/listinfo/dev-fxos> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
