cyphersec

Iterations are the heartbeat of an XP project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they’ve pumped out working, tested software for each story and are ready to begin the cycle again.

Iterations are exactly one week long and have a strictly defined completion time. This is a timebox: work ends at a particular time regardless of how much you’ve finished. Although the iteration timebox doesn’t prevent problems, it reveals them, which gives you the opportunity to correct the situation.

An iteration follow an unchanging schedule.

• Demonstrate previous iteration
• Hold retrospective on previous iteration
• Plan iteration
• Commit to delivering stories
• Develop stories
• Prepare release

Team usually start their iteration on Monday morning and end Friday evening. Some others start their iteration on Wednesday morning. They do this because it allows people to leave early on Friday or take Monday off without missing important events and also because it allows the team to conduct releases before the weekend, which is an important aspect of iteration planning.

Planning an iteration

After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the velocity of the previous iteration. Take all the stories that are “done done” and add up their original estimates. This number is the amount of story points we can reasonably expect to complete in the upcoming iteration.

With our velocity in hand, we can select the stories to work on the current iteration. Ask your customer to select the most important stories from the release plan. Select stories that exactly add up to the team’s velocity. You may need to split stories or include one or two less important stories to make the estimate add up perfectly.

Because the iteration planning meeting take stories from the front of the release plan, you should have already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only take a few minutes, with perhaps 10 or 15 minutes more to explain.

At this point, the real work of iteration planning begins. Start by breaking down the stories into engineering tasks.

Engineering tasks are task for programmers to complete. Unlike stories, engineering tasks don’t need to be customer-centric. Instead, they're programmer-centric. Typical engineering tasks include:

• Update build script
• Implement domain logic
• Add database table and associate ORM objects
• Create new UI form

Brainstorm the tasks you need in order to finish all the iteration’s stories. Some tasks will be specific to a single stories others not. Brainstorming tasks is a design activity. If everybody has the same ideas about how to develop the software, it should go fairly quickly. If not, it’s a great opportunity for discussion before coding begins. However you should not go into much details.

After you’ve finished brainstorming tasks, spread the out on the table and look at the whole picture. Are these tasks enough to finish all the stories? Are there any duplicates or overlaps? Discuss and fix any problem.

Afterwards go on with the next step required: Estimate the tasks.

As with brainstorming, this can occur in parallel, with individual programmers picking up cards,  writing estimates, and putting them back. Call out the estimates as you finish them. If you hear somebody call out an estimate you disagree with, stop to discuss it and come to consensus.

It’s important to estimate the tasks in ideal hours. How long would the task take if you had perfect focus on the task, suffered no interruptions, and could have the help of anybody on the team? Estimate them in person-hours as well: a task that takes a pair two hours is a four-hours estimate. If any of the tasks are bigger than six hours of effort, split them into smaller tasks and consequently combine small tasks that are less than an hour or two.

As final step, add up the estimates and compare them to the total task estimates from your previous iteration. Using this plan, you can commit to delivering all the stories? Is there any slack in the plan for dealing with unexpected problems?

Doing so, you may discover that you aren’t comfortable committing to the plan you have. If so, see if there are any tasks you can remove or simplify. Talk with your on-site customer. Can you replace a difficult part of a story with something easier but equally valuable? If not split or remove the story. Similarly, if you feel that you can commit to doing more, add a story to the plan.

Experience leads making plans that don’t need adjustment.

nTze Agile engineering tasks, estimates, Iteration planning, velocity

Good XP teams do achieve a stable velocity. Unfortunately, velocity only reflects the issues the team normally faces. Life always has some additional curve balls to throw. Team members get sick and take vacations; hard drive crash, and although the backups worked, the restore doesn’t; stakeholders suddenly realize that the software you’ve been showing them for the last two months needs some major tweaks before it’s ready to use.

Despite the uncertainties, your stakeholders need schedule commitments that they can rely upon. Risk management allows you to make and meet these commitments.

Risk Management Plan

Every project faces a set of common risks: turnover, new requirements, work disruption, and so forth. These risks act as a multiplier on your estimates, doubling or tripling the amount of time it takes to finish your work.

