I''m somewhat of a newbie to agile practices, and I know the Rails community in general is pretty "up to speed" on agile methodologies, but if there''s a better place for me to ask this question, let me know, and forgive the off topic post. I''m trying to "grok" agile practices in "the real world". I''ve read the Agile Manifesto (http://agilemanifesto.org/), and I find it somewhat vague. Most of this is common sense, but the one thing that irks me (probably because I don''t understand it fully) is that "responding to change" is more important than "following a plan". Now, what I''m trying to get, is exactly HOW - in terms of technology and practices - we, as software developers, can respond to change *over* following a plan. Let me illustrate with a real life example. I''m currently working a project for a cell phone company where the company supplies a list of employees and a list of sales, and what employee made which sales, and which of 4 different types of employees they are (retail sales, territory manager, store manager, business sales person, etc.). The goal of the project is to calculate the commission to be paid to each user (somewhere in the 200 users range - it''s a small company). One problem is that each of those four types has anywhere from 4 to 8 "sub parts" of their commissions. There''s a separate total for activations, a separate total for renewals, accessory sales, and other types of sales, depending on the role. Each of these is calculated in an entirely different manner, and compared to a "floating modifier" table, that is different for each role type, for each type of calculation, then re-calculated, etc. It''s a highly convoluted and screwed up process, but you know how it is with "management" in a corporation... Now, I''m tying this in with a Ruby on Rails application that serves as the company intranet web portal for our entire company as well, so this is all tied to the User model within the application. Here''s where agile practices come into play, and where the "rub" is: I had an entire system finished and ready to go. Then management stepped in, and for the third time in two months, changed it all. Four user types got expanded to 9, and instead of 4-8 sub parts for each user calculated differently, that got expanded from 4-15. The changes were so sweeping that there was no way to simply "modify" existing code. I had to start over again from scratch. Because it had to be tied to an already existent User model, I used some mixins to structure the different versions of the system (which I''m looking at making an entirely separate application, by the way). I''d consider this a somewhat "agile" method - keeping code modular; but what else could I do? I also practice TDD fairly well (though I need to teach myself RSpec/ Cucumber etc.). So of course, each method had tests to back it up, and I put a LOT of time and effort into simplifying and normalizing the database to keep things within best practices, not duplicate data, and "future proof" as best as I could. I find TDD a *big* help with stuff like this, to "prove" that your code works in case anyone starts a fight or a political struggle (which is common where I work, unfortunately), but more importantly, to facilitate change by making sure that changes don''t break existing functionality. My problem is that short of : - TDD - Really thinking hard about how to structure your data - Using source control (I''m still with Subversion though I want to play with git a bit more, get a better feel for the differences between them) - and "modularizing" code conceptually (MVC, mixins, etc.) I don''t know what ELSE I can do, in terms of agile PRACTICES, to respond to change better. In my experience, change is a daily to hourly occurrence. It''s ridiculous in some cases, and I''m wondering: how far can we take the "agile" concept? How do we EXECUTE that concept on a day-to-day basis? What best practices are there for making change this frequent, this sweeping, more manageable? I want to be a much better developer than I am, and be able to respond to these changes in a more "agile" way. I get stuff like this thrown at me all the time, and I''m sure I''m not alone in that, but I feel I may be behind the times in learning to respond to this better with better practices, development techniques, and possibly tools. Can anybody point me to some resources, comment on how I can better respond to changes LIKE this (the above is only for illustrative purposes, I''m not looking for "answers" to this situation, just some better ways to approach anything similar to it now and in the future), etc.? Thanks a lot for any input you can provide. And again, if this post is better suited to another Google talk group or elsewhere, let me know and I''ll go put it there, and please pardon the intrusion. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
kwerle-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org
2010-Mar-05 05:49 UTC
Re: Grokking agile practices
On Mar 4, 5:07 pm, Phoenix Rising <polarisris...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m trying to "grok" agile practices in "the real world". I''ve read > the Agile Manifesto (http://agilemanifesto.org/), and I find it > somewhat vague. Most of this is common sense, but the one thing that > irks me (probably because I don''t understand it fully) is that > "responding to change" is more important than "following a plan".I dunno. I''m big on plans - but I''m big on them being flexible. Maybe that is the same as responding to change, but I like to think of it as making it easy to modify the plan.> Here''s where agile practices come into play, and where the "rub" is: I > had an entire system finished and ready to go. Then management > stepped in, and for the third time in two months, changed it all. > Four user types got expanded to 9, and instead of 4-8 sub parts for > each user calculated differently, that got expanded from 4-15. The > changes were so sweeping that there was no way to simply "modify" > existing code. I had to start over again from scratch.I''d say this doesn''t have so much to do with rails or agile, as it does with OOA&D - and various OO Design Patterns. http://en.wikipedia.org/wiki/Design_pattern_(computer_science) http://en.wikipedia.org/wiki/Behavioral_pattern http://en.wikipedia.org/wiki/Design_Patterns_(book) You have a set of knowns: 1. Management is going to change things 2. There are users - and there are different kinds of users. 3. There are sales - and there are different kinds of sales. 4. Calculating commissions is going to be arbitrarily complex and will change. You know there are always going to be users. And you know there are always going to be sales. It seems like those objects should be pretty concrete and basic. It sounds like you might want to decorate (http://en.wikipedia.org/wiki/Decorator_pattern) users to differentiate them instead of messing with subclasses. The same goes for sales. Or maybe something even simpler - you could just tag the users and sales using something as simple as acts-as-taggable (http:// rubygems.org/gems/acts_as_taggable). Then when it comes time to calculate totals, maybe use Strategies (http://en.wikipedia.org/wiki/Strategy_pattern#Ruby). If you lay the objects out the right way, maybe the next time management changes how commissions are calculated all you need to do is change a few tags and modify/add some strategies. Or maybe they will decide that it depends on how many friends you have in Facebook - in which case you might need to do more coding. They are management, after all. --- Kurt Werle I am looking for a new Rails job: http://www.circlew.org/kurt/pages/resume -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Phoenix Rising wrote:> > Here''s where agile practices come into play, and where the "rub" is: I > had an entire system finished and ready to go. Then management > stepped in, and for the third time in two months, changed it all. > Four user types got expanded to 9, and instead of 4-8 sub parts for > each user calculated differently, that got expanded from 4-15. The > changes were so sweeping that there was no way to simply "modify" > existing code. I had to start over again from scratch. >Agile practices aside, it sounds like you want to develop a "computation engine" that can represent an arbitrary formula (it IS management driven after all) out of some number of components. Your key issue would be a decent UI for defining these nodes and how they fit together to create formulas. Calculations become a relatively simple DFS tree traversal. Node = [Constant] or [object method call] or [Operator, Node, Node] Back in the day, I did this with variant record types, and built such an engine which could compute bills from utility rate structures, or formulate deposition rates of different types of particulates from incinerators. Just food for thought. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Quoting Phoenix Rising <polarisrising-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> I''m somewhat of a newbie to agile practices, and I know the Rails > community in general is pretty "up to speed" on agile methodologies, > but if there''s a better place for me to ask this question, let me > know, and forgive the off topic post. >So I understand your situation better, are you trying to do agile alone or has management and other stakeholders bought into it? Jeffrey -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.