agile

Agile charts

2006-11-02T05:29:00Z

Conventional software project management uses Gantt Chart to plan task activities and estimate how long it will take to complete a project. However, it is hard to maintain and overshadow the the big picture with details. The most 2 important things to know in developing a project are

Are we on time?
Are we on budget?

By using the burn down chart or budget chart, we will get a clearer picture on our current project state. From there, we can estimate the works to be completed with reasonable budget. Look at the example below:

The dotted gray line is the target. In this example, the project is 10 weeks long. Each week, we expect to complete 10% of work and use up 10 % of budget.

That's the ideal scenario and of course real worls is different. That's why we need another 2 lines.

The orange line shows how much budget has been "burned". It is based on actual hours worked by the team. in this example, we are 3 weeks into the project and we've burned 40% of the budget.

The green line shows percent complete. It is based on features-completed so far. In this example only 20% of work completed at the end of week3.

The project is in trouble. We've spent 40% of the budget to complete only 20% of work. According to plan, we should have use 30% of budget to complete 30% of work. At least, we noticed the bad progressing early and we still have times to fix it.

Event Publication and Subscription on SCFC or CAB

2006-11-01T07:48:00Z

On SCSF and CAB there two things that for me is new. First is Event Publication. Event Publication is the publisher of event where the event if fire. As example i have this kind of code:

public void item_clicked(object sender, EventArgs e)
{
this.Clicked();
}

and i want publish this event so the other WorkItem can subscribe it. So what i do is i create an Event publication

[EventPublication(EventTopicNames.ItemClicked, PublicationScope.Global)]
public event EventHandler<EventArgs> ItemIsClicked

this is for publish the event and we have to create one protected virtual method to invoke that event as example:

protected virtual void OnItemIsClicked(object item)
{
    if(null != ItemIsClicked)
    {
       ItemIsClicked(this, new EventArgs())
    }
}

but at the item_clicked method we have to put CommandHandler so the CAB know which event have involve. What we have to do is

[CommandHandler(CommandNames.ItemClickedCommand)]
public void item_clicked(object sender, EventArgs e)
{
    this.Clicked();
}

that on event publication... on other presenter or Module Controller we can subscribe event as example like below;

[EventSubscription(EventTopicNames.ItemClicked, ThreadOption.UserInterface)]
public void ItemClicked(object sender, EventArgs e)
{
item.Clicked();
panel.Text = "Clicked";
}

thats what i've trying to familiar with CAB od SCSF and if there is some thing wrong... please comment it and fix the wrong... i still in learning on this kind of CAB and SCSF

Smart Client Software Factory and CAB

2006-10-06T08:19:00Z

What CAB? CAB is short term for Composite UI Application Block. This is realase by Microsoft to solve proble of many developer face when try to copy cat on wincontainer like Outlook. Using CAb, all proble of share state, transfering data and so on we face when using a wincontainer is solve. In CAB, its contains a part as major item. Work Item, SmartPart, ShellProgram, Presenter and so on. WorkItem is working as a module which can contain few smartpart. SmartPart is a user control or a view for user to look. A presenter is a place we put event handler, methods and rule or whatever. This part will communicate together and will be inject into shellProgram and run on it.

So if we have 4 or more workItem, we can combine it in ShellProgram and the data between workitem can be transfer to each other and we do not need to press our brain to work hard to think about it. All of ot will be done and will be help by using CAB.

But, ofurtunately, Smart Client Software factory came and more on helping us on developing. Using SCSF is very greatfull to me. Because, by using it, we simplu can reduce a time to think about on develop system on CAB.

It is realy easy. Very easy, even i who just very new in this programming arena can understand it. Create Smart Client solution when open VS and you just only have to follow the order and it is have guidance to. All help document is there. And to accomplish this, download all this from Microsoft. Refer to gotDotNet and find more about SCSF and CAB.

Happy trying dude.

adios

Estimating point size on User Stories

2006-10-06T08:13:00Z

