http://www.agileweboperations.com/scrum-vs-kanban.

http://en.wikipedia.org/wiki/Kanban_(development)

We have adopted a mix of Scrum/Kanban model for fixing bugs.
One of my team is in maintenance. During sprint planning we decide on the priority of the bugs and timebox all the issues based on the teams capacity. During the daily scrum meeting we discuss about the progress made. If the issue is critical, an update is send to the entire team every four hours. If any new issues are reported in between, PO prioritizes that and if it is the highest priority, team stops the work on the current bug and starts fixing the new issue. We encourage multiple people to work on the bugs. Once the top priority bugs are fixed, team moves to the next item in the backlog. If we take more time to fix than the anticipated timebox we inform the PO. Based on the discussion team will continue working on the exiting bug or work on a new higher prioritized bug.

–
Posted By Abhi to The Tech Jungle at 1/08/2012 11:31:00 AM

–
Posted By Abhi to The Tech Jungle at 1/08/2012 11:07:00 AM

What can be done in this situation?

I met with Anu and we agreed on the following

Identify the most critical requirements required for the team to start work. Do a casual analysis with the subject matter expert and the team and find the cost (duration + software + hardware costs) of doing (and not doing)

Anu held meetings with the team, PO & other stakeholders. This teamwork produced a wonderful infrastructure backlog and was presented to PO. She also added the dependency to this backlog. Nice to have infrastructure were at lower priority. This infrastructure work was added to the first two sprints. Team was also asked to do a sample application integrating all the infrastructure work as part of sprint backlog. With this sample application team validated the infrastructure configuration. The other infrastructure woke like server to do load testing; performance profiling was added to the middle sprints.

–
Posted By Abhi to The Tech Jungle at 12/26/2011 11:57:00 AM

There is no definite duration for sprint !!!

Ken Schwaber & Jeff Sutherland started the sprints with 30 days duration. Now majority of the companies prefer 2 week sprints. If you don’t have any idea; start with 2 weeks. After the couple of 2 weeks iterations get together with the team, collect their feedback and decide whether you want to change the sprint duration. Personally I have seen teams with sprint duration of 20 days, 15 days, 2 weeks & even 1 week (I have my two teams running on 1 week).

Checklist for sprint duration change.

Reduce the sprint duration

• Poor estimation (if team complains that they work for 8 hours on the task estimated for 4 hours)
• Poor quality (lot of bugs & performance issues)
• Unable to meet the sprint objectives
• Lot of scope creep
• Nature of deliverables (if the team is responsible for the delivery of small reports or documents which won’t take more than couple of days)

When the sprint duration is reduced team will meet more often for planning and review. This will help in better planning, estimation & understanding of sprint objectives. PO will also have a better time managing all the changes in the backlog due to frequent changes in customer priority.

Increase sprint duration

• Product backlog is almost stable
• The inability of the customers/PO/stakeholders to meet periodically to review the delivery
• Nature of deliverables (some deliverables need long time to develop, integrate & test)

–
Posted By Abhi to The Tech Jungle at 12/24/2011 12:24:00 PM

There should be a mechanism by which we should allow these changes to happen but in a controlled manner. Scrum has a definite answer to this problem.

As long as the “creep” doesn’t happens during the sprint its fine. Once the items for a sprint are finalized then nothing else should be added. The sprint demo should happen only on the items which were agreed during sprint planning & only on the conditions of acceptance defined. If anything new is found during actual sprint execution or during sprint demo, then it should be noted down and added to the backlog. PO can prioritize these new changes for the team after discussion with the stakeholders.

–
Posted By Abhi to The Tech Jungle at 12/24/2011 09:47:00 AM

In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes
In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s… anyone can update this but ultimately it is the PO who is responsible for the backlog.
User stories should be written in a non -technical manner from the perspective of an end user
e.g.
As an x user I should be able to xyz actions.

