An agile, iterative approach to software development differs from a traditional, waterfall approach in the belief that it is not possible to know everything there is to know about all requirements at the beginning of the project. This makes the agile approach an empirical process, wherein learning occurs throughout the cycle and new information is incorporated as it is derived, as opposed to the predictive or speculative process that assumes all can be known in advance. Still, one useful tool I've adopted from the waterfall approach is a formula for calculating most likely task durations. This formula is associated with PERT estimates and schedules, but I don't recommend PERT for software development. The formula is: (o + 4m + p)/6, where o = optimistic time estimate for a task, m = most likely time estimate for the same task, and p = pessimistic time estimate for that task. The equation produces the expected time for the task being estimated.
Popular posts from this blog
Defects and Risks are often dealt with in a subjective, emotional way. That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue. The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization. I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization. Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
As a project manager who does not have a programming background, I find it essential to understand as much as possible about the way developers craft solutions to business problems in their code design and implementation. The best developers I know follow a set of design principles and patterns that ensure strong, flexible, extensible, modular code. Writing on this subject at his website http://www.objectmentor.com/ , Robert C. Martin identifies a set of design principles and design patterns that all software development project managers should understand (see http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf ) Here they are in summary: Principles of Object Oriented Class Design The Open Closed Principle (OCP) - A module should be open for extension but closed for modification. The correct use of this principle and its related techniques allow developers to add new features to existing code without changing the existing code and by only adding new code. It