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.
Related
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
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 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.