This user story will be further sliced. The PO (or story writer) shouldn’t spend months is defining the backlog. After fine tuning the stories to an extent this should be put to review to the scrum team. The entire scrum team should work on these stories to understand it perfectly. Any technical constraints /limitations should be noted down & presented to customer. Scrum emphasizes this team work. It’s better to have 5 brains working together than one. The most important section out of these discussions/workshops will be the condition of acceptance (COA’s). Generally these COA’s are not technical. NFR’s can be added as constraints to these conditions.

–
Posted By Abhi to The Tech Jungle at 12/24/2011 08:08:00 AM

SOA is a framework that is used to design service-based distributed systems. In an SOA-based system, platform-independent services communicate across networked computers or computer processes.

WCF implements.

• Explicit boundaries WCF services function using defined interfaces to identify the communications that flow outside the boundaries of the service.
• Independent services All WCF services are deployed and managed independently; they are independent of deployment, installation, and version issues. Also, each service interaction is independent of other interactions.
• Schema and contract-based communication WCF services communicate with clients by providing only the schema of the message and not its implementation classes. This helps developers change the service implementation in the future without impacting the clients.
• Policy-based compatibility Compatibility between WCF services and clients at run time is determined using published policies. Policies help separate the description of the service from its implementation details.

The SOA-based WCF architecture contains four layers – Contracts, Service Runtime, Messaging, and Hosting.

Contracts: The Contracts layer describes the WCF message system.
This is described in terms of

• A Service Contract describes the method signatures of a service. It’s defined using programming languages, such as Visual Basic and Visual C# and is distributed as an interface
• A Data Contract enables .NET types to be expressed in XML. The data contract describes every parameter that makes up every message that a service can create or consume. The message parameters are defined by XML Schema definition language (XSD) documents, enabling any system that understands XML to process the documents.
• Message Contracts define the structure of SOAP messages exchanged between a service and a client, and they allow you to view or modify messages and allows finer-grained control over parts of the message
• Policies and Bindings : Policies and Bindings stipulate the conditions required to communicate with a service.They define the configuration, such as security levels, required by clients to communicate with a service.

Service Runtime
It describes the runtime behaviors of the service

• Throttling controls how many messages are processed, which can be varied if the demand for the service grows to a preset limit.
• Error behaviour decides the sequence of events when an occurs in service. This prevents the display of too much of error information to outside entities.
• Metadata behavior governs how and whether metadata is made available to the outside world
• Message inspection is the facility to inspect parts of a message
• Instance behavior specifies how many instances of the service can be run (for example, a singleton specifies only one instance to process all messages).
• Transaction behavior enables the rollback of transacted operations if a failure occurs.
• Dispatch behavior is the control of how a message is processed by the WCF infrastructure.
• Parameter filtering enables preset actions to occur based on filters acting on message headers

Messaging
The Messaging layer contains channels that process messages and operate on messages and message headers.A channel is a component that processes a message in some way, for example, by authenticating a message. A set of channels is also known as a channel stack. Channels operate on messages and message headers.

There are two types of channels: transport channels and protocol channels.
Transport channels read and write messages from the network, and protocol channels implement message processing protocols.Some transports use an encoder to convert messages (which are represented as XML Infosets) to and from the byte stream representation used by the network. Examples of transports are HTTP, named pipes, TCP, and MSMQ. Examples of encodings are XML and optimized binary.

Protocol channels implement message processing protocols, often by reading or writing additional headers to the message. Examples of such protocols include WS-Security and WS-Reliability.

• WS-Security is an implementation of the WS-Security specification enabling security at the message layer.
• The WS-Reliable Messaging channel enables the guarantee of message delivery.
• The encoders present a variety of encodings that can be used to suit the needs of the message.
• The HTTP channel specifies that the HyperText Transport Protocol is used for message delivery.
• The TCP channel similarly specifies the TCP protocol.
• The Transaction Flow channel governs transacted message patterns.
• The Named Pipe channel enables interprocess communication.
• The MSMQ channel enables interoperation with MSMQ applications.

Fig- A typical WCF architectural flow

Hosting and Activation
The Hosting layer describes the ways in which a WCF service can be hosted. WCF services can be hosted using either Windows Activation Services, Internet Information Services, Windows Services, .EXE, or COM+.

