[Python-ideas] Iterative development

[anatoly techtonik]

On Thu, Jan 30, 2014 at 4:40 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Jan 31, 2014 at 12:25 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Single dev hour is ok if you reached your goal. That's the point.
>> You set the goals - you reach them. If you didn't reach them - you
>> analyze and see what could be done better. It is all in relaxing and
>> free manner, unlike the bloody corporation culture. You may invite
>> other people to join the fun. People can find what are you working
>> on and propose help.
>>
>> This is the process.
>
> Let's say you pick up something that's going to turn out to take you
> three dev hours. You then put one hour of work into it, and the
> two-week cut-off rolls around. What do you do?

It *not cut-off*. It is *sync*.

So, what do you do when two-week sync rolls around..

You list the status, say what was the problem with completing as you're
planned, say if you need help, if there is something that could have
helped to avoid hurdles you had that led to divergence from the plan, and
you also communicate your vision about chances of this particular thing
to see the light in the next two weeks.

> In the current model, there is no cut-off, so you just keep your work
> where it is until you find the time to finish it. Then you format it
> as a patch, put it on the tracker issue, and move on. (Or, if you're a
> core dev, I suppose you push it, see if the buildbots start looking
> red and angry, and then move on. Either way.) It doesn't matter if
> that took you one day, two weeks, or three months.

It doesn't matter for you, because you work alone. But it still does worth
for other people, so if you run out of time and have a clear understanding
that over next three months you won't be able to work on this feature, and
you've made it clear during sync, you at least can enable others to look
into this problem and hack it for you, or you can *freeze* it properly with
all work-in-the-process that is necessary for someone to pick it up later.

> What you're suggesting is that people should conform to an arbitrary
> number-of-days cutoff. That means that if the cut-off is getting
> close, there's a *dis*incentive to pick up any job, because you won't
> be able to finish it.

There are *jobs*, yes. People choose what to do from existing backlog
sorted by some criteria (wishes?) or may develop their own idea. But..
That doesn't mean they should *finish* the job in this time period. Jobs
could be split into tasks for synchronization between people, and you
are free to make the task that you *will* be able to complete in the time
span that you've given. It is your own challenge. *research*, *triage*,
*make a writeup* are all tasks that are not directly related to a problem,
but if they yield some results for others to sync with, they worth to be
mentioned.

In my practice this sort of question came from people who undergo
formal Scrum training and was told that at the end of each iteration you
should deliver a complete feature set that was planned with all
documentation and related materials. This keeps people motivated to
complete the hard things. But Agile doesn't place this restriction - it is
flexible to choose what you want to deliver at the end. The main benefit
from the iterative process is that when people start to make goals that
are public to everyone else, and then these goals fail, it is possible to
make the analysis about the process - how to save time and make the
whole collaboration stuff more fun.

> Imagine if, when writing up a post for the
> mailing list, you had to finish each sentence inside one minute as per
> the clock. If it's currently showing hh:mm:49, you'd do better to not
> start a sentence, because you probably can't finish it in eleven
> seconds. Is that an advantage over "just write what you like, when you
> like"?

The advantage is that if I set a goal to reply to this thread in two weeks,
I have better chances to finally find the time to do this in two weeks.