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 6 years ago.
Improve this question
I am preparing a presentation. My topic is innovative software engineering methodologies. Agile is modern and innovative methodology but is the answer just Agile? What are the other innovative and modern methodologies? Are test driven development and behavior driven development also innovative methodologies? And eXtreme Programming is traditional methodology like waterfall?
I am not sure we can categorize these methodologies or frameworks as innovative, traditional or something else.
The choosing for a methodology or framework is completely depend on the product and customer needs. Any of them that meet the product requirements and provide efficiency to your team can be innovative in that scope.
Most of the software development process is developing complex products in complex environments in today's development World. I totally agree that agile methodologies, extreme programming, TDD and BDD are matches very well to the before definition of developing complex products in complex environment. Therefore, most of the agile methodologies are inspection of developing complex products.
Agile methodologies
The term agile is a really popular term used by software development professionals. There are lots of agile methodologies, frameworks like scrum, kanban or XP. They suggest methods to use to make us agile. The term agile is all covers these methods. Most of them solves the prediction, adaptation, transparency, inspection and empirical processes. All agile methodologies try to solve these problems faces during software development.
Extreme Programming
Extreme programming focuses on developing qualified software products and adopting to changing requirements and environment. Honestly, I really like XP. It does not suggest only development methodologies. It also suggests some about customer management, cost management etc. It is really basic, but hard to implement. I highly suggest to read the book Extreme Programming Explained by Kent Beck.
See Also :
Extreme Programming
Extreme Programming Explained, by Kent Beck
Scrum
Scrum is another framework for software development based on empirical process control: transparency, inspection, and adaptation. It is really simple and defines some role and event during software development. The roles are Scrum Master, Product Owner and Development team. The events are Sprint Planing, Daily Scrum, Sprint review and Sprint Retrospective. I suggest to read Scrum guide for further information.
See Also
Scrum Guide
Test Driven Development
Test driven development is a software development process. I can not say that it is an agile methodology itself. It helps software development to be agile. Test driven development support developers to test in the first phase. Test driven development also requires a mind set to think test before every development. It is not only writing unit test.
See also
Test-driven development
Test-driven development by Martin Fowler
Test Driven Development: By Example, Kent Beck
Behavior-driven development
It is another software development process and emerged from test driven development. It focuses on the cross team like development, management and customer have shared tools and shared processes to have the same understanding of the requirements. BDD suggest that business people, customer and technical teams should have same understanding for the product. Customer requirements, lets sat customer sentences, can be automatically tested by the tools.
See also
Behavior-driven development
10 Tips for Writing Good User Stories
Cucumber.io
Summary
The term Agile itself is missing without XP, Scrum, Kanban or any other methodology or framework. Any agile methodology or framework is also missing without TDD, BDD or Continuous integration. Any of these items must be supported by company culture, customer or business people. Every stakeholder in the project should have the mindset for product over project. Otherwise, Agile methodologies may not be helpful.
As a last word, I highly suggest to get well understanding of continuous integration.
See also
Continious Integration
Products over projects
The Clean Coder: A Code of Conduct for Professional Programmers
I think you are mixing up practises, methodologies and philosophy.
For finding new innovative software development methods you could look at the big tech companies and how they are doing it.
Let's take Facebook, they practise "The hacker way" as described in Erik Meijer's GOTO 2015 video. According to Erik its not Agile. It has a focus on making code, not talking a lot about code as in most Agile frameworks.
If you look at Spotify they have their own home-grown scaling "Agile" implementation. Looks really fun, see the Spotify engineering culture video's.
But are they really innovative? or is it just evolution of the cycle?
The things you name are not at all innovate anymore. Most are more then 10 years old. They are tried and tested concepts, some love them, some hate them, but innovative hell no.
In the end software development is a process where there is not a one size fits all solution. This because coding is a creative process, which is hard to standardise. Each company and product needs to find their own path.
"Agile" is a term coined in 2001 by a bunch of people who got together to work out why their projects tended to succeed (or fail fast) where other projects failed (sometimes expensively).
The Agile Manifesto came out of that meeting. You can see the list of people underneath. There are a bunch of people who are associated with principles, methods and practices that are all considered "Agile": Scrum, Crystal, XP, TDD, etc.
So "Agile" is an umbrella term for a bunch of stuff that follows the main values and principles.
The word "methodology" has a large number of vague meanings, so I'm going to take it back to its origins to. It comes from "method" and "ology".
From etymonline.com, the etymology includes:
Method: regular, systematic treatment... way of teaching or going... scientific inquiry... investigation... pursuit, a following after... a traveling, way... way of doing anything.
-ology: branch of knowledge, science
-logy: a speaking, discourse, treatise, doctrine, theory, science... the character or deportment of one who speaks or treats of (a certain subject)
So the "Agile Methodology" is an umbrella term for a bunch of values, principles, practices and ideas for how to do software development better; the teaching of those ideas; the following of those ideas; and the people who encompass that community.
I'll quickly go through the things you've mentioned so you can see how they're all part of Agile:
Test-Driven Development: part of XP originating with Kent Beck, popularized by other signatories too like Brian Marick who created JUnit
Behaviour-Driven Development: originated with Dan North, basically TDD without the word "test", except that's more profound than it sounds. Certainly derivative of Agile methods.
eXtreme Programming: Also Kent Beck, introduced TDD, definitely Agile.
Waterfall: typified by trying to get everything right up front, definitely not Agile.
However, there are a bunch of things which are emerging which come from other disciplines. A lot of the Lean body of knowledge, originating from Lean Manufacturing in Toyota, especially with respect to Deming's work, is starting to play into the space. So you get things like:
Lean Startup - ideas validated quickly through prototypes and experiments that might not be viable long-term, but which allow for immediate survival or profit
Lean UX - focused on continual UI improvement in collaboration with development team rather than requirements capture and analysis
Lean Product Development - Toyota's method for designing new cars applied to the software space, including set-based concurrent engineering, etc.
Kanban for Software Development - management methods that balance demand and capacity, also based on ideas originating from Toyota.
There's also a whole ton of other knowledge and ideas which are probably outside the scope of what you're looking for, so I'm going to just throw out the terms to raise awareness.
Product Development: Impact Mapping, Story Mapping, Example Mapping, A/B testing
Technical flow: DevOps, Continuous Integration, Continuous Deployment
People and Psychology: Dan Pink's "Drive", Cynefin, Neurodiversity, Social Capital
Scaled Agile methods: Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD)
Strategy: Lean Canvas, Enterprise Services Planning (ESP), Simon Wardley's Strategy Maps.
Some of the terms here really are emergent and will probably change; these lists are definitely not complete. Mostly I've included them to give you an idea of the scope of where Agile started, how wide the community is and where it's going.
I think in the future it won't be called Agile any more, and it's going to end up including the whole business, not just IT, which IMO is a fantastic thing. It's already started to increase collaboration across the world, beyond the borders of businesses, and that's the next step.
I would love it if your presentation ended with that as a note.
Hi #Yusuf as I mostly worked on agile and prototyping method while developing application. In my opinion prototyping is the most innovative way of applying software engineering practices since the client and the other stackholders are free to suggest any model and that model can be used to develop the prototype. And it goes on until the stack-holder get the desired software. Moreover I like and learn from the answer of #erencan
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
If one does use Scrum for the Software development portion of a project, does one still use PMBOK or some other project management methodology for the "other" tasks on a project e.g. the business, marketing, training tasks. What is the project management of non software development tasks referred to i.e. traditional project management?
A project is defined in the PMBOK as being something of fixed scope, duration and budget. Failure of the project is defined as breaking outside one of the three sides of this "iron triangle". Scrum is a set of principles, and a few concrete practices, for dealing with all sorts of knowledge work, based on Agile values, and is specifically designed for development efforts that may not be projects, or may have flexible scope, duration or budget.
You are right that Scrum only deals with a few aspects of the software development process, such as planning. It only defines a few roles, meetings and artifacts, this is to keep it as flexible as possible. Scrum can, and should, address parts of the value stream outside of the software development itself. However, as you mentioned, it does not deal with lots of things, such as software engineering practices, and analysing the business case.
Often the standard Scrum solution is to "let the team decide" on matters that are not directly specified by Scrum. Often the guidelines for dealing with such matters come from other cultures and value or principle-systems within the Agile world, such as XP, or lean software development. Other cultures providing useful stuff for Scrum teams include Real Options, the Incremental Funding Method, Evo.
Some of the PMBOK stuff can be useful to a "project manager" or PO on a Scrum team, however one has to be cautious as the PMBOK stuff implies a rather different value-system than that which Scrum is based on. It is usually best to look for solutions within the Agile culture. Some of the PMBOK stuff still applies in an agile context though.
If you look for mailing lists related to "agile project management" you will find many thriving communities discussing such topics.
Agile development and PMBOK should not be mixed. IF you do, you're likely to end up with Scrummerfall. I've seen this happen with traditional project managers who convert to agile. They just don't get it and seem to fall back to old patterns.
However, in my opinion SCRUM doesn't cover all you need for project management. It sort of lacks an overall strategy to rule by. One possibility is combining SCRUM with EVO project/value management or other value management methods. It will however require a different type of legal contract with the customer. Projects are then more like a continuous process that is time boxed, restrained by a budget or ends when the customer feels he gains less than his investment (using business cases and goal measures). An added benefit is that the customer will see you more as a long term partner than a short term supplier.
We have expanded scrum to other departments in the company, modeling, texture and animation artist. We had to adapt the method a little, but it does work nicely. We had problems that were solved by using agile methodology. Some smaller departments (audio, special effects) were already working fine so we didn't tried to fix what wasn't broken. Agile would have added an unnecessary overhead for them.
It is not necessary for all departments in a company to use the same methodology, the best is to be adapted for everyones' needs. But scrum can be the solution for people other than programmers, but may need a bit of adaptation. Daily stand-up, sprints, backlog, those can be a good thing for many types of jobs.
If your software development effort is just one facet of a larger project--for example, rolling out a new financial product--then sure, you will have to employ some kind of project management methodology to orchestrate all of the work involved. Fitting a Scrum-based software development effort into a project managed according to PMBOK principles can be challenging, however, since PMBOK prescribes a linear, phased approach to project execution whereas Scrum, like other Agile methodologies, promotes incremental improvement through iteration. That's not to say that the two can't coexist. Like everything else, it comes down to implementation. Just remember to be pragmatic and adapt the methodologies to your needs, not the other way around.
Scrum is NOT a software development method but a project management method.
Besides Scrum is often introduced with Lego, or other artefacts (search for "59 minutes Scrum").
Therefore it can be used to handle all of the tasks of a project, whatever their natures.
While learning about these techniques is great, can I suggest your main focus is actually on running the project and getting stuff done?
EDIT: that's a serious point by the way, not a throwaway quip.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Is PMBOK more for after implementing software is built, delivering it to the customer while Agile or Scrum is more for building the software in the first place? Just trying to understand.
Thank you.
EDIT: My main concern is the PMBOK. They use it a lot where I work but not for development (they implement with it.) They don't develop a lot and so I have no way of asking, "Hey, what do you use for development?" I have to come up with the best plan on my own. I really don't care a whole lot about being PMP certified but if that's the best way to go to develop software using PMBOK I can justify learning it. If scrum or agile is the best way, then I'd rather use that and be successful than have a pmp by my name.
Well I can answer this question from my real world experience being both a PMP certified implementer of enterprise software solutions as well as an experienced Agile PM having managed a team of 14 in a Hybrid Agile software development project.
When implementing COTS (commercial off the shelf) software I find that the PMBOK can be followed quite closely. If followed to a "T" the PMBOK will steer you down the path of a "Waterfall" methodology. If you are not familiar with Waterfall, this is the approach where most of your project time is spent early in the project gathering requirements, performing design, estimating, etc. Build or development comes much later in the process. The reason this approach works well for software implementations is because the customer generally wants to know the cost upfront for the project. The only real accurate way to determine the project cost is to follow the waterfall approach...at least initially.
The Agile/Scrum methodologies work much better for building software. When I say build I mean the entire build process from design, development, testing, etc. I won't go into the differences between what is covered in the PMBOK, Waterfall or Agile methodologies as that is not what you asked. Agile is very much about iterative design & build, and less up-front design. In agile you want to iterate quick, and perform JIT (just-in-time) requirements gathering (using storing), design, build and testing (TDD). This reduces the amount of waste and produces usable software earlier in the project. Agile has many benefits to software development projects.
Now what I have found helpful is taking the waterfall approach as far as you need to build an accurate estimate and resource plan. Once that is complete you can switch in more of the agile processes to finish off your project.
Remember not to confuse the PMBOK with an methodology. PMBOK is a set of industry standard processes that can be followed to deliver a project; not just a software project, it could be engineering, municipal planning, etc. There are many parts of the PMBOk that are beneficial in the software development world such as: communication planning, risk planning, project close-off, etc.
It's a pretty broad subject so I hope this helps you make the appropriate decision for your project. Remember one size does not fit all.
I would personally suggest understanding Scrum and/or Agile ( whichever suits your organization best) before jumping into PMBOK.. The standards in PMBOK are more conventional and the phases are described in a slightly pseudo- waterfall method which is not as acceptable in IT industry now as before Agile and Scrum knocked at our doors... If you study PMBOK after knowing about Scrum, then its easier to filter out whats not relevant and get a better understanding of both concepts overall..
Both PMBOK and Scrum/Agile are for engineering as well as Implementation.. PMBOK covers areas other than the IT industry, that's all!
Also, Scrum is something anyone or everyone in a project team learns and implements.. but PMBOK is primarily for a Project Manager...
PMBOK is just a naff industry standard used to give the management in organization A who don't know any better the (false) peace of mind that organization B is doing things in the 'correct' PMI certified way.
Scrum as Pedro said is an agile project management technique that revolves around working in fixed iterations which is highly regarded by most software professionals. Although Scrum doesn't prescribe any engineering techniques it is commonly used in conjunction with the engineering techniques outlined in XP (Extreme Programming) such as pair programming and continuous integration.
For business reasons some companies have to at least appear to follow PMI, CMMI or ISO in order to win work, but in reality most serious software shops are practicing agile techniques such as scrum/xp/kanban behind the scenes.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.
Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well.
Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
*) Sprint can range from 15-30 days.
What is you question ? Is it which methodology would be most suitable ?
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.
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 have been practicing TDD and (some) XP for a few years now and have found that it solves many of the problems I had in my career previous to it's adoption. By removing so many headaches, my love of coding has been rejuvenated. The problem is I have also found it difficult to find .NET (my current stack) projects utilizing these practices.
My question for the SO community is:
Which communities (language and/or frameworks) do you feel embrace agile practices such as tdd, (all the xDD's really) xp, ci, etc the most?
For this question to be asked, a means of measurement must be defined. I would define it for a given community/stack as:
(number of current projects embracing agile methodologies) / (number of current projects)
Obviously without data that probably does not exist this is impossible to determine...I am just looking for people's perceptions
I have toes in both the Rails and the Django camps. From what I see, the Rails folks really get testing. They talk about testing in blogs, talk about testing in conferences, and spin off some interesting testing tools (e.g., ScrewUnit) for testing the non-Rails parts of their apps. It's really hard to be part of the Rails community and not test.
The Django community lags behind on the testing front. Django ships with basic support for testing, but you have to look for it. None of current Django books do much more than give testing a footnote, and I rarely see any substantive "how to test" blogs from Django community members. There were no talks on testing at the first DjangoCon.
On the flip side, Rails people are far more likely to get themselves into messes dues to monkeypatching and gem version conflicts (or gems or plugins doing conflicting monkeypatching), so automated testing is essential. The Django projects I've seen have been able to skate by because it's harder to get yourself into the same trouble.
As for other agile practices, it's hard to say without being able to peek inside of a lot of projects on a day-to-day basis.
If by communitry this is about people, as what else is a community really, here are a few groups:
Agile Project Leadership Network has the implication in its name that it embraces Agile approaches.
Alt.Net strikes me as a group where you could bring various Agile practices and get various results as some may like them and some may have had problems with them.
Agile is more about process rather than specific technologies usually, though. If your question is more about what technologies and frameworks do companies using Agile embrace, that is a whole other ball of wax with questionable value to my mind. The companies near me, in Calgary, Alberta, that embrace Agile may be vastly different than others,e.g. what companies in Bangalore, India or London, U.K. or Silicon Valley or New York City, New York or Seattle, Washington to give a few locations where there are some developers working, usually unless you mean companies like Thoughtworks that do Agile if you are near a large city where they have an office.
Another line of thought would be to consider how some technologies may have various sub-communities or size that may cloud things here. For example, there are likely many Java and .Net developers that embrace Agile and many that loathe it. If some companies have a Waterfall methodology that works well for them, why should they switch to Agile? At the same time, some technologies may have really small communities and so they may be viewed in a much different light. There is also how well organized would the people using these new and emerging technologies be if that is a factor to your mind.
Hopefully someone found this brain dump interesting... ;)
I don't think any of these workflows are tied to a specific language, nor do I think any language necessarily lends itself to these workflows. Any deviation from this is largely cultural.
For example, the canonical rails project skeleton has a very low barrier to writing tests or using TDD, but there's nothing stopping you from grabbing NUnit and writing a TDD .NET project.
Here are some .NET tools you might be interested in researching:
Unit Testing:
NUnit
Continuous Integration:
TeamCity
CruiseControl
From my somewhat limited experience I have found that the Ruby/rail community has been pushing the cutting edge on testing. Introducing new technologies and generally integrating the concept of TDD and BDD into most things. PHP on the other hand is somewhat haphazard. Some groups use it religiously and other seemingly not at all. The toolset in PHP does not seem as robust and deep as it is in the Ruby & Rails communities.
YMMV.
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 9 years ago.
Improve this question
We are looking at hiring a software development project manager. His job is going to be concerned with running multiple dedicated project teams focused on delivery of software for external customers. He will also need to provide support to our business development unit and oversee post-implementations support of the aforementioned software. What level of hands on development experience should we expect from the applicants? Successful candidate is not expected to do any coding.
Not important. We should be focused on proven project management experience in software area.
None.
Some experience, exact technology does not matter.
Heavy experience, exact technology does not matter.
Some experience involving same acronyms as we use daily over here.
Heavy experience involving same acronyms as we use daily over here.
Some experience, mostly with technologies we do not use.
Heavy experience, mostly with technologies we do not use.
This question is regarding the best level and quality of required technical experience and is not concerned with any other skills and qualifications of a software project manager. Many thanks.
As with any position, you need to assess first and foremost what skills and experience you need on the team for you to be successful. Then hire to fill the gap for the skills that you do not already have on your team.
If you already have a team with strong technical and technical leadership skills then you don't need to hire someone who is likely to compete with the people you already have. If you are missing this, you probably want to hire a technical manager with some project planning and tracking skills.
Great project managers are those that are multidisciplinary - they are most successful where they can bridge the divide between the various stakeholders and team. The primary role of the project manager is to manage risk and facilitate communication and collaboration. As a minimum, you should look for someone that has proven experience in either your industry or with the technology space that you are playing in, otherwise they will be unable to gain the respect of the rest of the team and perform their primary role.
Which brings me to something else you should consider carefully - what is your culture? For example in a previous job, we had development leads that were very strong technically and wilful. Project managers were always relegated to second chair, and pretty much ended up as glorified MS Project admin. assistants. Anyone good did not stay long. What do you need to do to allow the type of skills you want to acquire for the team to flourish?
Most of our project managers have zero technical experience, so I'm guessing the skill sets are different enough that it's not necessary. However, they have to be bright enough to grasp/learn the concepts involved in development -- just not the implementation.
That's not to say that a technical background would be a bad thing -- it could be a "nice to have". Then again, it could possibly get in the way and they could try to control the implementation.
In my experience the very best technical managers I've had had very strong technical backgrounds (and usually were a little reluctant to trade herding code for herding coders). The worst were the the ones that were merely average programmers at best and had more of a management background.
The tentative conclusion I've drawn from this is that while not all programmers are management material, all good technical managers started out as good programmers.
Note that this answer is coming more from the perspective of hiring an engineering lead. For a project manager - someone whose job is to interface between the technical people and the customer - technical acuity is probably less of a requirement.
Some technical skill would be nice, but far more important is that they understand the functional area your company exists in. So if you sell an OS, then you probably want stronger technical skills than if you're writing banking software, for example.
Go with point 1. "Not important. We should be focused on proven project management experience in software area."
Edit: (after re-reading your intro-para) Seems what you want is a product-manager, and in support you need team-leaders on the diverse teams to handle and report on the technical issues. (Also since customer-contact is involved: a little marketing experience won't hurt!)
As an aside:
You are focusing on the wrong skill-set. You want proven administrative skill; proven organizational skill; and above all: proven people skills - (s)he must be able to communicate without antagonizing or patronizing the audience. The technical staff and programming staff will have all the necessary experience in development. (S)He must be able to manage and control these staff members effectitively.
The manager has to be able to communicate with developers. This either requires a decent technical background, although not necessarily with the same technology, or enough humility to know when the developers know more about something than the manager. I've seen both work well.
I think what I'm saying is that having respect for the developers is important, and there's two paths to it: understanding what they do, or understanding that you don't understand what they do.
Answer is "4".
Heavy experience with some technology is critical. I know the mindset is "project manager does not have to understand technology, he just manages people".
Well no, PM does not manage people: he manages project that is supposed to produce some deliverable that is acceptable at least across some desired aspects (capability, performance, reliability, security, maintainability, etc). If he can't understand technology, he's lost. Of course, he does not have to be an expert in peculiar technologies used in a project: but he has to be able to filter BS away, to question programmer's estimates (we know how those go), to feel at least technical risk here or there, to be able to formulate business ramifications of particular technologies.
In some ways I think that PM's challenges re technology are even bigger than those of programmer: he has to be genuinely interested in technology, yet he can't / should not have any technology bigotry, to be actually fair towards them (what they are actually good for and what they are actually not good for).
Read "In search of stupidity" for evidence how non-technical managers drove many tech companies into the ground.
This is excellent summary by Spolsky: http://www.joelonsoftware.com/articles/Stupidity.html
Now, the small print #1: not every programmer will make a good PM, of course. In short, control freaks, toxic personalities, egomaniacs, people who are good at coding but not at negotiating, people who are good at coding but yield to pressure too easily -- will FUBR their projects.
Small print #2: It might be possible that people with very good analytical skills might make up for lack of experience with technology. I've worked with people who were excellent business process and procedure designers, who instinctively understood how UI should be organized and what the software should be doing in this particular place and why and who could detect BS quickly even when served by domain experts but who could not program if their life depended on it.
Most has been answered already, but I'll add this:
Keep the same mindset that you would have when hiring an office manager. While the technology knowledge is important, you'll find that ambition, a will to learn, coupled with a team leader attitude will get you a better manager than looking at mostly technology knowledge. Most projects have some company/industry-specific skills that are involved and a quick learner / great leader will bridge that gap quickly.