Development methodologies one more time

Hello everybody,

Today I want to write a few words regarding different development methodologies in plain English. 

1. Lean. Lean is methodology of entering on the market. If you ever heard term MVP ( minimal viable product ), then it's origin is from Lean. It says that you don't need to create some huge product and jump on the market with such a huge product. Because if you'll write it for three years, market will say: uhhh, it's second hand outdated product. And even if you'll spend 10 million $ on that, market will say: I don't care. Throw it. Also it say that it is close to useless to quiz your customers. Because you quiz your users/customers, and they tell you some kind of crazy staff. There is famous story of company Sony, which wanted to make famous player. They surveyed their focus group which color they prefer. Members of group said we want red, green, purple. While near the exit everybody from focus group took black players. Why? Also nobody named black color. 

2. Kanban. Kanban speaks that we need to move tasks in visible manner. There is a ribbon on what we have in plan, what we are currently working on, what was delivered. Also Kanban says that we move tasks from one point to the other. This is actually all essence of Kanban. Please keep in mind that I give oversimplified version, mentioning only outside attributes. 

3. Scrum. Scrum says that you need to split your torrent of tasks into iterations. You need to group your tasks into something, that after it's completion will provide some value. And iteration after iteration you move to your goal. It is not very convenient ( as usually ) for developers, because as usually developers don't like to have their code tested. But that is good from business prospective. Business sees that each time you have incremental increase of functionality. And it's stable and works constantly. As additional bonus business will not loose much if market suddenly will change. 

4. Extreme programing. In it's pure form ( as proposed by Kent Beck ) it almost never used. For example extreme programming teaches that all code is written in two heads and four hands. Code is 100% covered by five types of tests. And so on. Name speaks of itself: extreme programming. I never seen such a think. As a developer I want to admit that physically it is hard to work with someone always. It is also hard to cover everything with 100% testing. 


Development methodologies

Hello everybody.

Today I want to make a post about list of development methodologies. How much of them you can name? Agile/Scrum, Waterfal. Which else? Take a look at list that I've discovered for myself:

  1. Waterfall
  2. Prototype
  3. Agile
  4. Rapid Application Development
  5. Dynamic System Development Model Methodology
  6. Spiral Model
  7. Extreme Programming Methodology
  8. XP
  9. Joint Application Development
  10. Lean Development
  11. Scrum


How many of those you know/tried/practiced?

Some notes on Jira usage

Hello everybody,

today I want to make a short recording of the following video: Introduction to Jira & Agile and Project management.

Actually I just want to have short text version of Dan Chuparkoff's  advices.

  1. Task is something that is bigger then 30 minutes but smaller then 3 days to complete. It is practical don't have tasks that take more then one day to do.
  2. You can't wait in the middle of the task. If you are waiting in the middle of the task, then take another look, maybe you have series of tasks. 
  3. You can be in three modes: in progress, done, not started.
  4. Estimating is hard, but use estimates. And use story points, not the hours. 
  5. There are different kinds of story points. 
  6. If you want other team members to see some additional fields during issue creation, you can configure them. 
  7. Scrum and Canban are subsets of Agile
  8. Scrum is more concentrated on date of release
  9. Batches of work in scrum are named sprints.
  10. Kanban is concentrated on what is delivered without strict deadline in mind. It means that in Kanban there is not plan, no sprints.
  11. Jira has Plan mode for scrum sprints
  12. You can tag your tasks with some labels. For example tag books you need to read. 
  13. You drag staff from Backlog to next sprint.
  14. As usually sprints length is two weeks. One week sprint is to small. You start and stop to often.
  15. For dependencies you can link tasks together
  16. Create Epics first
  17. To start spring, click at button start spring
  18. You can extend workflow with additional steps (  one of the customers of Dan has 8000 stages in workflow)
  19. You can create quick filter in order to see tasks for what you need.
  20. For sprint you can pull tasks from differnt Epics
  21. In each sprint try to move a bit all of your epics
  22. Burndown is idea that a lot of people try to look for results.
  23. Burndown has two lines: red is how your team actually going, and other shows how it should work in ideal
  24. You can make differnet kinds of search, even with JQL ( Jira Query Language )


Some explanations about some points which are not straight forward.

For point 1. If your task will be not bigger then 1 day then you'll have opportunity to shuffle your tasks every single day. But if your tasks are bigger, say 2 or 3 days that you'll be able to shuffle your tasks every 2 or 3 days. 

For point 4 and 5 Dan makes some kind of story point cheating:

30 minutes = 1 story point

1 hour = 2 story point 

2 hours = 4 story points 

4 hours = 8 story points

1 day = 16 story points

2 days = 32 story points

3 days = 48 story points

The more you practice in making estimates the better you'll become in making realistical estimates. 

Make sure that your team has the same estimates between each member in order to have the same measurement approach. 

For points 22 and 23 following additions. Don't add to much tasks to your sprint. Otherwise your burndown chart will not look nice. Second advice is make a big tv, visible to everybody in your team. That will help your team to see how they are doing and encourage them to close their tasks not prior to the end of the sprint but sooner.