Evaluation of Methodologies;
Name: SCRUM
Authors: Hirotaka Takeuchi & Ikujiro Nonaka
Ken Schwaber & Jeff Sutherland
This method is a set of ideas, concepts and values that can be imposed on an existing system, to increase the productivity of development of an actual product. SCRUM focuses alot on delivering an actual product to clients in time boxed iterations.
The system is designed to have daily communications. Other than its daily meetings the type of collaboration it promotes bringing new data to everybody's attention. So good news and bad news gets told and dealt with asap.
There is also a single responsible person for evaluating the ongoing progress. So for example if the project shows signs of being very late on delivery (which can be detected very early - unlike many other methodologies) remedial action can be taken and decisions made to alter how things are being done.
Scrum also promotes non conventional ways of responding to slumps in project delivery times. The typical response being to force human resources to work harder and longer hours. As stated before SCRUM is really a set of beliefs that can be enforced on any system. One of these is generally accepting that employees, development team, etc. are working diligently toward project goals and deadlines. Where normally it would be automatic to sacrifice quality and conformance to industry standards to deliver software on time; SCRUM promotes acceptable working hours, diligence in conforming to best practices (proper documentation) and standards.
This ensures the end product that the company and the team are so dedicated to is actually worthy for the customer deployment and meets the highest levels of quality and usability.
Core Concepts:
The system is designed to have daily communications. Other than its daily meetings the type of collaboration it promotes bringing new data to everybody's attention. So good news and bad news gets told and dealt with asap.
There is also a single responsible person for evaluating the ongoing progress. So for example if the project shows signs of being very late on delivery (which can be detected very early - unlike many other methodologies) remedial action can be taken and decisions made to alter how things are being done.
Scrum also promotes non conventional ways of responding to slumps in project delivery times. The typical response being to force human resources to work harder and longer hours. As stated before SCRUM is really a set of beliefs that can be enforced on any system. One of these is generally accepting that employees, development team, etc. are working diligently toward project goals and deadlines. Where normally it would be automatic to sacrifice quality and conformance to industry standards to deliver software on time; SCRUM promotes acceptable working hours, diligence in conforming to best practices (proper documentation) and standards.
This ensures the end product that the company and the team are so dedicated to is actually worthy for the customer deployment and meets the highest levels of quality and usability.
Core Concepts:
- Product Backlog - List of requirements / needs / activities in order of importance for the project. Highest importance, risk or most needed at the top.
- Sprint Backlog - Sprint - a period of development - usually weeks to 1 month but not much more than a month. The Sprint Backlog is what is to be accomplished at the end of the sprint. It comes from the requirements in the product backlog. The Team is presented with what The Product Owner / Scrum Master wants from the sprint and they get to say how much they can achieve.
- Sprint Meeting (Planning) - Before the start of a scrum sprint a meeting is held to plan the event and process of the scrum. 3 hrs - 8 hrs (max).
- Sprint Review - Team and scrum master and participants review work done in the sprint, the product delivered and the events that took place.
- Daily Meeting - 15 mins meeting held in each day of a scrum
- Burn Down - A chart displaying the remaining work for the project. This is available to all and is updated daily.
Project Pros:
- Focused on Delivery
- Team Oriented
- Supports Best Practices - Quality Software, Documentation
- Constant Evaluation of progress / risks / value / cost
- Focus on deadlines and time line
Project Cons:
- Requires large amts. organization|
- Even though it caters for changing requirements, I feel that it necessitates a solid set of initial requirements.
- The system is based on proper user representation and involvement. If it so happens that the client is slightly misrepresented, even thought it would not be the fault of the developers, the project could fail.
Can I use it:
This is a great framework for a large organization I think, or even a small very tight knit company, where communication and openness are valued and practiced principles.
Companies like Yahoo and Google are using it, so it is being tried. I really like that it is not restricted to just Software development. The fact that it can be used in any environment says alot about the base principles.
I could deploy this - I like some of the values; however the team effort required and the meeting schedules would be very confining and seems not practical for the situation.
So maybe we can adopt some of the values but not necessarily the entire methodology.
http://www.scrumalliance.org
http://www.controlchaos.com/about/
http://www.implementingscrum.com/
http://video.google.com/videosearch?q=SCRUM&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&sa=X&oi=video_result_group&resnum=4&ct=title#
Name: Extreme Programming
Authors: Originally - Kent Beck
Others - Ann Anderson, Ken Auer, Ward Cunningham, Martin Fowler, Chet Hendrickson, Ron Jeffries.
Extreme Programming or XP is a method that is built on the focus of the customer and the iterative design/development process. Like many systems for productive development XP surrounds a set of core practices, when used together boast a stable and more rapid development process. The code is only valuable when it works and works for the client. The code should be built on the test first policy - where the tests are written before the code. The tests should come from the programmers and the users - the test data should come from the most reliable source, i.e. the users. The users are involved from the start and their interaction in the least ambiguous way helps to ensure programmers and the rest of the project team have a clear understanding of what the customer wants. Tests are built to represent this before the software is built so that the efforts and aptitude of the development team is transparent. The development process is attempted in parts according to the requirements as described by the users in User Stories. All stories are organised according to a realistic priority of the users and the resources of the team and this paves the path that the development is guided upon. Each set of requirement from the user stories are attempted in a release and the release can be powered by a release plan.
Core Concepts:
- Development Environment - Other than the standard definitions of what a work environment should be, this methodology seems to take into consideration the people doing the core development work - the programmers. The extreme environment seems to directly address the needs of programmers by keeping the working hours to a limit of a 40hr week. (It is true - programmers need sleep too - even though we may not admit it). It encourages programmers to work together by having them all in the same room. It also has daily meetings to facilitate communication. This methodology goes as far as noting the need to provide food and additions to aid programmers on a daily basis.
- Listening - Involving the customer / users and understanding their needs and wants out of the project in way that is transparent to the programmers supporting the Customer Bill of Rights and the Developer Bill of Rights. User stories are used to capture scenarios that surround the system's environment. The user stories are eventually addressed as the requirements of the system. It is important to note that User Stories are not Use Cases and there are significant differences in the two. The deliverables from the user stories are organised according to importance for the customer and the resources of the development team.
- Design & Development - Extreme Programming is based on Testing and test first procedures. The test for the software are written before the actual software so that when the design is put into code it is sure to meet the requirements and needs of the users / customers. Additional tests called acceptance tests are used to validate software against the features needed by customers. Also the development is done in iterations, usually that each meet some of the user stories described above so that at the end of each cycle or release of the software there is something to test against in terms of user needs / system requirements.
Even though the work is derived from different users and stakeholders, the actual software is written by programmers / developers and there have been many public outcries denoting the disregard for working conditions.
http://www.extremeprogramming.org
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.xprogramming.com
http://www.cs.toronto.edu/~penny/research/release-planning/samplerp.html
http://books.google.tt/books?id=u13hVoYVZa8C&dq=who+founded+extreme+programming&printsec=frontcover&source=in&hl=en&ei=V0WQSZW2G9KgtwfDvtSNCw&sa=X&oi=book_result&resnum=12&ct=result#PPA1,M1
No comments:
Post a Comment