|
by Kirk Knoernschild
What makes a software developer agile? How about a software development team? And how do traditional techniques fit in the agile world? Agile Junction explores the practices of agile developers, agile teams, and the harmonious intersection of agility and the proven practices, principles, patterns, and paradigms of software development.
|
|
Written by Kirk Knoernschild
|
|
Thursday, 15 February 2007 04:54 |
|
Introduction
The Rational Unified Process (RUP) has become a defacto standard for
many organizations as they look to improve their software development
processes. Unfortunately, transitioning to RUP is an arduous and risky
process as teams struggle with adjusting to an iterative style of
development. As a witness to many process improvement efforts utilizing
RUP, I've found most are little more than reinventions of an
organization's existing practices. The result is a pseudo-iterative
style of development that favors excessive documentation manifest as
RUP artifacts, a predictive and plan-driven approach providing no clear
barometer to gauge success, and a tendency to revert to traditionally
flawed practices as teams succumb to the pressures of project
deadlines. Certainly, RUP should not be blamed for the failure, but
often times that's the case, casting a dark shadow on iterative
development and making teams ever more leary to consider agile
development.
|
|
|
Written by Kirk Knoernschild
|
|
Wednesday, 20 December 2006 02:43 |
|
Agile is iterative. But iterative isn't always agile. Increased agility is not a natural by-product of iterative development, and choosing an iterative evelopment process with high degrees of ceremony inhibit agility.
|
|
Written by Kirk Knoernschild
|
|
Thursday, 16 November 2006 06:04 |
|
Software architecture is difficult to define. Ask five different developers their definition of software architecture, and you'll likely get five different answers. Arguably though, we can agree that software architecture represents the significant technical decisions spanning the breadth of the system. For instance, managing the dependencies between modules is a significant aspect of software architecture. Developing application frameworks that promote consistency across use cases is architecturally significant. Identifying application layers and the behavioral granularity of those layers is architecturally significant, as well. As Booch so eloquently states:
|
|
|
Written by Kirk Knoernschild
|
|
Friday, 20 October 2006 05:25 |
I really don't care about Scrum. I really don't care about XP. I don't care about Agile RUP, or any other Agile process. But I do care about the agile practices embedded within these processes. I find little value in debating the advantages of XP over RUP. Of course, I've had the debate before, but mostly just to argue that it's not about the process, it's about the practice, the team and the culture. I don't care if you do Use Case Realizations. I care more about why you do them and what value they bring to your team. Agility is not a process, it is an ability. The ability to remain nimble and accommodate change. Why would we want to be anything but agile? Slow, brittle, and inept are certainly not defining characteristics of success. As in life, remaining agile requires care, attention, and nurturing.
|
|
Written by Kirk Knoernschild
|
|
Tuesday, 31 October 2006 05:10 |
|
I believe the Unified Modeling Languages (UML) is a wonderful and powerful modeling language. The ability to create different types of diagrams representing multiple system perspectives offers numerous advantages. A picture is worth a thousand words, and an enormous amount of information can be conveyed on a single diagram or a complete model of a system, no doubt. But what for? What problem are you trying to solve? It's possible there are other, more effective techniques that address the problem. How does UML compare to other agile practices that address the same challenges of UML? Can UML be used in an agile way? |
|
|
|
|
<< Start < Prev 1 2 Next > End >>
|
|
Page 1 of 2 |
