SCRUM

Definitions

1.     User Stories: User stories are a set of sentences that describe what the user experiences while using the software. These can be derived from the wireframes; design comps aren’t a requirement. 

2.    Backlog: These user stories go into a “Backlog”. This backlog is a list of all the user stories, say 50… or a hundred. How many user stories you have are irrelevant. What’s important is that they are all documented in one place called the Backlog. You need to ensure all of the user stories are valid with the stake holders. It also helps to go over them with your entire team to ensure they make sense to everyone involved. 

3.    Point System: Once you are done with your backlog, you then have your team go through and assign points to each user story. To do that, you need a Point System. A point system is defining a metric for “how challenging something is”. In simple terms, a 1 is easy and a 5 is hard. It doesn’t have to be 1 through 5; it could be 1 through 10 or whatever. It’s best if they are numeric values because you use the points to measure a variety of statistics about your project. Additionally, each team may have their own definitions of what is challenging. While it’s best to use the same 1-whatever metric for the client and server team, the server team will most likely think creating a new server-side method a “1-easy” whereas a client developer a “5-hard”. 

4.    Sprint: Sprints are a period of time that your team works on their assigned user stories. A sprint is however long your team decides it should be to get a working build with the user stories assigned. This could be one week, two, or a month. It’s important to note the “uninterrupted” part. The client and project manager won’t interject user stories mid-sprint, nor modify your work load. Basically, they don’t bother you. This allows your team to focus on the task at hand, prevent fire drills, and stay productive. 

5.       Daily Stand-ups: Each team member goes around talking about what they have completed yesterday, this morning, and what they plan for rest of the day. Team also cites’ any roadblocks or issues, and if that involves another team member, They  just schedule a separate call, or time to talk over IM, with that specific person.

 Roles

Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken.

·        “Pig” roles

The Pigs are the ones committed to the project in the Scrum process – they are the ones with “their bacon on the line.”

1.       Product Owner

The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog.

2.      ScrumMaster (or Facilitator)

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.

3.      Team

The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

·        “Chicken” roles

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an Agile approach is the practice of involving users, internal business groups and stakeholders into portions of the process. It is important for these people to be engaged in the outcome of the project by providing feedback into the development, its review and planning for each sprint.

1.       Users

The software is being built for someone. “If software is not used”—much like “the tree falling in a forest” riddle—”was it ever written?”

2.      Stakeholders (customers, vendors)

These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

3.      Managers

People who will set up the environment for the product development organizations.

  Meetings

1.       Daily Scrum

Each day during the sprint, a project status meeting occurs. This is called a “scrum”, or “the daily standup”. The scrum has specific guidelines:

§  The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)

§  All are welcome, but only “pigs” may speak

§  The meeting is timeboxed at 15-20 minutes depending on the team’s size

§  All attendees should stand (it helps to keep meeting short)

§  The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions:

§  What have you done since yesterday?

§  What are you planning to do by today?

§  Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

2.      Sprint Planning Meeting

At the beginning of the sprint cycle (every 15–30 days), a “Sprint Planning Meeting” is held.

§  Select what work is to be done

§  Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team

§  Identify and communicate how much of the work is likely to be done during the current sprint

§  Eight hour limit

3.      Sprint Review Meeting

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective

§  Review the work that was completed and not completed

§  Present the completed work to the stakeholders (a.k.a. “the demo”)

§  Incomplete work cannot be demonstrated

§  Four hour time limit

4.      Sprint Retrospective

§  All team members reflect on the past sprint.

§  Make continuous process improvement.

§  Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

§  Three hour time limit

 Artifacts

1.     Product backlog

The product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritised by business value. It is the “What” that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI is higher.

The product backlog is property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.

2.    Sprint backlog

The sprint backlog is a greatly detailed document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.

The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

3.    Burn down

The burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

It should not be confused with an earned value chart.

 

Low Latency Applications (Problems in development)

Definition: Latency can be defined as an application receiving the external interrupt and the process thread responding to it.

Problems with developing low latency applications:

