It seems to me that any good process should provide assistance in four basic areas.
Predictability is important because you want to be able to tell people approximately how long something will take. Quality is important for obvious reasons. Throughput, the amount of work you get done, should be positively impacted, and morale should go up if your process in a competent one.
Agile is handy for the above if you can create a meaningful velocity because it serves all four areas. If you can effectively break down and point stories and have a meaningful velocity, you can tell people more accurate information about when you will be done. If you effectively break down and point stories and have a meaningful velocity you can measure throughput and know if changes you make increase or decrease your throughput. If you effectively break down and point stories with the input of test and business stakeholders quality should theoretically improve, as well as predictability as stakeholders are more likely to get what they are asking for. If you effectively break down and point stories, and involve all team members as equals, morale is likely to be high.
Stand up meetings are nice, but that does not make for effective Agile. What makes for effective agile is tracking and maintaining an effective velocity. To do so means you are effectively breaking down work into stories that testers and business agree are of value and are done. Agile is really organizing yourself so you can create and track a meaningful velocity. By doing this good things collaterally happen. If you have stand up meetings, and scrum masters and task boards and no velocity you are doing something, but it isn’t Agile as far as I’m concerned. Have only the meetings and artifacts required to track and maintain a meaningful velocity and the rest will take care of itself.
When a group says they embrace Agile, ask them what their team’s velocities are and how long they’ve tracked them. If blank stares are the response, then run.
Have an interesting circumstance. If you are using an Agile/Scrum approach what I have seen historically is that each dev team has a backlog. Different projects funnel stories into the one team backlog. This allows you to clearly see the amount of work the team is tasked with doing. My current client insists on having a backlog for each project and sprint, so there is sort of a Cartesian product of backlogs.
I can understand how it may make project management activities easier, but it has only served to confuse me as far as understanding what work the team is currently and future tasked with. I mentioned my questions, but the client assures me they know Agile and this is how Agile is done. It has been interesting to compare this approach to others I have seen. So far it seems to muddle the concept of a sprint as sprints have no start and end date, they end when all the work for the project/sprint backlog is done. If it works better than one team backlog I’ll be down with it and waiting to see how it all turns out to make that determination.
We have finally started automating our functional testing. We have a large .net based web application and after much time I have convinced the powers that be that we should be creating selenium tests when we test new functionality so that we can retest that functionality later with the push of a button.
So first had to overcome creating same state for tests when they began, then had to overcome functionality common tasks. And now we are trying to automate the automation and have our selenium tests run on our build server. I’m all for it, but it is not easy.
Having issues as only headless browser that seems to work in a windows environment is PhantomJS. This would be ok except some of our tests send files down by changing content-type header, and PhantomJS doesn’t yet support this.
Trying to see if we can run Chrome headless, or setup a server somewhere to run tests so doesn’t matter if headless or not. Will update where we get to.
ASP.NET 5: How to Get Your Cheese Back
Surprised by how much has been changed in ASP.net 5. I think the changes are good, but concerned about lack of backward compatibility. MVC is now free of system.web so can be deployed sans IIS.
- ASP.net 5 is entire rewrite
- All files are part of project have to exclude what don’t want
- Unified dependencies
- can set dependency by framework
- Project file is not .json
- Configure method in startup, similar to owin and katana
- New concepts
- Command line tools
- dnvm: dot net version manager
- manages the versions of .net on your machine
- Can assign different framework version to different processes running at same time
- dnx: dot net execution environment
- dnx run will run your application
- dnu: dot net utility
- Command-line first development ?
- Modular, Composable HTTP Pipelie
- pipeline is entirely empty to start have to add everything
- good since don’t have to pay the price for things you don’t use.
- in startup configure method you add to the pipepline what you want
- Dependency injection all the way down
- built in container get swap out with your favorite
- ConfigureServices method in stratup used to config DI
- ConfigureOptions<T>, syntax for configuring, like identity
- in startup you tell app where and what kind of config files exist
- configurationmanager is all gone, where it was used you need to change
- Unified mvc and webapi
- removed mvc dependency on system.web
- Code editor agnostic
- Cross platform now
- can run windows,linux, osX
- kestrel web server is supported
- Can be dockerized now