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 3 years ago.
Improve this question
In scenaios where an RFP is issued by a customer for a vendor to be selected based on a certain technical and financial criteria, i.e. in a fixed scope / fixed price projects, is there any methodology can be used other than WATERFALL. I.e. Can the Incremental / Iterative approach work?
Why wouldn't you be able to do iterative? You can chunk up work in any size and do design-build-test iterations. I suppose what you're asking is whether or not a lightweight methodology designed to deal with changing or undefined scope is appropriate. I dont' see why FDD is not appropriate, for example, just because you know where you are going. :)
If they want that type of proposal, then they are presumably prepared to pay the price in change orders and large buffers (in time and $$) for unknowns. And you can bid accordingly.
But once the contract is signed, the most productive methodology is what it is. And if you're flushing out the risk factors, delivering early and often, etc. you just have the benefit of writing those change orders sooner.
Agile techniques are designed to contain change, but they work just as well if change is not so great. Most of the benefits still accrue. Just divide the work up into customer stories, the stories across milestones, and start the iteration clocks running. It should work just fine. You'll have to do a little more planning up front, but that doesn't imply waterfall.
Waterfall is when you do all the planning, then all the coding, then all the testing/debugging in that order. Instead you can do just enough planning, then iterate through planning/coding/testing cycles.
I think agile and iterative approach can be used and is important in many levels. The phase of defining business needs is extremely important and should also be iterative. By requesting fixed scope / fixed price contract the customer is giving up the chance to be flexible and killing the spirit of agile. Of course you can and should do some iterations even under fixed scope contract. But the most valuable advantages of iterative approach have been lost with signing the fixed scope.
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 1 year ago.
Improve this question
From what I can tell from online forums and posts, one of the main focuses of BDD/ATDD seems to be on discussion and ensuring that the customer, developers, testers and other relevant parties are involved in the understanding what the system must do.
Question 1: Do BDD/ATDD stories replace the need for traditional requirement specifications, such as the those captured using the Volere Template?
Because the traditional requirement specifications are one of the key inputs for developers and testers, traditional requirement specifications tend to be comprehensive.
Question 2: Should BDD/ATDD stories also be comprehensive enough to allow a system to be fully tested?
Question 1: Instead of looking at this question as a black-and-white situation, we should better understand how these two requirements capture methods get along with each other. Writing a story in the BDD/ATDD methodologies, or in Scrum for example, does not imply removing the templates like volere off the table. If we take a look at the volere requirements specification here, we can see that most of the information regards to project-related issues, and the shell used for functional requirements is far from being different to a story. They just have different information, not exclusive one.
Question 2: Here we have the advantage coming from the methodology itself. BDD comes from TDD, we can more or less rely on the test-first oriented process to allow the team to test the system. But, as I mentioned in question 1, making a BDD/ATDD story more comprehensive is not a sin, and wouldn't compromise the general idea of the story. This would also prove useful when interacting with more experienced clients.
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
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.
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
I edit my post to be more specific.
I wish to start using Scrum methodology, And would like to know how the Design and Scrum live together ?
In the "Old" world I would build a complete design for my application, saying exactly where each menu should be, and how many buttons it should contain.
By being so precise, I help my dev team to understand where to build reusable components (Such as a menu UI, that will be inherited by sub menus), and give them a "Big Picture" about the app.
How is this dealt with in Scrum ?
In Scrum we work by sprints, and it seems like a problem for developers to see a "Big Picture" about the app, because there is no "Big Picture", there is only the next sprint.
Thanks a lot,
Michael.
You can always give "the big picture" regardless of which methodology you're using. Very briefly, for scrum/agile, you have to remember the goal is to create a working software at the end of every iteration. So, one of your stories would not be create the upper menu, it'll be create an upper menu that has one specific function. Imagine if the whole project is stopped after any iteration, you should have an usable application out of that, no matter how limited it is.
Development methodologies cannot be effectively described in a 200 word SO post. IF you want to learn about this, read one of the books or take one of the courses.
And, with most development methodologies, either the "high level planning" has already been done by non-developers, or a "plan" has been thrown over the fence for the developers to pretend to follow while they do what they've always done.
And "Agile" is, ultimately, just that -- developers do what they've always done. Only with "Agile" you can admit that, rather than pretending to follow some grand (and fictitious) development schedule.
"Scrum" is just a regular technical/planning meeting between developers on a team, with as much of the busy-work as possible removed. There is no real blueprint or format (though the general rule of keeping it short is good).
There ain't no magic.
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 3 years ago.
Improve this question
Once a week we have a half hour session where we talk about a few features in our application or explain a customer question to our employees(sales, support, technical services, and development). This session is to teach our employees the application we sell and to help them improve the service to our customers. Once every two weeks, this session is mandatory. Unfortunately, some of our employees do not take this too seriously.
How can we, as developers, gain more involvement from the rest of the company? And make them understand the application we're building, selling and supporting more?
Ask them to present the topic in front of you after some days from the session day.
Another good way is to make them suggest new features and modifications in the project.
If you have any hidden "tricks" or "easter eggs" in your application then start showing them one every week.
Make it interesting and tell them how a trick can help a customer.
Couple of points:
Make them feel important. Give them direct input using proper questions, even if you need to resort to analogies.
Speak with them, not at them. When people are being lectured there's a natural instinct to not take any notice.
Use analogies for things they do not understand, and again, give them direct input.
The main goal is giving the person a stake in the project. If they do not have anything valuable in the project (even an opinion that led to a feature classes in here), they will not care.
You can't get any more involvement from your employees because subconsciously they know they will not get any more benefits through exercise of extra involvement.
Reasons?
They may not agree with your development strategy or with your customer relationship model. So they feel as they don't really belong here.
Their work will not profit from any extra insight, so for them it's a waste of time
They don't get paid enough so they are at a minimum accepted performance
They have other personal problems in mind and don't want to take extra mental burden during their working hours
They long since learned the company does not care about their opinion and improvement ideas, so they shut down their involvement service
They're that kind of people that are not interested in being involved (hire strategy issue)
Recognized anything? Then you know what to fix.
The important thing to understand that you should not just cure the disease but the reasons of its emergence. You may threaten people with some punishment actions if they don't get involved. You may play to emulate the need for their involvement. It will work for a brief time then fade out. Until you get to the origin of the problem, nothing will help.
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 3 years ago.
Improve this question
I've recently been looking at Extreme Programming and wondering if it would be realistic to implement it where I work.
My question is, if you're pitching to a potential new client and you tell them that you're using XP, and you explain what their responsibilities are as the customer, are they likely to be put off selecting your company if they've never worked within an XP environment before?
What are peoples experiences of selling XP to a client given that it seems to me to be a very customer intensive software development methodology? The context here is selling medium to large websites to a a wide variety of clients.
I usually try to explain it to my clients in non-technical terms, and focus on the benefits of my business model. With XP, you'll always have a higher degree of communication with your clients. This is always a plus for them. They like to know what's going on. Focus on that. Also, focus on the idea that they are able to discuss business requirements with you as the process moves along, so they don't get tied down into doing something the way they first envisioned it 6 months ago when they didn't really know what they wanted. This will also allow your contracts to extend their lifetimes when your clients get comfortable working with you and want to continue improving their products.
I'm working on a project that uses XP. The weekly meeting with our customer and the outcome of these meetings was that good, that our customer decided do try to implement an 'agile like' process as well.
Additionally I think that agile is getting more and more common in IT projects and that more customers are satisfied by the outcome of these projects. So I think that in a couple of years it will be harder to sell a non-agige project than an agile one.