Whenever I describe the agile practice of pair programming I usually get the same general reaction,which is something like “I don’t think I’d like to do that”. My usual attempt to convince someone that it could be an interesting tool to try is to suggest that verification team could do it for the complicated sections of code, or to have the designer and verification pair program to develop the drivers. While good reasons, these were never enough. This posting will be another attempt on my part to show the value of pair programming, and to provide some suggestions on where programming could be effective for you, and some reasons on why pair programming may not be effective.
I’m at the start of a new project. We’re currently determining what features are needed in the end-product. This has led to me to thinking a lot lately about how to capture, prioritize and track the completion of these requirements as we progress through the project. Of course, I want to do this in an ‘agile’ way.
The typical agile method is to capture requirements in a set of high level “users stories”. User stories typically provide a concise way of describing what the system will do from the user’s perspective. Several templates of a user story exist; Mike Cohn’s being the one that I think is clear and concise:
As a <type of user>, I want <some goal> so that <some reason>”.
It captures the who, the what and the why of a feature – providing some essential context to the assist in the implementation, validation and acceptance of a feature.
User stories are then typically split into progressively smaller use-cases, or tasks until you establish a firm understanding of what the feature is supposed to do, and how your team is going to complete the functionality as the user expects.
I found Cohn’s template particularly effective when creating some tool or script that I needed to create because it is much easier to comprehend than a typical requirement statement of “The system shall….”.
But… if there’s one aspect of agile that I really think is difficult to translate into an ASIC/FPGA world, it’s the concept of user story. Perhaps it’s because I simply don’t have the experience in writing user stories. But I think it has more to do with my trouble in writing an ASIC story from a user’s perspective. In many cases, a feature does not even provide any meaningful output that is visible to the user e.g., some esoteric standards requirement about how an interface must be defined.
Then serendipity came through for me, when my former colleague and AgileSoC collaborator Neil Johnson was in town on vacation and wanted to grab a beer. He knew James Grenning , who happened to be in Ottawa at the same time to deliver some training, and invited him along too. I’ll cut it short by saying I had a very intersting conversation with James and Neil. You see James is an expert in Test Driven Development for embedded systems. In fact, he’s written a book on the topic Test Driven Development for Embedded C. It was very interesting to discover the similarities that exist between embedded system design and SoC development. Including the perceived and real barriers to adopting an agile flow in an embedded design.
To cut to the chase, we got to talking about user stories and how they don’t really fit into the ASIC development, when James suggested that he calls user stories “Product Stories” instead. While its a simple semantic change of “user” to “product”, for me it was a lightbulb moment. It helped me identify the issue I’ve been having with ‘user stories’: I’m not implementing something for an end-user; I’m developing a product that will fit into a larger system that will ulimately be seen by a user.
Like User Stories, Product Stories are intended to be very high level descriptions of the features that you want to develop along with the acceptance testing that proves the feature is what you expect. The key is that these are short descriptions from the system’s perspective. Instead of the who, what and why as in a user story the product story for ASIC development should include the where,what and why. Specifically, a good requirement contains the following elements:
Behaviour: (the what) A short descriptive story explaining the behaviour at a high level. Justification: (the why) Some idea on why this is important to the system (unless it’s absolutely clear e.g., some standard protocol); Context: (the where) Where in the system this feature is needed Acceptance: simple set of acceptance tests to prove that behaviour is correct.
I’ve been developing the following template, that I’ll be considering to use for my Product Stories, which is similar to the ‘user story’ template above.
“The <context> needs to <do some behaviour> so that <some reason> “.
A product story provides some clear guidelines on the functionality expected, as well as a clear indication of what coverage points must be captured before you declare the product story complete. In fact, I think it might be a good idea to stating these acceptance criteria as functional coverage points.
As I work through these concepts in my head, I’ll attempt to describe them in in my next few blog posts. I’ll talk about how I see these Product Stories being created, developed and tracked in an AgileSoC world.
I’d welcome any comments on this post, and especially how you are doing your requirements management – especially when requirements are very fluid (which, I’m guessing, is probably most of the time for most of us :-)).
I’m starting to see people coming out of the woodwork. Hardware designers and verification engineers, modeling and architecture experts, embedded systems experts…there are people that are interested in seeing agile hardware development going mainstream. Lots of those same people have valuable experience to share.
What about you?
Do you have experience with agile hardware development that you’ve been wanting to tell the world about? Haven’t had the opportunity to do it yet? Well here’s your opportunity. If you’re interested in becoming a guest contributor… or even a regular contributor to the AgileSoC blog, let me know at firstname.lastname@example.org.
For anyone that’s new to AgileSoC.com, here’s a guide to what we have. I have all the top ranked articles here. I also have my favorites… these articles aren’t necessarily the most popular but they’re the ones that I’m happiest with. Finally, a couple of sleeper articles.
…and don’t forget to follow the discussions on the linkedin group!
- UVM Is Not A Methodology: This one is top ranked by a mile. Primarily for the verification engineers out there, this article discusses what teams need to keep in mind when adopting technology like UVM.
- Top-down ESL Design With Kanban: This article came together as I was reading 2 different books (ESL Models and their Applications (1st edition) and Kanban and Scrum: Making the Most of Both). It combines the modified V approach to system development that Brian Bailey and Grant Martin present and Kanban, which Bryan Morris and I have always thought as being hardware friendly.
- An Agile Approach To ESL Modeling: This is a general article for the ESL crowd. Why is modeling important, how modeling can fail and how agile can help modeling teams succeed.
- Agile IC Development With Scrum – Part I: the first of a two part video of the paper Bryan and I presented at SNUG San Jose in 2010. In the video, we talk about how hardware teams would have to evolve to adopt Scrum.
- IC Development And The Agile Manifesto: The Agile Manifesto spells out the fundamentals of agile development. This article shows how the manifesto is just as applicable to hardware development as it has been to software development.
- Operation Basic Sanity: A Faster Way To Sane Hardware: agile makes sense to a lot of people but getting started can be tricky to say the least. I like this article because it gives news teams a way to get started without changing much of what they already do.
- Top-down ESL Design With Kanban: top ranked on the site and also one of my favorites.
- Agile Transformation In Functional Verification – Part I: I think this is another good article that helps verification teams take the mental leap into agile development.
- Realizing EDA360 With Agile Development: If you’re not into the EDA360 message from Cadence, then the title might scare you away. But this isn’t just more EDA360. The theme here is convergence in hardware development, how functional teams drift apart over time and how agile can bring them back together.
- Why Agile Is A Good Fit For ASIC and FPGA Development: I think this was the first article we posted. I go back to it periodically just to see if our early writing still makes sense. I think it does!
AgileSoC.com is an idea that Bryan Morris and I started about 2 years ago after a few long conversations at SNUG San Jose in 2009. Bryan had been interested in agile software development for a while, I was completely new to it. Even though I didn’t know anything about agile, it didn’t take long for me to buy into the idea that it made sense. A lot of what happens in hardware development, particularly in the front-end design and verification, is pretty similar to what the software guys do. Sure the packaging and delivery is different (to varying degrees depending on what your target technology is) but there are a lot of day-to-day activities that are similar. In the last couple years, I’ve heard many people say that agile “makes sense”. I think those people are right.
Admittedly, I have a pretty short span of attention so I was interested to see how long I’d stay interested. I figured 6 months or so and I’d start to wear out. Turns out I was wrong.
We presented our first paper titled A Giant, Baby Step Forward: Agile Techniques for Hardware Design at SNUG Boston in the fall of 2009. That was about 90% book report and 10% practice/observation. It was good for a first crack but I think we did better at SNUG San Jose 2010 with Agile IC Development With Scrum. We have video of both presentations here. In between, I did a presentation to a group of software developers at a Calgary APLN meeting in Nov 2009. That was a little stressful because it was my first time talking to people that know and use agile. Since then we’ve had 2 articles posted in the Mentor Graphics Verification Horizons newsletter, Agile Transformation In IC Development and Agile Transformation In Functional Verification. We’ve also had entries in the Cadence community blogs, a nice write up by Richard Goering and a guest entry that I put together.
Time has passed and we have we’ve been writing articles pretty steadily. It’s been 2 years and if anything, my interest has grown. As of now, we have 17 articles posted on AgileSoC.com by 4 authors. The number of articles slowly grows as we stumble into new ideas and find the time to put them together.
And now, for some reason, I think I need a blog so I can spend more time on this stuff. I shake my head as I type that but here I am anyway. My first guess is that this will be an informal dumping ground for ideas and/or experiences that aren’t good enough to support “real” articles on their own. Not entirely sure so I’ll start with that and see where things end up!