Abstract

Many times, developers need to know if a technology or feature is supported by a specific .NET version. For example, how to verify that .NET Core has Linux support or not. Well, you can always Bing that but wouldn’t it be better if this need is supported by “one stop search” and results are authentic.

Accessing .NET API Browser

.NET API Browser can be accessed by https://docs.microsoft.com/en-us/dotnet/api/

.NET API Browser allows you to search a wide range of features across following:

  • .NET Framework
  • .NET Standard
  • .NET Core
  • Xamarin
  • Azure

Let’s Search in .NET Framework

Open the API Browser and filter it to .NET Framework and choose a version from the middle dropdown. .NET Framework allows to search only for .NET 4.5 – 4.7 I.e. you can’t search features prior to .NET 4.5 in the .NET API Browser.

With the release of .NET 4.6 a new overload was introduced for System.GC.Collect(). When Searched in .NET 4.5 you will see as shown below:

But when switched the Framework Version to 4.6; then new overload can be observed as shown in the image below.

Let’s Search in .NET Standard

.NET Standard is a “specification” of .NET API which are available across all the .NET Runtimes. .NET Standards provides and supports uniformity within entire .NET ecosystem. You can refer to the list of .NET Standard libraries here https://www.nuget.org/packages/NETStandard.Library

As name explains by it-self;  this become evident that all core APIs like System, System.Collections, System.Diagnostics and System.IO etc. are natural candidates for .NET Standard as shown in the image below

Let’s Search in .NET Core

.NET Core is brand new and well accepted framework in Microsoft and non-Microsoft world. To Learn more about .NET read my blog post or C-Sharpcorner Article or watch my Channel9 Video.

A well-known fact about .NET Core is that .NET Core has support for Linux as shown in the image below.

Summary

.NET API Browser is a great feature and can become very handy to identify supported features by various platforms as shown some related to .NET in the article above. You may want to use .NET API Browser to search and learn about other APIs related to Xamarin and Azure as well, remember it’s one stop .NET API Browser.

 

Free Web App Hosting On Azure

February 19th, 2017 | Posted by Vidya Vrat in Azure - (0 Comments)

Read this article on C-SharpCorner

Abstract

Primarily Azure is known for Pay-As-You-Go, but it has some great features and some of those can be used free of cost and one of them is Azure App Service, which allows you to host your web application on Azure, Free of Cost for entire life time.

Azure App Service

Azure App Service offers a variety of applications which can be hosted under Azure App Service, but this article is limited to Web App. You can learn more about various type of application https://azure.microsoft.com/en-us/try/app-service/

Creating Free Azure Service

Login to Azure Portal https://portal.azure.com

Click on App Services and you will see all your App Services panel as shown below (you will see your services listed if you will have any; which were created previously)

Click on +Add, and choose Web App from the screen as shown below

From the next screen as shown below click on Create. You may want to take a moment and read the text shown on the screen. I personally admire the Azure capabilities to even host PHP, Node.js or python and many more application types.

Now next screen will let you specify the name of the free app service.

Choosing Pricing Tier

After filling the details on the left Pane. Select “App Service plan/Location”, and from the right Pane, select “Create New” and a new window will appear as shown below. Enter Name and choose location of Azure Data-center to host your app service, and select Pricing Tier.

Click on Pricing Tier will popup a new screen; scroll to the bottom and you will see a free service tier option as shown below.

Make note that it offers only 1 GB space max, and it will be deployed on a shared infrastructure I.e. there might be other websites hosted under same IIS / Infrastructure. Also, note that it clearly and explicitly calls out 0.00 cost per month, I.e. it’s completely free and for lifetime. Click on “F1 Free” tier and click Select. Now “App Service Plan” pane will update to reflect the changes as shown below.

Verify the details and click OK, and now your “Web App” pane will pop up and show the changes applied to your App Service Plan and location as shown below.

Verify details and click “Create”. Your Free App Service deployment will start and you will notice that your “MyfreeAppService” will appear under “App Services” as shown below.