How much of a multiplier do these risks entail? It depends on your organization. Because most organizations don’t have this kind of information available we’ll use some based on the DeMarco & Lister’s RISKYOLOGY simulator.

These multipliers show your chances of meeting various schedules. For your example, in a “Risky"” approach, you have a 10 percent change of finishing according to your estimate schedule. Doubling your estimates gives you a 50 percent to chance of on-time completion, and to be virtually certain of meeting your schedule, you have to quadruple your estimates.

If you use the XP practices – in particular, if you’re strict about being “done done (agile principle number 7)” every iteration, your velocity is stable, and you fix all your bugs each iteration – then your risk is lowered. Use the risk multiplier in the “Rigorous” column. On the other hand, if you’re not strict about being “done done” every iteration, if your velocity is unstable, or if you postpone bugs and other work for future iterations, the use the risk multiplier in the “Risky column”.

Although these numbers come from studies of hundreds of industry projects, those projects didn’t use XP. As a result, it’s guessed somewhat at how accurately they apply to XP. However, unless your company has a database of prior projects to turn on, they are your best starting point.

Project-Specific Risks

Using the XP practices and applying risk multipliers will help contain the risks that are common to all projects. The generic risk multipliers include the normal risks of a flawed release plan, ordinary requirements growth, and employee turnover. In addition to these risks, you probably face that are specific to your project. To manage these, create a risk census – that is, a list of the risks your project faces that focuses on your project’s unique risks.

[DeMarco & Lister 2003] suggest starting work on your census by brainstorming catastrophes. Gather the whole team and hand out index cards. Remind team members that during this exercise, negative thinking is not only OK, it’s necessary. Ask them to consider ways in which the project could fail. Write several questions on the board:

1. What about the projects keep you up at night?
2. Imagine it’s year after the project’s disastrous failure and you’re being interviewed about what went wrong. What happened?
3. Imagine your best dreams for the project, then write down the opposite.
4. How could the project fail without anyone being at fault?
5. How could the project fail if it were the stakeholders’ fault? The customers’ faults? Testers? Programmers? Management? Your fault? Etc.

Write answers on the cards, then read the aloud to inspire further thoughts.

Once you have your list of catastrophes, brainstorm scenarios that could lead to those catastrophes. From those scenarios, imagine possible root causes. These root causes are your risks: the causes of scenarios that will lead to catastrophic results.

For example, if you’re creating an online application, one catastrophe might be “extended downtime". A scenario leading to that catastrophe would be “excessively high demand”, and root causes include “denial of service attack” and “more popular than expected”.

After you’ve finished brainstorming risks, let the rest of the team return to their iteration while you consider the risks within a smaller group. For each risk determinate:

1. Estimated probability (High, Medium, Low)
2. Specific impact to project if it occurs – pounds lost, days delayed, and project cancellation are more common possibilities.

You may be able to discard some risks as unimportant immediately. Ignore unlikely risks with low impact and all risks with negligible impact. Your generic risk multipliers accounts for those already.

For the remainder, decide whether you will avoid the risk by not taking the risky action; contain it by reserving extra time or money, as with the risk multiplier; or mitigate it by taking steps to reduce its impact. You can combine these actions.

For the risks you decide to handle, determinate transition indicators, mitigation and contingency activities, and your risk exposure:

• Transition indicators tell you when the risk will come true. It’s human nature to downplay upcoming risks, so chose indicators that are objective rather than subjective. For example, if your risk is “unexpected popularity causes extended downtime”, then your transition indicator might be “server utilization trend shows upcoming utilization over 80 percent”.
• Mitigation activities reduce the impact of the risk. Mitigation happens in advance, regardless of whether the risk comes to pass. Create stories for them and add them to your release plan. To continue the example, possible stories include “support horizontal scalability” and “prepare load balancer”.
• Contingency activities also reduce the impact of the risk, but they are only necessary if the risk occurs. They often depend on mitigation activities that you perform in advance.
• Risk exposure reflects how much time or money you should set aside to contain the risk. To calculate this, first estimate the numerical probability of the risk and then multiply that by the impact. When considering your impact, remember that you will have already paid for mitigation activities, but contingency activities are part of the impact.

