Технічні деталі розробки великого проекту в гетерогенному середовищі програмістів поділених на команди використовуючи git, gitorious.

Переклад "Why Scrum will never work". В принципі, для українських реалій стаття не дуже актуальна, але, можливо, для народу з софтсерву та глобалу це буде погляд «з іншої сторони барикад».

Почавши з такого провокативного заголовку я мушу одразу заявити про кілька речей. Усе написане тут — це тільки моя особиста думка, і аж ніяк не мого роботодавця. Якщо у мене взагалі ще будуть роботодавці після цього посту. Ще я захоплююсь Скрамом та іншими гнучкими методологіями. Я ними на життя заробляю. Гм, сформулюю точніше: мене на 100% влаштовує використання скраму в процесі розробки програмного забезпечення.

З формальностями покінчено, далі я буду серйознішим. Мені подобається методика Скрам. Я її використовую впродовж п’яти років, робив кілька презентацій щодо роботи розподілених скрам-команд на конференціях, написав якусь статтю у співавторстві з гуру Скраму Jeff Sutherland і так далі. Втім, наразі вже пройшло десять років з чаму проголошення Agile Manifesto. Час одягнути чорного капелюха та пояснити, чому скрам ніколи не буде ефективним.




( Читати далі )

Загальновідоме правило 80/20: 80% функціональності пишеться за 20% часу, решта 20% — за 80% часу.

Оце нещодавно трапилась ситуація, коли написав, на око, 80% деякого функціоналу, і по тому вирішив занести його у баг-трекер. А коли виставляв оцінку по часу, згадав про це правило. Якось, ніби, дивно, коли зробив майже всю задачу за півдня, а щоб доробити до кінця, пишеш в запас ще два дні, а не пару годин. Мені, в таких випадках, якось звичніше залишати в запасі, хай не 20%, нехай 30-50% від витраченого часу — але ж не 200%! Зажирно, знаєте.

Можливо, це правило не діє для маленьких, fine grained tasks, які можна «охопити одним поглядом»? Коли 20% — це лише «обробити напилком», а не, скажімо, «причепити бегемоту вуха, хобот і ще якусь дивну штуку, яку хоче замовник».

У кого які думки?

Думаю, що досить часто серед програмістів зустрічається проблема оцінки часу, що буде витрачений на розробку проекту, або того чи іншого компонента. За посиланням можна почитати досить розумні думки що до причин невірних оцінок часу та методи уникнення несвоєчасного завершення проектів.

Ось таке цікаве питання:

Чи попадались вам замовники, у яких всі внутрішні проекти здавались вчасно?

В буквальному розумінні — в той самий день коли планували і не на день пізніше.

Цікаво почути відповіді і думки по цьому поводу.