Not Signed-In
Which clippings match 'Software Development Method' keyword pg.1 of 1
19 SEPTEMBER 2014

Agile Software Development: what we've learned at Forty

"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...

On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').

In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."

(James Archer, Forty)

1

TAGS

agile development • agile model • agile modelling • agile software development • current situationdesign processdevelopment life cycle • development methodology • Eric Karjaluoto • evolving needseXtreme Programmingfacing unpredicted challengesflexible management methodology • flexible process • formalised principlesiterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)Kanban • Lean (methodology) • management methodology • over-thinking • perfect is the enemy of done • requirements documents • saving details for later • scrum software development processsoftware developmentsoftware development methoduser experience design (UX)UX designwaterfall modelwhirlpool model

CONTRIBUTOR

Simon Perkins
18 JUNE 2014

Scrum: iterative and incremental agile software development

"Scrum is a management framework for incremental product development using one or more cross–functional, self–organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed–length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration."

(Michael James)

1

2

3

TAGS

agile developmentagile modellingapplication development • close online collaboration • cross-functional teams • development life cycleface-to-face communicationfacing unpredicted challengesflexible management methodology • holistic process • incremental development • incremental product development • iterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)management methodology • Michael James • physical co-location • product development methodology • product development strategy • project managementproject management method • requirements churn • return on investment (ROI)scrum software development processself-organising teamssoftware development method • sprints • whirlpool model

CONTRIBUTOR

Liam Birtles
26 JANUARY 2014

MoSCoW Analysis: a project requirements prioritisation technique

"MoSCoW analysis divides requirements into four categories: Must, Should, Could, and Won't. It is most applicable for software development or timeboxed delivery efforts, as it focuses on determining which requirements can be implemented given specified time or resource constraints. Category descriptions are as follows:

Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Should: Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

Could: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

Won't: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future."

(Kevin Brennan, 2009, p.165)

Kevin Brennan (2009). "A Guide to the Business Analysis Body of Knowledge". International Institute of Business Analysis. ISBN 978–0–9811292–1–1.

TAGS

building in measuresbusiness analysis • business requirements • clear project objectives • could • design requirements • importance • International Institute of Business Analysis • management methodmanagement methodologymanagement technique • MoSCoW analysis • MoSCoW method • MoSCoW prioritisation • must • organisational process • organisational technique • prioritisationprioritisation analysisprioritisation techniqueproject definitionproject deliverables • project delivery • project goalsproject managementproject management methodproject objectivesproject requirementsquantifiable definitionsrequirements gatheringrequirements prioritisation • should • software development methodtime management • wont

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.