The most widely used methodologies based on the agile philosophy are XP and Scrum. These differ in particulars but share the iterative approach described above.
Xp
XP stands for extreme programming. It concentrates on the development rather than managerial aspects of soft-ware projects. XP was designed so that organizations would be free to adopt all or part of the methodology.
XP development
XP projects start with a release planning phase, followed by several iterations, each of which concludes with user acceptance testing. When the product has enough features to satisfy users, the team terminates iteration and releases the software.Users write “user stories” to describe the need the software should fulill. User stories help the team to esti-mate the time and resources necessary to build the release and to deine user acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to requirements as the software is being built. This allows requirements to evolve as both users and developers deine what the product will look like. To create a release plan, the team breaks up the development tasks into iterations. The release plan deines each iteration plan, which drives the development for that iteration. At the end of an iteration, users perform acceptance tests against the user stories. If they ind bugs, ixing the bugs becomes a step in the next iteration.Iterative user acceptance testing, in theory, can result in release of the software. If users decide that enough user stories have been delivered, the team can choose to terminate the project before all of the originally planned user stories have been implemented.
XP rules and concepts
Here are the most important concepts:
Integrate often. Development teams must integrate changes into the development baseline at least once aday. This concept is also called continuous integration.
Project velocity. Velocity is a measure of how much work is getting done on the project. This important metric drives release planning and schedule updates.
Pair programming. All code for a production release is created by two people working together at a single computer. XP proposes that two coders working together will satisfy user stories at the same rate as two coders working alone, but with much higher quality.
User story. A user story describes problems to be solved by the system being built. These stories must be written by the user and should be about three sentences long. User stories do not describe a solution, use technical language, or contain traditional requirements-speak, such as “shall” statements. Instead, a sample user story might go like this: Search for customers. The user tells the application to search for customers. The application asks the user to specify which customers. After the user speciies the search criteria, the applica-tion returns a list of customers meeting those criteria.
Because user stories are short and somewhat vague, XP will only work if the customer representative is on hand to review and approve user story implementations. This is one of the main objections to the XP meth-odology, but also one of its greatest strengths.
Scrum
In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. Scrum for software development came out of the rapid prototyping community because prototypers wanted a methodology that would sup-port an environment in which the requirements were not only incomplete at the start, but also could change 5rapidly during development. Unlike XP, Scrum methodology includes both managerial and development processes.
Scrum management
At the center of each Scrum project is a backlog of work to be done. This backlog is populated during the planning phase of a release and deines the scope of the release.
After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints. Each sprint aims to implement a ixed number of backlog items.Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress.
During a sprint, the team has a daily meeting called a scrum. Each team member describes the work to be done that day, progress from the day before, and any blocks that must be cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone in the same room—standing up for the whole meeting.
When enough of the backlog has been implemented so that the end users believe the release is worth put-ting into production, management closes development. The team then performs integration testing, training, and documentation as necessary for product release.
Scrum development
The Scrum development process concentrates on managing sprints. Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review, and adjust each of the backlog items.
During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary.
Following each sprint, the entire team—including management, users, and other interested parties—demonstrates progress from the sprint and reviews the backlog progress. The team then reviews the remaining backlog and adds, removes, or reprioritizes items as necessary to account for new information and understanding gathered during the sprint.
Scrum concepts
Here are a few of the most important concepts:
Burndown chart. This chart, updated every day, shows the work remaining within the sprint. The burndown chart is used both to track sprint progress and to decide when items must be removed from the sprint back-log and deferred to the next sprint.
Product backlog. Product backlog is the complete list of requirements—including bugs, enhancement requests, and usability and performance improvements—that are not currently in the product release.
Scrummaster. The ScrumMaster is the person responsible for managing the Scrum project. Sometimes it refers to a person who has become certiied as a ScrumMaster by taking ScrumMaster training.
Sprint backlog. Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed. In common practice, no sprint backlog item should take more than two days to complete. The sprint backlog helps the team predict the level of effort required to complete a sprint.
Saturday, December 13, 2008
SCRUM Methodology
Scrum is an iterative incremental process of software development commonly used with agile software development
Characteristics
Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similarly to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process which range from yellow stickers and white-boards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.
Roles
Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.
Characteristics
Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similarly to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process which range from yellow stickers and white-boards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.
Roles
Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.
- Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry. The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
- ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
- Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.
Friday, December 12, 2008
Wednesday, December 10, 2008
Enterprise 2.0
Enterprise 2.0 takes the original concept of the Web, using websites to feed content to visitors, and turns it upside down. Instead of a one-way conversation-your company talking to the site visitor-Enterprise 2.0 lets you implement a multiparty conversation to share information and manage knowledge inside and outside the organization using blogs and wikis, social networking and tagging, rating systems and the like. The link among these tools is the ability of the individuals involved to participate and to control the process while they work together, share information and create networks of people with similar interests.
Tools to enable these functions have existed for a long time. The trouble is that few people used them, despite large amounts of resources expended to deploy these systems. What changed is the simplicity of the tools. If they're simpler, they're more likely to be used, an important component for knowledge management. (That is, nobody had an incentive to share information, particularly when doing so was a pain.)
This gives new hope to the idea of managing knowledge and sharing information, a goal that goes back to the 1990s when vendors began developing knowledge management and content management solutions. Instead of trying to implement huge, all-encompassing enterprisewide systems, the simpler Web-based tools under the Enterprise 2.0 umbrella strip away the complexity of the '90s technologies while carrying on the spirit of the ideas.
The fact is, Enterprise 2.0 concepts are gaining credibility, and it's not just startups that are paying attention to this space. More than 800 people attended the recent Enterprise 2.0 Conference in Boston, which included speakers from IBM, Microsoft and Cisco, and a host of other smaller players. IBM introduced the Web 2.0 Goes to Work package for the WebSphere Portal, while Microsoft promoted Sharepoint, a natural collaboration environment, as a way to implement Enterprise 2.0 ideas along with Office and other Microsoft technologies.
Tools to enable these functions have existed for a long time. The trouble is that few people used them, despite large amounts of resources expended to deploy these systems. What changed is the simplicity of the tools. If they're simpler, they're more likely to be used, an important component for knowledge management. (That is, nobody had an incentive to share information, particularly when doing so was a pain.)
This gives new hope to the idea of managing knowledge and sharing information, a goal that goes back to the 1990s when vendors began developing knowledge management and content management solutions. Instead of trying to implement huge, all-encompassing enterprisewide systems, the simpler Web-based tools under the Enterprise 2.0 umbrella strip away the complexity of the '90s technologies while carrying on the spirit of the ideas.
The fact is, Enterprise 2.0 concepts are gaining credibility, and it's not just startups that are paying attention to this space. More than 800 people attended the recent Enterprise 2.0 Conference in Boston, which included speakers from IBM, Microsoft and Cisco, and a host of other smaller players. IBM introduced the Web 2.0 Goes to Work package for the WebSphere Portal, while Microsoft promoted Sharepoint, a natural collaboration environment, as a way to implement Enterprise 2.0 ideas along with Office and other Microsoft technologies.
Tuesday, December 9, 2008
Business Activity Monitoring
Automating a business process can bring clear benefits. Yet compared to one performed by people, an automated process is typically quite opaque; getting information about the status of a process can be challenging. The goal of business activity monitoring (BAM) is to provide visibility into automated processes, offering useful real-time information to the people who rely on those processes.
It’s useful to think of BAM technology in two distinct parts:
As the figure shows, BizTalk orchestrations can directly generate BAM events and data, all of which are sent into a common BAM database. BizTalk Server also includes a tool called the Tracking Profile Editor that lets a developer configure an orchestration to send the desired information to this database. Along with built-in support for using BAM with orchestrations, BizTalk Server also provides a BAM client API that can be used with any .NET application. (No BizTalk Server license is required for applications that use this BAM API.) In the example shown above, for instance, the BAM API is used by two other applications to send data to the BAM database. The product’s next release, BizTalk Server 2006 R2, will add built-in support for using BAM with applications built on Windows Communication Foundation or Windows Workflow Foundation. Although this forthcoming WF support for BAM isn’t usable with human workflows built on Windows SharePoint Services, it is possible to use the standard BAM client API with custom SharePoint workflows.
However it gets to the BAM database, data is always stored in tables and cubes. Cubes are most commonly used in data warehouses, and so they’re typically seen as a business intelligence technology. Yet BAM can also be viewed in this light: It’s real-time business intelligence. The information in the cubes is accessible via a set of BAM web services, as shown in the figure, and different clients are free to do different things with this information. An Excel user, for instance, might read it into a pivot table, then create a graphical view of the aspects of this process that she wishes to see. (BizTalk Server provides an Excel add-in to make this easier to do.) This view can be updated as often as necessary, allowing real-time monitoring of the business process.
Other tools can display the data in other ways. Office PerformancePoint Server, for example, might display BAM data generated by one or more business processes as part of a dashboard. The screen shot below shows an illustration of how this might look using PerformancePoint’s Business Scorecard Manager.
When it’s done well, an automated business process that uses BAM can provide more information to the people who depend on it than if it were a manual process. People don’t always have the time or the inclination to respond to status requests, but well-designed software does. Improving business processes with BPM technologies hinges on making them more automated, which implies an increasingly important role for BAM.
It’s useful to think of BAM technology in two distinct parts:
- Infrastructure for collecting information about in-progress business processes. Because these processes might rely on multiple applications, this infrastructure must be usable with more than just a single workflow technology.
- Tools that let information workers access that information. Different people will want to use BAM data in different ways, and so the tools they use might be quite diverse. Some typical examples include dashboards that provide real-time display of critical data, reporting services that present historical trends, and common desktop tools such as spreadsheet applications.
Since the technology required for BAM crosses diverse areas, it shouldn’t be surprising that it involves a number of different Microsoft products. Those products can be grouped into the two categories just described:
- Infrastructure for collecting information about running processes. This technology is licensed as part of BizTalk Server. Like the BRE, however, the BAM infrastructure can be used with both BizTalk orchestrations and any application built on the .NET Framework.
- Tools that let information workers access that information. Whatever application the BAM data comes from, it’s always stored in a SQL Server database, typically in a multi-dimensional cube. This means that any tool capable of working with SQL Server cubes can access and display BAM data. The most important of these for BAM include Microsoft Excel, Office PerformancePoint Server, BizTalk Server’s BAM Portal, and SQL Server Reporting Services. Other Microsoft products can also be used, such as Visio, as can products from other vendors.
The figure below gives a simple view of BAM in the Microsoft world, showing the fundamental technologies in both of these categories.
As the figure shows, BizTalk orchestrations can directly generate BAM events and data, all of which are sent into a common BAM database. BizTalk Server also includes a tool called the Tracking Profile Editor that lets a developer configure an orchestration to send the desired information to this database. Along with built-in support for using BAM with orchestrations, BizTalk Server also provides a BAM client API that can be used with any .NET application. (No BizTalk Server license is required for applications that use this BAM API.) In the example shown above, for instance, the BAM API is used by two other applications to send data to the BAM database. The product’s next release, BizTalk Server 2006 R2, will add built-in support for using BAM with applications built on Windows Communication Foundation or Windows Workflow Foundation. Although this forthcoming WF support for BAM isn’t usable with human workflows built on Windows SharePoint Services, it is possible to use the standard BAM client API with custom SharePoint workflows.
However it gets to the BAM database, data is always stored in tables and cubes. Cubes are most commonly used in data warehouses, and so they’re typically seen as a business intelligence technology. Yet BAM can also be viewed in this light: It’s real-time business intelligence. The information in the cubes is accessible via a set of BAM web services, as shown in the figure, and different clients are free to do different things with this information. An Excel user, for instance, might read it into a pivot table, then create a graphical view of the aspects of this process that she wishes to see. (BizTalk Server provides an Excel add-in to make this easier to do.) This view can be updated as often as necessary, allowing real-time monitoring of the business process.
Other tools can display the data in other ways. Office PerformancePoint Server, for example, might display BAM data generated by one or more business processes as part of a dashboard. The screen shot below shows an illustration of how this might look using PerformancePoint’s Business Scorecard Manager.
When it’s done well, an automated business process that uses BAM can provide more information to the people who depend on it than if it were a manual process. People don’t always have the time or the inclination to respond to status requests, but well-designed software does. Improving business processes with BPM technologies hinges on making them more automated, which implies an increasingly important role for BAM.
The BizTalk Server Business Rules Engine
Microsoft’s most widely used BRE today is provided as part of BizTalk Server. Despite how it’s packaged, this BRE can be used either with a BizTalk orchestration or with any .NET application. (And although using it requires licensing BizTalk Server, the product’s pricing is still competitive for a BRE.) To see how this technology might be used, think once again about the combined human and system workflow scenario shown earlier. In that example, BizTalk Server provided the system workflow and integration services that connected diverse applications, but the decision about whether to place high-value orders was made by people interacting via a Windows SharePoint Services workflow. It might be possible, however, to formalize the rules used to make this decision, then store them in the BizTalk Server BRE. Rather than relying on people, this business process could be implemented entirely in software. The figure below shows how this would look.
As the figure illustrates, the first three steps remain the same as in the previous scenarios. The decision to approve or reject a high-value order, however, is made by the BizTalk Server BRE (step 4) rather than by people. The BRE is invoked directly from the running orchestration, returning the result of its evaluation. As before, the order is then placed only if it was approved (step 5). If the rules underlying this decision can be expressed objectively and accurately, the benefit to the business process is clear: decision making will be faster and more consistent. It might also be more transparent, since the rules are now available in an external format—they’re no longer stored solely in people’s heads.
As this example shows, a BRE might be able to replace decisions made by people in a business process. It’s also possible for a process to use both decision-making approaches. In the example shown here, for instance, suppose that the decision criteria for some kinds of orders can’t be completely captured in formalized rules. It’s possible that along with the steps shown above, the process would also include a human workflow, perhaps implemented using Windows SharePoint Services. While a BRE might sometimes replace decisions made by people, the two can also be used together.
As the figure illustrates, the first three steps remain the same as in the previous scenarios. The decision to approve or reject a high-value order, however, is made by the BizTalk Server BRE (step 4) rather than by people. The BRE is invoked directly from the running orchestration, returning the result of its evaluation. As before, the order is then placed only if it was approved (step 5). If the rules underlying this decision can be expressed objectively and accurately, the benefit to the business process is clear: decision making will be faster and more consistent. It might also be more transparent, since the rules are now available in an external format—they’re no longer stored solely in people’s heads.
As this example shows, a BRE might be able to replace decisions made by people in a business process. It’s also possible for a process to use both decision-making approaches. In the example shown here, for instance, suppose that the decision criteria for some kinds of orders can’t be completely captured in formalized rules. It’s possible that along with the steps shown above, the process would also include a human workflow, perhaps implemented using Windows SharePoint Services. While a BRE might sometimes replace decisions made by people, the two can also be used together.
Workflow with SharePoint Services and BizTalk Server
Microsoft’s foundation solution for human workflow is Windows SharePoint Services, while BizTalk Server plays that role for system workflow. It shouldn’t be surprising that these technologies can be used together to implement a process combining human and system workflow. The figure below shows a simple example of how this might look.
The first three steps in this scenario are the same as in the system workflow example shown earlier: the inventory application sends an order request to BizTalk Server (step 1), and BizTalk Server requests (step 2) and receives (step 3) a purchase order from the ERP application. Now, however, let’s assume that the PO amount is sufficient to require approval from a group of managers at this firm. A human workflow implemented using Windows SharePoint Services is used to make this decision.
Once the orchestration has determined that this PO requires managerial approval, it uses a SharePoint adapter to add a document to a particular document library (step 4). As mentioned earlier, adding a new document to a library can automatically trigger execution of a SharePoint workflow, which is exactly what happens here. This workflow then executes as described earlier, adding tasks to the participants’ task lists. Each participant approves or rejects the order (step 5), and once all responses are in, the workflow adds information to the document previously created in this document library by the orchestration, an action not shown in this figure. BizTalk Server’s SharePoint adapter retrieves this modified document, something that’s also not shown, and if the order is approved, contacts the fulfillment application to place it (step 6).
Combining human and system workflow is the right approach for improving a number of business processes. As this example shows, Windows SharePoint Services and BizTalk Server can be used together to accomplish this. Two distinct workflows must be defined, using two different design tools, and those workflows will be executed by two separate workflow engines. Still, this combination can be used for business processes that require both kinds of workflow.
Once the orchestration has determined that this PO requires managerial approval, it uses a SharePoint adapter to add a document to a particular document library (step 4). As mentioned earlier, adding a new document to a library can automatically trigger execution of a SharePoint workflow, which is exactly what happens here. This workflow then executes as described earlier, adding tasks to the participants’ task lists. Each participant approves or rejects the order (step 5), and once all responses are in, the workflow adds information to the document previously created in this document library by the orchestration, an action not shown in this figure. BizTalk Server’s SharePoint adapter retrieves this modified document, something that’s also not shown, and if the order is approved, contacts the fulfillment application to place it (step 6).
Combining human and system workflow is the right approach for improving a number of business processes. As this example shows, Windows SharePoint Services and BizTalk Server can be used together to accomplish this. Two distinct workflows must be defined, using two different design tools, and those workflows will be executed by two separate workflow engines. Still, this combination can be used for business processes that require both kinds of workflow.
Subscribe to:
Posts (Atom)