Some risks have a 100 percent chance of occurring. These are no longer risk – they are reality. Update your release plan to deal with them.

For the remaining risks, update your release plan to address them. You will need stories for mitigation activities, and you may need stories to help you monitor transition indicators. For example, if you risk is “unexpected popularity overloads server capacity”, you might schedule the story “prepare additional servers in case of high demand” to mitigate the risk, and “server load trend report” to help you monitor the risk.

You also need to set aside time, and possibly money, for contingency activities. Don’t schedule any contingency stories yet – you don’t know if you’ll need them. Instead, add up your risk exposure and apply dollar exposure to the budget and day exposure to the schedule. Some risk will occur and others won’t, but on average, the impact will be equal to your risk exposure.

nTze Agile Agile, Done Done, Planning, Risk Management

nTze Pro ASP.NET ASP.net, SmptClient, System.Net, TimeSaver, Tricks

Projects start out as ideas focused on results.

eg: Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Open up a new market by offering a new service. The idea is so compelling that it gets funding, and the project begins.

Somewhere in the transition from idea to project, the compelling part – the vision of a better future – often gets lost. Details crowd it out. You have to hire programmers, domain experts, and interaction designers. You must create stories, schedule iterations, and report on progress. Hustle, people, hustle!

That’s a shame, because nothing matters more than delivering the vision. The goal of the entire project is to deliver the vision. If the details are perfect, but the vision is forgotten the the software will probably fail. Conversely, if you ship something that helps accomplish the vision, does it really matter how you did it?

Where the vision come from?

Sometimes the vision for a project strike as a single, compelling idea. One person gets a bright idea, evangelizes it, and gets approval to pursue it. This person is a visionary.

More often, the vision isn’t so clear. There are multiple visionaries, each with their own unique idea of what the project should deliver.

Either way, the project needs a single vision. Someone must unify, communicate, and promote the vision to the team and to stakeholders. That some is the product manager.

How to identity the vision

Like the children’s game of telephone, every step between the visionaries and the product manager reduces the product manager’s ability to accurately maintain and effectively promote the vision.

If you only have one visionary, the best approach is to have that visionary act as product manager. This reduces the possibility of any telephone-game confusion. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the project’s chances of delivering an impressive product.

If the visionary isn’t available to participate fully, as is often the case, someone else must be the product manager. Ask the visionary to recommend a trusted lieutenant: someone who has regular interaction with the visionary and understands how he thinks.

Documenting the Vision

After you’ve worked with visionaries to create a cohesive vision, document it in a vision statement. It’s best to do this collaboratively, as doing so will reveal areas of disagreement and confusion. Without a vision statement, it’s all too easy to gloss over disagreements and end up with an unsatisfactory product.

Once created, the vision statement will help you maintain and promote the vision. It will act as a vehicle for discussion about the vision and a touchpoint to remind stakeholders why the project is valuable.

Don’t forget that the vision statement should be a living document: the product manager should review it on a regular basis and make improvements. However, as a fundamental statement of the project’s purpose, it may not change much.

How to create a Vision Statement

The vision statement documents three things: what the project should accomplish, why it is valuable, and the project’s success criteria.

The vision statement can be short. Usually try to limit it to a single page. Remember, the vision statement is a clear and simple way of describing why the project deserves to exists. It’s not a roadmap; that’s the purpose of release planning.

In the first section – what the project should accomplish – describe the problem or opportunity that the project will address, expressed as an end result. Be specific, but not prescriptive. Leave room for the team to work out on details.

In the second section - describe why the project is valuable:

e.g. ”This product is so valuable to us because it gives us an opportunity to create an entrepreneurial product. Its success will allow us to form our own product company and make a good living doing work that we love.”

In the final section, describe the project’s “success criteria”: how you will know that the project has succeeded and when you will decide. Choose concrete, clear, and unambiguous targets.

Why vision is useful?

When your project has a clear and compelling vision, prioritizing stories is easy. You can easily see which stories to keep and which to leave out. Programmers contribute to planning discussions by suggesting ways to maximize value while minimizing development costs. Your release plan incorporates small releases that deliver value.