• A service is a program. Like other programs, a service must be run in an executable. This is known as a self-hosted service.
• Services can also be hosted, or run in an executable managed by an external agent, such as IIS or Windows Activation Service (WAS).
• COM+ components can also be hosted as WCF services.

–
Posted By Abhi to The Tech Jungle at 3/25/2010 12:00:00 PM

WCF Fundamentals

• Service are applications that wait for clients to communicate with them and respond to that communication. They expose the functionalities to client.
• Client initiate the communication. They consume the service offered by Service.
• Message: A message is a self-contained unit of data that may consist of seveal parts, including a body and headers. Clients & Service communicate using XML messages.

A single application can act as both a client and a service.

Endpoints
Messages are sent between endpoints. Endpoints are places where messages are sent or received (or both), and they define all the information required for the message exchange. A service exposes one or more application endpoints (as well as zero or more infrastructure endpoints), and the client generates an endpoint that is compatible with one of the service’s endpoints.

An endpoint describes in a standard-based way where messages should be sent, how they should be sent, and what the messages should look like. A service can expose this information as metadata that clients can process to generate appropriate WCF clients and communication stacks.

An endpoint consists of these components:

• address Each endpoint has a unique address that helps a client know where it is located on the network.It is specified as a Uniform Resource Identifier (URI). The URI schema part names the transport mechanism to use to reach the address, such as HTTP and TCP. The hierarchical part of the URI contains a unique location whose format is dependent on the transport mechanism. The client uses this address to send messages to an endpoint. An address can be absolute or relative. If you enter a relative address, WCF uses the absolute base address as the prefix for it. An example of an absolute address is http://localhost:8888/SampleService.
• binding The binding of an endpoint describes the channels used to communicate with the endpoint. A channel is a route through which all messages pass in a WCF architecture. A channel is composed of binding elements that tell clients which transport protocol, encoding, and security configurations should be used to communicate with the endpoint. WCF provides many default bindings such as BasicHttpBinding and NetTcpBinding.
• contract An endpoint’s contract informs clients about the type of capabilities or features the endpoint provides. It tells clients the form of the message, what operations they can call, how they can call an operation, and what response message they will receive from the endpoint. A contract is created by applying the ServiceContract attribute to an interface or class description and applying the OperationContract attribute to each method included as a service operation.

An WCF service is exposed to the world as a collection of endpoints.

• Infrastructure endpoint An endpoint that is exposed by the infrastructure to facilitate functionality that is needed or provided by the service that does not relate to a service contract. For example, a service might have an infrastructure endpoint that provides metadata information.
• Application endpoint An endpoint exposed by the application and that corresponds to a service contract implemented by the application.
• Binding element A binding element represents a particular piece of the binding, such as a transport, an encoding, an implementation of an infrastructure-level protocol (such as WS-ReliableMessaging), or any other component of the communication stack.
• service operation: A service operation is a procedure defined in a service’s code that implements the functionality for an operation. This operation is exposed to clients as methods on a WCF client. The method may return a value, and may take an optional number of arguments, or take no arguments, and return no response. For example, an operation that functions as a simple “Hello” can be used as a notification of a client’s presence and to begin a series of operations.
• service contract :The service contract ties together multiple related operations into a single functional unit. The contract can define service-level settings, such as the namespace of the service, a corresponding callback contract, and other such settings. In most cases, the contract is defined by creating an interface in the programming language of your choice
• Operation contract: An operation contract defines the parameters and return type of an operation. When creating an interface that defines the service contract, you signify an operation contract by applying the OperationContractAttribute attribute to each method
• Message contract:A message contract describes the format of a message. For example, it declares whether message elements should go in headers versus the body, what level of security should be applied to what elements of the message, and so on.
• Fault contract: A fault contract can be associated with a service operation to denote errors that can be returned to the caller. An operation can have zero or more faults associated with it. These errors are SOAP faults that are modeled as exceptions in the programming model.
• Data contract: The data types a service uses must be described in metadata to enable others to interoperate with the service. The descriptions of the data types are known as the data contract, and the types can be used in any part of a message, for example, as parameters or return types. If the service is using only simple types, there is no need to explicitly use data contracts.

