A couple of months ago, I happended to attend a presentation on a Software Product developed using Microsoft.NET Framework and I was pretty impressed with its features and the user interface. Since the Lead Architect himself was presenting the capabilities, I curiously asked how long did it take for you to come this far in terms of features that he presented. And he said we have been working on this for around 8 months now and we have a 6 people development team. I knew that the team had other tasks as well and I was pretty amazed. Then he said - "Its based on Smart Client Framework from Microsoft" in a way that sounded like - What! you dont know about Smart Client ?
Since then, i have been interested to know what MS is providing that makes Windows Forms Application development simple. So for the last couple of days I have been trying to understand what this is all about. My first stop was google and I would advise reading David Hill's blog to know more about Smart Client.
My attempts to download took me to the patterns and practices home page in MSDN and from there i jumped to CodePlex ( MS Open Source Project Repository). I downloaded everything that is available on SmartClient and when I ran the Setup, i saw a "Check Dependencies" button to the right and could immediately see that there were some items missing on my PC. Oh, btw, I have Visual Studio 2005 Professional Edition with Service Pack 1 installed on my Dell Latitude D620 Laptop. And I also have .NET 3.0 and the Visual Studio Extensions for .NET 3.0 In installed. Coming back, the items missing were -
Guidance Automation Extensions
Guidance Automation ToolKit
SQL Server 2005 Compact Edition
You could complete the installation and comeback to have Guidance Automation support. However I decided to install them before I go ahead. So I quit the installation and downloaded all of the above. I also noticed that there is an Enterprise Library 3.1 released in May 2007. uh! There is also a Microsoft .NET 3.0 Framework SP1, but since the installation failed, I gave up. Anyway it was not a dependency. I installed the items in the order as listed above and then finally i installed the Smart Client Software Factory.
I m all set for exploring Smart Client Software Factory. I launched Visual Studio and verified that I can create a solution that is using the Smart Client Software Factory and it works!
Keep looking at this space for updates on my experiments with Smart Client Software Factory.
Thanks for Reading.
Wednesday, December 12, 2007
Saturday, December 8, 2007
Reverse Engineering Sequence Diagrams - Are they effective
I have been asked this question several times - How do we synchronize designs automatically? THis is more of a question for sequence diagrams than for class diagrams.
Just to give a little bit more background, in almost all the projects that fall in my perimeter, we use OOAD with UML for design. We follow design, coding and unit testing in that order. We have still some catch up to do with agile practices (such as Model Storming, Refactoring). We typically prepare Class Diagrams, Sequence Diagrams and occasionally State Chart Diagrams to capture the design. Once we are satisfied with the design, we transition to Coding.
During coding phase, often times we introduce methods, private members, modify method signatures and occasionally even add new classes. And since the focus is entirely on implementation, the models prepared during design phase go out of sync. Of course if there is a gross design miss, we go back to the design phase, which is relatively very less. But this topic is more about the other majority of cases when the changes to design are nominal. I should be careful with words here. When i say "nominal" it means no major structural changes.
Once the coding & unit testing is over, typically developers are asked to synchronize original design models & documentation to match their implementation (what a pity!). And thats when they crib. Because both Rational Rose (or XDE) and MS Visio (to some extent) can reverse engineer class diagrams, but not sequence diagrams. I know some of you would be thinking - "There are loads of tool available that do it for you". My wishful thinking brings out 2 different questions(although they are related) -
A sequence diagram depicts the time ordering of messages exchanged between objects. Following is a sequence diagram that depicts the scenario of a customer viewing the account balance using an Automated Teller Machine(ATM).
Perhaps, I overdid the example. Anyway, I think it serves the purpose. I have tried to depict a high level flow right from the insertion of ATM card to the balance display. For the sake of simplicity, i have used only a minimal set of objects.
What if this sequence diagram had been auto generated from reverse engineering the code?
In short, reverse engineering tool can only be of little help. A reverse engineering sequence diagram is more of a flow diagram than anything else and thus are not effective in the true sense of it. Atleast thats what I tend to think. What are your thoughts on this?
Just to give a little bit more background, in almost all the projects that fall in my perimeter, we use OOAD with UML for design. We follow design, coding and unit testing in that order. We have still some catch up to do with agile practices (such as Model Storming, Refactoring). We typically prepare Class Diagrams, Sequence Diagrams and occasionally State Chart Diagrams to capture the design. Once we are satisfied with the design, we transition to Coding.
During coding phase, often times we introduce methods, private members, modify method signatures and occasionally even add new classes. And since the focus is entirely on implementation, the models prepared during design phase go out of sync. Of course if there is a gross design miss, we go back to the design phase, which is relatively very less. But this topic is more about the other majority of cases when the changes to design are nominal. I should be careful with words here. When i say "nominal" it means no major structural changes.
Once the coding & unit testing is over, typically developers are asked to synchronize original design models & documentation to match their implementation (what a pity!). And thats when they crib. Because both Rational Rose (or XDE) and MS Visio (to some extent) can reverse engineer class diagrams, but not sequence diagrams. I know some of you would be thinking - "There are loads of tool available that do it for you". My wishful thinking brings out 2 different questions(although they are related) -
- Why did IBM Rational Rose / MS Visio not provide this functionality even though there tools available out there that do it for you?
- Supposing even if you had a tool that automatically regenerated sequence diagrams for you, is it really helpful?
A sequence diagram depicts the time ordering of messages exchanged between objects. Following is a sequence diagram that depicts the scenario of a customer viewing the account balance using an Automated Teller Machine(ATM).
Perhaps, I overdid the example. Anyway, I think it serves the purpose. I have tried to depict a high level flow right from the insertion of ATM card to the balance display. For the sake of simplicity, i have used only a minimal set of objects.
What if this sequence diagram had been auto generated from reverse engineering the code?
- The auto generating tool would have depicted the message flow related to the low level functionality of reading the card. Obviously there is more to it than just a ReadCard(). Since the goal of this diagram was to depict the "View Balance" Scenario, we did not drill down on ReadCard().
- Take a close look at the message OnOptionSelected(ViewBalance). The design decision is that the option chosen will be handled by the ATM object(A switch-case implementation). It could be ViewBalance, WithdrawMoney or ChequeDeposit. Once again we were interested in just the ViewBalance and hence did not show the others. There is no way the sequence diagram generating tool would know the difference and would have message flows for other options too.
- Lastly, the actual code contains other aspects such as using a Messaging mechanism to post messages to other parts of the system. It can also include a Trace Logging mechanism for debugging purposes. Typically these would be calls to other infrastructural components. You may not want a sequence diagram depicting a functional scenario include message flows related to these.
In short, reverse engineering tool can only be of little help. A reverse engineering sequence diagram is more of a flow diagram than anything else and thus are not effective in the true sense of it. Atleast thats what I tend to think. What are your thoughts on this?
Friday, December 7, 2007
User Stories & Constraints for Requirements
I am part of a project, the goal of which is to identify high level requirements, draw conceptual architecture and finally provide cost estimate of execution(based on the requirements and the conceptual architecture) of what is perceived as another huge project. The project has been going on for just above 4 months and nearing completion in a week. When the project started we defined some rules of engagement and one of them was use of agile methodologies for execution management.
We went through few planning meetings, understanding the process, team building etc. The concept was new and appealed to everyone. Things were going good, until we stumbled upon a roadblock in the first sprint and that was - How to capture requirements? In the past we had used Use cases and "shall constructs" to define requirements. We could have gone the Use cases way but it would have taken lot of time given the size of the envisioned product and our project was "time boxed". The problem with using "shall" constructs is a single usage scenario is split into multiple statements and then you struggle with combining them together for the sake of understanding or estimation.
What we were actually looking for is -
This led us to explore User stories(on a side note, its a terrible name! for an artifact that is tremendously useful). Here is a definition from agile modeling that I found strikingly similar to what we needed.
A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it
There is another definition( another useful resource on XP) which treats User stories as a lead to the conversation between developer and customer.
However, we were not comfortable with the format and examples as the business value was not coming up and moreover the examples were not succinct. Finally one of my searches took me to a blog by Michael James and thus i found a reference to the best book on User Stories - User Stories Applied by Mike Cohn and also a primer on INVEST principle.
We finally used the format suggested by Mike Cohn and that is
As a <User>, I can <Requirement function statement>, so that <value derived from requirement>. Here is an example -
As a Technician, I can monitor sensor data and calibration values so that I can diagnose problems in the behavior of the engine.
Note that there are 3 broad portions -
The technician shall be able to view the monitored values from a distance of 10 meters.
Typically there are only a handful of them if you organize the user stories properly and are easy to remember at the time of estimation.
Where we are now - We are almost done with requirements, except for a select few, the estimation has been done and we are very satisfied with how it turned out.
Where to go from here - Certainly we can write acceptance test cases. To enhance the documentation, we can expand each user story into a full blown Use case OR we can drill down each user story into a bunch of testable and traceable requirements or both. But thats for the actual project execution to decide next year. Right now, i m looking forward to the holidays.
If you have any queries, comments, please do share. If you ever used User stories, i would be keen on what your experience has been.
We went through few planning meetings, understanding the process, team building etc. The concept was new and appealed to everyone. Things were going good, until we stumbled upon a roadblock in the first sprint and that was - How to capture requirements? In the past we had used Use cases and "shall constructs" to define requirements. We could have gone the Use cases way but it would have taken lot of time given the size of the envisioned product and our project was "time boxed". The problem with using "shall" constructs is a single usage scenario is split into multiple statements and then you struggle with combining them together for the sake of understanding or estimation.
What we were actually looking for is -
- A means of succinctly stating the requirements in user language; i.e. In a way so that we can identify the benefit
- Something that could immediately bring out the business value to the user.
- Something that we can base the acceptance test cases on.
This led us to explore User stories(on a side note, its a terrible name! for an artifact that is tremendously useful). Here is a definition from agile modeling that I found strikingly similar to what we needed.
A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it
There is another definition( another useful resource on XP) which treats User stories as a lead to the conversation between developer and customer.
However, we were not comfortable with the format and examples as the business value was not coming up and moreover the examples were not succinct. Finally one of my searches took me to a blog by Michael James and thus i found a reference to the best book on User Stories - User Stories Applied by Mike Cohn and also a primer on INVEST principle.
We finally used the format suggested by Mike Cohn and that is
As a <User>, I can <Requirement function statement>, so that <value derived from requirement>. Here is an example -
As a Technician, I can monitor sensor data and calibration values so that I can diagnose problems in the behavior of the engine.
Note that there are 3 broad portions -
- The User portion identifies the role. This helps in prioritizing the requirement as the product we are developing have several actors at various levels.
- The
second part identifies the requirement. This is the high level requirement. Some care needs to be taken to balance the content of the requirement so that it can be estimated. - The
third part identifies the business value derived from the requirement. So for the same actor, we can prioritize what functions are important.
The technician shall be able to view the monitored values from a distance of 10 meters.
Typically there are only a handful of them if you organize the user stories properly and are easy to remember at the time of estimation.
Where we are now - We are almost done with requirements, except for a select few, the estimation has been done and we are very satisfied with how it turned out.
Where to go from here - Certainly we can write acceptance test cases. To enhance the documentation, we can expand each user story into a full blown Use case OR we can drill down each user story into a bunch of testable and traceable requirements or both. But thats for the actual project execution to decide next year. Right now, i m looking forward to the holidays.
If you have any queries, comments, please do share. If you ever used User stories, i would be keen on what your experience has been.
Thursday, December 6, 2007
My experience with SCRUM - Agile Project Management
A post after a long long time. There are several topics that i want to write about, but time has been a issue always. I am still struggling to manage time and i see a potential new year resolution since its almost the end of year.
I have always been motivated to look at agile practices. For e.g. TDD, Pair Programming, Continuous Integration etc. That sounds reasonable given the kind of work I am involved with - HMI Tools development and bulk of the development being in .NET. All of these practices are related to Software Delivery, whereas what I m going to share with you is agile Project Management - SCRUM.
My first stint with SCRUM was a 15 mins daily meeting in the morning for one of the projects. We used to call the meeting itself "SCRUM". Not fully correct, but not fully incorrect either. We used to go through the 3 ubiquitous questions -
1. What you did yesterday?
2. What are you doing today?
3. Are there any roadblocks in your way?
It served a good means of tracking the project status daily and immensely helped my Manager. But did it serve the purpose ? I would say, partially as we were not following it in the spirit of Sprints, Product Backlog etc.
My second stint with SCRUM was a full fledged agile project management and interestingly it was not for a software delivery. There was no "working product" which is the soul of any agile practice. We applied SCRUM to deliver Requirements & Conceptual Architecture for a new software product. What made it even more interesting was the Product Owner wanted me to "project manage" the work and was very keen on experimenting with SCRUM. I was made the scape goat and was designated as the SCRUM Master(because i was the only one who had any experience with SCRUM before :-) ) and thus i came to experience the agile way of managing project.
As always, I surfed the web, downloaded presentations, materials etc. to educate myself with SCRUM. I also got an excellent training material from one of my friends by none other than Ken Schwaber himself. Unfortunately I cannot share it as i am not allowed to.
As the work we wanted to accomplish was not a working product, we had to use a unique way of arriving at the Product Backlog. We brainstormed and used mind map to identify the various topics pertaining to "Service Engineering" which was the theme of the product. Once we had the level 3 topics, we worded them as verb phrases and bingo we had the backlog. For e.g. 'Collecting Data about the Machine' was one such level 3 topic. We voted the rank (points) of the product backlog items. The Product Owner set the priority of each item and that's how we went about allocating them to Sprints of 2 weeks duration. Most of this activity was performed as a team within meeting room.
The GOAL was pretty simple. Draft Requirements and Architecture for each product backlog item allocated to the sprint and there was a responsible team member for each item. The sprint tasks then comprised of Interviewing Customers, Interviewing Subject Matter Experts, Observing Users work in a real shop floor and translating those to User stories. This way it was easy to see what was accomplished during the Retrospectives of the Sprints. And yeah, by the way we had the 15 mins Daily SCRUM meeting as well.
The planning & tracking was fairly simple using an excel sheet that tracks the Burndown and there are several examples available on the web. I started with a version that i found on Web and had to customize it to our needs. It was kind of bumpy in the first 2 sprints, but then we settled down nicely and have been consistently able to hit the estimated project velocity based on the BurnDown.
All in all, I must say i enjoyed every bit of SCRUM. Some of the important learnings from my experience of SCRUM are -
1) You do not have to dig past project data to come up with estimates. Just apply your confidence and pick a number. Within a couple of sprints, you will have enough data from the sprint itself to feed into and that is far more reliable than all other data you have as it is for the actual team and actual work.
2) Risks get constant and immediate attention and are always on the top of the stack. Obviously you never defer them as it is at the top. Another advantage is, since the Product owner is involved, the 'Classification of the Risk' is also adequately done. I.e. you do not chase false positives.
3) There is no detailed upfront schedule planning. You could do that, but i found it unnecessary. Within a couple of sprints, with the team velocity, I could project the project end date given no change in backlog. But in reality, you add more backlog items (we did too!) and immediately, based on the team velocity, you will know when you will finish. I.e you can forecast a realistic end date.
4) The project management is very very simple. There is no fooling around with complex numbers. The very fact that I could use a simple Excel sheet to "project manage" the work says it all. In terms of time, I had to spend no more than 2 hrs a week to analyse the numbers etc. for a team of 6 people.
5) Estimation is a on-going process as it is part of Sprint planning at the beginning of every sprint. Moreover every team member gets to estimate his/her task. So if you get it wrong the first time (or first sprint), use that knowledge to correct it in the later sprints. This is perfect as productivity tends to increase with project experience.
6) The focus is on "what the team achieved" rather than on "who failed". There are no finger pointing. Its the team that "accomplishes" and its the team that "fails".
Here is an example burndown sheet that i used for tracking the current sprint. The product backlog itself was contained in another sheet in a format as prescribed in Example of burndown for scrum backlog and sprint
To know about Scrum -
Excellent Wikipedia article
Control Chaos
More Search Links
Useful links for examples of Scrum Burndown Spreadsheets
The most interesting.
Applying SCRUM for an individual
MSDN article showing plugin for Project 2003 usage with SCRUM
Example of burndown for scrum backlog and sprint
If you have any queries or comments or if you simply find this useful, post a comment with your thoughts. I would also be keen on hearing about your experiences with SCRUM if any.
Thanks for reading
I have always been motivated to look at agile practices. For e.g. TDD, Pair Programming, Continuous Integration etc. That sounds reasonable given the kind of work I am involved with - HMI Tools development and bulk of the development being in .NET. All of these practices are related to Software Delivery, whereas what I m going to share with you is agile Project Management - SCRUM.
My first stint with SCRUM was a 15 mins daily meeting in the morning for one of the projects. We used to call the meeting itself "SCRUM". Not fully correct, but not fully incorrect either. We used to go through the 3 ubiquitous questions -
1. What you did yesterday?
2. What are you doing today?
3. Are there any roadblocks in your way?
It served a good means of tracking the project status daily and immensely helped my Manager. But did it serve the purpose ? I would say, partially as we were not following it in the spirit of Sprints, Product Backlog etc.
My second stint with SCRUM was a full fledged agile project management and interestingly it was not for a software delivery. There was no "working product" which is the soul of any agile practice. We applied SCRUM to deliver Requirements & Conceptual Architecture for a new software product. What made it even more interesting was the Product Owner wanted me to "project manage" the work and was very keen on experimenting with SCRUM. I was made the scape goat and was designated as the SCRUM Master(because i was the only one who had any experience with SCRUM before :-) ) and thus i came to experience the agile way of managing project.
As always, I surfed the web, downloaded presentations, materials etc. to educate myself with SCRUM. I also got an excellent training material from one of my friends by none other than Ken Schwaber himself. Unfortunately I cannot share it as i am not allowed to.
As the work we wanted to accomplish was not a working product, we had to use a unique way of arriving at the Product Backlog. We brainstormed and used mind map to identify the various topics pertaining to "Service Engineering" which was the theme of the product. Once we had the level 3 topics, we worded them as verb phrases and bingo we had the backlog. For e.g. 'Collecting Data about the Machine' was one such level 3 topic. We voted the rank (points) of the product backlog items. The Product Owner set the priority of each item and that's how we went about allocating them to Sprints of 2 weeks duration. Most of this activity was performed as a team within meeting room.
The GOAL was pretty simple. Draft Requirements and Architecture for each product backlog item allocated to the sprint and there was a responsible team member for each item. The sprint tasks then comprised of Interviewing Customers, Interviewing Subject Matter Experts, Observing Users work in a real shop floor and translating those to User stories. This way it was easy to see what was accomplished during the Retrospectives of the Sprints. And yeah, by the way we had the 15 mins Daily SCRUM meeting as well.
The planning & tracking was fairly simple using an excel sheet that tracks the Burndown and there are several examples available on the web. I started with a version that i found on Web and had to customize it to our needs. It was kind of bumpy in the first 2 sprints, but then we settled down nicely and have been consistently able to hit the estimated project velocity based on the BurnDown.
All in all, I must say i enjoyed every bit of SCRUM. Some of the important learnings from my experience of SCRUM are -
1) You do not have to dig past project data to come up with estimates. Just apply your confidence and pick a number. Within a couple of sprints, you will have enough data from the sprint itself to feed into and that is far more reliable than all other data you have as it is for the actual team and actual work.
2) Risks get constant and immediate attention and are always on the top of the stack. Obviously you never defer them as it is at the top. Another advantage is, since the Product owner is involved, the 'Classification of the Risk' is also adequately done. I.e. you do not chase false positives.
3) There is no detailed upfront schedule planning. You could do that, but i found it unnecessary. Within a couple of sprints, with the team velocity, I could project the project end date given no change in backlog. But in reality, you add more backlog items (we did too!) and immediately, based on the team velocity, you will know when you will finish. I.e you can forecast a realistic end date.
4) The project management is very very simple. There is no fooling around with complex numbers. The very fact that I could use a simple Excel sheet to "project manage" the work says it all. In terms of time, I had to spend no more than 2 hrs a week to analyse the numbers etc. for a team of 6 people.
5) Estimation is a on-going process as it is part of Sprint planning at the beginning of every sprint. Moreover every team member gets to estimate his/her task. So if you get it wrong the first time (or first sprint), use that knowledge to correct it in the later sprints. This is perfect as productivity tends to increase with project experience.
6) The focus is on "what the team achieved" rather than on "who failed". There are no finger pointing. Its the team that "accomplishes" and its the team that "fails".
Here is an example burndown sheet that i used for tracking the current sprint. The product backlog itself was contained in another sheet in a format as prescribed in Example of burndown for scrum backlog and sprint
To know about Scrum -
Excellent Wikipedia article
Control Chaos
More Search Links
Useful links for examples of Scrum Burndown Spreadsheets
The most interesting.
Applying SCRUM for an individual
MSDN article showing plugin for Project 2003 usage with SCRUM
Example of burndown for scrum backlog and sprint
If you have any queries or comments or if you simply find this useful, post a comment with your thoughts. I would also be keen on hearing about your experiences with SCRUM if any.
Thanks for reading
Subscribe to:
Posts (Atom)