Why it is important to clearly estimate point size of user stories. It is important because if we are over estimate the user stories point it will give a bad result on velocity and burdown chart. Over estimate is have to but if we are over2 estimate, that have to avoid. When we over estimate to some of user stories then it will cost of free time and this will cause of increasing of budget.

Under estimate is also bad on estimating user stories point... because if we under estimate a user story point... it will make delivery delay and this will dissapointed user because its not follow the schedule and this will make corporate to think about your position of Project Manager and Developer. under estimate user story point have to be avoid.

Estimating a user story point is okey if you over estimate it a little but avoid under estimate a point. As an example, you have a user story about "As a user i could search an item in the system". And you have estimate it that it will cause about 4 point however the actual point is 3. It is okey if you over estimate a little but if you estimate the user story is 2 point... it can cause delay and developer have to give a very high commitment to the user story because you have under estimate the user story.

Estimating actually is quite easy. On all user story you have create... chose the easiest one which cause 1 point. and choose other user story. If the user story is twice difficult to the first one, so multiply it. so the second user story will be 2 and so on. And on estimating user story point, you have sit down with all you developer and pruduct owner and project manager. So estimating point to user story will be accurate.

Adios

Dealing with user proxies

2006-10-05T06:48:00Z

User proxies are representative of the real user. It needs careful consideration to pick appropriate user proxies that really understands the goal of the project and view the the system similarly to domain experts. Although user proxy will be the decision maker, try to establish connection with the real-users. The best way for doing this is to request permission to start a user task force. It can consists any number of real users to gather their ideas on how they want the application to be developed. You can do this by conduct a series of discussion by taking top-level direction from user proxy. Show them the prototypes and generate feedback during task force meeting.

What if there really no user available and you must resort to user proxy, be sure to use more than one user proxy with different background. . This helps reduce the likelihood of building a system that meets exactly one person's needs. For example, combine marketing people with domain experts rather than using two domain experts. You can also use the competing product feature as a guide and source for your user stories. Get an idea and insert the new feature that they don't have. Try to find their features that are always discussed in online user group and are the features discussed because they are complex to use? This will be the advantage and value-add to your application.

Another technique to deal with user proxy rather than real users is to release the beta version of product soonest possible. Getting the real users use it early so that it can help to identify inconsistencies between the thinking of user proxy and real users.

Principles behind the Agile Manifesto

2006-10-05T01:45:00Z

We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

get it from ==>AgileManifesto

Prioritize the User Story

2006-10-04T06:36:00Z

Now you have a list of user stories to be implemented. Before you could assigns all the stories to iteration, you need to identify the risk and value of stories to customers so that you can prioritize which story to be done first. A risk is any probable event or condition that have a potentially negative outcome on the project while value is how much the story benefits the user. After identifying the risks and value, plot it to form a quadrant graph. Form there, you can prioritize which to be done first or assign to early iteration and which will be done later.

5 factor why planning a projects fail

2006-10-04T05:18:00Z

After i read about Planning and Estimates in Agile there a 5 factors why planning a projects is fail. And i thinking about it.. Is it true.. Is it happen if i'm apply it into my development of products... Ermmmm... it maybe happen.. So here i want to share what i have exprienced and know with all of you. Hope you all can avoid this to happen in your project development.

1. Planning always on activities rather than feutures.
In almost traditional approaches in planning a project, they are always give an avtivities status to the user rather than in Agile, we give a functional system to the user to keep up the status by an iteration. The traditional approach, by each of priod time, they will be give a status of an activities they have been doing on some priod of time reffering on Gant's chart. On traditional approaches, activities is pass after the others activities is finished. But if the first one activities is still not finish the second activities will be not doing. Because it's have to be pass down the activities. And because of this lateness, the delivery of the product will be delay from expected time. And also, the unindependent activities will make this traditional approaches will be dependent on other activities to be done.