When the visionary promotes the vision well, everyone understands why the project is important to the company. Team members experience higher morale, stakeholders trust the team more, and the organization supports the project.

nTze Agile Agile, Communicate, Product Vision

In economics, a game is something in which “players select actions and the payoffs depend on the actions of all players”.

The planning game is a structured approach to creating the best possible plan given the information available.

XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what t will take to implement and maintain those features, To be successful, the team needs to maximize value while minimizing costs. A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.

Accordingly, the planning game requires the participation of both customers and programmers. It’s a cooperative game; the team as a whole wins or loses, not individual players.

Because programmers have the most information about costs – they’re most qualified to say what is important – they prioritize.

During the planning game, programmers and customers may ask each other questions about estimates and priorities, but each group has final say over its area of expertise.

The result of the planning game is a plan: a single list of stories in priority order. Even if two stories are of equivalent priority, one must come before the other. If you’re not sure which put first, pick one at random.

How to win

When customers and programmers work directly together throughout this process, something amazing happens. It’s called the miracle of collaboration. It really is a miracle because time appears out of nowhere.

Like all miracles, it’s not easy to achieve. When programmers give an estimate, customers often ask a question that cause every programmer’s teeth to grind: “Why does it cost so much?” The instinctive reaction to this question is usually quite defensive: “It costs so much because software development is hard, damn it! Why are you questioning me?”

There’s always a better way to react. Reword the customer’s question in your head into a simple request for information: “Why is this expensive?” Answer by talking about what’s easy and what’s difficult.

For example, imagine that a product manager requests a toaster to automatically pop up the toast when it finishes. The programmer reply that the feature is very expensive, and when the product manager asks why, the programmer calmly answer, “Well, popping up the toast is easy; that’s just a spring. But detecting when the toast is done – that’s new. We’ll need an optical sensor and some custom brownness-detecting software”.

This gives the product manager an opportunity to ask, “What’s about all those other toasters out there?” How do they know when the toast is done?”.

The programmer respond, “They use a timer, but that doesn’t really detect when the toast is done. It’s just kludge.”

Now the product manager can reply: “That’s OK! Our customers don’t want a super toaster. They just want a regular toaster. Use a timer like everyone else.”

Programmer: “Oh, OK. Well, that won’t be expensive at all”.

When you have honest and open dialog between customers and programmers, the miracle of collaboration occurs and extra time appears out of nowhere.

Without communication, the customers tend not to know what’s easy and what’s not, and they end up planning stories that are difficult to implement. Similarly, programmers tend not to know what customers think is important, and they end up implementing stories that aren’t valuable.

With collaboration, the conflicting tendencies can be reconciled. For example, a customer could ask for something unimportant but difficult, and the programmers could point out the expense and offer easier alternatives. The product manager could then change directions and save time. Time appears out of nowhere. It’s the miracle of collaboration.

nTze Agile Agile, Collaborate, Communicate, Understanding

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction"

Albert Einstein

nTze riflessioni famous quotes, simplicity

For the fourth time, Forbes Magazine has published its annual Best Countries for Business ranking. For the second straight year Denmark has taken the No.1 spot.

Best Countries for Business:
1. Denmark
2. USA
3. Canada
4. Singapore
5. New Zealand
6. United Kingdom
7. Sweden
8. Australia
9. Hong Kong
10. Norway

Forbes analysed business climates in each of 127 national economies, focusing on degrees of trade freedom, monetary freedom like the right to participate in free and fair elections, or freedom of expression and organization.

The Criteria

• Trade Freedom
• Monetary Freedom
• Property Rights
• Innovation
• Technology
• Red Tape
• Investor Protection
• Corruption
• Personal Freedom
• Tax Burden
• Market Performance

Forbes used the following sources: Heritage Foundation (Economic Freedom Index); World Economic Forum (Global Competitiveness Report); Transparency International (Corruption Perceptions Index); Freedom House (Personal Freedom Index); Deloitte (World Tax Rates); World Bank (Doing Business); Central Intelligence Agency (World Factbook); Property Rights Alliance (International Property Rights Index).

