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
we have an org of around 300 people and certain people are very good at sharing articles, tips, blogs, etc but it usually happens within sub teams (between 5-15 people). whats the best way to scale this up to facilitate a culture of collaboration across a larger set of folks.
Post to central WIKI instead of email links?
Reward contributors and encourage bottom up organic collaboration ?
"Force" collaboration top down ?
You have to create an culture in which sharing is rewarded.
Post to central WIKI instead of email links.
Reward contributors and encourage bottom up organic collaboration
"Force" collaboration top down. By "force" you mean reward and encourage.
You must do all of this. And more.
You must teach collaboration
You must assure that all managers value and reward collaboration
You must measure collaboration.
Even then, you'll probably have to do even more.
Good answer by S.Lott.
I'd add: You need to make sure people can easily find things when they need them. That's partly cultural - do people think to look at the wiki, and do they know where to look. It's also about the wiki's structure & quality:
Is it easy to navigate & search?
Is it kept up to date?
How does it mesh with other documentation (eg javadoc)?
From my experience, forced = hated. So you have to make people want to use it, ie make it useful. A central Wiki sounds like the best solution, but it's hard to say. You might want to look into MediaWiki, Traq, or Sharepoint Services (not to be confused with Office Sharepoint).
Your organization may find it encouraging if you post a list of the top contributors, editors, or visitors to the site. But that depends on how your org perceives competition.
I wouldn't suggest a central wiki for collaboration (aside from internal specific stuff). But for sharing information found online you should encourage people to use one of the many existing systems for this. Google Reader has a really nice sharing and commenting mechanism. Delicious would also be a good fit for what you want.
There's no reason to try to create a walled garden inside your organization for content that is being created outside of it. The system you create will not be as good as the ones that already exist and that will kill adoption.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Does anyone know ways to use GML programming skills to find or make work, such as freelance work using Game Maker?
I was thinking of doing freelance game prototyping work for people looking for a quick mock-up and getting the feel for their game, that can be done within a week or a few days.
If anyone has an idea, could someone please help me out? Thank you.
Personally, I started out using GameMaker as a hobby, and I've worked on some small projects for other people, but I eventually got hired as a website and database programmer rather than as a game programmer.
Unless you find a team that is already using GameMaker for its project(s), your experience with GML may not count for much on its own, as the language is only useful inside GameMaker itself. However, understanding GML means that you also have basic programming skills, and once you know one way of programming it goes much quicker to learn another.
GameMaker made programming easy and interesting for me, but other languages gave me the tools needed for non-game projects.
A company may not hire you based on the fact that you know GameMaker specifically, but it may hire you because you know programming. It could be wise to research other programming languages and learn the basics of how they work.
If you are to sell your skills to a client, they will likely care more about the end result than the exact road you took to get there. For example, if the job is to make a game that works on Android phones, that is something GameMaker can do, and by extension it is something you could do.
If GameMaker doesn't seem like the tool for the job, use what you learned from GameMaker to help you understand a different program/framework. Even if you focus on GameMaker, you may need other languages if you are to set up an online game server or scoreboard.
A lot of successful games have been made with GameMaker, so it's definitely possible to make a living by using it. The Showcase section on the official homepage shows us games like Hotline Miami and Undertale - big hits in the Steam store.
This article from GameMakerBlog.com lists a few people who's made it big. Most important, I would say, is "True Valhalla", who gives the community running updates on how his business is going. You can find his blog linked in the article. He has written a book about how to make money by selling apps and games, which could be well worth checking out.
If you wish to focus on freelance work using GameMaker alone, then make sure to understand the ins and outs of the program so that you can be as flexible as possible. Make sure that you understand how the movement functions work, how to do collision checking, how to work with data structures, how to work with views and surfaces, and so on.
The technical skill doesn't need to be perfect, but you need to have an idea of what to do and how in order to realize your ideas within a reasonable time frame. Practice until you feel comfortable taking a game from concept to demo in a short time, and build a collection of examples and engines that could be useful to you. If you can reuse a script, that's a lot better than writing it from scratch for every new game you make.
Finally: Marketing yourself. In order to become attractive to potential clients, it helps to demonstrate your expertise by publishing your work online. Make yourself visible. Post screenshots, videos, and playable versions of games you've made. You could blog about game development, or build up a small profile by helping people online and getting credit for it.
Any project you can point to and say "I worked on this" makes you a more credible developer. If you are just starting out you may not have any projects yet, so one suggestion would be to make a small mini-game and publish it in an app store. You may even publish it for free. For your first games, exposure could be as valuable as sales.
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 11 years ago.
Improve this question
As a junior developer, I mean without great experience, what would you do for a client about an eshop? Start from scratch and handcode an e-shop(simple one)? If yes are there any good tutorials you suggest?
Or buy something ready, lets say VirtueMart templates for joomla or a similar solution for Wordpress?
Even if you described yourself as an expert I still wouldn't recommend that you write an ecommerce application from scratch unless
your client does something very specific that can't be made to fit an existing solution
your client has huge amounts of money and doesn't want you to deliver anything for months (or more)
you can offset either of the above because your business plan is to develop the next Magento and you have the resources to hire a development team and market your solution
Displaying products on the front end is relatively trivial. The rest of the iceberg e.g. security, user management, the back end (admin interface) of your website, tax calculations, shipping, cart functionality, templates, payment gateways etc. would take considerably longer.
Unfortunately, even if you deliver you would still be behind the competition when your client says: "I want feature x that I've seen on website y" and you have to quote for bespoke development instead of installing or enabling a module on a ready-made application. Unless they're prepared to spend a lot of time and money they will soon look for an alternative.
If you're already using Joomla, I'd recommend installing the Joomla + VirtueMart bundle here:
http://virtuemart.net/downloads
If you're using WordPress take a look at ShopperPress or Get Shopped.
There are many more out there (Magento, osCommerce, Zen etc.)!
The most important thing to do is to match your client's requirements with the features of the application you feel comfortable using.
I would definitely not hand code or encourage this.
It is not sustainable for the client unless him and you are going to work together for the next millennium. What happens is that in a year or two they want new functionality, and if you are available, you need to have done a very very good job of structuring and commenting your own code to remember it yourself (as a new developer you learn new things every day, and solutions I did a year ago, I would restructure today).
The even more likely scenario is that another developer, system designer or graphic designer comes along, and it will be pointless, enormously time consuming and costly for the client to have person number two dig through your code.
Your time is better spent learning solid cms-systems and improving those, rather than reinventing the wheel. There are too many sites out there that are made as one-offs, and therefore often unmanageable in the long run.
I understand that programmers wants to progam, and the temptation to start with a blank editor page, but it is not good for the client, and it is not good for you reputation down the road.
Use your skills to make unique and custom made plugins, functions etc for your client. Do not waste your time building frameworks that others have already - and most likely - done better.
..and make sure you pick a cms your customer can handle. Do not give him joomla or drupal, if he is of the sort that can barely figure out how to publish a post in wordpress.
You might take this opportunity to learn about recent Web technologies and tools, in particular non-PHP based things like Opa language or Ocsigen library or perhaps Kaya; these tools probably have some useful infrastructure for your needs.
You might also checkout ShopAlternaMart for WordPress
I'm happy with opencart, an open source e-Commerce (see my site here, if you like). There are of course many others.
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
I am a product owner and I am helping setup a themed sprint. To be clear, by themed I mean all the users stories are related or cluster around a common goal. I still have other stories that don't work well in the theme that I want to include. The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
The problem is that when I fragment the vision of a sprint we don't work as well. Any suggestions?
First of all, you and your Team yourself can answer this question, because only you and your Team have the most knowledge about your situation. I know you wish there was a Scrum Manual where you could refer to some page and get the answer but you have to be factual - Scrum's simple framework never suggests that you have themed Sprints. In fact it suggests that the PO prioritize the uncommitted Backlog list of user stories based on their value and ROI, irrespective of themes, as long as the stories follow the I.N.V.E.S.T Principle, and prioritized periodically. Not that there is something wrong with theming, but if it is not working for you or your Team then you have to adapt to something new, that works for you and the Team. Here are some basic suggestions from my side:
Taking a leaf out of another members post I can say that you and your Team, need an ingredient, which is called "Courage"
The SM of the Team, along with you, needs to have the Courage to use the "Inspect and Adapt" principle to find out why fragmenting is not working for the Team.
As long as the Product Backlog is "ready" before you go into Sprint Planning, The Team needs to have Courage to trust you, the PO, in prioritizing the work for them, irrespective of their own wish or desire or way of thinking.
If fragmented Sprints is what will bring most value, then you as the PO need to have the Courage to talk openly to the Team during the Retrospective about why fragmented Sprints is the way to go, and we need to make it work until you guys find an adapted way of working in that fashion.
Lastly Everyone i.e. The Team, the SM and you need to gather the facts and notes from the above discussions, and come to a common consensus and have the courage to try it until you achieve your goals.
Keep in mind, all this needs to be done within the simple Scrum Framework rules stated in the Scrum Guide.
If you have main vision of the sprint it doesn't mean that you can't include user story which is not part of that vision. User stories are included mainly by their business priority not by their theme. So if you have user story with higher priority than your themed stories you should include it. In my opinion, themed sprints make sence only if priorities reflect splitting user stories into themes.
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
As I understand things, the Scrum backlog is composed of a series of Stories that represent something for the end user and this is further decomposed into Features.
If this is the case, where does all the behind the scenes features go that aren't really linked to a story but are still useful?
For example, say I'm making an application that catalogs the contents of a hard drive. A story wouldn't require it but having an md5 hash on each file would be a nice feature for flagging duplicates.
The classic template to write good stories is: "As a <role>, I want to <action> so that <business value>" (or variations around this) and a story should indeed provide business value. Why? Well, if a story does not communicate the business value it generates, how could a (very likely non technical) Product Owner evaluate its importance and prioritize it accordingly? Writing good stories increases your chances to get them rated as important and thus implemented.
A great tool to find good business value is the 5 Whys (which is used for root cause analysis, i.e. finding the root cause of a problem). The cucumber documentation explains very well how to use it to find some "good" business value and has a very good sample, so, instead of paraphrasing it, I'm quoting the explanation below:
Business value and MMF
You should discuss the "In order to"
part of the feature and pop the why
stack max 5 times (ask why
recursively) until you end up with one
of the following business values:
Protect revenue
Increase revenue
Manage cost
Increase brand value
Make the product remarkable
Provide more value to your customers
If you’re about to implement a feature
that doesn’t support one of those
values, chances are you’re about to
implement a non-valuable feature.
Consider tossing it altogether or
pushing it down in your backlog. Focus
on implementing the MMFs (Minimum
Marketable Features) that will
yield the most value.
Here is an example taken from an IRC
chat session in #cucumber:
[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature
"login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login
in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy: Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why?
[5:12pm] aslakhellesoy: I'm asking you
[5:13pm] aslakhellesoy: Why have you decided login is needed?
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy: Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is
publishing what
[5:15pm] aslakhellesoy: Why would anyone want to know who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs
to someone, then the content is trustworthy
[5:17pm] aslakhellesoy: Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and
consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy: :-)
[5:21pm] aslakhellesoy: Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy: There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase
de revenues.
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy: In order to drive more people to the website and earn more admoney,
authors should have to login,
so that the content can be displayed with the author and appear
more trustworthy.
[5:23pm] aslakhellesoy: Does that make any sense?
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy: It's easier when you have someone clueless (like me) to ask the
stupid why questions
[5:26pm] aslakhellesoy: Now I know why you want login
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy: And if I was the customer I am in better shape to prioritise this
feature among others
[5:29pm] Luis_Byclosure: true!
So, let me start: why would it be nice to have a md5 hash on each file (which, expressed as you did, is an implementation detail and doesn't communicate any business value)?
There is no "scrum" backlog, only
Product Backlog by the product owner that has Business Values
and
Sprint Backlog by the scrumaster/developpers which list tasks traced back to a story.
I am updating for precising the distinction between a Vision Document and a Product Backlog as for Business Value:
Business Vision Document (Strategic Level) are all about Business Value as well as Product Backlog. But Product Backlog is equivalent to Functional Specifications in other traditional methodologies that is it is something CONCRETE or OPERATIONNALLY directly implementable by the team not just a VISION from a high level managing director.
Of course product backlog itself should be tracable to Vision Document Items.
At the end of the day, agile is about doing what works for you to be productive. These kind of answers are for you to decide what works.
It may just be an implementation detail of another story, or it may be a story unto itself.
What ever makes your group most productive is what it should be.
I would place them by something like:
"Non user-stories" or "NUS"
"Programmers Only" or "PO"
"Behind the sences" or "BTS"
Followed by a short description of the feature.
So:
BTS: catalog filesystem
PO: find file type with magic bytes
Strange! I'm making the same application! :-)
Update:
So, I read wiki, I think we need an extra log (the Sprint backlog).
Wiki says:
Sprint backlog
The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list.
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
We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.