Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Monday, July 17, 2017

, , , ,

Differences between Product and Software Development Life Cycle

I wish I have had more time to write. I have been busy with work, but it is almost equally important that I keep this thing current. At least, until the bills come.

I have been working with Kanban and “safe” projects: project that I can estimate without difficulty based on past experience. With Scrum, it is a bit easier to map out sprints and assign estimations to User Stories in order to give an estimate. Every CFO will want an estimate (or a QUOTE, really).

Kết quả hình ảnh cho Kanban

And this is what I want to point out in what amounts to a very poor excuse of a blog update: I am finding that Kanban works great for projects once the development process can begin, but until then, the board is not very useful. This may be obvious, but really, I like to start at the very beginning for every effort and I have found that even my swimlanes are changing based on the Client. This winds up being a symptom of deliverables, as dictated by a contract or project plan. Yes, I still do project plans when I am asked to, which is usually. I stay high level, or as high as I can get away with to avoid making even hints at a promise I cannot keep, but I can bust out a GANTT chart if the situation calls for it and because people like them. In truth, it never hurts to have a big picture view on the wall, however much it changes. It is almost like a snapshot of the initial vision. Well, it is.

Agile is a philosophy and not an SDLC or a PLC

Hình ảnh có liên quan

Since Agile is a philosophy and not an SDLC or a PLC, kanban fits nicely into an agile SDLC. Scrum extends a bit more into the PLC realm because of the structure and collaboration, scheduling, and metrics that it affords.

Again, I am finding that having a full toolbox is not as important as knowing what tools to use. Estimates will come from experience, and not the kanban board. They will come from whatever formula you have leveraged against the scope of work you are looking at.

Kanban aims to keep things moving and remove restrictions associated with sprints. It seems to do this well, but it also requires, in some cases, a little bee buzzing around and keeping an overall eye on things. Project Managers, there is still a use for you. PMs who only manage budget and resources as though a project is made of lego parts are not getting the full picture. The project is a living, breathing, flowing thing that kanban fits quite nicely with.

It is interesting to me that as “traditionalists” resisted agilie, some “agilists” are resisting kanban. Most of the time, these are not really agilists, but Scrum or XP practitioners. There is a big difference. A very important difference.

When a kanban flow begins, it also creates metrics. Unlike other methodologies, there is *mostly* new information gathered with these metrics. I am reminded of good old PMI when I say that these metrics become inputs into future estimates. Still, kanban does not create estimates and does not demand them. It only allows processes to flow.

Difference between sdlc and pdlc

A PLC,  pdlc product development life cycle is not an SDLC, and Agility is not Scrum or Kanban or anything in particular. I find it at once interesting and horribly bothersome that as more and more people are focusing on agile methods, two schools are forming; there are those who think Agile deserves and has a place for a maturity model, and there are those who are making things more and more simple, less formal, and just DOING. We start learning how to DO when we are young. Somehow, DOING got us to where we are. We did not predict every twist and turn, and few of us actually executed whatever plan we had in mind when we were in our early teens or even early college years. This is brilliant, and this is the way life works. Why should building software be any different? With Lean development, we learn to not have too much on our plate and only take what we need. With Scrum we learn to work as a team and keep moving forward knowing that we dont know everything. With Kanban we learn to keep it moving and lean on each other, as though the team is a body where sometimes, yeah, you can scratch your leg with your foot if your hands are busy.

I love simplicity. It tends to creep into my mind often that the more complicated something is, the further from a central truth it is. I like truth. I like few integration points. I like the fact that kanban seems to be very good at DOING, and that it can be wrapped in whatever presentation layer is required. I think it belongs in every IT Project Management and IT Team Lead’s toolbox. Right next to the “I don’t know but will find out” and amorphous hat. Top shelf stuff.

I am not a fan of sticky notes, though. This is a problem. They lose their stick too quick. Remember Fruit Stripe gum? Tasted great for about 15 minutes and then you kind of just chewed it. I get about 15 minutes out of a sticky note. Might have a bad batch? This is a fairly new expedition for me, but looking back, I cannot say I have ever had luck with sticky notes. Maybe that it a metaphor unto itself. I am far too sleepy to attempt that dissection at this moment.

Point is, kanban as an SDLC wrapped in a custom PLC seems optimal to me at this moment.

0 nhận xét:

Post a Comment