Source: Forbes Best Countries for Business

nTze riflessioni

"We are all responsible for high quality code"

There's a metric for the risk imposed by concentrating knowledge in just a few people's head. It's called truck number. How many people can get hit by a truck before the project suffers irreparable harm?

What happens when a critical person goes on holiday, stays home with a sick child, takes a new job, or suddenly retires?

How much time will your department spend training a replacement?

 
Collective code ownership spreads responsibility for maintaining the code to all the programmers.

Collective code ownership is exactly what it sounds like: everyone shares responsibility for the quality of the code. No single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere.

In fact, improved code quality may be the most important part of collective code ownership. Collective ownership allows everyone to fix problems they find. If you encounter duplication, unclear names, or even poorly designed code, it doesn't matter who wrote it. It's your code. Fix it!

Collective code ownership requires letting go of a little of ego. Rather than taking pride in your code, take pride in your team's code.

Rather than complaining when someone edits your code, enjoy how the code improves when you're not working on it. Rather than pushing your personal design vision, discuss design possibilities with the other programmers and agree on shared solutions.

Collective ownership requires a joint commitment from the team members to produce good code. When you see a problem, fix it. When writing new code, don't do a half-hearted job and assume somebody else will fix your mistakes. Write the best code you can.

On the other hand, collective code ownership means you don't have to be perfect. If you've produced code that works, is of reasonable quality, and you're not sure how to make it better, don't hesitate to let it go. Someone else will improve it later, if and when it needs it.

nTze Agile

The longer you wait to fix a bug, the more it costs to fix.

In addition, unfixed bugs probably indicate further problems. Each bug is the result of a flaw in your system that's likely to breed more mistakes. Fix it now and you'll improve both quality and productivity.

To fix the bug, start by writing an automated test that demonstrates the bug. It could be a unit test, integration test, or customer test, depending on what kind of defect [bug/errors] you've found. Once you have failing test, fix the bug. Get a green bar.

Don't congratulate yourself yet - you've fixed the problem, but you haven't solved the underlying cause. Why did that bug occur? Discuss the code with your pairing partner. Is there a design flaw that made this bug possible? Can you change an API to make such bugs more obvious?  Is there some way to refactor the code that would make this kind of bug less likely? Improve your design. If you've identified a systemic problem, discuss it with the rest of your team in your next stand-up meeting or iteration retrospective. Tell people what went wrong so they can avoid that mistake in the future.

Fixing bugs quickly requires the whole team to participate. We, Programmers, use collective code ownership so that any pair in our team can fix a buggy module. Customers and testers, personally bring new bugs to the attention of a programmer and help him reproduce it. These actions are easiest when the whole team sits together.

In practice, it's not possible to fix every bug right away. You may be in the middle of working on something else when you find a bug. When this happens, ask your navigator to write the problem on your to-do list. Come back to it when you come to a good stopping point.

Some bugs, are too big to fix while you're in the middle of another task. For these, write the bug  a story card and announce it to the team.

Collectively decide if there's enough slack in the iteration to fix the bug and still meet your other commitments. If there is, create tasks for the newly created story and pairs volunteer for the as normal. When your only task is "fix the bug" consider using the story card as its own task card.

If there isn't enough slack to fix the bug, estimate the cost to fix it and ask the product manager to decide whether to fix it in the current release. If it's important enough to fix, schedule it into the very next iteration.

nTze Agile

The SDL Process Template is a downloadable template that leverages the technology of Visual Studio Team System (VSTS) and Team Foundation Server (TFS) to automatically integrate the policy, process and tools associated with the Security Development Lifecycle v4.1into your software development environment.

• Installs SDL requirements as work items
• Includes SDL-based check-in policies
• Customizes security bugs and queries
• Includes extensive SDL how-to and guidance documentation

• Generates auditable Final Security Review report
• Accommodates third-party tool integration, e.g. the SDL Threat Modeling Tool
• Includes project plans and security risk assessment templates

source : http://msdn.microsoft.com/en-us/security/dd670265.aspx | http://blogs.msdn.com/sdl/archive/2009/05/19/making-secure-code-easier.aspx

nTze .NET