Design for Trustworthy Software is a rather impressive tome that comprises a compendium of the latest and greatest methods, tools and techniques for system and software design applied to software. It covers Design for Six-Sigma (DFSS) techniques, TRIZ, Taguchi Methods, Quality Metrics, Poka Yoke, 5S, QFD, FMEA, and more.
I expect this book to become a standard reference and graduate-level software engineering text. It is so comprehensive and and yet modern/up-to-date in its coverage. It's a very dry read (and I'm not finished with it yet) and looks to be a comprehensive synthesis of what has been working best in industry for the last 25 years that has only recently (in the past 10 years) been getting some visibility in complex systems software of any significant scale. And it shows how to apply them to software.
Saturday, June 30, 2007
Saturday, June 23, 2007
BOOK: OOAD 3e - updating the classic
April 2007 marked the release of theObject-Oriented Analysis & Design with Applications, 3rd edition by Grady Booch et.al.
For many, this book was the one that first turned them on to object-orientation as more than just a particular programming language or two, but as an overall way of thinking about how to analyze and design software programs. The book has many classic epiphanies that were precursors to things UML, RUP, patterns and agile development. Booch himself is practically a demi-god of modern software development, architecture and practice.
I guess I've moved on a bit since reading the first edition in the early nineties, because the third edition didn't have as much "zing" for me. And there are so many other good texts around now, that this one reads a bit dry and academic.
I'm actually more interested lately in the work that Booch is doing toward a Handbook of Software Architecture and in his blog.
For many, this book was the one that first turned them on to object-orientation as more than just a particular programming language or two, but as an overall way of thinking about how to analyze and design software programs. The book has many classic epiphanies that were precursors to things UML, RUP, patterns and agile development. Booch himself is practically a demi-god of modern software development, architecture and practice.
I guess I've moved on a bit since reading the first edition in the early nineties, because the third edition didn't have as much "zing" for me. And there are so many other good texts around now, that this one reads a bit dry and academic.
I'm actually more interested lately in the work that Booch is doing toward a Handbook of Software Architecture and in his blog.
Monday, June 18, 2007
BOOK: xUnit Test Patterns
xUnit Test Patterns: Refactoring Test Code, by Gerard Meszaros (Addison-Wesley Signature Series, May 2007) is nothing short of FANTASTIC!
As I'm reading through the book, I keep saying to myself "Yes!" and "Aha!" over and over again. This book is very appropros for me right now because I'm dealing with a team that has a legacy codebase and is just trying to develop automated tests and they don't yet have a lot of training or experience refactoring or in automating their own tests, or the xUnit-style tools, much less using all of them together.
This book is EXACTLY what the doctor ordered for my current situation. It covers the basics of test automation styles and frameworks using harnesses and drivers, data-driven as well as other styles and the challenges to be addressed, especially with test setup. It has comprehensive coverage of 68 patterns and an awesome website at http://xunitpatterns.com/ which does a far better job of depicting them than I could on this blog.
If you're trying to get a small group of folks to learn how to do agile-style test-automation and refactoring, this is the book with all the patterns and insight you will want to convey to your team.
'Nuff said!
As I'm reading through the book, I keep saying to myself "Yes!" and "Aha!" over and over again. This book is very appropros for me right now because I'm dealing with a team that has a legacy codebase and is just trying to develop automated tests and they don't yet have a lot of training or experience refactoring or in automating their own tests, or the xUnit-style tools, much less using all of them together.
This book is EXACTLY what the doctor ordered for my current situation. It covers the basics of test automation styles and frameworks using harnesses and drivers, data-driven as well as other styles and the challenges to be addressed, especially with test setup. It has comprehensive coverage of 68 patterns and an awesome website at http://xunitpatterns.com/ which does a far better job of depicting them than I could on this blog.
If you're trying to get a small group of folks to learn how to do agile-style test-automation and refactoring, this is the book with all the patterns and insight you will want to convey to your team.
'Nuff said!
Monday, June 11, 2007
BOOK: Lean Software Strategies
I reviewed the book Lean Software Strategies for the June 2007 issue of the Agile Journal.
You can read the full review at agilejournal.com.
Lean Software Strategies seems to be one of the first books specifically about applying Lean principles and techniques to software development that is not written by the Poppendiecks. When the book first came out, I admit I was put off by several unfavorable reviews at Amazon.com. When I later learned it won the 2007 Shingo prize for excellence in manufacturing research, and saw Lisa Crispin's review at StickyMinds, I decided to give it a second look. I'm glad I did!
Written by Lean experts from two backgrounds, one an academician/researcher and the other an industry practitioner, the style of the book is very different from that of the Poppendiecks. It takes a much more purist (even academic at times) application of Lean production to software development rather than landing squarely on "Agile" or roughly equating the two. I can understand why fans of the Poppendiecks' books, and perhaps those coming from a background that is more "Agile" than "Lean" didn't exactly "rave" about Middleton and Sutton's book. I can also understand the perspective of those coming from a background in Lean production who complain that the Poppendiecks' books are more about "Agile" than "Lean" and that Sutton and Middleton's book is, in their mind, the first book that is truly about applying Lean to Software. I think both camps are "right" in their own way, and that is why I think it is important to read this book in order to gain a broader and deeper perspective of what Lean is and how it applies to software development.
You can read the full review at agilejournal.com.
Monday, June 04, 2007
Upcoming Agile/Lean book reviews
I'm behind in a lot of reading and am finally catching up. As a result I be blogging a LOT about books this month. I have all of the following books (most of which are brand spanking new) that I'll be trying to blog about this summer:
I'm looking forward to writing more about them in the coming weeks!
I'm looking forward to writing more about them in the coming weeks!
Tuesday, May 29, 2007
Lean CM
I found a couple of great resources on Lean CM that are very compatible with the article we wrote last month on Lean-based Metrics for Agile CM Environments.
- Lean Configuration Management – Supporting Increased Value Delivery from Agile Software Teams
by Jens Norin and Daniel Karlström, in the Proceedings of the 6th Conference on Software Engineering Research & Practice in Sweded (SERPS'06), October 2006 (and also in September 2006 as a Softhouse Whitepaper on Lean CM) - Gain flexibility & speed with Lean CM
by Joe Beckett, Plant Magazine, June 2005
Monday, May 21, 2007
Defining Agile SCM
The May issue of the CM Journal is devoted to the theme of CM & Agility. Myself and Rob Cowham wrote an article for it entitled Defining Agile SCM: Past, Present and Future.
Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!
There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.
In our earliest articles on the topic, we defined Agile SCM as "the pragmatic application of sound CM principles & practices in accordance with Agile values, using Lean thinking, to serve the needs of the business!" We wish to elaborate what that means in terms of SCM for Agile development, but even more importantly in terms of how we should apply Agile, Lean and their related principles to SCM processes and procedures.
Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!
There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.
Saturday, May 12, 2007
Five R's of Agile SCM Baselines
Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):
I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).
Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.
Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).
What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?
Here are all the other R-words I considered:
- Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
- Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
- Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.
- Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)
- Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.
I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).
Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.
Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).
What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?
Here are all the other R-words I considered:
- Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible
Saturday, May 05, 2007
Software CM is Not a Process!
The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.
Armour maintains that:
So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!
This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).
If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.
If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.
For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.
Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).
So there you have it:
What do you think?
Armour maintains that:
The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).
Therefore:Software is not a product, it is a medium for storing executable knowledge.
Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.
The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.
So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!
This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).
If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.
If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.
For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.
Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.
The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.
Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).
So there you have it:
Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.
What do you think?
Sunday, April 29, 2007
BOOK: Release It!
I just received a copy of "Release It! Design and Deploy Production-Ready Software" by Michael Nygard. This looks to be yet another winner from the PragmaticProgrammers' Pragmatic Bookshelf. In fact it made #1 on Amazon.com's "Hot New Releases" list for Design Tools and Techniques for the past two weeks.
Actually, this book isn't about what I had originally thought from reading the early descriptions. I thought it was going to be related to build+release+deployment engineering (CM guy that I am :). It's not about that at all. It is about architecture and design for production deployment concerns, such as: hardware/software "fit", availability/reliability, operability, stability, capacity, and maintainability (not just of the code, but of the deployed product at the customer's site).
"Release It!" covers all those things many of us software-only, high-level abtractionists forgot (or worse yet, never learned) about design & architecture for where the rubber meets the road. I need to add it to my reading list!
Actually, this book isn't about what I had originally thought from reading the early descriptions. I thought it was going to be related to build+release+deployment engineering (CM guy that I am :). It's not about that at all. It is about architecture and design for production deployment concerns, such as: hardware/software "fit", availability/reliability, operability, stability, capacity, and maintainability (not just of the code, but of the deployed product at the customer's site).
"Release It!" covers all those things many of us software-only, high-level abtractionists forgot (or worse yet, never learned) about design & architecture for where the rubber meets the road. I need to add it to my reading list!
Saturday, April 21, 2007
April CM Journal and LDM
The April issue of the CM Journal, and there is a FANTASTIC article in it by Austin Hastings about his Longacre Deployment Management strategy for dealing with database CM. It's long, but well worth the read for the insight into a new way of thinking about and doing CM of a database.
The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.
The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.
Saturday, April 14, 2007
Agile Development Distilled
Lately I've been spending some time thinking about how to distill Agile development within my company on a single powerpoint slide for a top-level Executive. I keep going back and forth between something that shamelessly steals (and modifies) something used to describe RUP, and something that shamelessly steals (and slightly modifies) something from Dan Rawsthorne.
Dan Rawsthorne writes that the "essence of agility is: iteration, validation, feedback." I think something along those lines is ...
RUP talks about 6 Key Principles For Business-Driven Development:
1. Adapt The Process
2. Balance Stakeholder Priorities
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate The Level Of Abstraction
6. Focus Continuously On Quality
I think an "Agile slant" on that would be:
Of course much of this just seems like Steven Covey’s Seven Habits of Highly Effective People. And maybe that is true.
Other sources and quotes ...
Dan Rawsthorne writes that the "essence of agility is: iteration, validation, feedback." I think something along those lines is ...
Agility comes from rapid feedback & learning in short-cycles using:
- Close Collaboration
- Continuous Validation
- Frequent Iteration
- Dynamic Adaptation
RUP talks about 6 Key Principles For Business-Driven Development:
1. Adapt The Process
2. Balance Stakeholder Priorities
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate The Level Of Abstraction
6. Focus Continuously On Quality
I think an "Agile slant" on that would be:
1. Adapt to Change
2. Prioritize Scope
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate the Level of Automation
6. Continuously Validate Quality
Of course much of this just seems like Steven Covey’s Seven Habits of Highly Effective People. And maybe that is true.
Other sources and quotes ...
| Alistair Cockburn writes of Seven Properties of Agile Projects: 1. Frequent Delivery 2. Reflective Improvement 3. Osmotic Communication 4. Personal Safety 5. Focus 6. Easy Access to Expert Users 7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration |
| David Anderson's Agile Recipe for Success is: Focus on Quality, Reduce Work-in-Progress, Balance Demand against Throughput, Prioritize. He also writes "Trust is the essence of Agile" |
| Jim Highsmith adds that: "Agile Organizations don’t just respond to change; they generate it!" |
| “Agile development uses feedback to make constant adjustments in a highly collaborative environment." -- Andy Hunt, http://www.sdtimes.com/fullcolumn/column-20060615-01.html |
| "Short Cycles and Customer Involvement" -- 3rd eWorkshop on Agile Methods |
| "an inclusive, people-centred approach to doing iterative, incremental software development. It uses a combination of technical and social practices to increase collaboration and reduce feedback cycles" -- Steve Hayes, http://pliantalliance.org/?p=31 |
| "The essence of Agile evolution is to gradually transform a typically conservative, risky and unattractive activity into a positive and proactive development activity." --Dave Thomas, Agile Evolution, http://www.jot.fm/issues/issue_2006_09/column2 |
| See table of "Key Characteristics of Agile" at (Towards an Agile Systems Engineering process) |
| See Agile Axioms and Seven Core Practices of Agile Development |
| DSDM in a Nutshell |
| Getting Real |
| My Nutshell definitions of Agile Development |
| Why Agility Works |
| Scrum Primer |
| Agile EVM |
| Allan Shalloway's Agile Explained |
| Dean Leffingwell with Ryan Martens, Scaling Software Agility, Ch 7 on The Essence of Agile |
| Not so Agile aspects of Agile Development |
| The Agile-Oriented Paradigm |
| More take-offs on Covey's Seven habits are ... Five Habits of Highly Visionary Companies Six Habits of Highly Effective CIOs Seven Habits of Highly Effective Programmers Seven Habits of Highly Effective User Interface Designers Seven Habits of Highly Effective IT Managers The Seven Habits of Effective Iterative Development |
| From SurgeWorks (http://www.surgeworks.com/our-methodology) ... In a nutshell, Agile Methodologies are focused on delivering maximum business value in minimal time. There are several different Agile approaches, but all of them focus on a similar set of core practices. They are:
|
Saturday, April 07, 2007
Defining Design Quality
Nice article on Defining Design Quality at InfoQ.com. The article heavily references the work of James Shore, who is currently working on a book with chromatic entitled "The Art of Agility". It has a pretty nice definition of design quality:
This also ties in quite nicely with Agile ideas about "Simple Design" and some earlier blog-postings of mine about Simplicity in Design (and ChangeThis for Simplicity).
"A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance."It also references a few other nice articles:
- An Artima interview with Erich Gamma which notes that "Modification and maintenance time are more important than creation time."
- An article by Alistair Cockburn on programming as theory building
This also ties in quite nicely with Agile ideas about "Simple Design" and some earlier blog-postings of mine about Simplicity in Design (and ChangeThis for Simplicity).
Sunday, April 01, 2007
Best Kept Secrets of Code Reviews
The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).
This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]
SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:
And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.
The have some other nice resources too:
Looks like a lot of "good stuff" to me!!!
This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]
SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:
- CodeCollaborator - Automation for paperless peer code-reviews
- CodeReports - Continuous source code metrics over time.
- CodePickle - Suspend & resume code changes in local developer sandboxes (implements the PrivateVersions pattern without using version-control branches)
- CodeReviewer - automated peer-to-peer code reviews across remote sites
- CodeHistorian - Data-mining and visualizations for version control systems.
And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.
The have some other nice resources too:
- Agile Peer Review: Methods, and Results (Powerpoint Presentation)
- The Case for Peer Code Review
- Brand New Information about Code Reviews
- 11 Best Practices for peer code review
- 2500 Reviews at Cisco® - The Largest Case Study of Code Review, Ever
- Why formal inspections fail
- Team-Building for the Cold, Dark, and Alone
- Compare 5 styles of review
- Pros & Cons of Four Types of Review
- Social effects of peer code review
Looks like a lot of "good stuff" to me!!!
Sunday, March 25, 2007
Agile in March RationalEdge & April CrossTalk
The March issue of The Rational Edge and the April issue of Crosstalk are both devoted to the the theme of Agile Software Development this month!
Wednesday, March 21, 2007
Lean-based Metrics for Agile CM Environments
My paper in this month's issue of The CM Journal is about Lean-based Metrics for Agile CM Environments.
This month we take an "Agile" slant on metrics for CM, including the CM process itself. Agility is supposed to be people-centric and value-driven. So any metrics related to agility should, at least in theory, provide some indication of the performance & effectiveness of the value-delivery system, and how well it supports the people collaborating to produce that value. We borrow heavily from the concepts of Lean Production (and a little from the Theory of Constraints, a.k.a. TOC). Let's see where it takes us ....
Saturday, March 17, 2007
Elements of Agile Style
Joe Little has authored a nice little booklet on The Elements of Agile Style
Wednesday, March 14, 2007
Top-down Agile Adoption in March Agile Journal
The March issue of the Agile Journal is about scaling-agility and agile adoption in the enterprise.
Sunday, March 11, 2007
Scaling Agility - new book & blog
Dean Leffingwell, previously known for his book Managing Software Requirements: a Use-case driven approach has just published a new book entitled Scaling Software Agility: Best-Practices for Large Enterprises. He also has a corresponding Scaling Software Agility blog. See the forthcoming reviews on amazon.com.
So how did Dean go from being a requirements-management guru to being a large-scale agile guru? It's not too big of a leap if you think about it! Dean is at Rally Software Development these days (the noted Agile consulting services & tool vendor) and has also authored a few Agile Whitepapers, an essay on The Essence of Agile (now an excerpt from the book), and a few articles for The Agile Journal, most notably Agile at Scale: 7+7 Practices for Enterprise Agility.
So how did Dean go from being a requirements-management guru to being a large-scale agile guru? It's not too big of a leap if you think about it! Dean is at Rally Software Development these days (the noted Agile consulting services & tool vendor) and has also authored a few Agile Whitepapers, an essay on The Essence of Agile (now an excerpt from the book), and a few articles for The Agile Journal, most notably Agile at Scale: 7+7 Practices for Enterprise Agility.
Wednesday, March 07, 2007
SEI Reflections on Agility: Challenges, Dillemas, & the Way Ahead
Interesting paper from Linda Levine and the SEI about Reflections on Software Agility and Agile Methods: Challenges, Dillemmas & the Way Ahead (see the corresponding presentation slides)
Some other related documents from the SEI are:
See! Not everything from the SEI is about CMM or CMMI ;-) They also a have a wealth of resources on Software Architecture and Software Product-Lines and other areas of Software Engineering!
Some other related documents from the SEI are:
- Systems of Systems: Scaling Up the Development Process; by Watts Humphrey. SEI Technical Report CMU/SEI-2006-TR-017
- Documenting Software Architectures in an Agile World; by Paul Clements, James Ivers, Reed Little, Robert Nord, Judith Stafford. SEI Technical Note CMU/SEI-2003-TN-023
- Integrating Software-Architecture-Centric Methods into Extreme Programming (XP); by R. Nord, J. Tomayko and R. Wojcik. SEI Technical Note CMU/SEI-2004-TN-036, ADA431084
- Using Earned Value Management (EVM) in Spiral Development; by Lisa Brownsword, Jim Smith. SEI Technical Note CMU/SEI-2005-TN-016
See! Not everything from the SEI is about CMM or CMMI ;-) They also a have a wealth of resources on Software Architecture and Software Product-Lines and other areas of Software Engineering!
Subscribe to:
Posts (Atom)