1.       Memory Locking: All operating systems have virtual memory which implies that they pretend to have mode physical memory than is present at any given time. The physical memory is extended using paging on demand. As paging involves disk subsystem it takes more time compared to the data fetch from the physical memory.

2.       Early Binding: Since C# uses JIT compilation all the application and its reference dependencies are compiled at run time. This takes a lot of performance hit.

3.       Processor Binding: Most of the time applications have multiple threads running in a process. Since OS scheduling keeps on changing the thread , the efficiency of the code handled by the thread reduces.

Pulling data from USASpending.gov

So i found this great post by doug finke on his blog where he has show implementation for retrieving data from usaspending website using Power Shell and LinqToXml here are my implmentation on C# and F#

ccode1

 

 

 

 

here is F# implementation.

 

fcode1

Learning LINQ

I came across the blog of Eric White and this is the best material to learn linq i have seen.

http://blogs.msdn.com/ericwhite/pages/FP-Tutorial.aspx

Talks about functional programming and who C# implements functional programming using Linq.

Here one more link for learning LINQ technology.
http://www.linqhelp.com/

Posted in .Net, LINQ. Tags: . Leave a Comment »

Unity 1.2

Some thing to really look at new functionalities like Circular references with dependency injection, Interception with Unityhttp://unity.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=18855

MapReduce in F#

I came across the following link on MapReduce implementation in F#

http://www.twine.com/item/1229c60s4-4q/exploring-mapreduce-with-f

Also Microsoft is working on C# implementation known as LINQ to DataCenter.

For those who don’t know MapReduce should think twice as anyone using google search is the user of MapReduce algorithm.

Wikipedia has clear explanation of the MapReduce http://en.wikipedia.org/wiki/MapReduce

Posted in F#. Tags: . 1 Comment »

WPF ConverterParameter

Just came to my knowledge and want share with people. 

<TextBlock Text=”{Binding Path=ABCD, Converter={StaticResource FormatConv}, ConverterParameter=’{0:C}’}” />

The above code wont work i know there is nothing wrong in there but still compiler would complianed about it.

One needs to add {}  in the ConverterParameter value and that will solve the problem.

ConverterParameter=’{}{0:C}’

Posted in WPF. Tags: . Leave a Comment »

Functional Fibonnaci series in C#

C# code for functional fibonnaci numbers

Func<int, int> fib = null;
fib = n => n > 1 ? fib(n – 1) + fib(n – 2) : n;

Okay so you guys would think why would i declare the delegate in one line and instantiate in the next. The reason is that if you do everything in same line complier wont recognize the recursive call using the delegate. Try this 

Func<int, int> fib = n => n > 1 ? fib(n – 1) + fib(n – 2) : n;

Above code wont compile 

Haskell code for same 
fib n
| n == 0 = 0
| n == 1 = 1
| n > 1 = fib (n-1) + fib (n-2)

New Class in .Net 4.1

Came across a new class in framework .Net 4.1 StringOr<TOther>

public class StringOr<TOther> {
public StringOr(string stringValue, TOther otherValue);

public string StringValue { get; }
public TOther OtherValue { get; }
}

There are lot of situations where you store datetime and other values in string simply because they are not formatted correctly or there are chances that database may or may not return a value which can be converted to exact format.

StringOr<int> userInput= GetUserInput(“Quantity”);
string szUserInput=userInput.StringValue;
int intUserInput=userInput.OtherValue;

Here is the solution to that problem.

Posted in .Net, C#. Tags: . Leave a Comment »

C# functional programming

Finally i have decided to write on how we can achieve  funcational programming in C#.

Lets start with defining a function 
Math: f(x) = x
C#: Action<int> f = x =>x;
Math : f(x) =  6x + 2
C#: Func<int,int> f = x=> 6*x + 2;
Math: f(x,y) = 2x+ 3y
C#: Func<int,int,int> f = (x,y) => 2*x + 3*y;
function which returns a function
Func<int,Func<int,int>> fg = x => (y => y + x);