esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Pollak" <feeder.of.the.be...@gmail.com>
Subject Re: The ESME to-do list
Date Tue, 16 Dec 2008 17:22:29 GMT
On Tue, Dec 16, 2008 at 6:46 AM, Vassil Dichev <vdichev@gmail.com> wrote:

> Hello all,
>
> There are a couple of things I wanted to address:
>
> * How would we go about implementing the changes from the to-do list:
> which are better developed in a separate branch and which in trunk?


Right now, I expect that the trunk is going to be unstable for the next 1-2
months.  I'd vote for doing stuff on trunk.


>
> David also mentioned git, should we use that for experimentation?


Bi-directional git <-> svn doesn't work well.  Apache is an SVN shop and I
think that's what we should use.


>
>
> * Regarding timeline: maybe we should first specify which are the
> priority tasks and then it would be easier to follow with timelines.
> I'm OK with not being able to stick to a timeline strictly, that
> doesn't mean we shouldn't try to make one.


It's going to be at least 6 months until we figure out what the cadence of
the team is.  I suggest that we have 3 or 4 week iterations starting on
January 5.  We'll do an iteration planning meeting on the 5th or 6th and see
how many points we consume for the first few iterations.  Over time, we'll
get a sense of how many points each team consumes and we'll get more
feedback from end users (I'd like to figure out how Dick and other end users
fit into the planning and iteration structure.)  After 6-8 sprints, we'll
have some averages of number of points consumed and that'll give us some
ability to project into the future.


>
>
> * Regarding the development process: scrum is great, but might not
> work so well when the group is distributed around the world time
> zones, and it only scales insofar as the ability to split work to
> small teams. Any ideas on a process we could use and preferred method
> of communication to consolidate changes- besides ESME itself, of
> course ;-) ?


We have scrum calls, be we're not really using scrum.  We don't have formal
iterations, etc.  I think we need to get up on the scrum horse and use the
various scrum tools.  Also, I expect that we'll have 4 or 5 2-4 person teams
working on different parts of the code.  Each of these teams can figure out
how to do periodic check-ins.


>
>
> * Regarding the target group: maybe it's a good idea to target ESME
> not exclusively to enterprise users. People have different ideas about
> what can be useful to them, maybe they find ESME's features
> appropriate for use outside of the corporate environment. Who knows
> what will come out of that...


We have limited resources.  Focusing on our core market and our core users
will allow us to be excellent and make them jumping up and down happy.
Making sure we don't box ourselves in is something we need to keep in mind,
but, barring some consumer company coming and paying to have certain
features added to ESME, I expect that we're going to focus on what makes
Siemens, SAP and Colgate-Palmolive happy.

On a broader note, I think we need to balance vision, strategy and
backbone.  The vision is the innovation that goes beyond what our customers
are asking for.  The strategy is the part the makes sure that we're not
foreclosing the future, and backbone is the strength to make it happen.

Thanks,

David


>
>
> > Yes. Oops. That was a result of quick typing and a brain half asleep.
>
> Err, talk about quick typing, this is not exactly what I meant either:
> "I think I'm the only one who hasn't seen anyone of the team in
> person, and I owe this in a significant part to micro-messaging.". I
> meant to say that *despite* the fact I haven't met any of you, I got
> in touch with you and we are able to work together- thanks to
> micro-messaging (in this case, Twitter).
>
> Best Regards,
> Vassil
>



-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message