Behaviors

• A behavior is a component that controls various run-time aspects of a service, an endpoint, a particular operation, or a client.
• Behaviors are grouped according to scope.
• Common behaviors affect all endpoints globally, service behaviors affect only service-related aspects, endpoint behaviors affect only endpoint-related properties, and operation-level behaviors affect particular operations. For example, one service behavior is throttling, which specifies how a service reacts when an excess of messages threaten to overwhelm its handling capabilities. An endpoint behavior, on the other hand, controls only aspects relevant to endpoints, such as how and where to find a security credential.

Communication Protocols
One required element of the communication stack is the transport protocol. Messages can be sent over intranets and the Internet using common transports, such as HTTP and TCP. Other transports are included that support communication with Microsoft Message Queuing (MSMQ) applications and nodes on a Peer Networking mesh. More transport mechanisms can be added using the built-in extension points of WCF.

Encoding is specified in communication stack which specifies how any given message is formatted. WCF provides the following encodings:

• Text encoding, an interoperable encoding.
• Message Transmission Optimization Mechanism (MTOM) encoding, which is an interoperable way for efficiently sending unstructured binary data to and from a service.
• Binary encoding for efficient transfer.

More encoding mechanisms (for example, a compression encoding) can be added using the built-in extension points of WCF.

Message Patterns
The message exchange patterns used in WCF are either

• One Way: The One Way is when the sender sends a message to the receiver but the sender doesn’t expect the receiver to reply to this message, it is something like Fire & Forget.
• Request/Reply: The Request / Reply is when the sender sends a message to the receiver and expects ONLY one reply from the receiver, as an example any web page you request for it in your browser you expect a reply (Response) which is the Page you requested.
• Duplex: The Duplex is when both Sender & Receiver construct a channel between them and everyone of them can send messages to the other at well, it is just like a Phone Call.

Hosting: A service must be hosted in some process. A host is an application that controls the lifetime of the service. Services can be self-hosted or managed by an existing hosting process.

Self-hosted service: A self-hosted service is one that runs within a process application that the developer created. The developer controls its lifetime, sets the properties of the service, opens the service, and closes the service.

metadata

• The metadata of a service describes the characteristics of the service that an external entity needs to understand to communicate with the service. Metadata can be consumed by the ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client and accompanying configuration that a client application can use to interact with the service.
• The metadata exposed by the service includes XML schema documents, which define the data contract of the service, and WSDL documents, which describe the methods of the service.
• When enabled, metadata for the service is automatically generated by WCF by inspecting the service and its endpoints. To publish metadata from a service, you must explicitly enable the metadata behavior.

WS-* Shorthand for the growing set of Web Service (WS) specifications, such as WS-Security, WS-ReliableMessaging, and so on, that are implemented in WCF.

–
Posted By Abhi to The Tech Jungle at 3/25/2010 11:55:00 AM

The WCF architecture uses message-based communication. This involves messages being sent between endpoints generated by either a service or a client.

A service is an application that responds to a request, and a client is an application that initiates a request. In many cases, a single application can act as both a client and a service, depending on the situation.

WCF is implemented primarily as a set of classes on top of the .NET Framework’s Common Language Runtime (CLR). Because it extends their familiar environment, WCF allows .NET developers to build service-oriented applications in a familiar way.

The benefits of WCF

• asynchronous one-way messaging Many applications use asynchronous one-way messaging. For example, web browsers send requests to web servers and wait for replies. WCF supports asynchronous one-way messaging, which provides advanced functionality, reliability, and application responsiveness. It also makes efficient use of available processing power. Asynchronous messaging is the most efficient way of performing the input and output tasks required by a distributed application.
• Support for cross-vendor interoperability, including security, and transactions. WCF has interoperability features that were previously spread across different technologies. It communicates using SOAP-based web services (WS-*) and supports Representational State Transfer (REST) architectures, Plan Old XML (POX) messaging systems, and JavaScript Object Notation (JSON) data during WCF runtimes. In addition, you can write custom extensions that enable WCF applications to communicate with applications that require proprietary message encodings.
  WCF allows transactional scopes to flow across multiple applications
  Because WCF adheres to the WS-Security specifications, its default security options range from message-based security to the more traditional transport-centric security model.
