[bind10-dev] Sprint Planning Meetings on 30 Nov/1 Dec

[JINMEI Tatuya / 神明達哉]

At Tue, 30 Nov 2010 14:31:36 +0000,
Stephen Morris <stephen at isc.org> wrote:
 
> Just to remind you that the R-team meeting is today (Tuesday 30
> November) and the A-Team Meeting tomorrow (Wednesday 1 December),
> both at 15:00 UTC.
> 
> The agenda will be:

The following is a memo of my thought for the agenda.  I have a sore
throat today and would like to avoid speaking as much as possible:-)

> Review
> 1. What have we achieved in past 6-week release cycle?

In short, partially complete in memory data source and related stuff,
partially complete TSIG related stuff, and partially complete
outstanding reviews.

> 2. Review of Sprint process
>    - What went right?

To me, frankly, it didn't go right in that we couldn't include any
runnable feature (or sub-story) in trunk; everything is partial.  On
the other hand, since this is our initial trial, getting the lessons
is probably the "right" thing.

>    - What can we do better in the next cycle?

We first need to recognize the A-team is much smaller than originally
considered, and, unless we can rebalance the team size, we should
recognize the A-team can only do a limited set of work items.  And,
A-team won't be an "anything" team any more (as shown in
http://bind10.isc.org/wiki/ATeamSprintPlanning)

Recalling the lessons we've had in the initial release cycle, and
reading some materials about agile-ness, I think what we should
specifically improve next is the following two things:
  - story size
  - task size

Our "story" is too big (I forgot the exact sentence and couldn't find
the original spreadsheet, but it was something like "I want to get
faster qps" and its consequence is having an in memory data source.
This is too big even for one release cycle.  But what we actually
needed is a small sub stories that can be completed in a single sprint
(two weeks).

Likewise, as we all knew, our tasks are too big.  According to agile
materials a single task should be completed within a day or two; ours
took weeks.  The large size of tasks also makes review harder, and
makes a bad spiral of slower integration.

So, in the next release cycle,
- we should first agree on a mid-size story (or stories if we think we
  can do more than one) that can be completed within the cycle
- divide that story into several small stories that can be completed
  within a single sprint
- then break down each small story into small tasks each of which can
  be done in a day or two (including documentation, and of course
  tests because it should be TDD).  These tasks should be integrated
  (with review) by the end of the sprint.

This way, (ideally) we can see workable small features in trunk at the
end of each sprint, and we can include the mid size story (which
should be meaningful to some extent for end users) in the next tar
ball.

> Planning

Based on the above thought, my gut feeling is:

> 1. Schedule for the next release cycle
> 2. High-Level aims for the next release cycle

The mid size story is "be able to load textual zone file(s) into
memory, and be able to respond to queries to these zones" (no DNSSEC
support, no zone transfer, no dynamic update, no reload).  This may be
too conservative, and perhaps we can do a bit more.

And (examples of) small stories would be:
 - load a normalized zone file into memory and simply return an
   authoritative answer (no NXDOMAIN or NXRRSET, delegation, no
   additional section)
 - on top of that, additional section processing for MX
 - on top of that, support delegation with additional section
 - support negative answers
 - support CNAME matching
 - support DNAME matching
 - support wildcard matching
 - support type ANY query
 - support various forms of unusual zone files (redundant RRs,
   inconsistent TTLs, etc)
 - support validation of the zone (checking NS, additional AAAA/A,
   etc)

With this plan, we initially don't even need a smart RBT.  An STL
container with exact match suffice, and on the other hand we should
first write a simple zone file parser.

> 3. Task Selection
> 4. Task Estimation

---
JINMEI, Tatuya