Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Can Agile/XP go together with layered approach?
Should Agile/XP go together with layered approach?
Breaking the source code into layers requires extra efforts and thereby increases the development-time significantly.
N.B : By 'Layers' I mean separate assemblies with POCO, DA, etc.
Agile/XP is an approach to managing your project activities, deliverables and timelines.
Layered (N-tier) applications are a way to improve maintainability, scalability, and the ability for team members separate areas of responsibility.
They don't have much to do with each other, except that they both will require an additional investment in time if you're not familiar with each. Both will tend to improve the quality of your project if used properly, compared to traditional alternatives.
It seems to me instead that the agile warning "You Ain't Going to Need It" is not to avoid complexity altogether, but to avoid adding NEEDLESS complexity. Indeed, one of the benefits of unit testing is to set up a discipline wherein you can fearlessly refactor so stuff ends up where it belongs, rather than where it may have started.
So the point is not to avoid layers (or tiers, if you must) -- the point is to avoid layers that suck.
The two are entirely orthogonal.
In XP you develop the system feature by feature. As you add features you continually refactor the system to ensure that it's implementation is as clear as possible. Layers usually fall out of that refactoring. As do tiers if that architecture is appropriate, or other large-scale architectural structures such as SEDA or REST.
I think they real question here is should have developers divided up by layers on a team- should you have an html dev, a js dev, a middle tier person, a messaging system person, and a dba all working together to build a CRUD form, or should you build by feature and let one person own the thread. The latter is preferable in agile- specializing generalists are preferred to specialists.
Is it sensible to have several teams working together on an Agile project? Yes: I've worked on a large-scale project with 200+ developers across 15+ teams. There were about 20 or 30 services in all.
Can this be done with specialised teams? Not really.
Can the members of the teams have specialisations? Yes, but you really need generalists with strengths in some areas rather than people who only know one thing and won't touch anything else.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing a project using prototyping methodology. However, since end users are involved, I am thinking of user stories for requirements gathering. I can see that user stories are generally associated with AGILE methodology. So can I use it in a project that involves prototyping methodology?
In my experience User stories are used to divide a major chunk of work into smaller parts from an end users point of view.
Similarly, it can be used in prototyping methodology to divide the functionality of the prototype into small parts, each from an end users point of view.
since end users are involved, I am thinking of user stories for requirements gathering.
In line with the previous answer by Surkeet, user stories are written from the perspective of the user. Having them written in their language may make the communication between your development team and the user(s) smoother and based on a common vocabulary. The answer to this question is that "it depends". It really depends on the nature of your project. If the details of the user story (i.e. as a , I would like to so that ) is good enough for you, you have good-enough communication with your customer, and the nature your development tolerates iterations, then maybe user stories alone would be a good tactic to document and communicate requirements. However, there are cases where documenting requirements in terms of user stories is not enough. An example of that would the pressing need to agree on the non-functional requirements (a.k.a. quality attributes). An example of theses requirements is reliability, performance, and security. Especially in very large/critical systems that may fit an agile methodology, having to formally express non-functional requirements is a must. This is arguable and may start technical wars as some people do use user stories to document non-functional requirements.
So can I use it in a project that involves prototyping methodology?
Using user stories, however, is not the only tactic that you could use to develop effective prototype. Yes, it can be used to trigger the first iteration of prototyping and maybe govern the iterations of prototyping, but again it is not the only way. One could complement prototyping with different tactics that fits agile methodologies well such as storyboarding. Think of storyboards as an interactive, comic-like, representation of a given interaction to achieve a certain user-defined goal. The great thing about them is that they are graphical (as opposed to narrated bullet points of a use-case scenario), making them a powerful illustration tools. Here is a short article about the subject (link).
Also, I would recommend not thinking about Agile as a package that comes with techniques that you have to follow. Tailor the process to your needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there anyone who can tell me what is the difference between CMMI and Agile. I know some obvious difference, but I want to know it further. I will appreciate it a lot if someone can help me! Thanks!
CMMI is a process improvement methodology which aims to take projects or teams from level 1, "chaotic", to a higher level, ideally but not necessarily level 5, "optimising".
It consists of various capabilities, each of which is assigned to a specific level. For example, CMM level 2 requires the Project Planning capability. The levels are basically:
Chaotic, no real control.
Managed, processes at project level, mostly reactive.
Defined, processes at organisation level, proactive.
Quantitative, processes measured and controlled.
Optimising, feedback loops and continuously improving.
In my opinion, high levels of CMMI maturity are rather complex and difficult to achieve. While working for a large company doing outsourcing for a major Telco, we achieved level 5 but it was a great deal of work for continuously diminishing returns. We ended up viewing it as mostly a way to get government work and, in fact, I made a name for myself as a small projects specialist where we could still follow CMMI but not have to charge megabucks to the customer.
Agile, on the other hand, is a project management methodology focusing more on delivering what customers need rather than copious amounts of paperwork :-)
I see CMMI as one level up from Agile in that Agile itself is not a massively self-improving process.
It has improvement processes built in (such as retrospectives) but not in such a manner that the whole methodology may be turfed out if it's not performing.
In higher CMMI levels, whole chunks of project management methods (including Agile for example) can be tossed out or bought in depending on their performance and/or likely efficiencies.
Agile is a set of four main principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
—Agile Manifesto
From which dozens of software development methodologies are derived.
CMMI is a process improvement model. It's a meta-process and it's not, AFAIK, strictly related to software development.
As such it makes absolutely no sense comparing the two (a model and a set of principles). It also makes no sense asking about which maturity level is agile or even which maturity level is a specific agile methodology.
We can only talk about the specific maturity level of a particular agile software methodology implementation, e.g. "in this team we do Scrum at an optimizing maturity level".
Some great formal answers are already here, maybe this will help to understand the difference for ones who seek understanding:
On a pirate ship set of principles that keep pirates moving towards a common goal is called "pirate code of honor" - this is set of Agile principles.
But there is always one guy on a boat with navigational instruments and a map, who knows where we are now and how to guide the ship through the seas - this is CMMI.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The Mythical Man-Month is now classic, but the "Surgical Team" methodology is still interesting. What methodology most closely resembles it or has the same essence?
To summarize the Surgical Team analogy:
A surgeon understands the problem/business domain and is the expert. They are the authority when there are questions or conflict with in the team. The surgeons work between themselves when there are issues, say with design, functioning as a smaller tight team of experts. So in essence they have the knowledge of the domain, are entrusted to do they think is right, and do the actual coding? The rest of the team focuses on support, testing, documentation, and project plans are delegated tasks. Consequently the surgeon is also the most skilled/trained resource.
The answer could be project, programming, design methodologies as it seems to have implications across main methodology domains. Agile, MDA, Extreme, in sourcing development?
This question also make more sense for software that is large in a complex business domain, think air traffic control, not a COTS developer to or common utility.
One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.
Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.
In the case of a surgeon, the key actor is both the domain expert and the implementor.
I.e., he's both the software program manager (architect) and the developer.
This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.
For general development, however, there are a few issues with such "hero" methodologies:
Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.
Scalability is limited by the number of "surgeons" you have available.
There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.
I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.
If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.
I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.
From the text I see the following:
Agile Like:
Small teams focused on solving specific problems
Collaboration among the surgeions
Non Agile Like:
Surgeons are the authority, driving the plan, determining the design, allocating support tasks (viewng them as subservent to coding) and doing the coding. All of those are very command and control in approach and contrary to self directing teams (vs a directed team)
There appears to be no collaboration with the business partner (let alone frequent collaboration with the busines partner)
There appears to be no prioritized product backlog, thus the surgeon picks what is important not the business partner
There appears to be no incrmental delivery (tight feedback loop)
For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.
One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Maybe my understanding of agile development isn't as good as it should be, but I'm curious how an agile developer would potentially use off-the-shelf (OTS) software when the requirements and knowledge of what the final system should be are changing as rapidly as I understand them to (often after each iteration of development).
I see two situations that are of particular interest to me:
(1) An OTS system meets the initial set of requirements with little to no modification, other than potential integration into an existing system. However, within a few iterations of development, this system no longer meets the needs without rewriting the core code. The developers must choose to either spend additional time learning the core code behind this OTS software or throw it away and build from scratch. Either would have a drastic impact on development time and project cost.
(2) The initial needs are not like any existing OTS system available, however, in the end when the customer accepts the product, it ends up being much like existing solutions due to requirement additions and subtractions. If the developers had more requirements and spent more time working on them up front, this solution could have been used instead of building again. The project was delivered, but later and at a higher cost than necessary.
As a software engineer, part of my responsibilities (as I have been taught), are to deliver high-quality software to the customer on time at the lowest possible cost (among other things). Agile development allows for high-quality software, but in some cases, it might not be apparent that there are better alternatives until it is too late and too much money has been spent.
My questions are:
How does off-the-shelf software fit in with agile development?
How do the agile manager and agile developer deal with these cases?
What do the agile paradigms say about these cases?
Scenario1:
This can occur regardless off the OTS nature of the component. Agile does not mean near-sighted.. you'd need to know the big chunks.. the framework bits and spend thinking time on it beforehand. That said, you can only build to what you know .. Delay only till the last responsible moment.Then you need to pick one of the alternatives and start on it. (I'd Avoid third party application unless the cost of developing it in-house is infeasible.. but that's just me). Prototype multiple solutions to check feasibility with list of known requirements. Keep things loosely coupled (replacable), easy to change and full tested. If you reach the fork of keep hacking or rewrite, you'd need to think of which has better value for the business and pick that option. It's comes down 'Now that we're here, what's the best we can do now?'
Scenario2:
This can happen although the chances are slim compared to the team spending 2-3 months trying to get the requirements 'finalized' only to find that the market needs or customer minds have changed and 'Now we want it this way'. Once again, its a question of what is the point of time till which you are prepared to investigate and explore before committing on a path of action. Decide wisely with whatever information you have upto that point.. Hindsight is always 20-20 but the customers wont wait forever. You can't wait till the point of time where the requirements coalesce to fit a known OTS component :)
Agile says Do whatever makes sense and strip out the non-value-adding activities :) Agile is no magic bullet. just my 2 agile cents :)
Not a strict answer per se, but I think that using off the shelf software as a component in a software solution can be very beneficial if:
It's data is open, e.g. an open database or a web service to interact with it
The off the shelf system can customised easily using a similar programming paradigm to the rest of your solution
It can be seamlessly adapted to the rest of your work-flow
I'm a big fan of not re-inventing the wheel, and using your development skills to design the 'glue' between off-the-shelf solutions can be a big win.
Remember 'open' is the important part, and a vendor will often tout their solution as open when it isn't really.
I think I read somewhere that if during an iteration you discover that you have more than 20% more work that you initially thought then you should abandon the sprint and start planning a new one taking into account the additional work.
So this would mean replanning with the business to see if they still want to go ahead with the original requirements now that you know more.
At our company we also make use of prototyping before the sprint to try and identify these kind of situations before they arise on a sprint. Although of course that still may not identify the kind of situation that you describe.
C2 wiki discussion: http://c2.com/cgi/wiki?BuyDontBuild