Jenk wrote:but for 4+5, everyone should be involved - juniors may be juniors, but they'll still be able to provide valuable contributions to any design and/or discussions - if for nothing more than their own gain
I agree, what I really meant by that comment though, is don't leave those choices exclusively to the inexperienced (which is common practice).
Jenk wrote:For 9, try to use documentation tools like phpDoc and documentation really does become minimal, if any at all
I disagree. Proper documentation takes time and a certain skillset (hence the asking someone who enjoys it first - yields higher quality docs). Relying soley on phpDocumentor is not usually enough for any project beyond hell world.
Compare the MSDN with even PHP and the clear winner hands down is M$. Yea PHP is sufficient (once your up to speed) but MSDN really shines in this area. The point it, docs are usually more than just functional comments or module level comments. Programmers often get writers block, especially while switching from logic mode to english mode and back again.
Jenk wrote:Also for 7.. try to emphasise that everyone looks after their own "mess." No one likes Janitorial duties, so remind everyone to keep check on their own "mess."
I want to work with your teams then.

You can preach this as much as you like but people still get lazy, having a routine "cleanup" time really helps in my experience. Personally I can take a Sunday off to spend a couple hours cleaning code, no problems.
Jenk wrote:Gantt charts and timelines are a no-no. SCRUM (Agile) all the way baby.
I disagree. For the most part your "stakeholders" will not be Ron Jefferies or Kent Beck and they will want some kind of deadline. This is where I differ slightly from an "Agile-ist" - while I agree with most principles. Keeping a Gantt updated isn't really alot of work if your experienced at project estimation. I never suggested it would dictate your project from start to finish right from square one, but rather it evolves with the development process.
Sure you hammer out some ideas before development, as even Agile suggests some fore-thought. I can crank out an API for an object in 15 minutes or less so a couple hours of planning (sketching the GUI, discovering objects, estimating atomic delivery times) can easily be entered into a project mangment program and give you some ongoing idea as to where you stand in the SDLC (helpful to stakeholders and Agile managers). It helps you refine your estimating abiilities as a project manager in my experience.
CoderGoblin wrote:For coding documentation phpDoc/unit tests are usually sufficient.
If your the sole developer and the only person going to use the source code, that maybe true. When you work on a real project with other real people, expecting them to rely on tests and API docs alone will almost *always* make the learning curve greater than it needs to be. This is epcially true if the architecture isn't a qualified/standard implementation of MVC - which in PHP applications is usually the case.
CodeGoblin wrote:I also agree a basic prototype is needed as the first thing. Just getting a client to agree on "this page will do this and move to that page" can often be a major step forward. The requirements often change drastically during this stage.
While I agree, that isn't what I was refering to, but instead I meant the object interface (not the user interface). Test infected people advocate that you hammer the API out then write tests immediately. I disagree because the API cannot be fully known without some prototype or proof of concept. Once the object has been normalized (DBA term but for objects) then I write tests and re-implement/refactor the implementation to do as expected.
In steps Agile/SCRUM.. you have a member of the client team working with you. By with you, I mean sat in the same area as your team developing along side you
You know what tickles me pink about this community and it's zeal for Agile, XP and design patterns. These books are written by industry veterans who work on million/multi-million dollar projects which are beyond most of us, so many of those principles or best practices are merely meant to be suggestions.
I highly DOUGHT that any of us here work on anything close to that magnitude, so this is where I define myself as a "Versatile" software developer. Meaning I have enough insight to make my own decisions based on my environment.
Expecting to have a stakeholder or end user available to you while developing in a small scale, is highly unlikely. Most small/medium businesses simply do not have the resources or people available to borrow one to you for more than an hour or so a week.
Likewise, team programming, while I can see it being effective, simply isn't realistic on small/medium business budgets.
It's about adapting rather than controlling. "Process Control" involves all the timescales, deadlines, defined requirements etc. etc. but in reality that can be VERY hard work to maintain, and very hard to enjoy! Agile and SCRUM are about a real-world attitude to working - you start working and adapt when the need arises
EXACTLY. So the steps I offered reflect my experience and my environments, not yours. Instead of focusing or suggesting corrections in my own, would it not have been easier to just state your own perspective in a point by point basis?
jayshields wrote:It's specifically aimed at projects which have to stick to a time line though. If you have no time line, then I agree Agile development is a better way to tackle project management.
No timelines??? haha...have you seriously ever worked on a project where the stakeholder said:
"Go ahead take as long as you want?" I think you have misinterpreted Agile/XP.
Jenk wrote:That's the whole purpose of Agile.. there is no deadline
Haha. Read my last reply to
jayshields
You guys seriously need to hook me up with a job where you guys work.

No deadlines, no pressure...talk about job security.
While it's common knowledge in the development community, that the one constant in software development is change itself, this is usually easy to convince stakeholders of too. The problem is, deadlines are absolutely required. What book on Agile or XP did you read where it suggests no estimation or project deadlines? How is a business supposed to budget with no time estimate? Agile might not require a hardened deadline, but you have a deadline, it's just more flexible.
The books I've read on the subject (plus countless articles) suggest not that there is "NO" deadline, but rather, "getting real" which you are clearly not IMHO. Getting real is reducing waste and following KISS principles. That means developing only what is required and growing with that, rather than trying to get everything spot on first round.
Many developers try and hammer out the perfect API on the first go, Agile suggests just developing what is needed for that given time and thats it. XP advocates refactoring and refactoring often.
Team programming, for instance, although effective i'm sure, isn't "Agile" if there are only 3-5 developers in the company. This is where I always felt the they kinda contradict themselves. Keeping things simple, keeping things small (in terms of team size) and yet pairing when there are only a handful of developers. I'm personally not convinced pair programming is a best practice or something I would employ in my business model.
timvw wrote:In my experience there are just too many businesses out there that first sign a multibillion contract and then assign IT to deliver a solution, with a FIXED delivery date, which is far from agile
Hook me up wth a job...
Cheers
