Thursday, June 13, 2013

C# Delegates



A delegate is a C# language element that allows you to reference a method. A delegate is a reference type variable that holds the reference to a method. The reference can be changed at runtime. A delegate in C# is similar to a function pointer in C or C++. Using a delegate allows the programmer to encapsulate a reference to a method inside a delegate object. The delegate object can then be passed to code which can call the referenced method, without having to know at compile time which method will be invoked. Unlike function pointers in C or C++, delegates are object-oriented, type-safe, and secure.

Delegates are especially used for implementing events and the call-back methods. All delegates are implicitly derived from the System.Delegate class.
A delegate type maintains three important pices of information :
  1. The name of the method on which it make calls.
  2. Any argument (if any) of this method.
  3. The return value (if any) of this method.
Declaring Delegates
Delegate declaration determines the methods that can be referenced by the delegate. A delegate can refer to a method, which have the same signature as that of the delegate.

Syntax for delegate declaration is:
delegate <return type> <delegate-name> <parameter list>

Example:
using System;   
 
delegate void MyDelegate();
 
public class MyApp
{
    static void Main()
    {
        MyDelegate delegate1 = new MyDelegate(MyFunction);
        delegate1();
    }
 
    static void MyFunction()
    {
        Console.WriteLine("Calling MyFunction");
    }
}
We declare a delegate, create an instance of the delegate and invoke it.
delegate void MyDelegate();
This is our delegate declaration. It returns no value and takes no parameters.
MyDelegate delegate1 = new MyDelegate(MyFunction);
We create an instance of the delegate. When called, the delegate will invoke the static Callback() method.
delegate1 ();
We call the delegate.
Output.
$ ./simple.exe 
Calling MyFunction
Example2:
using System;
 
 
public delegate void NameDelegate(string msg);
 
public class Person 
{
    public string firstName;
    public string secondName;
 
    public Person(string firstName, string secondName)
    { 
        this.firstName = firstName;
        this.secondName = secondName;
    }
 
    public void ShowFirstName(string msg)
    {
        Console.WriteLine(msg + this.firstName);
    }
 
    public void ShowSecondName(string msg)
    {
        Console.WriteLine(msg + this.secondName);
    }
}
 
public class CSharpApp
{
    public static void Main()
    {
        Person per = new Person("Fabius", "Maximus");       
 
        NameDelegate nDelegate = new NameDelegate(per.ShowFirstName);
        nDelegate("Call 1: ");
 
        nDelegate = new NameDelegate(per.ShowSecondName);
        nDelegate("Call 2: ");     
    }
}
In the example we have one delegate. This delegate is used to point to two methods of the Person class. The methods are called with the delegate.
public delegate void NameDelegate(string msg);
The delegate is created with a delegate keyword. The delegate signature must match the signature of the method being called with the delegate.
NameDelegate nDelegate = new NameDelegate(per.ShowFirstName);
nDelegate("Call 1: ");
We create an instance of a new delegate, that points to the ShowFirstName() method. Later we call the method via the delegate.
$ ./simpledelegate.exe 
Call 1: Fabius
Call 2: Maximus
Both names are printed via the delegate.

Multicasting of a Delegate

Delegate objects can be composed using the "+" operator. A composed delegate calls the two delegates it was composed from. Only delegates of the same type can be composed. The "-" operator can be used to remove a component delegate from a composed delegate.
Using this useful property of delegates you can create an invocation list of methods that will be called when a delegate is invoked. This is called multicasting of a delegate.
covariance means we can substitute derived type in place of base type. Contravariance means we can substitute base class in place of derived class

Wednesday, June 12, 2013

Scrum Overview



Abbreviations
PO – Product Owner
SM – ScrumMaster
PMP – Project Management Process
SAL – Scrum Adherence Level

SCRUM Terminology
The SCRUM process consists of following
Sprints: These are the delivery iterations. Mostly last for 2-3 weeks. Every sprint will develop functionality (increment) which is useful to end user.
Development Team: This is the team of developers who is responsible for delivering the increment.
SCRUM Master: A person who understands SCRUM methodology and is responsible for setting up all the meetings and helping the team to deliver the increments.
Product Owner: The person who defines the characteristics of the product. Not necessarily the user of the product.
Sprint planning meeting: Meeting to plan the scope of the sprint.
Sprint review meeting: Retrospective after each sprint. To identify the improvements over last sprint and improvement opportunities.
Product Backlog: This is nothing but the product requirements listed in order of priority.
Sprint Backlog: A list of task items which will be executed by development team in a sprint (part of product backlog)
Burn down Chart: This document lists down the tasks, estimated time to complete the same and team members performing the task. The unit for measurement is “hours remaining” to complete the task. It should be a straight line.
Daily SCRUM: A status check meeting which occurs every day. Everybody has to stand so that this finishes in less than 20 minutes.
Increment: An increment of product which can be used by end users.

