Making Enterprise Process StickYou've decided your company needs a software process, but now what?by Daniel Pilone Continued from Page 1 After completing the group use case, we selected three more use cases to flesh out. The team broke into pairs and spent the following morning writing their use cases. We reviewed these as a group and made corrections as we went. Returning to our first group use case, we began to analyze and design the use case, modeling everything in UML. The team broke into pairs again, this time exchanging use cases with other teams. Any use case questions that came up during design had to be resolved with the use case authors. This strategy worked extremely well to drive home the importance of complete use case authoring. Design consumed the remainder of the second day and half of the third. We met to group review the designs in the afternoon of the third day. Everyone's designs had to be in the UML model and committed into the repository before being reviewed. At this point, things shifted back to a classroom style: We discussed design patterns, architecture, subsystems, and interfaces. Because most developers were experienced with C++, extensive low-level, object-oriented discussions were unnecessary. We redesigned quite a bit to ensure maintainable architectural and design patterns. In order to increase overall Java knowledge, we generated code from the newly updated model and implemented one use case as a group. At the end of the week, we had use cases, a design model, implementation guidelines, templates, tool experience, and excited developers. All the artifacts were committed into the repository to be used as a reference for other groups in the organization. Finally, we sat down for our first iteration review. We revisited just about every discussion we had at the beginning of the iteration. The developers now felt they were tuning their process. Everyone agreed the first attempts at use cases were too short, UML modeling was very helpful, and we needed to have stricter code documentation requirements. Although there was always lively debate, developers didn't feel the process was being forced upon them. In this sense, our process was reminiscent of XP; however, our artifacts were closer to RUP style. If there were parts of the process people couldn't agree upon, we would try a different approach for the upcoming iteration with the commitment to reevaluate at the next review. Everyone was willing to try a controversial solution for at least one iteration. Going LiveThe following Monday we began our first real iteration. All our question and process decisions were captured in either our development case (although ours had changed substantially from the RUP template) or our iteration plan. Iteration 1 would attack real pieces of the project but was deliberately light on use case scenarios to give us some flexibility to work out the remaining kinks in our process. We worked on more group design and group reviews than a typical iteration would have to help flesh out some of the architectural patterns and subsystems. We continued to use XP-style pair programming; the increase in morale and productivity was amazing. I had been skeptical during the previous iteration review about pair programming but lost the argument to the developers for this iteration. Afterward, it was clear that they made the right decision. Our first iteration was a resounding success. We still had to resolve some issues with our process, but everyone came to the iteration review excited and ready to offer suggestions on how to streamline things for the next iteration. (See the sidebar, "Lessons Learned.") Our process was flexible, and it helped the project rather than slowed things down — we had an "agile process." Daniel Pilone [pilone@slac.com] is a software architect with SFA Inc. He has helped kick start the Rational Unified Process and Extreme Programming on several projects in both the public and private sector. LESSONS LEARNEDHere are some things we learned from our software process approach: Developer buy-in: Your developers must be on board for any process to be successful in an organization. Experiment: The process is a tool just like any other. Give everyone (including you) a trial run with it outside the context of your project. Fluid processes: Establish a rhythm but let your team customize the process at the right times. Different projects, teams, and iterations may require different styles of process. Respect that! Automate everything: We wrote our documentation in DocBook and generated it nightly for the Web. Everyone saw polished, professional documents updated daily. It made everything feel fast-moving and sharp. Management loved the ability to follow progress (our code documentation was generated nightly as well) and didn't need to look over developers' shoulders. Borrow: Always keep your eyes open for great ideas from other processes. Select the parts that best fit your team and enterprise culture. Be careful to cover the basics of software process. If the RUP style of iteration planning doesn't fit with your organization, look at XP or another process. But don't forget iteration planning! Involved developers: Your process needs to be internalized by your developers. Get them involved early in decisions and keep them involved. If you have a small enough team, try to include everyone in your iteration reviews. If the team is too big, make sure your architect, team leads, and possibly a representative of the developers attend the meetings and vote on decisions. RESOURCESDocBook: www.docbook.org Extreme Programming: www.extremeprogramming.org Rational Unified Process: www.rational.com
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| |||||||||||||||||||||||||||||||