• reliability:WCF provides four assurances for reliability for distributed computing – at most once, at least once, exactly once, and in order. An assurance is similar to a guarantee. It contains mechanisms that provide these assurances with little or no modification to the application. As opposed to traditional types of assurances, WCF’s assurance mechanisms don’t depend on the transport method used.
• platform consolidation

WCF unifies the following distributed communication technologies

ASP.NET Web Services (ASMX) and the Web Service Enhancements (WSE): The ASMX and WSE technologies provide an interoperable, service-oriented infrastructure and programming model that can easily be integrated into web services or web service clients. They work on HTTP only and can have performance issues but are interoperable because their data is encoded using XML.
Enterprise Services: Enterprise Services is a component-oriented technology that provides transaction integration across multiple objects performing related work in a distributed environment. It minimizes throttling, optimizes pooling of object instances, provides a publish/subscribe mechanism for events, and uses a fast, secure, and platform-integrated transport method. However, Enterprise Services provides poor interoperability, because it is tightly coupled with the infrastructure.
Microsoft Message Queue (MSMQ): MSMQ is a set of objects that provide a durable, volatile, and scalable message queuing system that ensures reliable data transport from one place to the next. It is used to collect a group of messages, send them to a server for processing, and receive a reply from the server. However, MSMQ cannot process corrupted messages efficiently. When a corrupted message is received by the server, it blocks other messages in the queue.
Remoting: Remoting is the application programming interface (API) used by .NET to allow .NET Framework applications to communicate across application domain boundaries. It is a very flexible and extensible model that enables developers to manipulate proxy mechanisms, transports, and the way communication channels function. However, Remoting does not provide interoperability with non-.NET applications.

• Explicit support for service-oriented development.

explicit boundaries WCF services function using defined interfaces to identify the communications that flow outside the boundaries of the service.
independent services All WCF services are deployed and managed independently; they are independent of deployment, installation, and version issues. Also, each service interaction is independent of other interactions.
schema and contract-based communication WCF services communicate with clients by providing only the schema of the message and not its implementation classes. This helps developers change the service implementation in the future without impacting the clients.
policy-based compatibility Compatibility between WCF services and clients at run time is determined using published policies. Policies help separate the description of the service from its implementation details.

The SOA-based WCF architecture contains four layers – Contracts, Service Runtime, Messaging, and Hosting.

Contracts: The Contracts layer describes the WCF message system.
They are of two types- Data & Service

• A Service Contract describes the method signatures of a service. It’s defined using programming languages, such as Visual Basic and Visual C#.
• A Data Contract enables .NET types to be expressed in XML.
• Message Contracts define the structure of SOAP messages exchanged between a service and a client, and they allow you to view or modify messages.
• Policies and Bindings
• Policies and Bindings define the configuration, such as security levels, required by clients to communicate with a service.