Scrum Roles
In Scrum there are typically 3 clearly defined roles:

·        the Product Owner,
·        the Scrum Master, and
·        the Scrum Team.
 
1.     the "Product Owner", who represents the stakeholders and the business
2.     the "Scrum Master", a facilitator and project manager, acts as an advocate for the Scrum process.
3.     the "Team", a cross-functional group of around 7 people
These three roles are always needed and should people in these roles should be committed to the Scrum process and the project. 

Responsibilities of the Product Owner
·         Defines and adjusts the features of the product
·         Writes user stories and places them in the product backlog
·         Prioritizes items in the Product Backlog according to customer/market value
·         Accepts or rejects work results
·         Decides on release date and content
·         The Product Owner cannot also be the Scrum Master, however the Product Owner may sometimes be a member of the Scrum Team
Challenges of being the Product Owner
·         Be willing to make hard choices during the sprint planning meeting.
·         Resist temptation to add more important work after a Sprint is already in progress.
·         Balance the interests of competing stakeholders.
·         Resist the temptation to "manage" the team, even if team members request intervention with issues that the team should sort out itself.
 
The Scrum Master is also responsible for removing any impediments or obstacles faced by the team.
·         The Scrum Master is a member of the Scrum Team
·         The Scrum Master cannot be the Product Owner
Responsibilities of the Scrum Master
·         Removes impediments (obstacles) and makes sure that the team is fully functional and productive
·         Ensures that the Scrum process is followed
·         Updates burndown chart and maintains the Scrum board
·         Facilitates Sprint Planning, Daily Scrum and Retrospective meetings
·         Maintains the Sprint backlog
·         Supports the Product Owner; including communicating updates and impediments as well as assisting with backlog and release plan maintenance
·         Ensures that the team’s progress, status and success is highly visible to all stakeholders, including the team itself
·         Facilitate creativity and empowerment for the development team
·         Shields the team from external interferences
Cross-Functional Scrum Team
The Scrum team are the people who do the actual analysis, design, implementation and testing required to complete the features, stories or tasks in a given sprint. The Scrum team is self-organizing, there is no command and control. Everyone in the Scrum team is equally responsible for determining the most suitable way to proceed.
·         Agrees on the sprint goal with the product owner and specifies in detail the work needed to accomplish this goal
·         Demonstrates the work results to the Product Owner
·         Scrum team has the authority to do whatever is needed to meet its commitments.
·         Self-organizing; Organizes itself and its work
·         Cross-functional; team members have all the required skills and expertise to complete the tasks given to the team
 
Ideal Team Size for Scrum
The team should ideally consist of 7 plus or minus 2 people (5-9) with the necessary skills to complete the tasks. Larger teams should either organize in sub-groups or split into multiple Scrum Teams to ensure the team is still effective. Studies have shown that teams exceeding 9 are typically less effective than smaller teams. In smaller organizations the team may be smaller.



Important Process in Scrum
·         Sprint Planning (Task Breakdown and Estimation)
·         Daily Scrum (Daily stand-up)
·         Sprint Review (Demo & Retrospective)

During the Sprint Planning the team will initially estimate the relative size of each story, typically during a process called planning poker. This process minimizes the risk of vocal individuals influencing the estimate and reduces underestimating of tasks.  
 
·         Stories are estimated in relative size using "days" or "story points"
·         Estimating in relative sizes has been show to be a lot more accurate than trying to use actual or specific units of time
·         Tasks are estimated in hours
Daily Scrum
The daily stand-up meeting or daily scrum is one of the core rituals or ceremonies in Scrum. This daily meeting gives the team and Scrum Master a daily update on progress, enabling obstacles and potential problems to be identified and dealt with as early as possible before they become real problems. It also enables the Scrum Master to make adjustments to the sprint plan to ensure things are kept on track. 

Sprint Review – Demo and Sprint Retrospective
The Sprint Demo
At the end of each sprint the team demonstrates the work completed in the Sprint to the Product Owner and potentially some stakeholders. The demo to the product owner should showcase the completion of each story committed to during the sprint. The demo should make it clear what aspects of the stories are not complete, if any, and what the plan is for getting them completed.

The Sprint Retrospective
After each Sprint the team holds a Sprint Retrospective meeting. The meeting acts as a self-assessment for the team and aims to improve processes for future sprints.