2. Multitasking on employee
When we assign a multiple task on a developer, the productivity of the developer will drop down. This is happen when the developer cannot do the all task which have been assign to him because of big responsibilities he have to carried. Because on this presure to meet a deadline with a lots of task, moral will down and productivity will drop. as example which in Mike Cohn book, as he said "Loading everyone to 100% of capacity has the same effect as loading a highway to 100% capacity: No one can make any progress".

3. Features not developed on priority
The traditional planning approaches is always prioritized the work by value to the user and customer. In traditional planning, we will plan all activities to the success of a projects. Will will go through one by one all activities to meet the complete system. And all developer will consider that all activities which have been planned and put in Gant's chart is mandatory and have to complete by the dateline. But at the end, the activities which have been complete is actualy no value to the customer. Customer not satisfy and have to reproduce. In agile this will not bee happen because user or customer will se a functional delivery by each iteration and any changes, the will find earlier.

4. Ingoring of Uncertainty
Ignoring on uncertainty is very big mistakes on planning. Without assuming user will not change their requirement cann kill your project successness. The customer or user is first. That the slogan.We cannot hope to identify every activities that will be needed in the course of a project. Maybe later on suddenly customer found that some feuters which really greate to them. This can make late delivery and the planning is fail. To avoid this, we can work in shot iterate. We deliver functional system to user in every each iteration. Work in short iteration so user will alway can see a functional system that we will deliver to them. Some missing task we cann add into the system because user find it on functional delivery. This will reduce uncertainty.

5. Estimates become Commitments
Estimating is very important to a team because before the start working, the have to figure out what a risk they will face. If we as a planner estimates short of time but there a lot of risk a team will face, than the team will cannot deliver the product. So estimating have to equivalent to the commitments the team will give. Such as Phillip Armour (2002) said "An estimates is probability, and commitments cannot be made to probability"

Adios

Test Driven Development (TDD)

2006-10-03T07:39:00Z

This TDD is the best development process i have been involved to. The "Red, Green and Refactor" is the most esiest way i have ever exprienced when develop a system. Before this, i majorly use Waterfall model which get a bussines requirement from user first. It take a lot of time and will make a uselees of time.

With this "Red, Green and Refactor", i just doin the simplest , less bug and fastest way to develop a system.

First of all, how to make use of this TDD. First, we must know about Unit Test environment. U can get the environment by using NUnit or Unit Test in .Net framework. And when doing a test, think it is for designing... Not for doin a testing only.

There is step2 tahat involve in thid TDD.

1. Fisrt things is, think as consumer when create a test. As example here :

I have a student and want to register to the system which whe call it StudentRegisSystem.

         example :
         Student student = new Student();
       student.Name = "Student Test";
       student.ID = Guid.NewGuid();

return student.Save();

2. Compile after writing a code. We will be promt an error. Create a domain class for student, create properties and Save() method just simple as simple as.
Just writing a code which to be need the code can be compile only. After it can be compile, run a test to the UnitTest. Like Example below:

        example:
        public partial class Student
        {
             private string m_name;
             private string m_id;

             public string Name
             {
                   get { return m_name; }
                   set { value = m_name; }
             }

             public string ID
             {
                   get { return m_id; }
                   set { value = m_id; }
             }

             public string Save()
             {
                throw new Exception("The method or operation is not implemented.");
             }

        }

3. And Red signal will be display. The red signal will be displayed marking thar there no implementation yet. So rewriting Save() method just to make the test past. Rewrite like below as at Save() method.

            example:
             public string Save()
             {
                return string.Empty;
             }

4. Compile and run Unit Test again. This time Green light appear. Thats meant the unit test have been pass. And the third factor in TDD is Refactor. At this step refactor your code to be easy to maintain and be read by other programmers which maybe make use of you code. Refactor you code and run Unit Test everytime you make a change. This too make sure thats is no bug after refactor.

The benefit of usinf thid development process is, we will start small. Use this princip, "Think Big, Start Small" . Using this TDD, we can detect a bug before we start a real development. and also, we can design our system while testing it. We have save our time and effort by using TDD. It is veryyy use full of me and maybe for you. Try to make use of it.

Adios.

Themes and Epic in User Stories

