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 2 years ago.
Improve this question
I am Computer Science student, but there is no particular provision or course for learning game programming in our college. I have been studying allegro API for the past year. But I am still unsure how to apply physics in games and realistic games. Its overwhelming and lack of resources is quite confusing.
I think the best thing you can do at this point is simply start making games. They may not be complex or realistic, but getting some experience under your belt will set the stage for learning more complex things. I would disagree that there is a "lack of resources", a plethora of advanced game development tutorials are a web search away. I think the problem here is more related to those resources seeming "overwhelming", as you said.
If your experience studying computer science is anything like mine was, you likely spend a lot of time studying relative to a small amount of time actually doing. Use your interest in game development to get practical experience doing something that interests you. The important thing here is to complete games. When working on simple games, its easy to stop as soon as the bare minimum feature set is completed (I've got a paddle and a bouncing ball -- my pong game is complete!). Take the time to create a title screen, add sounds and music, can work out bugs.
As you gain confidence making smaller games, you'll have a better basis for learning more advanced concepts. It's not a matter of being 'smart' enough to understand complex tutorials, its a matter of being able to retain and absorb that knowledge because you are able to immediately apply it. College computer science teaches a ton of knowledge, but, at least in my experience, a large portion went to waste because I wasn't regularly applying it.
The bottom line is: just develop things. Make games. Even the ones that seem simple will end up being more complex that you expected, and as you progress you will gradually assimilate more advanced knowledge. Look up advanced concepts as you need them, not because you anticipate needing them.
That being said, here are a smattering of tutorials I really like:
Entity Component Framework
Programming Game AI by Example
Procedural Terrain
Collision Detection
Of course, don't try to read these all at once. Read these and similar tutorials as you need them, and in the meanwhile, just keep on developing.
And of course:
Allegro5 Tutorials.
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 5 years ago.
Improve this question
My team is making the transition to Scrum.
I am facing an issue I still not found on the various Scrum resources I've been studying: how to manage training?
I express myself by example:
my team has 4 developers, 2 of them know nothing about Test Driven Development
the project must be done using TDD
Should I create a backlog item "Study TDD" and use the first sprints so that the untrained developers learn TDD?
Or should I remove the developers from the project until they completed the training? Which is the best practice in this case?
Just send them to the training, and continue your sprints as normal. While they are in training they won't contribute to the velocity, the same as if they were sick or on vacation or just having a bad day. The velocity isn't a goal so much it's an indicator.
You can create a story for training if you want, but it isn't necessary. If creating the story helps, by all means do it. Don't do it just because you think you're supposed to. I've been on teams that liked to track non-product tasks, and teams that didn't. Do what your team decides to do.
In your question you wrote:
the project must be done using TDD
I hope that's because the team decided that, and it wasn't something that was decided for them. The whole point of scrum is to build a team that can make these decisions for themselves.
Well, I will answer YES.
you need to create back log
you need to define test cases and follow TDD
you need to do stand-up meetings and daily follow up
you need to define a team member as scrum master who have best understanding
further, you can engage an online training of transformation expert
Like, I know these guys regarding Agile/Scrum Transformation. http://sparklegenius.com/solutions/agile-transformation/
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 team of 30 people, consisting of business managers, developers and software testers.
Our developers are on different projects that have partially different - partially the same products. They help each other where ever they can. As we are all in the same room this is quite easy.
Now I asked why we do not use Scrum.
One answer I got is: Because we are all in the same room and we are helping each other. This goes quite quick and so we might not need scrum. Some of our products are developed only by 2 people. So this would be kind of weird to have a standup meeting with only two of us. Also our colleagues come to work at different times and some are doing home office sometimes.
Is it true that in such a setting Scrum is not feasible or does not bring any value to the company?
Hope for your comments, ideas, thoughts...
Best,
Marc
As literature states (see here) ideal Teamsize is between 4-8. Smaller Teams should use XP.
My persional Opinion is, yes do scrum, even if you are a single developer!
Scrum is about your customer and team and about the way how they communicate. You always talk about your team. But even more is important how is the communication with the "customer/stakeholder", how is the project management done. If you have a customer involved than have a look at these processes if they are also that good as within your dev team. Most of the problems of softwaredevelopment lay here (requirements specifiction, customer expectations, being in budget/time...)
Some aspects you loose not using scrum (and therefore I would suggest using scrum even in a team of 2). You also have to not pick everything but only theparts you like
Backlog (what is planned in the next x weeks) and its documented!
Burndown Chart (where are we standing at the moment)
Continouus improvements (in Scrum you capture impediments, you reflect what was good and bad..)
Daily Scrum (makes even sense for a single person reflecting what I did and do the next day! and what problems happened.)
Most other apsects of scrum...
I am currently starting to implement/use all this for me as a single person/developer and I can only say it makes my work and me better as a programmer. And I am even saying this, being my own customer and PO (I develop my own products/business for me)! And even than it makes sense. The advantage is, that this is with scrum all extremely lightweight (no overhead).
The Scrum Guide suggests a team size of 3-9 people.
There is a reason for the lower limit. Teams smaller than 3 people have less interaction and may lack the skills to deliver a potentially releasable increment in a sprint. It can be a challenge to keep the Product Owner engaged when you have a very small team.
My personal experience is that 4 people is a more realistic lower limit due to the impact of holidays and other absences on a team.
It is also important that a Scrum team is consistent over time. One of the benefits of the Scrum approach is it lets us calculate the capacity of the team and this is complicated by frequently changing team members.
Team members working from home and having different core hours should not be a major problem when working with Scrum. This is common in a lot of Scrum teams and can be mitigated with careful synchronisation and the use of technologies such as messaging applications and voice/video conferencing.
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 9 years ago.
Improve this question
I'd like to try scrum with my team. Studied a lot of posts about scrum tools here, but i think it's all superfluous and excel file is ok for product and sprint backlog. But it's problem to fing a good template. Maybe somebody could share excel template he is using for scrum backlog? Thanks.
Excel is really an extremely powerful tool and is very appropriate for the product backlog (and it has my preference if suitable: just share the product backlog on a network drive and there you go). I have used the following templates successfully in the past:
Henrik Kniberg's Index Card Generator and a wall for the sprint backlog
Petri Heiramo's advanced product and sprint backlog template (video tutorial here)
You can browse my personal collection for more of them but I recommend the two above.
Don't have any templates, but what tool you use for scrum is indeed whatever works for you, so excel could be just as good as any other. Just so long as it's quick and easy for all to use.
I was taught scrum techniques using physical props. Sticky notes and meeting drawing boards. The idea is you use that for a while, and then see if you can fit it into technology after if it doesn't hinder the scrum process.
I'd just try and knock up an excel template that fits for you, starting from a blank worksheet and just build up whatever seems to work.
Though for backlogs it may be better to have a tool that manages it if you are going to have a lot of items, and especially if you will have many stakeholders inputting into it. Maybe a bug tracking kind of tool. Plenty of good open sources ones about. Don't know how they fit into scrum, but always thought the likes of bugzilla could work but haven't tried it.
I'll say it is a good idea to start for a couple of sprints on paper.
It will let you understand the process before having to fight against the difficulties in using the software tool.
On the other hand, scrum can be used for projects of different nature, and not in all cases will have computers available.
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
What approach did you take to describe the benefits of SCRUM to clients / business units who do not have a technical background? Please list any analogies you thought were useful. Finally, how did you address the concerns that the Waterfall camp had?
I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.
Using a incremental process significantly reduces the risk of wasting money on something that's not gonna be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles. The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?
Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.
You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction.
An additional point is protection of investment - with traditional approaches, a system typically "ages" with time, its value decreases, and maintenance costs rise until it's no longer feasable to maintain it. With an Agile approach applied well, the code should be maintainable and extensible indefinitely.
Here is a good, short video on all three points: http://www.youtube.com/watch?v=OWvSnYjqOTQ
I would mention the benefits of focus. Because the guiding principle of sprints is functional focus and shipability, all details (e.g. ergonomics) need to be taken care of, whose fixing would otherwise be postponed under pressure in more global approaches. You don't have it all but what you have is solid. Non technical people appreciate that because it reduces risk from their point of view: it injects honesty and trust, together with interactivity, in the dialog with clients.
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 9 years ago.
Improve this question
How many people actually write an SDD document before writing a single line of code?
How do you handle large CSCI's?
What standard do you use for SDD content?
What tailoring have you done?
I certainly have. Historically and on recent projects.
Years ago I worked in organisations where templates were everything.
Then I worked other places where the templates were looser or non-existent or didn't fit the projects I was working on.
Now the content of the software design is pretty much governed by what I need to describe to get the idea across to the audience.
"before writing a single line of code" there wouldn't be a a lot of detail. The documents I produce before I start coding are meant to get the idea of what we need to build across to the affected teams and senior management so they introduce high level architecture, functionality, technologies, risks and scope. Those last two are really important. The rest is to show other teams where you need to interface with them and to leave managers with a lingering notion that cool stuff is happening.
Most big software companies have their own practices. For example Motorola has detailed documentation for every aspect of software development process. There are standard templates for each type of documents. Having strict standards allows effectively maintain huge number of documents and integrate it with different tools. Each document obtains tracking number from special document-tracking system. They even have system (last time I seen it was in stage of early development) for automatically requirements tracking - you can say which line of code relate to given requirement\design guideline.
I would suppose that most people who write SDD documents and use terminology like CSCI have to be using a specific software development methodology and most likely are working for some serious government customer. They usually tend to take their preparations quite seriously and the documents are ready and approved before any development starts.
In an Agile process the development and the design document could be developed in parallel. It means that there will be plenty of refactoring to be done but it usually delivers very good results in the end.
In more formal processes (like RUP) a SAD document is mostly created during the elaboration/prototyping phase based on the team research.