DAILY
Require written standup reports each day. Read ALL standup reports. If someone did not write a standup report, contact them by chat or email, and escalate if they do not respond.
Attend a daily chat. Ask for comments and issues. Make it short. Move long discussions offline.
Resolve any needs or roadblocks posted in StandUp by a team member in the scrum chat.
Look at the detailed activity report for each developer.
Move any request, agreement to a ticket/message/wiki. Do not rely on chat agreements because they can’t be tracked.
Let team members select their own tasks. Balance load. Do not let team members work on many tickets concurrently. A team member should select one or two tickets to work on and finish. The rest are available for others to select.
If someone has been working for several days on one ticket, without committing, ask him to split it into smaller tasks.
WEEKLY
Review all tickets for the current milestone. Add or move depending on schedule and capacity.
Ask specific developers to take the planning and task breakdown for complex tickets, features, stories. To distribute the load, you should also be getting mockups and stories/scenarios from a non-developer product owner.
Write and post a message about what the team did last week and what the team will do next week – a sort of scrum of scrums report
BI-WEEKLY TEAM BUILDING
Look at new developer applications and say who you are interested in. Someone else should handle the details of finding new candidates and then getting them started.
Do “onboarding”. Make sure each new developer has the information he needs, a development environment, and a simple task. Help the new developers to update the setup documentation. Send them contact information and an outline of the daily requirements (standup, chat, commits).
Evaluate trial developers near the end of the trial period. Look at all of their work, and evaluate productivity and quality. Write a little review. Say whether you want to continue working with them.
оригинал
Showing posts with label процесс. Show all posts
Showing posts with label процесс. Show all posts
Thursday, December 8, 2011
Friday, December 2, 2011
Lean For Mechanics – LeanGiving in the Real World
Visualize the work flow and limit each mechanic’s work
Have nightly check-ins to plan for the next days work
Conduct retrospectives at the end each week for continuous improvement
First, expert mechanics were doing low cost, routine jobs like oil changes instead of high performance jobs that brought in more revenue.
Second, mechanics spent overhead time ordering parts (instead of the service manager) rather than revenue generating time working on cars.
Third, a large backlog of cars were stacking up waiting for a mechanic to become available.
оригинал
Have nightly check-ins to plan for the next days work
Conduct retrospectives at the end each week for continuous improvement
First, expert mechanics were doing low cost, routine jobs like oil changes instead of high performance jobs that brought in more revenue.
Second, mechanics spent overhead time ordering parts (instead of the service manager) rather than revenue generating time working on cars.
Third, a large backlog of cars were stacking up waiting for a mechanic to become available.
оригинал
Thursday, December 1, 2011
Why Software Projects are Terrible and How Not To Fix Them
Shouldn’t a little startup using XP be able to wipe the floor with bad companies in an hour? If all it takes is better engineering practice, shouldn’t the better engineers always win?
our industry’s best practices don’t make sense. I don’t mean, of course, that they aren’t objectively better–of course they are. But they are nonintuitive.
If the guy you’re talking too is thinking “This sounds like a really good idea but I’m concerned I can’t sell this upstairs,” you are dead in the water.
Put yourself in the middle manager’s shoes. If the project goes bad, he has to “look busy”. He has to put more developers on the project, call a meeting and yell at people, and other arbitrary bad ideas. Not because he thinks those will solve the problem. In fact, managers often do this in spite of the fact that they know it’s bad. Because that’s what will convince upper management that they’re doing their best.
My second theory is that business objectives can change faster than anyone can react.
Jobs was fired in 1985, but he was re-hired in 1997. That is twelve long years before they admitted their mistake.
Reality is slow.
They want results today. They want a PowerPoint slide to present at the meeting upstairs in ten minutes that explains how the project is back on track. They don’t want a real solution, they want smoke.
Actually writing better software doesn’t matter. What matters is stats.
If a prospect objects to being involved in the testing, starts editing your contracts line-by-line in pencil, and starts talking about penalties for missed final delivery deadlines and bugs,
run.
CTOs in mainstream companies still believe in function point analysis.
I would like someone smarter than I, to produce a software formula that balances these factors: Speed to Market, Profit, Cost, Happy Customer, Happy Stakeholder, Quality, Performance, Keep your Job and Happy Worker.
оригинал
our industry’s best practices don’t make sense. I don’t mean, of course, that they aren’t objectively better–of course they are. But they are nonintuitive.
If the guy you’re talking too is thinking “This sounds like a really good idea but I’m concerned I can’t sell this upstairs,” you are dead in the water.
Put yourself in the middle manager’s shoes. If the project goes bad, he has to “look busy”. He has to put more developers on the project, call a meeting and yell at people, and other arbitrary bad ideas. Not because he thinks those will solve the problem. In fact, managers often do this in spite of the fact that they know it’s bad. Because that’s what will convince upper management that they’re doing their best.
My second theory is that business objectives can change faster than anyone can react.
Jobs was fired in 1985, but he was re-hired in 1997. That is twelve long years before they admitted their mistake.
Reality is slow.
They want results today. They want a PowerPoint slide to present at the meeting upstairs in ten minutes that explains how the project is back on track. They don’t want a real solution, they want smoke.
Actually writing better software doesn’t matter. What matters is stats.
If a prospect objects to being involved in the testing, starts editing your contracts line-by-line in pencil, and starts talking about penalties for missed final delivery deadlines and bugs,
run.
CTOs in mainstream companies still believe in function point analysis.
I would like someone smarter than I, to produce a software formula that balances these factors: Speed to Market, Profit, Cost, Happy Customer, Happy Stakeholder, Quality, Performance, Keep your Job and Happy Worker.
оригинал
The Joel Test: 12 Steps to Better Code
The Joel Test
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
оригинал
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
оригинал
Tuesday, June 28, 2011
черновик нового cobit. временно в паблик - хомячим товрисчи ;)
COBIT5 Framework ED-27June2011 http://bit.ly/l9a1kv
COBIT5 Process Ref Guide ED-27June2011 http://bit.ly/ldm3GS
COBIT5 Process Ref Guide ED-27June2011 http://bit.ly/ldm3GS
Wednesday, June 22, 2011
Статья - Как жить с дедлайнами
Visualise them
Сделайте их видимыми. Можно и щупательными тоже :)
Don’t fret out as they approach
A missed deadline is not the end of the world, but your boss/client will be happier if he knows you’ve given it everything you got
Не паникуйте при приближении часа Х. Просто делайте, пытайтесь и боритесь.
Plan ahead of time
If you don’t have a plan you’ll end up working twice as much as you would with a plan. And probably will add a few sleepless nights due to the anxiety of not knowing exactly what is left.
Break the big into the simple
Разбивайте. Прям пособие по ВБС :) Я бы все равно остановился на 8 часах, а не 3-4 дня.
Be flexible
Гибчайте. Аджайлисты оккупировали хорошее слово. Вспоминается цитата из Стратоплана: "Гибкость, которая не аджайл, а в изначальном его смысле"
оригинал
Сделайте их видимыми. Можно и щупательными тоже :)
Don’t fret out as they approach
A missed deadline is not the end of the world, but your boss/client will be happier if he knows you’ve given it everything you got
Не паникуйте при приближении часа Х. Просто делайте, пытайтесь и боритесь.
Plan ahead of time
If you don’t have a plan you’ll end up working twice as much as you would with a plan. And probably will add a few sleepless nights due to the anxiety of not knowing exactly what is left.
Планируйте (о, как неожиданно:)
Без плана вы можете сделать лишнюю работу или не сделать необходимую.Break the big into the simple
Разбивайте. Прям пособие по ВБС :) Я бы все равно остановился на 8 часах, а не 3-4 дня.
Be flexible
Гибчайте. Аджайлисты оккупировали хорошее слово. Вспоминается цитата из Стратоплана: "Гибкость, которая не аджайл, а в изначальном его смысле"
оригинал
Monday, April 18, 2011
Манифест, бл*ть!
Мы — сообщество программистов, которые вдоволь намучились с разнообразными методологиями разработки.
Нас уже тошнит и от экстремального программирования, и от Скрама, и от Канбана, и вообще от всего, что напрямую не связано с написанием блять кода.
Нам очень неприятно, что нас считают асоциальными дебилами, которые ничего не могут сделать без указания менеджеров. Нас просто бесит, когда нас заставляют заниматься парным программированием, передвиганием листочков по доске, утренними standup-митингами и другими дурацкими приседаниями просто потому что из 10 менеджеров в нашей конторе никто не умеет блять писать код (а какую-то видимость работы создавать нужно).
Мы выступаем за то, чтобы отказаться от всех существующих методологий разработки в пользу одной, самой простой и единственно верной. Эта методология называется «пиши код блять»!
Мы уверены, что вся хрень, написанная в первых двух колонках, абсолютно никому не нужна. Есть только одно дело, которым действительно нужно заниматься: писать код блять!
манифест Manifesto
Нас уже тошнит и от экстремального программирования, и от Скрама, и от Канбана, и вообще от всего, что напрямую не связано с написанием блять кода.
Нам очень неприятно, что нас считают асоциальными дебилами, которые ничего не могут сделать без указания менеджеров. Нас просто бесит, когда нас заставляют заниматься парным программированием, передвиганием листочков по доске, утренними standup-митингами и другими дурацкими приседаниями просто потому что из 10 менеджеров в нашей конторе никто не умеет блять писать код (а какую-то видимость работы создавать нужно).
Мы выступаем за то, чтобы отказаться от всех существующих методологий разработки в пользу одной, самой простой и единственно верной. Эта методология называется «пиши код блять»!
| Что говорят менеджеры? | Что им нужно на самом деле? | Что мы делаем в итоге? |
|---|---|---|
| Продуктивная командная работа | Сотни рабочих часов в неделю | Мы пишем код блять! |
| Качественные продукты | 100% покрытие кода юнит-тестами | Мы пишем код блять! |
| Учитывание пожеланий пользователей | Выполнять любой каприз заказчика | Мы пишем код блять! |
| Продукт должен быстро эволюционировать | Постоянные изменения требований и пустопорожние обсуждения новых фич | Мы пишем код блять! |
Мы уверены, что вся хрень, написанная в первых двух колонках, абсолютно никому не нужна. Есть только одно дело, которым действительно нужно заниматься: писать код блять!
манифест Manifesto
Subscribe to:
Posts (Atom)