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.
Related
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 4 years ago.
Improve this question
I plan to use JIRA-Agile as used to:
EPIC->US->Task
Nevertheless, the JIRA is not only used by one project but rather by a couple of projects, which cooperate or even interfere in a few topics.
At the end I want to mark up which EPIC belongs to which project. I thought about to use labels or components, but for me it seems not very suitable. What is the best (may even standard) way representing this project structure above the EPIC level ?
Features I need:
Epic can belong to more than one Project
Epic can be shifted between projects
Projects existing on different levels (one Project can even combine 2 smaller one)
"nearly" automatic reporting export is possible
Project structure can be "read" from the Jira
Are you asking about project management and analysis in jira.?
if so then you can see if the Jira Portfolio management app works for you
https://www.atlassian.com/blog/jira-service-desk/portfolio-for-jira-2-0-is-here
I am not sure how Epic will help in your case -- lets hear more answers here.
Well i am not sure if a jql will make it happen, but https://softwareplant.com/jira-aggregate-multiple-sprints-single-screen/ could help you.!
it has an option to view the board based on Epic, userstory also.!
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 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 6 years ago.
Improve this question
We (a group of 4 students) are planning to create a web-app on Ruby on Rails. I have done some web app projects in the past and one thing I have learned is the initial time devoted to design the app, which was very less, I just start coding with some basic things in my mind.
So, this time, I don't want to do the same mistake and want to plan the app (high level design). But again, sometimes I feel it might be an overkill for a student project which might span for 6 months.
So, what should be the best approach in this case?
My reqs are:
A plan which guides us through the development.
Should the plan be a text doc, a block diagram or what?
Should be clean, crisp and concise.
Would be great if you point me to some sample doc, template etc. Which is not an overkill but effective.
Start making a clone for stackoverflow. Dont go for a full deep functionality for initial stage.
Divide the whole functionality in 4-5 different phases.
Decide your phases.
You can use basecamphq(30 days free) or Fogbugz for planing, to-dos and lighthouse for bug tracking.
EDIT
Just think about the basic minimal functionality SO has:--
Sign-up. (Normal + open-id)
Ask a question, answer a question
Comments on question and answer
Votes on question and answer
tag a question
Question stats like question views, Unanswered question etc
Points
Badges etc
Make a list and divide them in various phases. Don't try to make exact thing in one go. Just start from basic things.
Like for the first phase.
Sign up
Ask question, with tags
answer a question
comments on them
Basic profile page.
For next phase:--
Add ajax for comments (Good for learning ajax)
Votes, Not points
Add things like Unanswered questions. (initial dont try to find the logic how SO is listing unanswered questions, Just do something like unanswered questions means question having no answer.)
Question views
then next phase and next phase. and finally you have a clone. :-)
Ask Jeff to review it. (Kidding)
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.