Дневник цели
Arkency Team and Robert Pankowecki - Developer Oriented Project Management
Developers creating tickets Опять же сокращаем путь от идеи клиента до реализации и исключаем "поломанный телефон". Плюс присутствует понимание бизнес-проблемы и возможность найти наиболее эффективное решение нежели предложенное клиентом.
Specification as floating ticket Большие задачи можно хранить вместе с мелкими. Когда до большой задачи доходит очередь из нее выделяются более мелкие, а она сама уходит вниз в списке либо удаляется вовсе.
Working with tickets 1) Разделение больших задач 2) Критическая оценка задач 3) Общий доступ к артефактам у всей команды
Arkency Team and Robert Pankowecki - Developer Oriented Project Management
Chronos vs Kairos
Can developers be project managers?
Developers attitude В общем-то очевидные уже для меня вещи. Каждый может общаться с заказчиком, формулировать задачи, распределять приоритеты и самостоятельно контролировать процесс разработки. При желании )
Customer Meetings Если с клиентом общается исключительно ПМ, то получается единственная точка отказа в лице этого самого ПМа. Кроме того если разработчики сами общаются с клиентом, то исключается эффект "поломанного телефона".
Arkency Team and Robert Pankowecki - Developer Oriented Project Management
Story Of Size 1 Надо делить большие задчи на мелкие, занимающие не больше одного дня.
Forget About Sprints Спринты насколько я понимаю только в Scrum'е применяются. Но в той-же JIRA или PivotalTracker'е они присутствуют, хотя они прямо на Scrum не ссылаются.
Stream Of Work Не назначать задачи разработчикам - просто расставлять приоритеты. Разработчик закончивший задау берет самую приоритетную в списке. Это избаляет от специализации разработчиков на каких-то конкретных частях проекта. Из-за каких-то форс-мажоров важные задачи не зависют, как если бы они были назначены на конкретного человека.