[teampractices] Towards more holistic product/feature development

[Chris Steipp]

Thanks for bringing this up Diederik. It's become a popular trend in secure
development to define security requirements as non-functional requirements,
so working to get those into the standard wmf scrum process would be
helpful.

I feel like for security, Platform has been asked to just sign off on
security at the very end, which has lead to long delays waiting for reviews
(yup, limn is still on my list..), and the end result has, at least in one
case, been a total rewrite. And then months later I'm finding security bugs
in code that went in after my review... it's really hasn't been a great
model, although it's getting us by.

I've been thinking about this general problem for the last few months as a
result of some of the issues I've seen come up. Ideally, I'd love to see at
least one person on each team who has some extra security training, so they
can advocate for these requirements, sign-off on the basic stuff, and
escalate any issues / decisions that are more complex to the right person
(me for MediaWiki issues, someone in ops for systems or third-party
software use, etc). If that sounds like a good direction, I'm more than
happy to make the time to try and make that happen for security (after
OAuth is done).




On Sun, Sep 22, 2013 at 9:28 PM, Diederik van Liere <dvanliere at wikimedia.org
> wrote:

> Heya,
>
> Some recent discussions on different internal mailing lists seem to
> indicate to me that we need to think about a more holistic approach to our
> product development. In my mind, the following discussion threads point all
> in the same direction:
> 1) Faidon -- Site issues, past two weeks & in progress (Ops list)
> 2) Erik -- Scrum of Scrums (Team practises list)
> 3) Tomasz - The Rule of Three (Team practises list)
>
> One of the challenges that we face as we are adopting the scrum
> methodology is how we cope with 'non-functional requirements' [0]. Within
> the scrum methodology there is not a clear advocate for these
> non-functional requirements. I do not think that we have found yet a
> systematic solution for this problem. We are obviously not operating at a
> startup-scale so we must take non-functional requirements into
> consideration from the inception of a new feature/product.
>
> One of the mistakes that the Analytics team made last year is that we
> focused too much on non-functional requirements and not enough on
> functional requirements. I think we are striking now a much better balance
> between these two set of requirements. In the area of non-functional
> requirements, the Analytics team has made two changes to how it's using the
> scrum methodology:
> 1) We treat non-functional requirements as functional requirements and
> have the customer sign it off. For example, with our recent collaboration
> with Ops on developing varnishkafka we explicitly defined minimum
> performance in terms of processing speed of messages per second.
> 2) At the epic [1] level, we define both 'business value' (why does the
> customer care about this feature) and 'platform capability' (how does this
> epic contributes to building out our total offering of solutions and we do
> not accrue technical debt along the way). This forces us to consider
> non-functional requirements from the get-go.
>
> I can imagine that in the near-future, we will have to consider more
> non-functional requirements besides (for example) scalability and security.
> The following three come to mind (and sometimes we are already considering
> them on an individual product basis and this list will evolve):
> 1) Mobile -- all products / features will work on mobile from the very
> first beta launch
> 2) Measurability -- measuring the efficacy of the feature and how to
> instrument it
> 3) Privacy by Design -- what data is stored and how can the person whose
> data we store manage this data
>
> How to manage these non-functional requirements is an open question. Scrum
> subscribes to the view that the architecture is emergent but I am not
> convinced that is going to work well for us. I think we need a more
> holistic approach to discuss such requirements -- maybe we should treat
> Ops, Platform, Mobile and Analytics as the 'customers' for such
> non-functional requirements. It's not 100% scrum but then again scrum
> always emphasizes communication over process ;)
>
> Curious to hear what other folks are thinking about this!
>
> Best,
>
> D
>
> [0] BTW, I believe that non-functional requirements are a misnomer; I
> think that architectural requirement would be a better term.
> [1] The Analytics team defines an epic as a high level function that
> consists of either conceptually related user stories (End-to-End monitoring
> for different products) or a complex new feature 'Cohort Management' for
> Wikimetrics.
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130923/f32c2dce/attachment.html>