Click on the “MyfreeAppService” to explore this App Service and whole new pane with lot of options will load as shown below.

To Test this App Service, click on “Browse” button from the top of right pane and you will notice that website will load in your default browser as shown below.

What’s next?

As this website shows nothing worthwhile, and that is because we just created an Azure App Service which is Free and have no application code in it.

We need to deploy the application to this newly created Free App Service on Azure. Microsoft Visual Studio, and DevOps CI/CD are fully feature to let you deploy your web application to this app service and a separate article will better justify this requirement which is next logical step.

Can Pricing Tier be changed?

Yes, once your application starts to have more features and you want to make it scalable, secure and take advantage of Azure App Service features you may want to change Pricing Trier from Free to Paid. This can be done very easily and quickly; by selecting “App Service Plan” and then choosing the Pricing Tier which aligns with your evolving business and application needs.

Beginning with Git using VSTS

February 9th, 2017 | Posted by Vidya Vrat in ALM | VSTS - (0 Comments)

Introduction

Just like TFVC (Team Foundation Version Control), Git is another Source Version Control and it’s becoming very popular. VSTS (Visual Studio Team Services) supports both TFVC and Git. Let’s assume that you have no project or Repository and wants to begin with Git on VSTS.

Create a New Project

Login to your VSTS account and click on New Project

Fill the information

Click “Create” and you will notice that Project will be Created as shown below.

Clone it in IDE

Click “Clone in Visual Studio”. New Visual Studio IDE will start a dialog like shown below will popup.

Provide the Repository path and click on “Clone”.

Switch to Team explorer and Click on “Create a new project or solution”

 

When prompted choose the project type. After Project is added successfully you will notice that project is added in Solution Explorer and shows (+) in front of various items and also Team Explorer’s Changes tab shows all the items listed as newly being added.

Commit Changes and Publish

After project being added into Solution Explorer it’s considered as a change to the blank repository/project you created. Hence, this change needs to be added to remote Master branch.

In Team Explorer à Changes, add a comment for check-in and click on “Commit All”

Click “Commit All” and from the next Synchronization Tab, click “Publish”

Now your Git Repository in VSTS should be updated with the code you have pushed-in to it. Refresh your VSTS page and you should be able to see your project code added.

Abstract

Convention over configuration is a software design paradigm which is used by many modern software framework including ASP .NET MVC and Web API. It’s also known as “Coding by Convention”.  It takes a lot of burden away from developers, which is otherwise required; to handle basic aspects of the application. For example, mapping of database tables with classes, or handling URLs etc.

Introduction

ASP.NET MVC (Model View Controller) very nicely showcases this software design paradigm via Visual Studio’s ASP.NET MVC Project template directory structure. ASP.NET MVC Project have three core folders “Controllers, Models and Views” as shown in Figure- 1 below.

Figure-1 Visual Studio MVC project folder structure

ASP.NET MVC framework’s folder structure is based on “Convention over Configuration” and that’s why practically, a class in Models folder can be safely assumed that there is a table with that name in the database. A Controller can be created with a <Name> with a suffix “Controller” (for example, EmployeeController, ProductController etc.) Similarly, an action method in Controllers folder’s controller class can be accessed with Controller class name (name without suffix Controller) for example, Details action method in EmployeeController by convention can be easily accessed via http://Your-Domain-Url/Employee/Details

Implementation

If there is no “Convention over configuration” paradigm; to make any such behavior work, developers need to specify/code some configuration rules to educate the application about interpreting a url and under which folder or where to look for the resource to serve that request.

Hence, having Convention over configuration is already baked into ASP.NET  MVC, Developers don’t need to write any code to establish communication mechanism among various application components. To have it function properly, conventions need to be followed and developers need to adhere to those conventions.

For example, all controller classes must reside under “Controllers” folder with <Controller> suffix as convention for example, Controller\HomeController, Controller\EmployeeController etc.
Views folder is known to have all the views and convention tells Controller where to look for a View(s) associated with a controller action method; as shown in Figure 2 below, each action method in Controller\HomeController refers to individual cshtml under “Views\<folder with controller name>”

Figure-2 Convention over configuration in Action
Hence, convention over configuration help developers to easily communicate with the ASP.NET MVC web framework by providing the pre-defined conventions as shown in Figure-3 below

Figure-3 Convention over configuration in action.

Note, that if you don’ follow the conventions correctly for example, create a controller class named DefaultController1.cs under Controller folder and build it; then Visual Studio IDE will not report any issues and it will build successfully.

Or simply move HomeController out of Controllers folder, under the project. Hit the route http://locathost/Home/About and you will get 404.

Building solution successfully doesn’t mean, that it will work.

No error was reported because as a developer you are given freedom to name your controller class etc. as per your wish; so you have freedom. But to have it working “Convention needs to be followed strictly” hence, it will not work. But once you adhere to the Convention by renaming DefaultController1 to “DefaultController” or moving HomeController back into Controllers folder; and you hit the route then it will start to function as expected.

Scenario

Are you involved in end-to-end solution delivery or got responsibility to ensure successful deployment of your .NET solution on a server box. If yes, then you need to make sure that right version of .NET Framework is installed on the deployment server(s). Many times I have observed that on premise server(s) or VMs are usually prepared by the client’s IT/Operations or Infrastructure team and they might have assured you that they have installed the correct .NET Framework Version; which application needs to have for successful execution.

What all .NET Versions could there be

Today almost every .NET application is written on .NET 4.5 or higher version (4.5.1, 4.5.2, 4.6, 4.6.1 or 4.6.2) unless you are dealing with some old .NET applications written on .NET 2.0 or 3.5 or 4.0; today all applications are built using greatest and latest .NET Framework.

Well, good to know that; let’ check

As soon as .NET Framework installation comes to mind; one location glares in the eyes C:\Windows\Microsoft.NET\Framework

The above image shows that you have .NET Framework 4.0 or may be higher version installed.

But which .NET 4.x is installed exactly

To know which .NET 4.x is installed; requires some drilling into Registry.

Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4

Under V4 folder you will see “Client” and “Full” subkey, if “Full” subkey is missing then there is no .NET 4.5 or higher version is installed.

Reading “Full” subkey

As shown in the image below read the “v4\Full” subkey and look at the Release and its value on the right hand side as highlighted in the image below.

The value shown in parentheses ( ) under Data for the Name Release and Type REG_DWORD will resolve to a specific version of the .NET Framework.

Now if you map the value 394802 to the table above, then you will come to know that .NET Framework 4.6.2 is installed. Similarly, you can map shown value as per the table above to identify which .NET Framework is installed on the machine.

Abstract

Microsoft launched Visual Studio 2017 RC on November 16, 2016 and it’s a free trial for all .NET Enthusiasts and developer community. Once a developer downloads the free trial, its only valid for certain period and this article will help you to learn how to check the validity date of VS 2017 RC.

If you have not yet installed the Visual Studio 2017 RC yet, then you might want to read my previous article on Installing Visual Studio 2017 RC

What is the benefit of Free trial?

Release Candidate is a free trail for developers to try the another latest and greatest features of new IDE and tooling around it; and that gives sufficient time to anyone learn and try what’s new in that new shiny tool and when you or your organization is ready to upgrade to a paid licensed version; you can continue to use the greatest and latest.

So when this free trial will end?

Unlike Visual Studio Community edition which is a Free download, Visual Studio 2017 Developer and Enterprise Editions are Free trial.

Free Download

Visual Studio Community is a Free Download and it remains free the whole life time of the application while it’s installed on your machine.

Free Trial

Visual Studio 2017 Professional and Enterprise are NOT FREE but offer Free Trial, which means that Trial will end after certain date and then you will be no longer able to use that product unless you buy or upgrade to a licensed version of that product.

Until when is RC Valid

Well, usually Microsoft Product Teams know well in advance and work towards releasing the product after few months of RC. But to be sure until when your installed Visual Studio 2017 RC is valid, you can follow the steps below.

  1. Launch Visual Studio 2017 RC

  2. Go to Help menu and click on “About Microsoft Visual Studio”

  3. From the opened dialog as shown below, click on “License Status”

  4. Now you will see a dialog as shown below and you can clearly see the final date of the end of Free trial.

Introduction

Microsoft Visual Studio 2017 is the most exciting version of Visual Studio. You can download the RC from https://www.visualstudio.com/vs/visual-studio-2017-rc/

Visual Studio 2017 has a lot of cool features, tool support and best developer experience right from Installation to code to debug to test to deploy (even it’s better if it’s to Azure).

System Requirements

To know minimum requirements for successful installation of Visual Studio 2017 product family, please visit this URL
https://www.visualstudio.com/en-us/productinfo/vs2017-system-requirements-vs

Installation

Run the downloaded .exe and you will see a very unique launch screen as shown below.

Option Selection

Visual Studio 2017 offers a brand new way of choosing the tool set’s. You can choose one of the following:

  • workloads I.e. what exactly you do or want to do.
  • Individual Components I.e. hand pick all components individually. I feel it could be messy unless you want to cherry pick.
  • Language Packs I.e. select language of your choice.

Workloads

Workloads is the easiest and most effective way of installing all components and dependencies of your chosen field of development. For example, web, desktop, cloud, node, data science etc.

This is so much loaded that you can select up to 8 “Web & Cloud” workloads. As shown in the image below.

Individual Components

This is a tricky one and can cause issues if someone really starts to pick and choose options from here. However, this will be perfect choice when you just want to install “.NET Core Runtime” or so.

Language Packs

This enables you to pick language of your choice. Based on your operating System, it will automatically default to a language; as shown in the image below.

Making Selection

Once selection is made; preferably from Workloads tab; you will see that Summary section is populated with all the components which will be installed. If you want you can expand the each listed item under summary and see all the components installed under each item to a very granular level.

Now, Let’s Begin the Installation

I personally feel that this is one of the fastest Visual Studio setup since 1st version I had my hands on back in 1996.

 

 

 

 

 

 

 

 

 

Setup Complete

Visual Studio 2017 RC setup requires you to Restart your PC. You may not want to do that; but I recommend to “Restart” it.

Welcome Visual Studio 2017

Notice the Recently added section and see all the Visual Studio 2017 components.

Check the Installed .NET Frameworks

Below image shows that all the .NET Frameworks are successfully installed. Which includes .NET Framework until 4.6.x and .NET 1.0 Preview 3. You can run commands as shown below to check those in any machine.

“dotnet –version” is a very handy command to be executed from Developer Command Prompt to identify if you have .NET Core or not.

Visual Studio Installer

In the installed items, there is an item listed at the very end “Visual Studio Installer” this is to Modify, Repair, Uninstall etc.

Let’s Fire-up Visual Studio 2017

Here comes the Most Awaited IDE

How to Integrate Slack with VSTS

October 10th, 2016 | Posted by Vidya Vrat in .NET | ALM | Visual Studio | VSTS - (0 Comments)

Abstract

All software development teams use some sort of team communication tool. Like many  team messaging tools  Slack is one of them. What I like most about slack is its ability to gel with VSTS (Visual Studio Team Services) and send notifications when an event is triggered for example, a Pull Request is created, or build succeeded or failed etc.

Note: VSTS was previously known as VSO. I.e. VSO is renamed to VSTS.

Introducing Slack

Slack is a widely used messaging application (web / desktop) it is widely used by many mission critical projects including Mars Curiosity Rover robots. In terms of software development, slack is very handy and efficient to notify when a VSTS event takes place. This feature reduces explicit team communication with peers that a pull requested is created and someone needs to look at that etc.

Let’s preview the final outcome

Objective is to  empower software development team(s) by enabling them to collaborate not only with peers but also with tools and services (VSTS in this case) and get immediate notification for any status updates instead of emailing or pinging someone in person for instance “Hi, Vidya Vrat. I have submitted a pull request.”

Now this article will show you Step-by-Step procedure to achieve “Slack integration with VSTS” and receive message as sown in the figure 0 below.

Figure 0 – Slack channel showing message received from VSTS

Create a Team on Slack

First step is to create a team (if not already) on https://slack.com click on “Create a new team” and enter a valid email-id which you have access to as shown in figure 1 below.

Figure 1- Slack.com main page to create a new team

When you click on “Create New Team” then you will be taken to a confirmation page as shown in figure 2 below.

Figure 2 – Page to enter confirmation code

Check your email which you have entered while creating a team and you shall see an email with Slack confirmation code as shown in figure 3 below.

Figure 3- Slack Confirmation code email received

After successful validation of confirmation code as asked in Figure-2, next step will be to enter your name and username etc. as shown in Figure 4 below.

Figure 4- Personal details

Next step will be to enter team information as shown in figure 5 below.

Figure 5 – Team information

Next Enter your company information as asked in figure 6 below.

Figure 6 – Company name

Next step will be to enter your company domain as asked in figure 7 below. It is OK to enter a domain name which is not registered or you don’t have plans to register.

Figure 7 – Company web domain info

Figure 8 – Team invitation

If you don’t want to invite people now, then click Skip and you will be taken to slack team for DotNetPassion as shown in the figure 9 below.

Figure 9 – DotNetPassion slack team page

Channel Creation on your Slack Team

Once your team is created, next step is to create a channel, which people will join and exchange messages.

Click on the + as shown in the figure 10 below.

Figure 10 – Creating channel under team

Choose channel name and purpose etc. as shown in figure 11 below.

Figure 11 – Enter channel details

Click on “Create Channel” will create the channel named “pull_requests” under your team “DotNetPassion” as shown in the figure 12 below.

Figure 12 – Successful channel creation

Integration with VSTS

Click “Add an app or custom integration link on your slack channel page as shown in the figure 12 above. Then select Developer Tools, and then select VSTS as shown in figure 13 below.

Figure 13 – Adding an app integration

Selecting Visual Studio Team Services will take you to next steps to Install as shown in figure 14 below.

Figure 14 – VSTS Integration page

Click on Install to begin the integration procedure.

Figure 15 – Selecting channel name.

After clicking on “Add Visual Studio Integration” you will see step-by-step Instructions to configure your VSTS for clack integration as shown in figure 16 below.

Figure 16 – VSTS setup instructions

Getting the Web Hook URL

Figure 17 – Wikipedia Webhook definition

Scroll down on this page to see Integration Settings and get the “Webhook URL” as shown in Figure 18 below. This Webhook url is most important piece of information to complete VSTS and Slack integration. Either keep this page open or copy and paste in notepad etc.

Figure 18 – Webhook url

Now open a new Tab in your browser and login to your VSTS account and navigate to your code Repository as shown in figure 19 below.

Figure 19 – Code repository in VSTS

Add VSTS Service Hook

From your VSTS code repository’s setting page, click on Service Hooks as shown in figure 20 below.

Figure 20 – Adding a VSTS Service Hook

Click on + to add a Service hook and choose Slack as shown in figure 21 below.

Figure 21 – Using Slack for Service Hook Subscription

Next you need to select the Trigger and repository settings etc. as shown in figure 22 below.

Figure 22 – Selecting Trigger settings

Next, confirm Action and webhook URL as shown in figure 23 below.

Figure 23 – Confirming Action with Webhook url

Next, click on “Test” to verify and test the VSTS integration as shown in figure 24 and 25 below.

Figure 24– Test integration with VSTS

Figure 25 – Test message from VSTS delivered in slack channel

Now, switch back to the VSTS Integration page and click Finish as shown in figure 26 below.

Figure 26 – Slack Integration Finish page

After Finish you will be taken to VSTS page and there you can see that service hook for slack is added as shown in figure 27 below.

Figure 27 – Service hook for slack added in VSTS

Let’s Submit a Pull Request

In Visual Studio’s Team Explorer connect to a VSTS Git Repository as shown in figure 28 below.

Figure 28 – Connecting with VSTS

Open the solution and make some changes as shown in figure 29 below.

Figure 29 – File changes in Visual Studio

After you  Submit a new Pull Request, then slack will receive a notification as shown in the figure 30 below.

Figure 30 – Slack received VSTS Pull Request message

To navigate to Pull Request you can click on the pull request link in the message (pull request 3) and it will take you to the VSTS as shown in figure 31 below. If all looks good, then you can take next action steps(s).

Figure 31 – Navigation to VSTS page from Slack message.

How to use Agile Correctly

September 27th, 2016 | Posted by Vidya Vrat in Agile-Scrum | ALM | Best Practices - (1 Comments)

Abstract

This article uncovers the various aspects of Agile software development technique and Scrum framework to enable an Agile team/ team member to understand various issues any software development team sails through and how to come over those challenges.

Where Did Agile Come from?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” which criticized sequential development.

He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.

Developing a Solution for Customer

Any software project starts from Gathering Requirements phase and many times what is developed is not exactly what end user wanted, and many software projects fail during implementation.

Value Delivery Impediments

In today’s world teams have huge dependencies on various stakeholders of the project including Users <-> Developers <-> QA <->Operations etc. and it’s proven that we need regular communication and collaboration to deliver the value.

Any communication gap or lack of collaboration between these team(s) or individuals will have impact in following areas

Plan Driven Vs Value Driven Approach 

Old school of software development has taught “waterfall” approach of software development.  In waterfall approach, one phase’s output becomes input to next phase and those phases are distributed across the project timeline as shown in the image below.

Today’s software development technique is “Iterative“ and “Incremental” I.e. Agile. In Agile, team run through all the phases within a Sprint as briefly shown in the image below.

In waterfall, development teams only have one chance to get each aspect of a project right. Whereas in Agile team has better understanding and learning from previous Sprint on what to emphasize upon and what to avoid to reap better results.

Why Agile

  • Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle.
  • This is achieved through regular cadences of work, known as sprints or iterations.
  • At the end of which teams must present a potentially shippable product increment. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market.

Agile Manifesto

Perfect Agile Team, does it really exist?

Success of any project depends on Team. I.e. it’s critical to have an awesome team to have rocking results. But in reality this doesn’t happen as team consists of individuals with their own attitude, aptitude, work style, ethics, behavior and issues etc.

Bruce Tuckman’s team development model is a perfect example how team can come together and start functioning.

Agile team’s Success heavily depends upon “self-Organized” team.

Scrum Process

Sprint Length and Team Size

Sprint is to Run at full speed over a short distance. Ideal Sprint length is 2 weeks. My recommendation is as following and I have experienced that it really works well.

  • Ideal Agile teams must be 7 to 9 +/-2 members.
  • If you have more candidates in a team, then divide teams and have separate agile teams.
  • A representative of each team might want to attend other team’s standup for critical issues, follow-up and announcements etc.

Most wanted thing in Agile – Velocity

Velocity is the account of work team completes and delivers in each sprint. Ideal sprint duration is 2 weeks and highly recommend this to any team.

I have seen better results when team works towards a pre-defined code complete date for instance, today is Tuesday and sprint is for two weeks, team can agree upon a code complete date of Wednesday of 2nd week. I.e. team will try to complete all the work by that day and have it ready for QA.

This just gives a deadline to accomplish the work, however there will be situations where work couldn’t get complete or even rolled over to next sprint and that is fine in some cases.

Here are some of my recommendations:

Give as much time as possible to Developers, SDETs and QA to fulfill their commitment. I.e. less meetings and hindrance.

Have at-least 2-3 sprints worth work well-groomed and available for the team as “ready for development”.  Two reasons:

1 – At times for unforeseen reasons or instances a user story may be pulled out of current sprint. In such situations you lose story points you committed to. In such scenarios other US can be delivered.

2- Sometimes team or an individual is able to complete the work early and available to pick more work, in such situation well-groomed loaded backlog can come very handy.

Groom Often (Backlog Grooming)

  • Usually Sprint 0 is dedicated for backlog grooming and then team start to deliver in Sprint 1 and onward.
  • Considering any Enterprise Line of Business (LOB) application, sprint 0 can’t suffice the entire backlog groomed at once.
  • Hence, team must regularly have backlog grooming in small chunks of time instead of lengthy full day meetings.

Ideally, grooming is a lengthy process and hence groom in short chunks and team lead can be present in the regular or small grooming sessions with PO or business and team can continue to focus on their work. However, team must be present at Sprint Planning time.

Brainstorm Together (Sprint Planning)

  • Everyone is invited. Many teams ask only Dev’s to attend and excuse the QA team members.
  • Understand the problem 1st.
  • Ask Questions and clarifications.
  • “Well defined” Acceptance criteria is a must.
  • Confirm that User Story is ready for development.
  • Nothing should fall from the cracks, document all within the User Story.

Daily Status Check

Just three things, no more; no less

  1.  What have you done since yesterday?
  2.  What are you planning to do today?
  3.  Do you have any blockers preventing you from accomplishing your goal?

I recommend, that if you have to discuss something related to a User Story or bug or some reported a status on something etc. then “Post Scrum” that. I.e. discuss that when team has given the status and now you can drill into the detailed discussion.

Many times Dev’s start going into technical details of the issue, design of solution, architecture, code review comment details etc. during their status. This is not right way of doing it. Just Post Scrum all that; if you have to discuss anything other than those three absolute must.

I am Blocked

It’s is obvious that someone at some time is blocked on something. You can help, by asking just:

  • Really
  • On what
  • What is the issue
  • Who is POC (Point of Contact)
  • What is ETA (Estimated Time of Arrival) I.e. delivering solution to you.

I will give you a scenario, let’s say I join a team which works on some third part control library and my license of that product is pending or not yet processed. Am I blocked. Well in a way; yes, but I can use trial version up to 30 days and when my license information come I can punch those.

Also, many times we just tell other team that we are blocked on something and we are expecting the endpoint or JSON format etc. but we don’t always ask what is ETA and convey the timelines we have to adhere. If this has any impact on your team’s deliverable than you need to re-prioritize, escalate etc. so either that work is delivered to you on time or that user story is pushed to next sprint and you pick next item on Stack rank (priority) from the Product backlog.

Scrum Master must help you to get unblocked.

Is there time to Think?

Many people and teams think that Agile has no time for following:

  • Researching a solution
  • Brain storming on the solution architecture.
  • Share your thought process, design, approach with the architects, PO etc. to get the insight.

Well, there is and it’s called “Spike”. In agile software development, a “Spike” is a user story that cannot be estimated until a development team runs a time boxed investigation. The output of a spike story is an estimate for the original story.

Some examples of spikes:

1- Discussing authentication mechanism and partner team’s flexibility to apply / accept those changes.

2- Discovering or researching for an off the shelf solution work flow solution.

Technical Debt

Every team has it, generated it, accumulate it; not a problem. Just make sure you pay it off.

Technical debt is a terms which is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and require improvements.

  • First and foremost, poor coding style and standards.
  • No unit test cases.
  • Not following OO design principles and developing long monolithic classes and code libraries.
  • Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
  • Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
  • Code is not self-documented.
  • Magic strings (hard coded path and endpoints etc. in the code)
  • Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.

Read my detailed article on Technical Debt

Branching and Merging

Branching enables parallel development and delivery by providing each development activity a self-contained snapshot of needed sources, tools, external dependencies and process automation.

Continuous check-ins pollute the branch.  Have a separate Release branch per Release.

