Scenarios and Goals of the Security Application Block
- Obtaining a temporary token for an authenticated user
- Authenticating a user using a token
- Ending a user session (expire a token)
- Determining if a user is authorized to perform a task
- Authorization
- Security-related caching and session management
 Note: |
|---|
| If you use the Security Application Block to cache security-related information, the default caching store provider for the security cache is the Caching Application Block. Although the Caching Application Block can be configured to encrypt cache data in backing stores, the application block does not support encryption of cache data stored in memory. If an attacker compromises the computer and accesses the memory of your process, he or she can access information stored in the cache. If this threat is significant for your application, you should avoid storing sensitive information such as credit card numbers or passwords in the cache or use an alternate caching store provider that supports in-memory encryption. |
Some Results From Scrum
The benefits of Scrum reported by teams come in various aspects of their experience. At
Yahoo!, we have migrated nearly 90 projects to Scrum in the last 30 months, totaling almost
900 people, and the list of teams using it is quickly growing. These projects have ranged from consumer-facing, design-heavy websites like Yahoo! Photos, to the mission-critical back-end infrastructure of services like Yahoo! Mail, which serves hundreds of millions of customers; they range from entirely new products like Yahoo! Podcasts, which used Scrum from concept through launch (and won a Webby Award for best product in its category that year), to more incremental projects, which included work on new features as well as bug fixes and other maintenance; and we’ve used Scrum for distributed projects, where the team is on separate continents. Several times each year we survey everyone at Yahoo! that is using Scrum (including Product Owners, Team Members, ScrumMasters, and the functional managers of those individuals) and ask them to compare Scrum to the approach they were using previously. Some summary data is presented here:
ƒ Productivity: 68% of respondents reported Scrum is better or much better (4 or 5 on a 5-
point scale); 5% reported Scrum is worse or much worse (1 or 2 on a 5-point scale); 27%
reported Scrum is about the same (3 on a 5-point scale).
ƒ Team Morale: 52% of respondents reported Scrum is better or much better; 9% reported
Scrum is worse or much worse; 39% reported Scrum is about the same.
ƒ Adaptability: 63% of respondents reported Scrum is better or much better; 4% reported
Scrum is worse or much worse; 33% reported Scrum is about the same.
ƒ Accountability: 62% of respondents reported Scrum is better or much better; 6%
reported Scrum is worse or much worse; 32% reported Scrum is about the same.
ƒ Collaboration and Cooperation: 81% of respondents reported Scrum is better or much
better; 1% reported Scrum is worse or much worse; 18% reported Scrum about the same.
ƒ Team productivity increased an average of 36%, based on the estimates of the
Product Owners.
ƒ 85% of team-members stated that they would continue using Scrum if the decision
were solely up to them.
Posted in: Software Programming| Tags: Benefit Result Productivity Morale Team Morale Adaptability Accountability Colaboration Cooperation Team Productivity Team MemberCommon Challenges in Scrum
Scrum is not a process – rather, it’s a framework which provides a lot of visibility to the team, and a mechanism that allows them to “inspect and adapt” accordingly. Scrum works by making visible the dysfunction and impediments that are impacting the team’s effectiveness, so that they can be addressed. For example, most teams are not good at estimating how much they can get done in a certain period, and so will fail to deliver what they committed to in the first Sprint. To the team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about their commitments, and also being even more committed to delivering what they signed up for. This pattern – of Scrum helping make visible dysfunction, enabling the team to do something about it – is the basic mechanism that produces the most significant benefits which teams using Scrum experience.
One very common mistake teams make, when presented with a Scrum practice that challenges them, is to change the practice, not change themselves. For example, teams that have trouble delivering on their Sprint commitment might decide to make the Sprint duration extendable, so they never run out of time – and in the process, ensure they never have to learn how to do a better job of estimating and managing their time. In this way, without training and the support of an experienced Scrum coach, teams can morph Scrum into just a mirror image of their own weaknesses and dysfunction, and undermine the real benefit that Scrum offers: Making visible the good and the bad, and giving the team the choice of elevating itself to a higher level.
Another common mistake is to assume that a practice is discouraged or prohibited just because Scrum doesn’t specifically require it. For example, Scrum doesn’t specifically require the Product Owner to set a long-term strategy for his or her product; nor does it require engineers to seek advice from more experienced engineers about complex technical problems. Scrum leaves it to the individuals involved to make the right decision; and in most cases, both of these practices (along with many others) would be well-advised.
Something else to be wary of is managers imposing Scrum on their teams; Scrum is about giving a team space and tools to self-organize, and having this dictated from above is not a recipe for success. A better approach might begin with a team learning about Scrum from a peer or manager, getting comprehensively educated in professional training, and then making a decision as a team to follow the practices faithfully for a defined period (say, 90 days); at the end of that period, the team will evaluate its experience, and decide whether to continue.
The good news is that while the first Sprint is often very challenging to the team, the benefits of Scrum tend to be visible by the end of it, leading many new Scrum teams to exclaim: “Scrum is hard, but it sure is a whole lot better than what we were doing before!”
Posted in: Software Programming| Tags: Scrum Benefit Programming Common Challenge team Elevate Approch Thoughtful CommitmentResults From Scrum
The benefits of Scrum reported by teams come in various aspects of their experience. At
Yahoo!, we have migrated nearly 90 projects to Scrum in the last 30 months, totaling almost
900 people, and the list of teams using it is quickly growing. These projects have ranged from consumer-facing, design-heavy websites like Yahoo! Photos, to the mission-critical back-end infrastructure of services like Yahoo! Mail, which serves hundreds of millions of customers; they range from entirely new products like Yahoo! Podcasts, which used Scrum from concept through launch (and won a Webby Award for best product in its category that year), to more incremental projects, which included work on new features as well as bug fixes and other maintenance; and we’ve used Scrum for distributed projects, where the team is on separate continents. Several times each year we survey everyone at Yahoo! that is using Scrum
(including Product Owners, Team Members, ScrumMasters, and the functional managers of those individuals) and ask them to compare Scrum to the approach they were using previously.
Some summary data is presented here:
Productivity: 68% of respondents reported Scrum is better or much better (4 or 5 on a 5- point scale); 5% reported Scrum is worse or much worse (1 or 2 on a 5-point scale); 27% reported Scrum is about the same (3 on a 5-point scale).
Team Morale: 52% of respondents reported Scrum is better or much better; 9% reported
Scrum is worse or much worse; 39% reported Scrum is about the same.
Adaptability: 63% of respondents reported Scrum is better or much better; 4% reported
Scrum is worse or much worse; 33% reported Scrum is about the same.
Accountability: 62% of respondents reported Scrum is better or much better; 6% reported Scrum is worse or much worse; 32% reported Scrum is about the same.
Collaboration and Cooperation: 81% of respondents reported Scrum is better or much better; 1% reported Scrum is worse or much worse; 18% reported Scrum about the same.
Team productivity increased an average of 36%, based on the estimates of the
Product Owners.
85% of team-members stated that they would continue using Scrum if the decision were solely up to them.