2006-10-03T07:35:00Z

What is themes and what is epic? Someday before, i dont know about these 2 kind of type in user stories.

First, i want to start with Epic. Epic is actually a large user stories which we can break apart of it. We can break it up into smallest user stories. As example here "Sarah want send hers resume". This is a large user stories. Because we can break it apart into example below"

     "Sarah want to create hers resume"
     "Sarah want to select a company before send hers resume"
     "Sarah want find availabe position of work before send a resume"

Thats an example i can describe about an Epic. It is a large user stories thats can be break apart to smaller user stories which the break aparrt one from epic can be done independency.

Now what is themes. From Mike Cohn from Mountain Goat, he said that, "themes is a colletion of related user stories." And what i understand is, theme is colection of user stories that we have to done under one iteration because they are related with each other, which meant dependency with other user stories. Even though, in agile methodology, it is pressure that create a not dependent user story which we can deliver an freaquent functional feutures to users in every iteration. But we cannot escape from dependencies. There will be some of user stories dependent on others user stories to complete a iteration. But if we can keep small on dependencies, it is quite better.

Adios

User Story "Epics"

2006-10-03T07:14:00Z

The word epic usually refers to the brave action or excitement or the films about the deeds of gods and great man. From it's literal meaning, we can conclude that user story epics is a great, large and complex set of user story. User role must be included in the epic user story description to picture the real scenario on how they will use the system. There are 2 types of epic user story; compound and complex. Compound user story can be dissambled into smaller user stories within the same story subject while complex user story is an extremely large and generic stories that cannot simply be broken down into smaller stories.

The "chunk" of splitted user stories shares the same subject and is called a theme.

To get clearer picture, look at these example:

Epic

User can cancel hotel reservation

Theme

Privilege member can cancel reservation up to last minute
Normal customer can cancel not less than 48 hours
Customer can cancel reservation by phone

To fake it or not

2006-10-03T06:57:00Z

Continuation from my 1st blog about Fake/Mock object. With the availbility of Dependency Injection framework(Microsoft Pattern and Practice ObjectBuilder, Spring Framewrok and StructureMap). We could easily swicth the implemetation of our interface. In my opinion creating a Mock just for the sake of it, just going to make your code less readable i.e. it's going to cost more on the maintanance.

This is how we would normally work when dealing with a dependency that we didn't really care about. Just as exmple we have a domain object called Patient, it has one operation , Save() returs void, the idea is when we call Save on the Patient instance, it must do some validation, then if the patientID is not null , it's new item and we want to add a new item to our persintance, if PatientID is not null, is mean we're updating existing patient.

        // our test case
        [Test]
        public void SavePatient()
        {

            Patient p = new Patient();
            p.Save();

            Assert.AreEqual(p.PatientID, 30);

        }



        public class Patient
        {

            public int PatientID { set; get;}

            public void Save()
            {

                if (this.Validator.Validate(this)) 
               throw new ArgumentException("Validation error");
                if (PatientID > 0)
                {
                    this.Persistance.Update(this);

                }
                else
                {
                    this.PatientID = this.Persistance.Add(this);

                }
            }
        }

So there are a couple of dependecies that we have here in order to make this method works , the Persistace and Validator, so what do we want to do is to test the domain Save method , not the Persistance or Validator. So the instinct is to do some refactoring , the first one is "Extract Interface" ( please refer to Martin Fowler -Refactoring for more refactoring details, I also a bif fan of Refactoring to Pattern by Joshue Krienvesky). Instead of having a concrete class for Validator and Persistance we now rever it to their interface

        public interface IValidator
        {
            bool Validate(Patient patient);
        }

        public interface IPersistance
        {
            int Save(Patient patient);
        }
        // thus our patient object
        private IValidator m_validator;
        private IPersistance m_persistance;

        public IPersistance Persistance
        {
            get { return m_persistance; }
            set { m_persistance = value; }
        }

        public IValidator Validator
        {
            get { return m_validator; }
            set { m_validator = value; }
        }