Метод определения сроков выполнения проекта по Бобуку-Бацеку

Scrum

Недостатки Getting Things GNOME!

В Getting Things GNOME! не хватает возможности сделать зависимость задач друг друга. Т.е. например, переходить к задаче 5, только после решения задач 1 и 3. И чтобы это учитывалось при сортировке задач. Чтобы сначала шли задачи 1 и 3, а уже потом только 5.

Сейчас я насколько понял Getting Things GNOME! сортирует задачи в зависимости от их срока. А у меня сроки неопределенные. Я могу какую-то задачу всю жизнь делать.

Хороший тимлид - лучший друг программиста

Возможно единственный.

источник

Принцип проектирования наудачу

Многие руководители начинающих веб-компаний действительно применяют удивительно простой принцип проектирования наудачу. Они создают клон какой-нибудь древней программы, разработка которого почти не требует затрат времени, и демонстрируют результат пользователям. Затем они выслушивают жалобы и отзывы, оценивают сценарии использования программы, дорабатывают слабые места и снова выпускают программу на рынок. Программистам, как правило, итеративный метод не слишком нравится, поскольку увеличивает объем их работы. Но итеративный процесс обычно нравится именно руководителям, слабо знакомым с технологией, поскольку этот процесс освобождает их от необходимости тщательного планирования, от размышлений и от необходимости усердствовать (иными словами, от проектирования взаимодействий). И конечно, дороже всего за подобное отношение платят пользователи. Им приходится продираться через одну за другой вялые попытки авторов, пока они не получат наконец программу, сносную в использовании.

В штате Instagram 13 человек

У Instagram очень маленькая команда разработки — и тратить её время на то, что уже сделано, было бы попросту нерационально. Всего в штате Instagram 13 человек. Разработкой занимается ещё меньшее количество сотрудников. По словам создателей сервиса, небольшой команде легче сосредоточиться, кофмортнее общаться и удобнее работать.

источник

Техника «Код – в последнюю очередь»

Том ДеМарко “Deadline. Роман об управлении проектами”

Минимум сорок, а скорее шестьдесят процентов времени должно уходить на низкоуровневое проектирование – неимоверно тщательное и детализированное. Низкоуровневое проектирование – единственная реальная вещь во всем проекте. В этом случае, необходимость в отладке программы настолько снизится, что команда сможет существенно сэкономить на этом время.

В таком случае, если проект был рассчитан на год, то на кодирование отводится лишь последние два месяца перед выпуском.

Утверждён профстандарт менеджера ИТ-продуктов

источник

Министр труда Российской Федерации утвердил профессиональный стандарт Менеджера продуктов в области информационных технологий, который в 2013-м году разработала рабочая группа Школы управления продуктами, сообщил основатель школы Денис Бесков. 

Стандарт может стать основой для разработки:

• Должностных инструкций;
• Текстов вакансий;
• Корпоративных профилей компетенций;
• Планов профессионального развития;
• Сертификационных программ и тестов;
• Коммерческих учебных программ;
• Федеральных образовательных программ.

С текстом стандарта можно ознакомиться по ссылке (*.pdf). 

Над стандартом работали: Владимир Батаев (EsperantoXL), Денис Бесков (Школа управления продуктами), Михаил Бутлицкий (KamaGames), Алексей Жук (Enkata), Михаил Карпов (Яндекс), Антон Катков (Flexis), Роман Седых (Whitescape), Андрей Сыцко (Anturis), Дмитрий Школьников (Mail.ru), Владимир Червоненко (NPTV / Digital October).