Basic Dual Branch is an Ideal branch plan, have a Main, spin a Dev branch for development and have RI (Reverse Integration) and FI (Forward Integration) to merge changes between Child and Parent branch respectively.

When you are ready to deliver the shippable product at sprint completion then spin a Release Branch and deliver the product out of that.

Feature Branch Plan is slightly complex and requires more merge efforts but at the same time it give entire isolation of work being done in a feature branch for entire time; until it’s ready for merge to Dev branch. One major issue with this plan is that your feature branch will have old and stale code and when you will Get Latest / Pull from the changes then you will get some conflicts etc.

Just saying

“Save your creativity for your product… not the branch plan.”

“Your branch distance from main is equal to your level of insanity”

Unit Testing

Many teams don’t invest in Unit Testing. For any Agile Team Unit Test is the most critical thing and team must continue to increase the code coverage of the tests. Even based on Test Triangle as shown in the image below, Unit Test has the larger scope in Software Testing.

Read my detailed article on NUnit with Visual Studio

Read my article on Visual Studio and .NET’s Unit Test Framework

Read my article on Inside Out: TDD using C#

Benefits of Unit Testing

  1. Unit Testing gives an opportunity to think as User of your code, instead of an implementer of the production code.
  2. Reduce bugs by identifying all the use case scenarios to reflect intent (end user’s mindset, business needs, expected functionality and business validations etc.)
  1. Less-n-less time on debugging.
  2. Avoid collateral damage. I.e. a fix in one area may break functionality in another possibly
    related/unrelated area.
  3. Helps you achieve YAGNI– You Aren’t Gonna Need It. I.e. saves you from writing code which you
    don’t need

Tips for System Test

  • Must know how much to test, drive your Test cases from Acceptance criteria.
  • Avoid duplicate test steps.
  • Make sure that all your Test Cases are Mapped to Acceptance Criteria.
  • Try to combine similar behaviors in a single test case.
  • Do not go above and beyond to identify every corner case or hack the system. I.e. above a beyond the acceptance criteria. I know this is tricky and someone may want to debate on it. I didn’t mean to say that don’t test any areas of application which might have direct impact of a User Story or what not. But there is always a fine line on what to test and what not.
  • Time box for ad-hoc testing. I.e. in each sprint time-box some time

Continuous Integration (CI)

  • An important part of any software development process is getting reliable builds of the software. – Martin Fowler
  • Continuous Integration (CI) is the strategy and practice of making sure that changes to a software project’s code base are successfully built, tested, reported on, and rapidly made available to all parties after they are introduced.

Advantages of CI

  • Increase ROI (Return on Investment).
  • Guarantees successfully compiled software.
  • Visible progress reporting and problem tracking.
  • Low TCO (Total Cost of Ownership).
  • Improve development standards, consistencies and accountability.
  • Rapidly identify bugs, who created them, and where it is.
  • Quickly push high quality change updates to testing.
  • Reduce development integration effort.
  • Increase amount of quality code.

Successful Build

An aggressive goal for a successful build would include:

•       All the latest sources are checked out of the configuration management system.

•       Every file is compiled from scratch.

•       The resulting object files are linked and deployed for execution.

•       The system is started and a suite of tests is run against the system.

•       If all of the above execute without error or human intervention and every test passes, that is a successful build.

Let the Team see what is happening

  • Must have Gated builds and nightly builds to ensure value delivery of the functionality.

You can use this build monitoring tool from https://teambuildscreen.codeplex.com/

Continuous Delivery (CD)

CI mainly focuses on development teams. The output of the CI system normally forms the input to the manual testing process and to the rest of the release process.

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle
  • Your team prioritizes keeping the software deployable over working on new features
  • You can perform push-button deployments of any version of the software to any environment on demand

I am speaking at Seattle Code Camp and my session topic is “How to use Agile correctly“. It’s totally FREE community event. Please register and spend the weekend in learning all you can.

My session will be in Room#204 at 1-2 pm.