Anarchy Programming
Anarchy ProgrammingThis is a short name for a series of sometimes ambiquous, unclear, undefined, and undocumented processes by which one or two or many programmers evolve a UsefulUsableAndUsed? program package. The programming process usually first acquires a catchy name for a group of processes an individual or group has found as effective for an activity which has shown some promise, if not fulfillment as a general paradigm for developing software for a specific client. The scheme may apply to other situations and clients, or not.
When the paradigm is used by those who develop it, it can be an effective means, if it is adopted as a fad or silver bullet by inexperienced or poorly trained individuals, it can be deceptive and counter-productive, as well as a waste of time, money and resources. It may provide golden opportunites for employment or training for the many programmers who become involved.
One perception of AnarchyProgramming:
A key strategy used in this programming scheme is to recast the names of old methods and combinations of methods, and how completion is measured. Thus, one does not plan for and construct features to be completed, one creates stories and story points, and delivers data. One does not freeze specification and discourage changes which may interrupt or disturb, one welcomes and encourages change, and offers a continuous partially completed software product which approaches 80 percent of the story points, or until the project is cancelled or accepted in a present incomplete form. A project produced with AnarchyProgramming replaces maintenance issues with implementing changing requirements. In AnarchyProgramming, not only do requirements change, but personnel on both sides of the requirements change as well. Face to Face communication is conducted without the benefit of memorized agreements or fixed specifications.
Another:
According to eWeek.com Microsoft is adopting the agile methodology called Scrum to get software built faster. Is it working? They seem to be claiming that Scrum and Extreme Programming have helped them get recent releases such as SQLServer out the door faster with better quality. Many other large organizations are also adopting agile methods including Yahoo, and Google. Are agile methods the next big thing in software development? -- Room for Milk
Levels of Abstraction and UseCases
Use cases can start at a high level of abstraction and with as little as a name and just enough information to provide an expectation of what is intended for delivery—for instance, the use case goal, without scenarios—and through time grow in detail to be a fully dressed use case and/or expand into multiple use cases. In true rolling wave-style planning, use cases let us plan in detail for what is close and plan loosely for what is distant. For projects in the portfolio not due to start for a while, Extreme Programming's story may be a good model for a starting level of detail; it provides just enough to get the idea across, but not so much that it won't fit on an index card.[8] Leffingwell and Widrig's (2003) approach to picking the right level of abstraction for features can be applied here for use cases: for projects in the portfolio scheduled to start in the future, use a level of abstraction for use cases that is high enough so that the result is under some maximum number of use cases, such as 10. -- http://safari.oreilly.com/0321316436/ch08lev1sec2
Examples: (to be filled in by community)
EditText of this page
(last edited December 28, 2007)
or FindPage with title or text search