written by: Admin on May 23rd, 2014
Software development is a team effort and making sure the whole team is on the same page is vital to the process.
Buy one class scheduled in July or August and receive a second seat in the same class for free!
This is a great way to supplement training for your entire team. Enter code: SAVE2014BOGO at checkout to receive the discount. When registering, specify “2” in the quantity box; the discount will not be recognized unless you specify you want the second seat. You may also call one of our Training Advisors to register for the course. Second seat is available when first seat is purchased at list price and cannot be combined with other offers.
Click to continue »
written by: Mary Repetto on July 23rd, 2014
That is a question we, as facilitators of use case workshops, often get asked and it is a good one. My favorite answer for all sorts of questions is that “It depends”. Is it a large system with all sorts of functions or a small with just a few.
Use cases describe functions of the system in a sequential way that shows the steps it takes to complete the function or process of the system. So, let’s think about who is using the system and just what they need to do. Once we define everything that needs to be done and get it approved by the sponsor, we have defined the functional scope. Now we sit down and write a use case for each process or function we have identified.
So, how many uses cases are there in the system? Well, I guess “it depends”!
written by: Melissa Monroe on July 18th, 2014
Scrum is one of the many subsets of the agile methodology. It places an emphasis on the idea of “empirical process control” which means Scrum uses the actual progress of a project to plan and schedule releases. Projects are broken down into brief work cadences, called sprints. Sprints usually last between one to three weeks. After each sprint stakeholders and team members meet to evaluate the progress of a project and plan its next steps. This approach allows a project’s direction to be changed based on finished work, instead of speculation or predictions. Scrum works because it has a simple set of unchanging roles, responsibilities, and meetings. Scrum not only provides flexibility but stability that teams can rely on when development gets hectic.
Scrum has three roles: Product Owner, ScrumMaster, and team member.
Responsible for communicating the vision of the product to the development team. They also represent the customer’s interests through requirements and prioritization.
Acts as a facilitator for the Product Owner and the team. They work to remove any obstacles that are preventing the team from achieving its sprint goals. They also advise the Product Owner about how to maximize ROI for the team.
Responsible for completing work. Ideally, teams are made of seven cross-functional members, plus or minus two individuals. The team is responsible for deciding how it will complete the work for each sprint.
written by: Mary Repetto on July 16th, 2014
I’m not sure anyone else has ever called use cases beautiful, but they really are!
Use cases tell a story from beginning to end in a way that makes sense to all sorts of folks including extreme opposites like developers and business users. In the use case we set up the story and give you a short summary, we tell you who all the key stakeholders are and we tell you what should happen and how it is supposed to end. Then we go through some steps to actually tell the story from the actor’s perspective…what they see happening when they interact with the system and whether or not the story has a happy ending and, if not, just exactly how it does end.
So now when I sit down with my stakeholders and ask them to review the requirements, I can actually just tell them a story. And, isn’t that beautiful?
written by: Melissa Monroe on July 14th, 2014
Something that isn’t talked about often is the tradeoff between schedule and cost. To a certain extent on software projects it is possible to deliver a project faster by adding more people, but at what cost?
Whenever additional human resources are allocated to a project, it may often reduce the time to complete, but it also can add to the overall “person months”. These “person months” account for misunderstandings between team members, miscommunication, and other human errors. Additional “person months” can often make a project more expensive to deliver, if the added resources do not entirely counteract by reducing the time to deliver by a proportional amount.
This phenomenon shows that there is a tradeoff between schedule and cost. Schedule typically wins. This can be explained by an article in the Harvard Business Review in 1988. In this article George Stalk Jr. said that the next source of competitive advantage was time. Companies may want to get things at the lowest price possible but not at the expense of schedule. Shortening development cycles and releasing new products faster create a competitive advantage that is often more important than developing products at the lowest cost.
However, a shorter schedule is not a priority all of the time. Optimizing for schedule and optimizing for cost have subtle, but important, differences in how an Agile process could be applied.
Optimizing for schedule means following standard Agile advice and having the designer work as closely as possible with the team. Ideally, user interface designs are done in the same sprint as the rest of the development work but exceptions can be made for complex interfaces where the designer may work a sprint ahead of the team. By having the designer work closely with the team the schedule is shortened but there are potential expenses due to reworking design inconsistencies discovered over multiple sprints. Additional costs could also come because the programmers are idle for periods, waiting for the most recent design.
Optimizing for cost in some ways means doing the opposite of optimizing for schedule. When optimizing for cost the designer works as far ahead as possible while avoiding designing ideas that are hard to implement and designing things that are not needed. The designer should not try to make a perfect design of every screen that will be part of the system but, if cost is more important than schedule, it may be best for the designer to work ahead of the development group.
written by: Mary Repetto on July 9th, 2014
Wouldn’t it be nice on each project if we, the Business Analysts, were given a thorough and exhaustive list of the key stakeholders for our project? I can tell you right now, that that list does not exist anywhere…promise!
And yet what happens on a project if, in gathering requirements, we miss a stakeholder. OMG, that could derail the entire event if this person is truly a player.
What normally happens is that we are given a few names to contact…a SME, a manager here or there…and we run with it hoping not to miss a thing. However, we usually do and that creates rework nightmares. The trick is that EVERY time we interview a stakeholder we ask that person “Who else should I be talking to? Who else impacts the project or is impacted by it?” Don’t wait for the names to come on a silver platter.
written by: Melissa Monroe on July 7th, 2014
Agile engineering serves as the foundation for those who are developing software following the Agile ideals. Two common Agile processes that are useful for their explicit Agile engineering practice systems are Extreme Programming and Feature Driven Development. These two practices come from very different origins; therefore, they have very distinct features.
Extreme Programming (XP)
The use of pair programming can be critically important when developing in dynamic language. Many errors of all sizes are identified up-front which is vital for decreasing error-corrections and code re-execution cycles.
Engineering practices of Extreme Programming:
- Pair Programming
- Test Driven Development/Unit Testing
- Continuous Integration
- Acceptance Testing
- Small Releases
Click to continue »
written by: Mary Repetto on July 3rd, 2014
Not exactly the words you think of as you ponder the profession of business analysis, are they?
Creativity is about producing something new or a new application for something old. Within the business is a wealth of creative talent and it is the analyst who must facilitate the extraction of these untapped, great ideas. Who has thought longer and harder about the challenges faced everyday with their current processes than the business…it’s too bogged down, to much paperwork, too many hands touch the deliverable? The expert facilitator can tap these dormant ideas and bring them to the fore.
After all, creativity is about change…change for the better.