Interested in developing agile software using the SCRUM methodology? Like looking at Burndown Charts and managing software development teams while keeping a close relationship with the client? Check out SCRUMDESK…This application manages projects using SCRUM and User Stories, its FREE for the first 5 users! A great tool in terms of Agile SCRUM practices but the UI does take some time to get use to…
The use of partial classes can help improve coding for the following reasons:
- As you can split code into seperate physical files, its easier to seperate UI and Business Logic that may belong in a single class
- Produces clean and organised code
- No performance hit… The compiler groups all partial classes into one entity during compilation
public partial class MyPartialClass
int foo = 0;
public partial class MyPartialClass
public String ShowMessage()
REMEMBER: Keep partial classes in the same namespace to avoid confusion!
Came across a interesting problem…what happens when your assembly is using a third party assembly that is not strongly named and you want to sign your own assembly..the issue is that you cannot sign your assembly without all other references being signed with a strong name also.
Two possible options:
- Ask the thirdparty provider to give you their assembly signed
- If option 1 is not possible, you can download this tool called Signer which will allow you to sign a assembly after its been compiled with a key. All you need to do is generate a key (sn -k myKey.key) and use the Signer command “signer -k myKey.key -output Directory -a assembly.dll
When you throw an exception, use the throw keyword..do not throw the original exception. This way, the original call stack is preserved.
Use // or /// for comments. Avoid using /* … */
This gives you the ability to generate XML documentation from VS.
There are many ways to get a notification icon displaying in the system tray, this is how I managed to get it working using Windows Presentation Framework:
public partial class ClassName : Window
private System.Windows.Forms.NotifyIcon m_notifyIcon;
private System.Windows.Forms.ContextMenuStrip m_contextMenu;
//Initalize the context menu strip
m_contextMenu = new System.Windows.Forms.ContextMenuStrip();
System.Windows.Forms.ToolStripMenuItem mI1 = new System.Windows.Forms.ToolStripMenuItem();
mI1.Text = “Menu One”;
mI1.Click += new EventHandler(Click_Handler); //Add Click Handler
System.Windows.Forms.ToolStripMenuItem mI2 = new System.Windows.Forms.ToolStripMenuItem();
mI2.Text = “Menu Two”;
mI2.Click += new EventHandler(Click_Handler); //Add Click Handler
//Initalize Notify Icon
m_notifyIcon = new System.Windows.Forms.NotifyIcon();
m_notifyIcon.Text = “Application Title”;
m_notifyIcon.Icon = new System.Drawing.Icon(“Icon.ico”);
m_notifyIcon.ContextMenuStrip = m_contextMenu; //Associate the contextmenustrip with notify icon
m_notifyIcon.Visible = true;
I am reading a inspiring book “User Stories Applied: For Agile Software Development” by Mike Cohn (2004) which explains writing lengthy requirement specifications is a waist of time and how applying “User Stories” involves the client from start to end, keeps the communication standardised and balances the client/developer’s input to gathering requirements the same.
User roles are the type of user who will be using the application. Typically we write requirements based on a user, but we should brainstorm the type of users and consolidate them into different user roles.
For example, we are developing an Online Cemeteries Web Application that allows users to search where people are buried etc.
We can brainstorm the different types of users who potentially could use the web application:
- Grand parents
- Family tree experts
- Younger generation
We consolidate them further
- Genealogists/Expert family history
- General Public
Finally we refine and came up with one user role as there will be no functionality to have a separate area of Genealogists in the system.
- User role: General Public
Mike talks about the acronym INVEST
User stories should be:
- Valuable to Purchases or Users
Typically user stories are written on cards with the front side having the story and any recorded “reminders” that summarise what developers have discussed with the client. The back side describes all the test cases that will meet the client’s expectations about the story. The more test cases are made before the code is written the better the developer can factor this into their code.
Here is an example from when we developed the Online Cemeteries Web Application:
Story: The general public can perform a simple search entering a first and last name which returns a list of results
- What happens when the general public enters no first name or last name?
- Can they enter 1 or none?
Story: The general public can perform a advanced search entering several parameters which results a list of results
- What happens when the general public enters no parameters?
Story: The general public can view an individual cemetery record which consists of several cemetery specific items
Story: The general public can go back and change their simple/advanced parameters to perform another search
- Does the system remember the general public’s input so that they can come back to the website and get the same results?
Tips – Here are some tips to building better user stories:
- If a story is too long and have too much detail, break the story down into smaller stories (keeping in mind they should run with the INVEST attributes).
- Don’t be technical! This is written from the client’s perspective!
- You can also write down non-functional stories!
- Try to not include any UI specific details as this can cause confusion later on during implementation
PART 2 will be on estimation and planning using “User Stories”.