Tag Info

New answers tagged

0

If things are properly planned generally you should experience very little stress in day to day work. Maximum stress to be tolerated At worse you should feel stress only when something unpredictable goes to hell. (Building fire, infrastructure failure, unusual loss on work hours due to sickness, etc.) The sort of stuff that no one could reasonably predict. ...


0

For me, I find the simplest method of resuming projects is just to keep a constant record of notes on your work. I find that Microsoft's 'OneNote' is particularly good for keeping and grouping pages of notes. In particular, the search bar makes it extremely easy to quickly find your notes on something. Here are some things I do within OneNote which help me ...


0

How can I document a project such that anytime I look back it shouldn't take me more than a few minutes to get going from wherever I left. First off, this implies there is some high-level description and code structure in the project that you can easily grasp in a few minutes -- as opposed to a zillion lines of code with no apparent structure and ...


-1

I keep a daily journal of the work I do. What did I do today, what was difficult today, what is the next step, what ideas did I have today for the future. I also add a bit of narrative about what the day was like: was there an interesting conversation or meeting? Did something anger or delight? This helps to put things into perspective when I later read my ...


0

In terms of documentation and handling the change in a strict Scrum framework it should be handled as a new user story and not allowed into the existing iteration but... Let's be practical and not create unnecessary overhead...that's not Agile. If the coding/testing complexity/effort is so minimal that it takes longer to create, prioritize, and manage the ...


0

Assuming you're a product owner or business analyst, don't. Tasks are generally not created by PO's or BAs because they focus on technical details, not requirements. If you're in a dev or QA role think about tasks as tools for the development team to understand the work steps needed to complete the user story. Formal tasking can be a good way of getting ...


1

Making implicit requirements explicit is the correct answer. About your follow up constraints: The customer can't hear about these requirements, because I will be presenting a long list of ways in which the product can fail, instead of talking about how it will make them happy. Imagine you're an architect, you design buildings for big companies. Big ...


1

Requirements can come from any source, as long as they are traceable to where they came from and not in conflict with each other. Customers can provide their requirements, but requirements also come from laws and regulations, industry standards, business needs, and even prior experiences learned by delivering similar products to other customers. Each of ...


0

Any implicit requirements that will end up causing work for the team should be made explicit. If not, they will end up either biting you later when people bring them up anyway, causing overruns on development ignored and later reported as bugs being implemented anyway, despite not having been scheduled, causing overruns and bug reports because they were ...


7

The industry term for such requirements as you describe is called: Non-Functional Requirements They should under every aspect be identified by technical resources and added to the project plan as atomic units of work. If you are doing an Agile project then they would be written in user story form and added to the backlog to be dealt with. As the ...


0

This is when having a diverse team that has people who specialize in different areas comes in. It also requires more sr. people on the team to lead the rest. For example performance, future extensibility, and data traceability should really all be things that are thought of from the start. They aren't a checkbox that you can just go back and add in later, ...


9

Define everything. The only potential negative to doing so is that you may get something back complaining that they feel you're stating the obvious. State the obvious then. This is key: Anything you don't define can get thrown back in your face with "you never told us..." Anything that isn't defined can potentially blow up in your face. "Better safe than ...


3

As it happens, we had some of those implicit requirements bite us because they were not defined and thus QA didn't test them and the bugs went to production and were not found for some time causing not only the hassle of explaining to the customers the problem and why it wasn't found earlier but an actual legal problem for our company. (It was a report that ...


2


3

Even if you ask them about this questions directly, they only can say "I don't know, but this work should be done". Your job is now to explain to them why you need that information. As far as s/he is concerned, you don't need to know, you just need to do what they say. You need to explain that if you know why all of this needs to get done, you will be able ...


20

Fire them. Refer them to your worst enemy. You don't need the headaches. If they don't know what they want, neither will you, and the amount of trouble you will go through, finding out what is needed, IS NOT WORTH whatever they're planning on paying you. Many years ago, a drinking buddy of mine gave me a piece of wisdom. When considering undertaking any ...


0

Especially when using git I would suggest using different branches for implementing prototype functionality (feature branches). The review process could then be executed on the different branches and in case the new prototype will be needed later in the master branch, it can easily be merged to the main development branch. The main versioning would still ...


3

If your products are relatively complex, it will take a long time for newcomer to get a hang of it no matter what you do, but you can make it less painful with your active support. Not a long time ago I joined (and still work for) a company where we have: seniors teaching juniors our own wiki and documentation storage designated time for studying ...


1

If you haven't already got them, you desperately need:- A issue logging system. Every bug report and feature request goes in the log as a new ticket. Every change you make is logged against the relevant ticket, and nothing ever changes without a ticket. The log will say which tickets are new, which are in progress and which are done. You can even ...


3

You have a very superficial understanding of user stories. That's fine, but you should know. If you really want to understand this topic, then I highly recommend you look at the work of Liz Keogh, Dan North, Chris Matts, and Jeff Patton. Have fun. Don't overthink tracking this stuff in Jira. It's just a fancy to-do list. Here's a story. What's left to do? ...



Top 50 recent answers are included