Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm going to give a two hour workshop on a programming topic (NHibernate). It will be a small group, of around five people. The attendees will all have their own laptops.
What would be the best way to structure the workshop so that the attendees get an insight into the topic and preferrably don't fall asleep?
I don't know if you can get a black-n-white answer here, but definitely there's opinions on how to best engage your audience...
You will probably know your audience much better than I do, so you're in a better place to make this determination. I'll assume your attendees are going to be developers, due to the topic you'll be presenting.
And here's my personal opinion: "what we learn to do, we learn by doing", right? So, go with some hands-on exercise. For instance, look at the NerdDinner tutorial online to see how you can have them 'build' something while exploring the features of NHibernate you wish to expose them to.
I also reccomend making sure one of the exercises is more similar to a 'maintainance' task instead of a 'create from scratch' example since people will eventually spend more time in the former rather than the latter mode. SO perhaps have an exercise or two for them to do from scratch, and then have a prepared 'code base' they'll have to modify.
HTH
Add a few (or just one!) hands-on lab(s) into the mix. You could burn it on CD or whatever, hand it out at the start and they can all load it up and play along and run it. It just means you need to put some effort in, in terms of creating the template project and to ensure they just have to fill in a few things/gaps here and there, and it will run without a problem.
During your presentation you will then have 'Hands-on lab intervals'. Where you go through some of the steps and let the candidates fill in some of the pieces of the puzzle.
That way, you can let them fill in the appropriate gaps that you think are necessary in order to "get" it. And at the same time, it ensures the attendees won't fall asleep, as they actually actively participate.
I think the most important thing to keep in mind is that your attendees are going to have different learning styles. What I would do is create a slide-show or outline that gives the skeleton of the topics you want to cover. Then create the code examples you want to work from based off of the topics. Once that is done create your solution code files to all of the examples you made. Ideally, you will want to give all of the attendees a copy of the material when they show up. This way they have something to following along with and if they get ahead or fall behind they have the material necessary to still learn. Finally, make sure you practice your presentation. When you practice it you won't want it to take the full 2 hours because you will want to leave time for questions. It also could help if you mark on your outline how long it should take you to get to each major point. That way you know if you are staying on pace or not.
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
I'm working on a software product that is content heavy. The problem is that a feature often requires new content, and content production for us takes longer than a sprint or takes more than half a sprint.
For example, one feature might require us to film 100 different short videos (2-3 seconds) and go through post-production. To film the videos requires travel time, etc. Even if I broke out the feature into 100 stories, one for each video, the content is still going to require a lot of time because it's not going to be filmed one by one and edited one by one.
Could I have the same story throughout subsequent sprints, with different acceptance criteria? For example the story would be "As a User I want to see blah blah videos so that I can blah blah". Then in one Sprint the AC would be to film the videos. The next sprint I would have another user story (different ID), with the same text, but the AC might be to "integrate the videos into the app"? Not sure if that violates Scrum doctrine.
Has anyone run into a similar situation? How is this handled in a Scrum environment?
From your description, it sounds like you're trying to use Scrum to drive a production line, which is absolutely the wrong tool for the job. It sounds like you know exactly what you need to shoot and produce, so no learning is occurring (which is fine if you don't need it). To illustrate, let's create an example where scrum would be ideally suited:
Let's say you run a marketing web page for a popular brand and they want to run a new campaign this season. They want to do something with "getting back to nature" and you have a few ideas. You would have to shoot tons of videos to replace the ones on the site, but you don't want to shoot 100 new videos only to have the client unhappy with them. So, you take 3 major ideas and you change one page requires you to shoot and edit 4 videos for each idea. You do 2 of them in the sprint and maybe pitch the third because it's going to be more involved - you have to travel to Thailand to get the footage. If they like one of the first two, you go with that for the whole site. Otherwise you invest in the proof of concept for the third.
Here, it's all about confirming your assumptions before you invest too much, and then Scrum makes sense. If you're just producing a ton of videos though, I'm not sure why you would try to force the use of Scrum.
You can split your ticket into sub tickets like 10 video shootings and editing. Or you can prolong your sprint period according to your needs. Another approach can be switching to kanban.
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's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have been thinking about setting up some sort of library for all our internally developed software at my organisation. I would like collect any ideas the good SO folk may have on this topic.
I figure, what is the point in instilling into developers the benefits of writing reusable code, if on the next project the first thing developers do is file -> new due to a lack of knowledge of what code is already out there to be reused.
As an added benefit, I think that just by having a library like this would encourage developers to think more in terms of reusability when writing code
I would like to keep this library as simple as possible, perhaps my only two requirements being:
Search facility
Usable for many types of components: assemblies, web services, etc
I see the basic information required on each asset/component to be:
Name & version
Description / purpose
Dependencies
Would you record any more information?
What would be the best platform for this i.e., wiki, forum, etc?
What would make a software library like this successful vs unsuccessful?
All ideas are greatly appreciated.
Thanks
Edit:
Found these similar questions after posting:
How do you ensure code is reused correctly?
How do you foster the use of shared components in your organization?
Sounds like there is no central repository of code available at your organization. Depending on what you do this could be because of compatmentalization of the knowledge due to security restrictions, the fact that external vendor code is included in some/all of the solutions, or your company has not yet seen the benefits of getting people to reuse, refactor, and evangelize the benefits of such a repository.
The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.
Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.
Unsuccessful attributes I've seen?
N submissions per engineer per time period = lots of crap starts making it's way in
No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
Lack of feedback/email link that contacts the author with questions directly into their email.
lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.
Just my thinking.
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
Quite often I would complete numerous daily tasks i.e. not working on anything one component in particular. Therefore, I find it quite difficult to remember these individual tasks in our next day stand up meeting. Is it ok to bring a small sticky note with a few reminder points on the previous days tasks? For example, the contents of the sticky could be:
Yesterday:
----------------
- Implemented component X
- Refactored Y class
- Updated Bamboo build settings
- Submit test request to 3rd party harness
- Read up on X API
Today:
----------
- Write tests for component B
- Implement component B
- Document install instructions
- Code review meeting
Obstacles:
----------------
- Sys admin still haven't opened external port
What are your views on this?
A key point of scrum is that it's not written in stone -- you should adapt it to whatever works best in your organization. However, the daily standup meeting is meant to be short, so if you bring notes, you should use them as a reference, not like a meeting agenda.
Yes, short notes are fine. Long stories probably destroys the relationship with your coworkers.
Implement Scrum in a way you feel it comfortably. Stand up meetings should be short, but who is saying that they can't take so much time as you need it?
If you are using some kind of Scrum tool, you don't have to take your notes, all is written in tool - obstacles, tasks status, comments.
I don't know if it is "officially" ok but I do this all the time. If you are like me and lose track of the last thing you did because you are now focusing on something new then write stuff down. Its better to show up at SCRUM with a short list then to show up and say: "now ... what was it I was working on?".
I think notes are ok, but you are talking about subjects which may not be pertinent to user stories in your sprint. If you keep focused on that rather than other tasks that you have performed you will keep the scrum meeting short and relevant.
If the tasks are relevant say what story they were part of to give co workers context.
I don't see any reason why it wouldn't be OK to bring some notes to the daily meeting.
In our team, we have extended the daily scrum a little bit. It consists of the following parts:
The normal daily scrum (yesterday, today, obstacles). This should not take more than 5-10 minutes.
We update the sprint backlog. Should not take more than 5 minutes. This ensures that the whole team knows about the the current state of the sprint backlog.
If required, we discuss any important topics (which concern the whole team)
If required, we schedule meetings between team members (or directly hold the meetings after the daily scrum).
Because of the way we do the daily scrum/daily meeting, it is quite normal that everyone brings some short notes, for example about what topics they need to discuss with others.
After all (as others already mentioned), you should implement SCRUM in a way that works for you and your team. And of course you should always be open to improve/change your process if you found some problems (e.g. during a retrospective).
Why would they not be?
Only rules are:
Answer the three question
what did you do yesterday
what are you going to do today
what is blocking you
you speak to the team (not any one individual)
you keep it short
no story telling
no problem solving
speak when you have the token
know who to send the token to next (not someone that has already spoken)
if someone goes long or tries to problem solve others may call for a focus meeting after the stand up
Story card wall should be visible
A person in the room updates the blocker boards as blockers are called out
Notes are fine, as are projectors, laser pointers and beanie caps with propellers.
The answer to the basic question is yes. It is entirely appropriate to bring notes to a standup if it helps you.
Your example, however, points to a common pitfall in standups... providing detail on activities that may not be important to the team. You read something, and you attended a meeting. Those are examples of what I sometimes refer to as "justifying your 8-hours".
The key is - share what you did and what you will do without elaboration. If someone has questions on something particular, they can ask for details outside the meeting.
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'm writing a small app for my friend's business, and thought I'd take the opportunity to brush up on some Agile Project Management training I did at the start of the year.
I (and I think, my current organisation!) have always struggled with gathering requirements in the form of User Stories, which take the form:
As a [User Type] I want [feature] so that [some benefit]
I'm always tempted to miss out the beginning and end, and just leave the feature - but this then just becomes requirements gathering the old way!
But I don't want to just make it fit, so that I can say 'I'm doing Agile'.... for example, if I know that the user is to be presented with a list of items, then the reason is self-evident, is it not?
e.g.
As a [Store Manager] I want [to see a list of Stock Items] so that ... ?
Is it normal practice to leave out the [so that] clause?
We used to miss it out as well. And by leaving it out we missed a lot.
To understand the feature properly and not just do the thing right but DO THE RIGHT THING it is key to know WHY the feature, and for that the next key is WHO (the role)
In DDD terms, stakeholder. Stakeholders can be different, everyone who cares. From programmers and db admins to all the types of users.
So, first understand, who is the stakeholder, then you know 50% of WHY he cares, then the benefit, and then it is already almost obviously WHAT to implement.
Try to not just write "as a user". Specify. "as store manager", or even "as the lead of the shift responsible for closing the day", i need....so that....
Maybe you can implement something different which will give the same stakeholder even better benefit!!!
Try, To Achieve [Business Value] As [User] I need [Feature].
The goal is to focus on the value the feature delivers. It helps you think in vertical slices, which reduces pure "technical tasks" that aren't visible. It's not an easy transition, but when you start thinking vertically you start really being able to reduce the waste in your process.
Another way is to thinking of the acceptance tests that your customer could write to ensure the feature would work. It's a short jump to then using something like FitNesse to automated those tests.
No, it's actually not obvious - there are a lot of reasons to want to see a list, a lot of things you might want to with it - scan it for some info, get an overview, print it, copy and paste it into a word document etc. And what exactly it is will give you valuable hints on reasonable implementation details - formatting of the list, exact content; or even a hint that a different feature might be a better idea to satisfy that need. Don't be surprised to find out that the reason actually is "so that I can count the number of entries"...
Of course, this might in fact not apply to you. My actual point in fact is that there are reasons that people came up with this template - and there are also reasons that a lot of experienced people don't actually use it. And when you are new to the practice, you are not in a good position to assess all the pros and cons of following a practice, so I'd highly recommend to simply try to follow it closely for some time. You might be surprised by the usefulness of it - or not, in which case you still learned something and can drop it with a clear concise... :)
User Stories is another way of saying you need to interview your users to find out what they want and what problems they are trying to solve. That the heart of having this in agile development. If the form is not working for your then take a step back and try a different approach that feels more natural to you or better suited to your capabilities as a writer.
In short don't feel like you have to be in a straight jacket. The important thing is that you follow the spirit of the methodology.
In this specific case you want to get a list of what problems the user has, why they are problems, and what they think will help them.
I think you should really try to get a reason defined, even if it may seem obvious. If you can't come up with a reason then why build the feature in the first place? Also the reason may point out other deficiencies in the design that could trigger improvements in other areas.
I often categorize my stories by the user/persona that it primarily relates to, thus I don't put the user's identity in the story title. My stories also are bigger than some agile methodologies suggest. Usually, I start with a title. I use it for planning purposes. Once I get close to actually working on that story, I flesh it out with some details -- basic idea, constraints, assumptions, related stories -- so that I capture more of the information that I know about it. I also keep my stories in a wiki, not on note cards. I understand the trade-off -- i.e., I may spend too much time on details before I need them, but I am able to capture and share it with, typically, off-site customers easily.
The bottom line for me is that Agile is a philosophy, rather than a specification. There are particular implementations that may (strongly) suggest that you do things a certain way and may be non-negotiable on some items. For example, it's hard to say you're doing XP if you don't pair program. In general, though, I would say that most agilists would say that you ought to do those things that work for you, in the way that they work for you -- as long as they are consistent with the general principles, you can still call yourself agile. The general principles would include things like release early/release often, unit testing, short iterations, acknowledge that change will happen, delay detailed planning until you are ready to implement, ...
Bottom line for me: if the stories work for you without the user and rationale -- as long as you understand who the user is and why they want something -- do it however you want. Just don't require a complete specification before you start implementing.