<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 22, 2013 at 9:28 PM, Diederik van Liere <span dir="ltr"><<a href="mailto:dvanliere@wikimedia.org" target="_blank">dvanliere@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Heya,<br><div><br>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:<br>

1) Faidon -- Site issues, past two weeks & in progress (Ops list)<br>2) Erik -- Scrum of Scrums (Team practises list)<br>3) Tomasz - The Rule of Three (Team practises list)<br><br>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. <br>

<br>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:<br>

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. <br>

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. <br>

<br>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):<br>

1) Mobile -- all products / features will work on mobile from the very first beta launch<br>2) Measurability -- measuring the efficacy of the feature and how to instrument it<br>3) Privacy by Design -- what data is stored and how can the person whose data we store manage this data<br>

<br>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 ;)<br>

<br>Curious to hear what other folks are thinking about this!<br><br>Best,<br><br>D<br><br>[0] BTW, I believe that non-functional requirements are a misnomer; I think that architectural requirement would be a better term. <br>

[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. <br>

</div></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>