Update on work, and then some geekiness
Sep. 13th, 2007 06:03 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bethlakshmiSo - first for the non-geeks that read this, I'll start with the general life stuff you don't have to read any further. If you don't read past the cut tags, you should be safe from too much technical jargon.
I am officially out of the market for a job. My company offered me my dream job out of the blue. With a manager I really like and a chance to make life pleasant around here. There's still alot about the corporation as a whole I don't like. But having my dream job - software task manager - makes up for a lot.
Plus the fact that the job hunt had sucked so badly that I had given up for a while in the hopes of defending what scraps of ego still remained mine. But now I'm not "taking a hiatus" from the hunt, but really and truly giving up.
The job is being a software task manager, and this time I get to be REAL one - responsibility for schedule, purchasing, and sign off of people's time cards. The other times I've done this, I've done most of the work, but it hasn't been my butt on the line. The project is with a manager I worked for 2 years back, who liked me so much he requested me and got me off another high profile project. The feeling is mutual, so I'm excited to have a manager I like so much.
People Hunt
Also on the work news front - my company is really staffing up in a hardcore way. We are looking for:
- people who have US security clearances (they will munch you up in a heartbeat, even if you have very little else)
- people who can get clearances (not being able to get a clearance is deal breaker - so if you aren't a US citizen, I can't help you) - if we have to get you a clearance, the bar is higher - we have to make sure you're worth having around for a year until the clearance comes in.
Other wishes:
- software people - Java, obj oriented design, web design, enterprise architecture experience, apps server knowledge, security system development knowledge
- systems people - geeks who look at networks, collections of software on a computer system, collections of computer systems - you gotta like hooking stuff up, reading and writing requirements, testing, breaking stuff, evaluating software and hardware - it's easily 50% or more writing, so if you hate writing, don't do this. Security knowledge is good for this. It can blend will with sys admin skills, but where as sys admins are constantly trying to keep a system running, this is a lot more formal and is more about design and less about keeping the users off your back.
This is very vague - but if you are interested, or have a friend who's looking, drop me a comment or email me at my bethlakshmi account on Gmail.
No, you won't be working with me... my project is a tiny flea compared to the elephant staffing needs we have right now... the chances of being on my project are pretty low. But I know the people in the know.
How agile can a govt contractor be?
That is the question I have today for you geeky people who cared to read on. For the first time, ever, I'm in a position of enough power that I can say how we do the work. The project deliverables are loose enough that I can do almost anything. We don't have a design review, the system requirements are the only requirements we have to develop and they are done already. As long as we meet the system requirements in 2 years and pass the system tests then, we're good. Looking seriously at our tasks and deliverables, I see nothing that dictates waterfall model management.
AND I have a manager who like low process/ritual in favor of high features as long as the quality is there.
AND He has a lot of faith in me and my ability to be risk-averse.
I'm not sure I'll ever get a better time to try something wild and experimental (at least for our company).
The problem? I have never, ever done anything like Agile development. I know just enough of the principles to see why it could be a really good way to approach the elephant of a project we have on our plates, but I also know that implementing a new process that no one's ever heard of
(in this company...) is very risky. I have to get it by the process people (we have people who's job it is to make sure you do things in a quality and process-oriented manner), which means I need a really good strategy for this. They will let me do wild stuff, but only if my wacky idea is planned out and well-considered.
We're getting a IDE tool that I think could be very helpful - JBuilder. It looks like it has a strong focus on integration of design, code, builds and unit tests - which seems vital for agile development.
So.... I have some questions for the few of you I know have read down this far...
- What are some good books or sites for getting into agile? I'm especially looking for guidance on agile practices and how to pick and choose what will work for your company.
- What are the biggest pitfalls of agile development? I have a pretty small team right now - 4 people. It could double, but I don't see this being very big.
- Where do I start. I've got this requirements document (it definitely qualifies as "barely there") and a ConOps. How can I digest this for my team to give us a place to start?
- Is it possible to survive with minimum customer contact? I've got systems engineers who can give some external insight into the system, but I won't have access to actual users until the end of the project. 1 year in I might manage a demo or something. We have so many features, though, that we could stay busy without customer feedback... but is that all bad?
- I'm kind of thinking that one way to approach this would be to segment out a small number of system requirements and view them as features. Use this subset to develop the first little increment. Repeat process by adding more and more features to the product, first making sure that the system does the major threads and then branching out into the diverse scenarios we have to support. Is that crazy?
- How does agile design work? My biggest fear is that if we don't design for the massive complexity of some parts of the system, the pain of refactoring will be more than we can handle later. How do we avoid that?
I'm writing the Engineering Management Plan soon, so now is the best time to figure this out.
I will gladly take you out to dinner if you have have agile management experience to share and will let me pick your brain. :)
I am officially out of the market for a job. My company offered me my dream job out of the blue. With a manager I really like and a chance to make life pleasant around here. There's still alot about the corporation as a whole I don't like. But having my dream job - software task manager - makes up for a lot.
Plus the fact that the job hunt had sucked so badly that I had given up for a while in the hopes of defending what scraps of ego still remained mine. But now I'm not "taking a hiatus" from the hunt, but really and truly giving up.
The job is being a software task manager, and this time I get to be REAL one - responsibility for schedule, purchasing, and sign off of people's time cards. The other times I've done this, I've done most of the work, but it hasn't been my butt on the line. The project is with a manager I worked for 2 years back, who liked me so much he requested me and got me off another high profile project. The feeling is mutual, so I'm excited to have a manager I like so much.
People Hunt
Also on the work news front - my company is really staffing up in a hardcore way. We are looking for:
- people who have US security clearances (they will munch you up in a heartbeat, even if you have very little else)
- people who can get clearances (not being able to get a clearance is deal breaker - so if you aren't a US citizen, I can't help you) - if we have to get you a clearance, the bar is higher - we have to make sure you're worth having around for a year until the clearance comes in.
Other wishes:
- software people - Java, obj oriented design, web design, enterprise architecture experience, apps server knowledge, security system development knowledge
- systems people - geeks who look at networks, collections of software on a computer system, collections of computer systems - you gotta like hooking stuff up, reading and writing requirements, testing, breaking stuff, evaluating software and hardware - it's easily 50% or more writing, so if you hate writing, don't do this. Security knowledge is good for this. It can blend will with sys admin skills, but where as sys admins are constantly trying to keep a system running, this is a lot more formal and is more about design and less about keeping the users off your back.
This is very vague - but if you are interested, or have a friend who's looking, drop me a comment or email me at my bethlakshmi account on Gmail.
No, you won't be working with me... my project is a tiny flea compared to the elephant staffing needs we have right now... the chances of being on my project are pretty low. But I know the people in the know.
How agile can a govt contractor be?
That is the question I have today for you geeky people who cared to read on. For the first time, ever, I'm in a position of enough power that I can say how we do the work. The project deliverables are loose enough that I can do almost anything. We don't have a design review, the system requirements are the only requirements we have to develop and they are done already. As long as we meet the system requirements in 2 years and pass the system tests then, we're good. Looking seriously at our tasks and deliverables, I see nothing that dictates waterfall model management.
AND I have a manager who like low process/ritual in favor of high features as long as the quality is there.
AND He has a lot of faith in me and my ability to be risk-averse.
I'm not sure I'll ever get a better time to try something wild and experimental (at least for our company).
The problem? I have never, ever done anything like Agile development. I know just enough of the principles to see why it could be a really good way to approach the elephant of a project we have on our plates, but I also know that implementing a new process that no one's ever heard of
(in this company...) is very risky. I have to get it by the process people (we have people who's job it is to make sure you do things in a quality and process-oriented manner), which means I need a really good strategy for this. They will let me do wild stuff, but only if my wacky idea is planned out and well-considered.
We're getting a IDE tool that I think could be very helpful - JBuilder. It looks like it has a strong focus on integration of design, code, builds and unit tests - which seems vital for agile development.
So.... I have some questions for the few of you I know have read down this far...
- What are some good books or sites for getting into agile? I'm especially looking for guidance on agile practices and how to pick and choose what will work for your company.
- What are the biggest pitfalls of agile development? I have a pretty small team right now - 4 people. It could double, but I don't see this being very big.
- Where do I start. I've got this requirements document (it definitely qualifies as "barely there") and a ConOps. How can I digest this for my team to give us a place to start?
- Is it possible to survive with minimum customer contact? I've got systems engineers who can give some external insight into the system, but I won't have access to actual users until the end of the project. 1 year in I might manage a demo or something. We have so many features, though, that we could stay busy without customer feedback... but is that all bad?
- I'm kind of thinking that one way to approach this would be to segment out a small number of system requirements and view them as features. Use this subset to develop the first little increment. Repeat process by adding more and more features to the product, first making sure that the system does the major threads and then branching out into the diverse scenarios we have to support. Is that crazy?
- How does agile design work? My biggest fear is that if we don't design for the massive complexity of some parts of the system, the pain of refactoring will be more than we can handle later. How do we avoid that?
I'm writing the Engineering Management Plan soon, so now is the best time to figure this out.
I will gladly take you out to dinner if you have have agile management experience to share and will let me pick your brain. :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
I Am Not Agile, But...
Date: 2007-09-13 11:32 pm (UTC)Re: I Am Not Agile, But...
Date: 2007-09-14 01:59 am (UTC)By the time my company agreed to pay for it, I was already slated to go to Augusta, GA for another type of training. This one being customer-domain related, and also important.
I am sending one of my people, though, and she and I worked out a schedule that includes quite a few of the agile courses, including one that may very well answer all these... but I also figure that if I get interesting answers here, I'll add further thoughts to my list of things I'd love for her to get answers on...
no subject
Date: 2007-09-14 01:34 am (UTC)no subject
Date: 2007-09-14 02:02 am (UTC)What version of JBuilder did you use? I'm getting a feeling that 2007 is different from 2005... But don't have a heck of a lot of info on it.
Given that the last thing I used was JDeveloper from 2003 or so, the whole field has changed a lot and I don't really have time to do a full analysis, since we really needed to have purchased the tool last week.
no subject
Date: 2007-09-14 02:06 am (UTC)thier offices are in CA and NJ and i think the chezk republic...
no subject
Date: 2007-09-14 02:39 am (UTC)What are some good books or sites for getting into agile?
It's worth getting Extreme Programming Explained, because it's a fine overview of one end of the spectrum. You don't have to do all the pieces in XP, but the book does a decent job of giving the rationale of why each is helpful. Note that this is mainly focused on the technical development side; a lot of folks like to get into Scrum for the day-to-day management. (I don't know Scrum nearly as well.)
I absolutely recommend Mike Cohn's book on writing User Stories. It's really been the bible of our agile process, and how well things are working at any given time seems directly related to whether or not we're really paying attention to it.
What are the biggest pitfalls of agile development?
The biggest specific pitfall, I've found, is simply getting peoples' heads around the idea. One speaker I heard last year said that it takes about six months of hell to get an agile process working really smoothly; that's proven more or less true at Convoq. (It wasn't the case at Buzzpad, but that was probably because the CTO was driving the process, and had a very clear vision of how he wanted it to work.)
How can I digest this for my team to give us a place to start?
Especially in a low-customer-contact environment? I'd recommend *not* digesting it too much. Have the team work together on the project. Work jointly to break the thing down into stories. While story-driven development isn't essential for agile, I find it a very productive way to work.
Working with minimum customer contact *will* be a bit tough, but mostly in that it tends to lead down dangerous paths. It's actually very, very easy to work without customers -- it just often leads to developing the wrong things. So *someone* will need to play the customer representative, and will need to be authoritative within the process, empowered to make decisions. (In our case, we hired a Product Manager specifically to play this role -- she's not a customer per se, but she is specifically empowered to speak with the voice of the customer.)
Is that crazy?
No, it sounds about right. The key thing is the "slice of cake" model. You want to cut a thin but complete slice of the entire system to start with -- it should *do* almost nothing, but it should do it all *right*. Then you add features to that. (We've just finished that first "slice" on our new project, in fact; next iteration we start to make it useful.)
How does agile design work?
The key is to design *enough*, and then stop. It takes some practice, but you develop an instinct for it. I've found that the thing to do is to design very sketchily until I start feeling vaguely comfortable with the architecture, then slam out draft APIs between the pieces. That helps define what the responsibility of the pieces are, and gives everyone some guidance for coding. From that point, refactoring to get the fine details right isn't usually too hard. Remember: refactoring *within* a component is usually fairly easy. The hard bit is changing what those big objects are. So if you can get the big objects roughly correct upfront, the rest shouldn't be too awful.
That's a very quick start, anyway. Grab me sometime, and let's chat...
no subject
Date: 2007-09-14 03:55 am (UTC)no subject
Date: 2007-09-14 04:23 am (UTC)no subject
Date: 2007-09-14 12:54 pm (UTC)no subject
Date: 2007-09-14 01:15 pm (UTC)first it is free.. and very robust, hundreds of useful plug-ins
and from my mgr.. look for book extreme programming installed
totally unrelated to this post - sorry
Date: 2007-09-27 04:41 pm (UTC)A couple of months ago, my daughter borrowed an outfit to wear to a Pakistani wedding. We still haven't had it dry cleaned (or
whatever would be appropriate). What technique *would* be appropriate? She asked her friend (these are college aged women) who didn't answer.
I hand wash many items that say "dry clean only" but would hate to ruin this.
A photo is here:
http://www.flickr.com/photo_zoom.gne?id=1140587697&size=l
Thanks for any information.
Re: totally unrelated to this post - sorry
Date: 2007-10-19 02:29 am (UTC)If you're very concerned - especially since it's a loan - I'd suggest dry cleaning. It looks like it has raised embroidery - which will definitely not fair well in a machine. Often times Indian dyes will run pretty badly - a hand wash may not prevent the dye bleeding in unexpected ways. I've had saris bleed and then restain themselves with their own dye.
I've never had dry cleaning do me wrong, so that would be my best guess.
no subject
Date: 2007-11-26 12:20 pm (UTC)giggle
Date: 2007-11-26 05:07 pm (UTC)Usually I'm a Far Side kinda girl, but that one really tickles me.
...hmmm.... maybe I can dig up the "well boys, its clear we're not rocket scientists" from the Far Side to balance out the Dilbertness.