A practical experience
Last year i was associated with a project (.Net 2.0) which had both Java & .net modules interacting with each other. More over there were custom adapters/interfaces (in C#) for around 500 external devices which interected with our application. Few devices provided the data for our application and few others were dependant on the data generated by our application. A specific set of meesages were send to MSMQ for other devices to read. It was a distirbution nightmare. We had web services. custom adapters, MSMQ, remoting almost all the distributed technologies supported by Microsoft in one project. Initially we had a very difficult time managing all these.

We migrated the project to .Net 3.5. To solve this distribution nightmare we adopted WCF. The following factors helped us to choose WCF

• Because WCF can communicate using Web services, interoperability with other platforms that also support SOAP, such as the leading J2EE-based application servers, is straightforward.(We can also configure and extend WCF to communicate with Web services using messages not based on SOAP, for example, simple XML formats like RSS)
• Managing object lifetimes, defining distributed transactions, and other aspects of Enterprise Services are now provided by WCF. They are available to any WCF-based application, which means that the our application can use them with any of the other applications it communicates with.
• The WCF option for queued messaging, built on Message Queuing, allows applications to use persistent queuing without using another set of application programming interfaces.
• Performance is of paramount concern for most businesses. WCF is developed with the goal of being one of the fastest distributed application platform developed by Microsoft. (To allow optimal performance when both parties in a communication are built on WCF, the wire encoding can be used, in this case is an optimized binary version of an XML Information Set. Messages still conform to the data structure of a SOAP message, but their encoding uses a binary representation of that data structure rather than the standard angle-brackets-and-text format of the XML 1.0 text encoding.)

–
Posted By Abhi to The Tech Jungle at 3/24/2010 11:26:00 AM

You can create HTTP handler in any of the .net language which can run in the framework (any CLS compliant language).
In the following example I have used C#

public class ImageHandlerNew :IHttpHandler
{
const string connectionStringName = "Images";

public void ProcessRequest(HttpContext context)
{

}

public bool IsReusable
{
get { return true; }
}

}

In this example the most important function is ProcessRequest which handles the incoming request from browser, process it and sends back the response. This function takes the current running context as parameter. This context enables has all the runtime objects & context information of ASPX execution thread.
As mentioned in http://thetechjungle.blogspot.com/2010/02/aspnet-http-handlers-generic-hander.html , The IsReusable property indicates whether the same handler can be reused over multiple requests.

You can add a lot of different functionalities like generating the PDF, excel files or retrieving the stock quotes in ProcessRequest function (when client requests for a specific resource). For testing you can use the following function which retrieves the image file stored in SQL server database.

public void ProcessRequest(HttpContext context)
{
context.Response.Buffer = false;

string filename = VirtualPathUtility.GetFileName(context.Request.Path);

string connstring = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;

SqlConnection con = new SqlConnection(connstring);
SqlCommand cmd = new SqlCommand("SELECT Image FROM Images WHERE FileName=@FileName", con);
cmd.Parameters.AddWithValue("@FileName", filename);

using (con)

{
con.Open();
SqlDataReader reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess);
if (reader.Read())

{
int bufferSize = 8040;
byte[] chunk = new byte[bufferSize];
long retcount;

long startindex = 0;
retcount = reader.GetBytes(0, startindex, chunk, 0, bufferSize);
while (retcount == bufferSize)
{
context.Response.BinaryWrite(chunk);

startindex += bufferSize;

retcount = reader.GetBytes(0, startindex, chunk, 0, bufferSize);

}

byte[] actualchunk = new byte[retcount - 1];
Buffer.BlockCopy(chunk, 0, actualchunk, 0,(int) retcount-1);
context.Response.BinaryWrite(actualchunk);

}
}

}

After adding thie CS file in your application add the following in web.config

<httpHandlers>
<add verb="*" path="*.gif" validate="false" type="AspNet.ImageHandlerNew"/>
<add verb="*" path="*.jpg" validate="false" type="AspNet.ImageHandlerNew"/>
<add verb="*" path="*.jpeg" validate="false" type="AspNet.ImageHandlerNew"/>
httpHandlers>

• path: Enables you to specify the path associated with the handler. You can use wildcards in the path expression.
• verb:Enables you to specify the HTTP verbs, such as GET or POST, associated with the handler. You can specify multiple verbs in a comma-separated list. You can represent any verb with the * wildcard.
• type : Enables you to specify the name of the class that implements the handler.
• validate:Enables you to specify whether the handler is loaded during application startup. When true, the handler is loaded at startup. When false, the handler is not loaded until a request associated with the handler is made. This second option can improve your application’s performance.

How to execute this Handler?
Remember once you create this handler all the requests for .gif,.jpg & .jpeg resources will be handled by this. So if the corresponding data is not available in database this code will not display anything. You don’t have to add any special code in your aspx or associated class files, ASPNET/IIS runtime will automatically redirect the corresponding resource request to this class/dll.

–
Posted By Abhi to The Tech Jungle at 3/01/2010 10:10:00 AM