Despite protestations to the contrary, nobody--certainly not I--would advocate that you don't need to communicate what needs to be implemented. It's a question of how it is done, and traditional func specs are but one, very poor (IMO) way to do so.
On Mon, Oct 19, 2009 at 4:12 AM, paul bryan <[email protected]> wrote: > I think the > dimension that segments the responders is the degree to which the > people writing the code are separated from decisions about design, in > a physical distance, process, or organizational sense. > This can be true, but Scott Ambler<http://www.ambysoft.com/onlineWritings.html>has been researching, thinking about, and writing about the different contexts in which Agile plays, and specifically distributed and large teams via his agil...@scale blog<https://www.ibm.com/developerworks/mydeveloperworks/blogs/roller-ui/rendering/feed/ambler/entries/atom>. His thinking on docs in general<http://www.agilemodeling.com/essays/agileDocumentation.htm#CriticalPoints>is good, and he specifically cautions against hand-offs<http://www.agilemodeling.com/essays/agileDocumentation.htm#EffectiveDocumentationHandoffs>. I'm not saying he's the end all authority or best guy for software process in general, but he's probably the most prolific, well-researched, and balanced speaker and writer on the subject of Agile. Point is that not wanting to do func specs doesn't have to be related to the elements you mention. Nor would I hold up Agile as the end all in terms of the way to make software, either, but there can be a lot of synergy in terms of aspirations between it and UX/XD/IxD. In the last few years, it seems that the UX/XD/IxD world has crossed a threshold where Agile is now more assumed than less; I think people are seeing <http://www.agileexperiencedesign.org/> the synergy and, if nothing else, the reality that Agile (broadly speaking) is where most of software dev is these days. I suspect as in-house/FTE UX/XD/IxD competency becomes more and more common, this trend will only continue because hand offs necessitated by consultancy will decline. Anyways, I think the difference between doing traditional func specs and other docs lies more in familiarity and comfort zones. We have quite a heritage of functional specs in software, and people are loath to change, even though the software industry at large has been going that way for over a decade. I should maybe be clearer that I'm talking about "functional specifications" in the traditional sense of function-centric, often componentized, functional descriptions of what the *system shall do*. I think even traditional use case diagrams and use case scenarios are not ideal, even though they're at least trying to focus on use rather than just system functions. The problem is that usually they're still function/system-centric and the user is this amorphous "actor" who is basically just there to serve as an external entity that is acting on the system--the centricity is still systemic and functional when it should be on the people and purpose of the software. And they are only marginally better at helping normal people grasp what the end product will be like. When I think, talk, and write about how to do software, I'm pretty passionate about it and am concerned, in a forum like this, about the *best*way to do software. That means in some ideal world somewhere, but best practices always have to be contextualized. The thing is, there are better alternatives to func specs even in the most distributed and diverse teams; I can't imagine a scenario where they're better than alternatives except in the case that people just don't want to change or just don't know any better. That's why I was rather hyperbolic in my previous reply--to make a point. -a ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
