RE: [UG-ADMINS] Project Planning

Hi Tim,

I don't have many answers, but here is some food for thought:

-- there is no one no good way, so it's really about flexibility in a project

-- business people don't get development, so flexibility is even more important

-- that said, there are some generally accepted best practices that will not be contentious amongst developers, project managers, etc.

-- The fundamental concepts are important to discuss - I'd start a discussion on the mailing list, have someone organize and record the various comments, and then put together bullet points outlining the fundamental topics/concepts

-- present this to the list, ask for speakers, and perhaps have a panel style discussion at the meeting

-- put resources online for future reference.  this is akin to our PHundamentals which was hugely successful, although getting a bit dated because of lack of time


And from my personal experience:

-- only large, rich corporations have the resources to dedicate the right amount of time to discovery and specification - and even then sometimes they don't want to

-- most gigs are about agility; even if the business person says he knows what he wants, he doesn't.  So be clear with him that it's going to be an iterative development cycle, with give and take on both sides

-- what this really means:  always do a day or hourly rate - never a fixed bid :)


---
Hans Zaunere / Managing Member / New York PHP
      www.nyphp.org  /  www.nyphp.com





> -----Original Message-----
> From: Tim Stiles [mailto:[email protected]]
> Sent: Wednesday, September 24, 2008 12:09 AM
> To: [email protected]
> Subject: [UG-ADMINS] Project Planning
>
> A year ago we held a session on teamwork tools, communication methods
> to use when either working in a team multiple developers (something
> fairly rare among most local PHP devs, who have been historically
> freelancers), or tools that can be used to keep track of goals and
> progress when your project is too large to keep entirely in hour head
> at one time (inspired by a blog post from Paul Graham).  We discussed
> outliners, UML tools, some great document editors, work ticketing and
> production tools.  We also regularly bring up version control and
> working in dedicated development environments.
>
> What I really wanted to get into was to get into the actual planning
> of large applications, but with so many different schools of thought
> about how much planning to do before you code (and never really
> having had the luxury of enough time to do as much planning as I've
> wanted to), I wasn't sure how to structure it.  What I didn't want
> was "Here's a problem and here's how I solved it".  I want an honest
> to goodness discussion on planning large projects, because we have
> some extremely smart guys in the group and there are many things at
> which I suck, whereas they are very good at them.  No one has the
> time for a user-group open source project, but I think we could get a
> pretty good planning discussion crammed into available time, and I
> want to know what our members worry about before they start coding.
>
> We've had a couple of discussions on frameworks/MVC since then which
> might make a planning discussion easier, but it could limit the
> discussion at the same time (and while the discussions of frameworks
> are always civil, there are aspects of holy wars to them which could
> flare up once you get off of  theory and start talking actual
> implementation)
>
> I've been thinking about simply showing up and asking the room "So,
> how would you define, plan and construct software to operate, say, a
> multi-person blog?" and try to point out specific architectural,
> performance and scale concerns as they come up.  Barely even try to
> control the direction.  Record the all the ideas on a virtual
> whiteboard/outliner, maybe even a local wiki, if possible, so that
> anyone with a notebook can jump in to help.
>
> Do you think we could get far enough into such a discussion to be
> worthwhile?  To reach a reasonable stopping point?  Do you have any
> other ideas or suggestions of how to tackle large issues like
> architecture and planning concerns without overly relying on a
> specific school of thought or programming theory?
>
> Tim Stiles,
> Co-Organizer, DallasPHP
> WatchMaker, Icomex.com
>
>
>
>
> --
> Usergroup Coordination Mailing List (http://ug.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php