Gerhard Fiedler wrote: > Vitaliy wrote: > > >> "Gerhard Fiedler" wrote: >> >>>>> "Every project is different. What works for one project may not >>>>> work for another project. What doesn't work for one project may >>>>> work for another project. There are no rules, you must adapt." >>>>> >>> This is a good rule. It means we need to pay attention, even when >>> using Agile-approved methods. It means we need to pay attention to >>> the conditions and results. It means we need to pay attention where >>> we start making compromises, not because something better suited >>> would not be available, but because what's available is not a >>> "recognized technique" by whatever authority. >>> >> What are you attacking with this, Gerhard? >> > > Nothing. I'm agreeing with (and expanding on) what Rolf wrote. Is this > an attack on anything? Didn't you start all this because (and this is > again quoting from memory) you wanted to hear what we think is > important? Here you have (some of) it. I happen to think that this is > more important than to know whether or not a given technique is > Agile-compliant. > > [ Whole bunch of fascinating stuff snipped..... ] > > Gerhard > Oh, holy cow batman. Thanks Gerhard. Your post inspired me to read that website. I could hardly believe that all those things you quoted were the Agile 'mantra'. They sound like things written by poor advertising agencies. So, some quick responses to Agile development now that I have spent (a little) time reading up on it.... in response to the 13 "Best practices of AMDD" 1. Active Stakeholder Participation - Our company has many clients (hundreds) that all purchase and use the same software.... now what? Our development happens in 8 countries and our clients are in many language regions (from Colombia to Japan). Again, now what? "Active Stakeholder Participation" using "Inclusive tools and techniques". OK, I go to client meetings on occasion, and we have whiteboards, but I don't think I can take a ball of string to my next meeting at Citibank. Then again, we have whole teams of people who communicate regularly with clients and determine the 'functionality voids' that become requirements for our systems. They get this from discussions and on-site needs assessments with the clients, and prioritize things, and we deliver at some point. This process is all about prioritization and compromize. 2. Architecture Envisioning - they admit that this is really what I would call 'good progect design'... choose the right environments/people/teams up front because you really don;t want to re-write everything later when your client uses UNIX instead of Windows, or some other problem. This is where my 'Wise/Experienced' Manager comes in - they instinctively know how a project will have to unfold in order to be successful. This setup phase is critical for the success of the project... 3. Document Late - I am surprised that Wiki pages do not appear in the things I read. I find them invaluable for maintaining a close relationship between the specifications and compromises that inevitably happen during the development of the code. The formal documentation people can then use the wiki's to keep their work in line with reality. It also allows the documentation process to be started before even the programming is, and then the documentation can be comprehensive about the requirements, can be re-active to known issues, and can even be completed at pretty much the same time as the program itself. Why document Late when you can get better delivery by documentin concurrently and keep the documentation up to date with useful tools like e-mail and wiki's. A huge tool for our documentation guys is also the bug-tracking software we have, because it is intricately linked with a lot of things and all issues can be documented and the process is comprehensive. The bug-tracking software has specific components designed to be used by documentation people so that we (the developers) can keep the documentation up to date with changing features/known issues. Documentation is a process, not a product. Well, that's how I feel anyway. If you leave it all to the last minute you get incomplete documentation. Sure, it is hard to keep documentation current with the code, but, they don't pay me money to slack up on the important stuff. Documentation/comments/bug-tracking and prioritization are at least as important as the program itself. Programming only means you do a 1/4 of a job. 4. Executable Specification - we have another department of "Financial Engineers". They determine how to model financial concepts, and part of that process is the development of meaningful test data so that we can develop with some form of certainty that we will hit the mark with the final product. So, sure, I agree that "Executable Tests" are important. We also have another department that takes the test data and warps and breaks it in such a way that we ensure that our code can process broken data and responds appropriately, so we also have an executable ex-specification too. 5. Iteration Modelling - an Agile iteration is a 'short time' (couple of weeks or so). This tells me that the developer should know where they are going to aim for in the next 'iteration' - what they want to get done. Sure, anything else is wrong, really. All this says is that if you want to get to place X at the end of an iteration, then you have to know where X is, and how to get there... I guess the alternate is to not do iteration modelling, and just programm to no 'model' and maybe you will get somewhere useful. I must be missing something else because this concept appears so common-sensical.... Perhaps the agile 'Iteration' is not what I understand, but, if I had to spend some time implementing a financial feature, I would first determine what my data requirements were, where that data was to be stored, how I was going to process it (like in the database, or a seperate program), and how I was going to present the results to the next in line process/report, etc. Break that down in to 'iterations', and each can be modeled in more detail. 6. Just Barely Good Enough Artifacts - Do only as much as needed for the situation at hand - I'll comment on this one with the next one.... 7. Model a bit ahead - this is a contradiction of 6. I thought that you should only do as much as needed for the situation at hand...? Now we need to model/plan/think ahead 'to reduce overall risk'. 8. Model storming - "model on a just-in-time basis" ... "to think through a design issue". Again, contradictory, do I model a bit ahead, or do I model only when needed? 9. Multiple models - no idea if this makes sense. The only way it makes sense to me in the context it is written is if the type of "Model" that practice 9 refers to is different to the type of model that 5, 6, 7, and 8 refer to. 10. Prioritized Requirements - according to 'stakeholder' interests - this makes no sense... The stakeholder wants results. Results are the consequence of a process, and have a logical progression where there are dependencies (perhaps co-dependencies) that need to be accomplished before a result is achieved. In order for this to make sense, you have to break the 'final product' down in to sensible sub-products that make sense to the client, and then focus on the delivery of a logical subset of the functionality. This is called "compromizing" and is common to many projects I do. Not all functionality is delivered with the first version, but will be expanded/completed later. This is part of a client negotiation process, but, after that is done, then the order of development is not determined by the client, but by the logical progression required to accomplish the reduced goal (which the added complexity of developing with the full product in mind so that when the remainder of the product is implemented it needs as little re-work of the initial deliverable as possible. 11. Requirements Envisioning - this is just a souped up way of saying "know what your customer wants". I notice that it explicitly says "at the beginning of an Agile project". So much for welcomming requirement changes at the end..... 12. Single Source Information - keep information in one place and one place only. Get real. I have a bridge to sell anyone who believes this can be done. Data is unprocessed information. Information is data that is taken in a context. The context of the data is as important as the data itself. What the programmer considers to be information is different to what the end used considers to be information. The same data has to be represented different ways to make the data become information for the different parties. Saying that information should be kept in one place is diminishing the value of data. Data has to be expressed in different ways to accomplish different goals. 13. Test Driven Design - No problem with this. I use the technique often - in context (both big and small scale). But, remember that the tests need validation too. All in all, I have to agree with my colleagues at work. Agile is a non-starter for our company. It seems to be most appropriate for software projects with clients of a certain nature, and not the system I have at work. Given that I take issue with most of the 13 best practices of ADMM, I guess I misunderstand things. My impression of the 'best practices' is that it is a collection of compressed 'sound bites' that have lost the weight of the argument in the compression. Anyways, I like number 6 the most: "Just Barely Good Enough Artifacts". Sounds like it can be applied to anything, including agile development itself.... ... I hereby claim to be an Agile programmer because my "programming methodology" is Just Barely Good Enough! ;-) ;-) Finally, the way the whole site is written is not like a 'must-do' thing. It is more a case of 'zen buddism' and 'third person' stuff. I have a mental image of Yoda that is in my mind when I read the page. "The Agility .. you must embrace ... or a Jedi you are not!" "A disturbance in Agility, your document is too early". Rolf -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist