This time, my post has nothing to do with .NET but rather with an issue that seems to be common, according to my search on the net and I thought that my findings may help people who experience the same issue.
Yesterday morning, I started to have serious issues with my cell phone, a HTC Touch.
Here is the list of issues (that came all together on the same day):
When starting up, it was taking way too long compared to usually (the Windows Mobile 6.1 screen was taking ages before to display the home screen).
The touch screen as it was no longer responding to my orders! For a cell phone that does not have a keyboard, that is rather a serious issue.
My cell phone was no longer recognized by my computer and the 'cube' interface was no longer working.
When I tried to access the contacts, the screen was empty and whenever I typed a name it kept displaying "Matching..." and it never comes back with suggestions.
Here are the things I have done and it looks like it is working today... Hope for a long term.
1 - Removed the screen protector: In fact, when I bought it, I put a plastic screen protector. It started to be dirty anyway. As a result, the touch screen was responding intermittently only. All other issues were still there (and I did not expect the cell phone to start up faster just by removing the protector :)).
2 - I did a hard reset of the phone following the instructions on the site http://www.flickr.com/photos/ryjones/2193904710/
Well, I lost all my contacts eventually and everything else in my cell phone (notes, documents, photos etc...). I did not really have the choice cause the cell phone could not synchronize anyway and was unusable.
Once the hard reset done, it looks like the cell phone is back again and everything is working perfectly now. I just cross my fingers!
Hope that helps!
Friday, October 2, 2009
Wednesday, April 29, 2009
Do we need an architect in SCRUM?
Few months ago, I went through the SCRUM certification process and during the training, I have asked the question 'Do we need an architect or technical lead in a SCRUM team?'. The answer was that from a pure SCRUM definition perspective, we should not.
SCRUM puts a lot of emphasis on team collaboration and it suggests that all decisions must emerge from the team as a whole and not from one particular person. Most of design decisions can be taken with this approach however, not all.
Software design is not a deterministic activity; i.e. same problem can be solved by many different approaches and here comes the problem: In Agile, we do not a design phase prior to start the devleopment activities. We design as we progress and sometimes we look back and do some refactoring (very brief definition of the design in an Agile process). That is, the way we are going to implement different use cases is not defined in details and chances are that a developer will implement a functionality using an approach that differs from the overall design of the application. For instance, I have encountered developers who use extensively Design Patterns. I have nothing against DPs but if only the features implemented by one developer are coded using heavily design patterns then we will end up with a code that is a bit messy in the sense that it does not solve problems in the same way consistently.
For me, the philosophy behind a solution design is as important as the design itself. At the begining of a project, we choose an approach or philosophy (for instance, we decide not to use web services for certain reasons. We decide to use data classes - we decide to decouple some projects from the infrastructure....) and the whole team must stick with it. The issue is that when a developer, and especially those added in the middle of the project, does not agree and does not respect our coding rules, we end up with some philosophical discussions that are often endless. It is here where do need someone who have the power to stop the discussion in order to move forward.
What I am trying to say here is that the technical leader or the architect does not have the power to take a decision against all the team members, but to make some developers follow the line and get them on track without wasting hours of useless meetings. The team still takes most of design decisions anyway.
The architect can bring his point and try to convince the team to adopt it. If she is very diplomatic and collaborative, she will succeed. Trying to impose a decision will just kill the confidence of team members in the collaboration process which will probably even make your SCRUM implementation a failure.
As a conclusion, I strongly believe that SCRUM is an excellent process however, I believe that a software architect is still required even in Agile processes. She will not produce any thick documentation but guide developers and ensure that the team is on the right track all along the project lifetime.
SCRUM puts a lot of emphasis on team collaboration and it suggests that all decisions must emerge from the team as a whole and not from one particular person. Most of design decisions can be taken with this approach however, not all.
Software design is not a deterministic activity; i.e. same problem can be solved by many different approaches and here comes the problem: In Agile, we do not a design phase prior to start the devleopment activities. We design as we progress and sometimes we look back and do some refactoring (very brief definition of the design in an Agile process). That is, the way we are going to implement different use cases is not defined in details and chances are that a developer will implement a functionality using an approach that differs from the overall design of the application. For instance, I have encountered developers who use extensively Design Patterns. I have nothing against DPs but if only the features implemented by one developer are coded using heavily design patterns then we will end up with a code that is a bit messy in the sense that it does not solve problems in the same way consistently.
For me, the philosophy behind a solution design is as important as the design itself. At the begining of a project, we choose an approach or philosophy (for instance, we decide not to use web services for certain reasons. We decide to use data classes - we decide to decouple some projects from the infrastructure....) and the whole team must stick with it. The issue is that when a developer, and especially those added in the middle of the project, does not agree and does not respect our coding rules, we end up with some philosophical discussions that are often endless. It is here where do need someone who have the power to stop the discussion in order to move forward.
What I am trying to say here is that the technical leader or the architect does not have the power to take a decision against all the team members, but to make some developers follow the line and get them on track without wasting hours of useless meetings. The team still takes most of design decisions anyway.
The architect can bring his point and try to convince the team to adopt it. If she is very diplomatic and collaborative, she will succeed. Trying to impose a decision will just kill the confidence of team members in the collaboration process which will probably even make your SCRUM implementation a failure.
As a conclusion, I strongly believe that SCRUM is an excellent process however, I believe that a software architect is still required even in Agile processes. She will not produce any thick documentation but guide developers and ensure that the team is on the right track all along the project lifetime.
Subscribe to:
Posts (Atom)